Как стать автором
Обновить

Когда у вас сберовские масштабы. Использование Ab Initio при работе с Hive и GreenPlum

Время на прочтение 12 мин
Количество просмотров 11K
Всего голосов 10: ↑10 и ↓0 +10
Комментарии 24

Комментарии 24

Вот это я понимаю годная статья
Спасибо.
>Инкрементальная загрузка в Hive также линейно зависит от объёма имеющихся в целевой таблице ранее загруженных данных и проходит достаточно медленно с ростом объёма
Ну согласитесь, Hive все-таки не про это. Для Hive инкремент — это заливка данных в виде файлов parquet, к примеру, и создание новой партиции, например. А оно как раз не зависит от исходного объема данных вообще.

Если же вы при сравнении делаете что-то другое — то было бы неплохо это понимать, а поэтому тут и описать, что именно — в терминах Hive.
Хорошо, когда таблицы Hive партиционированы, не бывает апдейтов задним числом и нужно просто подгружать транзакционные данные (например, проводки) в последнюю партицию. В случае же ЕСС у нас много непартиционированных таблиц, изменений «в прошлом» и т.д. Для такий целей GreenPlum подходит лучше. Это было в целом понятно из архитектуры Hive и GreenPlum. Соответствие ожиданиям полученного результата говорит о том, что все загрузки настроили верно и достигли оптимальной скорости загрузки в GreenPlum, полноценно использовав возможности многопоточной загрузки Ab Initio.
Я скорее про другое — что если Hive и Greenplum тут в посте сравниваются, то желательно бы чуть более четко описать, что именно происходит внутри (не на уровне Ab Initio, а на уровне Hive). То есть, Hive использутся неэффективно — а почему? А ожидания вполне логичные, кто бы сомневался, что у Hive с транзакциями все не очень хорошо.

Если что, это не придирка, а исключительно пожелание.
В статье написано «В случае Hive поступившие данные дельты соединяются посредством Ab Initio Join с данными, которые были в таблице до обновления. Загрузчики данных в MDW (как в Hive, так и в RDBMS) не только вставляют новые данные из дельты, но и закрывают периоды актуальности данных, по первичным ключам которых поступила дельта. Кроме того, приходится переписать заново неизменившуюся часть данных. Но так приходится делать, поскольку в Hive нет операций delete или update.» Это более-менее даёт представление о том, почему Hive проигрывает. Более подробно расписывать, что происходит в какой трансформации, считаю не столь интересным излишним техническим копанием. Спасибо, ваш комментарий ценен тем, что помог обратить на это внимание.
Я думаю вот этого комментария вполне достаточно. Из него в принципе понятно, что это достаточно нетривиальная операция, у которой нет прямого аналога. А я просто это изначально пропустил.

Можно поинтересоваться, каковы они, "сберовские масштабы"? Сколько у вас данных в HDFS? Или сколько нод в самом большом кластере?

Например, главная бухгалтерская книга по юрлицам и аналитическая информация по кредитам физлиц начиная с даты, когда они начали накапливаться, весят примерно по 30 Тб. Есть много кластеров для различных бизнес-блоков. Примерный порядок величин на средний бизнес-кластер — это 20 нод и 1000 Тб.
Немного дополню ответ коллеги: текущие объемы в Фабрике Данных — порядка 12 ПБ. Изменений в день от различных источников — около 20 ТБ.
Приведу ещё одно число. Самый большой из Сберовских кластеров состоит из 360 нод.
Как я понял по статье — в качестве хралищ используется Hive и Greenplum. Т.е. все 12 ПБ лежат в них или еще что-то интересное используете?
Ещё используются HBase, Teradata, Oracle.

В свое время поработал с этой системой и у меня к АИ накопилось куча претензий особенно к интерфейсу


  1. По сути GDE это генератор Sh скриптов, очень глючный где глюки решаются перезагрузкой GDE и бывает очень тяжело отлаживать что там происходит. Какие-то базовые вещи можно отладить, но сделано не очень удобно и со сложными графами все очень печально. Весь исполняемый код это sh и никих преимуществ это не дает, но зато дает кучу проблем. Представьте что весь ваш ETL на sh. Когда это 5-10 процессов это еще норм, а когда 1000? Это боль
  2. Flash в 2к20
  3. Сами SH скрипты тяжело читать
  4. Отсутствие комьюнити на том же stackoverflow. Я помню у меня были какие то проблемы с системой и быстро у кого то спросить невозможно. AI очень тчательно "секретит" всю документацию, вы не найдете ее в открытом виде.
  5. Система застряла в 90х
  6. Система слишком сложная по этому через пару лет это представляет из себя просто запускалку SQL скриптов по расписанию, то есть вся логика в SQL коде

Никакой удивительности в обработки даных через AI нет, вообще все ETL будут это делать примерно одинаково, потому что операции чтения и записи происходят на стороне СУБД, а они самые дорогие. Напиши ты скриптик хоть на js, хоть на С++ оно будет работать примерно одинаково, но этот .sh реально тяжело дебажить. Смысла сравнивать производительность вообще нет.
АИ стоит кучу денег, но по факту это одна большая жопа, но платят за нее норм.

>что операции чтения и записи происходят на стороне СУБД, а они самые дорогие
Ну это не совсем правда. Есть еще и Hive/HDFS, а они не совсем СУБД, и к ним можно и нужно применять более тонкие (или если угодно — ручные) оптимизации. Условный SQL для этого пришлось бы обвесить хинтами от и до, потому что статистики как правило тоже нет, и оптимизатор, даже если он есть, зачастую не имеет информации, что именно и какого размера у него попросили выбрать.

