Pull to refresh

Comments 24

Заголовок статьи: «Как готовят Kafka».

В статье про же Kafka только вот такое предложение:
Это, конечно же, Spark, Kafka и прочие популярные вещи. Это технологически.

И все.
Там было про кафку, но я вырезал в процессе подготовки. Сорри. В будущем буду аккуратней.
Какие проблемы откатить статью и дополнить? Или написать UPDATE?
Есть вопросы.
Задайте их при следующем интервью с архитекторами Сбербанка, если это будет возможно.
1. Зачем для спецпроектов Сбербанка использовали key-value хранилище Hadoop? Чем обосновывался этот выбор?
2. Можно ли обойтись без эффективного SQL для задач аналитики спецпроектов?
3. Что можно сказать об эффективности SQL в Spark SQL(и в других аналогичных решениях, построенных поверх хранилища key-value) по сравнению с реализациями SQL в реляционных СУБД?
4. Почему не использовались распределенные реляционные СУБД для этих задач?

В данном интервью есть не убедительные и не понятные рассуждения на эту тему
После наполнения Hadoop данными, думаю, опять всё переключится на продвинутую аналитику. Суть перехода от традиционных SQL-хранилищ к Hadoop, в том числе, и в том, чтобы можно было применять и более продвинутые методы анализа данных. Не просто SELECT сделать, а всё-таки подключить машинное обучение, применять нереляционные способы поиска, хотя бы те же полнотекстовые индексы, которые позволяют проще найти информацию во всём этом объёме. Это всё пойдет в сторону более глубокой аналитики — раз. И второе, то, где технологический процесс интересный — это realtime-обработка на Hadoop. Которая, думаю, будет развиваться просто в силу того, что с точки зрения банка есть потребность в ускорении процессов и в ускорении выдачи кредитов. Сейчас идут соответствующие инициативы, и они закатывают все IT-системы, в том числе — наш Hadoop. Это и мировая тенденция — на Big Data делать потоковые и более быстрые решения. Первой была техническая масштабируемость, а сейчас уже идут в сторону скорости. Мне кажется, как-то так.

В чем проблемы «подключения машинного обучения» к реляционным СУБД?
Почему нельзя использовать полнотекстовые индексы реляционных СУБД?
Почему нельзя поставить задачу (видимо, не простую) извлечения потоковых данных из реляционных СУБД?
скорость @ стоимость
скорость с которой генерируются данные и стоимость их хранения
Ну и хадуп это модно молодежно и т.д.
Есть даже мем: " Если у вас нет Hadoop значит у вас не bigdata"
с чего вы взяли, что у них key-value хранилище? у вас какие-то кривые представления о hadoop, spark и прочая
Archi_Pro
1. У Hadoop нет подавляющего преимущества по скорости сохранения сгенерированных данных по сравнению распределенными реляционными СУБД(в два, три и более раз). Скорее всего эти показатели сопоставимы.
2. Также у Hadoop нет подавляющего преимущества по стоимости хранения информации
2.1. Имеются бесплатные реляционные СУБД
2.2. Реляционные СУБД очень оптимизированы в вопросах использования дискового пространства для хранения структурированной и не структурированной информации. При тщательном изучении этого вопроса вполне может оказаться, что Hadoop уступает
3. А вопрос собственно в том, что если заявлено, что нужно разработать аналитическую распределенную систему, то как это можно делать без полноценного высокоэффективного SQL? Неужели такие решения выглядят модно, молодежно и современно?
Я вот тут молчал-молчал, да не могу хотя бы 1 коммент оставить. Дорогой, какая скорость сохранения сгенерированных данных, что ты говоришь-то. Вот если ты возьмешь in memory data grid, типа кэша на apache ignite, да ещё пофлушишь его на жесткий диск иногда в варианте gridgain, и запустишь на десяти тысячах серверов в ДЦ, вот это будет throughput. А реляционные БД вообще не для этого, они для того, чтобы работать с реляциями, и эта их способность приносит дичайший оверхед, благодаря которому ни одна из текущих реляционных баз не может нормально кластеризоваться (даже на сотни серверов в кластере уже всё). Поэтому люди берут разные интересные решения и сами, с болью, кровью и реками слёз, пишут масштабируемые мощные решения. Там Вадим где-то в середине текста говорит, что ни одна из существующих баз не справилась, им пришлось писать свою
из текущих реляционных баз не может нормально кластеризоваться (на тысячи серверов в кластере
Teradata может и у Oracle тож что такое есть
Но это все дорого очень дорого
З.Ы. А вообще я думаю что в Сбере тож не дураки сидят и если они выбрали хадуп значит это оптимальное решение для их задач. И думаю там намного больше экспертизы в этом вопросе чем у комментатора требующего SQL решения на опенсорсе. То есть человек уверен что лицензия на ПО в деле хранения данных что то решает а не покупка оборудования для дата центра
Настоятельно рекомендую всех, кому интересно данное обсуждение, набрать в поиске Google строку «Facebook использует MySQL».
Можно узнать много интересного. В частности, сколько тысяч серверов MySQL использует сейчас Facebook.
Также рекомендую набрать в поиске Google строку «Google использует MySQL»

Для тех, у кого мало времени, рекомендую прочитать очень короткую статью
habrahabr.ru/post/99884.
Разработка была инициирована в начале 2005 года Дугом Каттингом (англ. Doug Cutting) с целью построения программной инфраструктуры распределённых вычислений для проекта Nutch — свободной программной поисковой машины на Java, её идейной основой стала публикация сотрудников Google Джеффри Дина и Санжая Гемавата[7] о вычислительной концепции MapReduce[8]. Новый проект был назван в честь игрушечного слонёнка ребёнка основателя проекта [9]
Вы действительно считаете, что приведенные Вами статьи являются веским аргументом в обсуждении темы «Почему Сбербанк использовал для своей аналитической системы хранилище Hadoop, а не распределенные реляционные СУБД»?
Для Google работают их проекты поверх MySQL, а для Сбертеха работает GridGain/Ignite и Hadoop. Разные компании используют то, что выгодно для их бизнеса. Всё правильно.

Касательно статьи по ссылке: там CTO Facebook/Quora пишет: «В действительности, распределенные базы данных вроде Cassandra, MongoDB и CouchDB [3] не очень-то масштабируемы или стабильны. Например, парни из Твиттера пытаются перейти с MySQL'а на Cassandr'у целый год. Конечно, если кто-то расскажет про то, как он использовал любую из этих БД как основное хранилище на 1000 машин в течении года, то я изменю свое мнение.»

Это как раз тот момент, когда ему самое время менять мнение :-)

Если правильно помню, у Сбертеха целевая конфигурация расчитана на куда большее количество серверов, чем просто 1 тысяча. Это не какое-то теоретическое предположение или мечта, а реальная постановка задачи, с которой они живут. Для этого разрабатываются собственные кастомные решения. Точно так же как Cassandra когда-то была создана в недрах Facebook, Сбертех тратит многие годы на разработку своих собственных решений, позволяющих достигать фантастических результатов. И один год, о котором тут говорит Адам — вообще не срок. Oracle Database делался десятками лет, а тут предполагается сделать нечто еще более продвинутое.

Про решение Вадима у меня нет подробной информации. Но вот подробнее о деталях другого проекта (ППРБ) можно посмореть вот здесь: www.youtube.com/watch?list=PLVe-2wcL84b-Waky1nkWVSNHPg6eOQWU9&v=gE4FXjP0-Cc
По поводу количества серверов MySQL в Facebook рекомендую посмотреть статью habrahabr.ru/company/mediagrus/blog/182966, в которой приводятся следующие данные
Уже традиционно для крупных дата-центров информация о точном количестве серверов не разглашается, однако известно, что в 2008 года эта цифра эта составила 10 тыс. серверов, в 2009-м — 30 тыс., в 2010-м — 60 тыс. Согласно сведениям из разных источников, сегодняшнее количество серверов составляет от 120 до 180 тыс

Это данные 2013 года
Понятно, что количество MySql-серверов меньше.
И никакаих проблем с масштабированием.

1. Посмотрел рекомендованное Вами выступление Алексея Курагина и Александра Перковского.
1.1. В основном выступлении они заявили, что отрабатывают возможность(и видимо скоро это закончат) полного отказа от реляционных СУБД и переход к нереляционным способам хранения, которые они обозначили Local Recoverable Store. Это хранилище будет работать в связке с GridGain
1.2. На вопрос «Вы совсем хотите отказаться от реляционных СУБД?» они ответили, что для построения отчетов все-таки будут использоваться реляционные СУБД. Больше вопросов на эту тему не было. Зоопарк какой-то.
2. Вадим Сурпин похоже расcказывал о извлечении данных напрямую из Hadoop. И это полностью согласуется с докладом Алексея Курагина и Александра Перковского.
3. Поэтому самый впечатляющий факт из Вашей статьи, что такой большой объем очень сложной работы по спецпроектам Сбербанка удалось проделать, не использую ни одного оператора Select.
4. Очень интересно, чем это все закончится.
Надеюсь, что это не закончится. Будут пилить своё решение десятками лет — как Оракл :-)

Насколько понимаю, та часть ППРБ, про которую рассказывают Курагин с Перковским — это в основном OLTP и distributed storage. Было бы очень странно заниматься там аналитикой.

Аналитика как раз в руках других людей, включая бигдату Вадима
в реляционных субд туча лишнего, чего не столь уж нужно для задач dwh и анализа. таблички оракла в 25 гб длегко превращаются в 3-4 гб parquet файла. хадупам не нужно преобразовывать данные во всякие звезды и снежинки, там нет проблем поставить 100500 узлов и просто решать задачи в лоб вычитывая каждый раз всю историю всех транзакций на каждый чих за счет чудовищных ресурсов. с рдбмс такие фокусы не проходят: ораклы и мсскл требуют непомерных денег за каждое ядро, постгрес хреново масштабируется, не имеет кластера. есть варианты типа гринплум, там вроде лучше, но все равно там больше от реляционной бд — с ETL в звезды/снежинки, форейн кеи, индексы.
хадупы выглядят модно потому, что не отменяют конечному пользователю похожие на реляционные таблички, SQL и прочие привычные аналитикам вещи, при этом в параллель читают на 100500 узлах, которые не требуют лицензирования каждого ядрышка.
Вы забавно приводите свои аргументы:
1. Сначала рассказываете, как Вам крупно повезло с экономией дискового пространства за счет использования формата parquet. И уже в следующем предложении рассуждаете о ненужности звезд и снежинок, которые как раз экономят дисковое пространство.
2. Утверждаете, что PostgreSQL хреново масштабируется. И тут же рассказываете про кластер на 100500 узлах, в котором для получения результата нужно выполнить полное их сканирование.
А это как раз пример плохо масштабируемого кластера.
Кластеры, создаваемые на основе реляционных СУБД, редко когда доходят до такого полного сканирования всех узлов.
ничего забавного, просто вы похоже не задумывались ради чего эти снежинки и звезды, как внутри устроены рдбмс.
1. отказ от звезд не отменяет экономию пространства в паркетниках, лишь подчеркивают. хадуп может по разному, может как ваш постгрес, делать ETL и класть в звезду. эта звезда будет жрать много меньше места за счет колончатой структуры более экономного формата. у рдбмс же масса всего в блоке данных, у оракла там и место под блокировки и заголовок и много, много другого не нужного в задачах DWH/аналитики. у постгрес вовсе мрак — старые версии строк в датафайле живут, которые раздувают размер и которые GC вычищает. плюс индексы удваивают размер.
но звезда или снежинка не единственный поход в хадупе, сейчас вот модно с минимум трансформаций пихать в паркетник, тратя меньше ресурсов на ETL. витрины под отчетные системы из сырых данных строят. с рдбмс такое не выйдет.

2. вы путаете параллельные термины. то что хадуп много больше вычитывает не делает его менее масштабируемым. как раз эти чтения/писанина и позволяют ему дальше чем рдбмс масштабироваться. так же как оракловый кластер масштабируется дальше чем один узел, за счет гоняния огромных объемов данных по сети интерконекта, так и хадуп раскидывает на еще большее число узлов, но обычно и выполняя на порядок-два больше работы.
как пример в хадупах зачастую не напрягаются с мутными ETL которые вычислят что изменилось, а тупо перестраивают всю витрину после каждого обновления хранилища. и это часто много быстрее выходит, чем мутные ETL рдбмс, которые зачастую однопоточный pl/sql код.
Вы действительно считаете, что приведенные Вами доводы являются вескими аргументами в обсуждении темы «Почему Сбербанк использовал для своей аналитической системы хранилище Hadoop, а не распределенные реляционные СУБД»?
что считаю или не считаю объективно мало кому интересно. я могу сочинять, я могу быть заинтересованным продажником. я просто поработал и с тем и с другим, а теперь в принципе понимаю «Почему Сбербанк использовал». наша кантора пришла абсолютно к тем же выводам, не на пустом месте.
Вопросы скорее в воздух, но мало ли у vadsu найдется пара минут свободного времени на ответ:
1. На счет того, что хочется SQL и realtime, но все лежит во всяких Hadoop/Key-Value/NoSQL, а прорабатывались ли такие варианты, как предоставлять SQL через Impala (вместо Key-Value у HBase/Cassandra), а хранение в Kudu, вместо HDFS? Или даже более координально — Yandex ClickHouse?
2. Очень интересно про «Лабиринт», правильно понимаю, что в Key-Value лежит список узлов, а внутри каждого узла уже вся доп информация, которую по нему нашли + список связанных ребер? Если так, то как устроено хранение информации о финансовых связях между организациями, в том смысле, что такие связи порождают не статические ребра, а динамические (сегодня транзакция есть, завтра ее нет, послезавтра снова есть, это одно и тоже ребро или 2 разных?). Агрегируете до достаточно больших периодов, чтобы можно было работать как со статическими ребрами? У пользователей есть возможность запустить какой-нибудь «умный» алгоритм, который проанализирует подграф этого графа начиная с какого-либо узла хотя бы на глубину 2-3 в realtime?
Sign up to leave a comment.