Это я не к тому, что у AI все хорошо (про AI я как раз мало что знаю, я больше на спарке), а скорее к тому, что не все ETL одинаковые. И дело скорее не в языке, а в том, сколько знаний о своих данных вы сможете в ETL заложить.
Коль уж моя статья старается характеризовать Ab Initio положительно, то постараюсь оппонировать вашим тезисам.

1) Да, Ab Initio тесно интегрирован с sh, однако это не совсем чёрный ящик и эти sh можно смотреть и дорабатывать. Давайте сравним с другими ETL-средствами. Например, Informatica PowerCenter (на самом деле лучшее из ETL средств) — в чистом виде чёрный ящик с кодом на .cpp. Отладчик там тоже не самый удобный, клиент так же периодически падает. Процессы так же виснут и приходится их снимать на уровне ОС. Трансформаций в Ab Initio больше и есть способы делать напрямую то, что делается в других ETL средствах окольными путями. Поругаюсь и на другие ETL-средства, что ODI — это всего 2 трансформации, фильтр и джойн и никакой умной логики. А SAP BODS и SAS Data Integration Studio — вообще чёрные ящики, которые непонятно как эффективно настраивать с кучей глюков и низкой производительностью.
2) Видимо, имеется в виду Flash в видеокурсах. Что ж, молодцы, что давно держатся, со времён Flash и курсы не потеряли своей актуальности.
3) Вопрос вкуса. Кому-то тяжело смотреть на sh, кому-то на java, кому-то на sql и т.д.
4) Доступ к документации открывается, если зарегистрироваться с почтового адреса на домене компании, являющейся клиентом Ab Initio. Так или иначе, с Ab Initio поставляется базовый учебный курс по GDE, который можно целый месяц изучать и выполнять упражнения самостоятельно. С дистрибутивом поставляется множество примеров по работе с трансформациями в папке .../examples. Есть техподдержка, которая быстро отвечает на вопросы и консультирует, как какую задачу лучше сделать. И у нас в Сбербанке накопились видеокурсы по Ab Initio с обучений. Т.е. компетенции можно копить.
5) Так можно говорить про любое другое ETL-средство, любую СУБД, любой язык программирования. Прорывных идей бывает не так много. К таковым можно отнести Hadoop, но Ab Initio как раз научилась с ним работать.
6) Практика показывает, что на многих проектах ETL вырождается в запускалку SQL, spark-submit, sh-скриптов и т.п. вместо использования трансформаций. Чем профессиональнее коллектив и лучше ETL-средство, тем менее вероятно такое вырождение. Посмотрим на Ab Initio с Сбербанке, надеюсь, такого не случится.

Насчёт последнего абзаца, что Ab Initio не уникален и весь мир ETL примерно одно и тоже, скажу, что весь мир программирования тоже так устроен — есть разные пути реализации одной задачи различными способами на разных языках с одинаковым выхлопом. Вопрос вкуса, что выбрать. И тут на выбор могут влиять договорные условия, открытость техподдержки, отношения с клиентами. Мне видится, что у Сбербанка с Ab Initio это всё налажено не так плохо и уровень взаимопонимания постепенно повышается.
  1. Зачем сравнивать вообще инструменты из 90х? Я так понимаю вы много работали с Информатикой, но информатика это просто ужасное старье, она застряла в 90х и никакие попытки ее оживить не привели к успеху, ну серьезно, сравните АИ с каким нибудь matilion, pentaho, они гораздо удобнее. Даже писать скрипты на Python удобнее быстрее и понятнее
  2. Control center на flash, lineage анализ на нем же ну и плюс куча остального хлама на нем же, metadatHub и т.д. Сам GDE имеет несколько компонент которые на flash
  3. Да, но ту же Java можно профилировать и дебажить отлично, что не скажешь про sh.
  4. В этом то и вся проблема, слишком сложно получить доку, что бы стать клиентом компании нужно заплатить кучу денег, а в доке про баги вы не узнаете и как лечить их тоже. Я сейчас точно не помню какая у меня была проблема, но АИ работал не так как было нужно и я не мог никак найти проблему и мне повезло что в другой комманде был человек который с этой проблемой сталкивался и подсказал лекарство.
Ваш опыт понятен. Я сравнивал с инструментами, давно существующими на рынке и имеющими много внедрений. Вы считаете, что с годами инструменты прогнивают, закостеневают или теряют гибкость и предпочитаете наиболее современные технологии, появившиеся на рынке не так давно. Возможно, крупные компании вынуждены придерживаться консервативных позиций. И их вполне можно понять с точки зрения бизнеса.
Использовался ли при загрузке в Greenplum параллельный загрузчик gpfdist, или заливали через JDBC/ODBC? В последнем случае все данные льются через мастер, это плохой способ загрузки в Greenplum.
Gpfdist не использовали, настроить его работу с Ab Initio в параллельном режиме (чтобы каждая нода Ab Initio вызывала свой gpfdist для свой порции данных) не получилось. Итоговая производительность загрузки вполне устроила нас и без gpfdist. В общем случае, загрузка в GreenPlum осуществлялась путём SQL insert. Соединение Ab Initio с GreenPlum и другими БД представляет собой не JDBC/ODBC, а некие «родные» коннекторы от Ab Initio. (Аналогично Informatica PowerCenter.) Мониторинг Grafana, применённый к кластеру GreenPlum, показал, что нагрузка на ноды GreenPlum получается почти равномерная. Мастер-нода нагружается чуть больше, но не сильно.

Понятно, спасибо. Хорошо, если хватает пропускной способности мастера, но в случае масштабирования нагрузки и самого кластера крайне рекомендую вложиться в загрузчик на gpfdist :)

Немного не по теме, но все же, подскажите у вас в GP модели в каком виде хранятся? anchor? data vault? просто 3nf? или готовые витрины?
В основном, готовые витрины.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий