Работы над этим решением имели разную интенсивность и ведутся около 4 лет. В виде сервиса у нас оформлен сервис метаданных (о модели данных, к которой обращается SMTL), остальное посмотрим по ситуации.
Язык SMTL, GUI, фреймворк на Java и генераторы - внутренняя разработка. Spec-to-graph - внешний продукт, который может быть заменён на что-либо другое. Элементарные операции и тест-кейсы к ним разработаны, так что пересесть при необходимости на какую-либо другую платформу - посильная задача.
Что касается потребителя: сгенерированный граф запускается из контрольного механизма shell-скриптом в кластерном режиме на нодах Hadoop, результаты складываются в HDFS и подхватываются ещё одним процессом (loader), которые опять-таки в кластерном режиме складывает данные в Hive.
Данный пример условный и выстраивает историю с точностью до целых дней.
Считаем, что hist1, hist2, hist3 подготовлены таким образом, что за один день по одному атрибуту может быть только одно изменение.
Если поменять ограничение и предположить, что, например, за одну секунду по одному атрибуту может быть только одно изменение, то в запросе надо написать «lead(start_dt — 1/24/60/60)».
Конечно же, программисты не забывают сдать никакие изменения в Git и вывод кода на продуктив осуществляется только после тестирования на стендах СТ (системного тестирования), ИФТ (интеграционного функционального тестирование) и ПСИ (приёмо-сдаточных испытаний). С боевыми БД все в порядке, но кроме них есть отладочные, с которыми работают большие ученые, отличающиеся рассеянностью. Так что система логирования не бесполезна. А хранить деньги в Сбере можно и нужно.
Благодарен вам за отзыв. Если этот пост – пример того, как не нужно работать с Oracle, то у вас и сообщества читателей Хабр есть возможность написать, как же нужно с ним работать. В том числе, можно пройтись по каждому из описанных приёмов. Согласен, что есть масса других способов реализации написанного выше, в том числе с использованием готовых поисковых машин. Не всегда есть время разбираться со специализированными решениями. Не всегда есть возможность пользоваться более специализированными решениями из-за требований режима, в том числе, не всегда исходники можно выложить. Согласен, что PL/SQL уступает многим другим средствам разработки. Однако, приведённые решения просты для понимания, могут быть реализованы “на коленке” и не требуют сложных доступов. Предложенные решения хороши тем, что их можно использовать “здесь и сейчас”. Для каждого решения существует лучший инструмент с учётом сложившейся среды разработки, версий продукта, имеющихся доступов и практики вывода кода на промышленные серверы. В зависимости от этого наилучший инструмент может варьироваться. Вижу, что у вас другие средства и технологии. Пожалуйста, делитесь ими. Хабр – отличная площадка для этого.
Gpfdist не использовали, настроить его работу с Ab Initio в параллельном режиме (чтобы каждая нода Ab Initio вызывала свой gpfdist для свой порции данных) не получилось. Итоговая производительность загрузки вполне устроила нас и без gpfdist. В общем случае, загрузка в GreenPlum осуществлялась путём SQL insert. Соединение Ab Initio с GreenPlum и другими БД представляет собой не JDBC/ODBC, а некие «родные» коннекторы от Ab Initio. (Аналогично Informatica PowerCenter.) Мониторинг Grafana, применённый к кластеру GreenPlum, показал, что нагрузка на ноды GreenPlum получается почти равномерная. Мастер-нода нагружается чуть больше, но не сильно.
Ваш опыт понятен. Я сравнивал с инструментами, давно существующими на рынке и имеющими много внедрений. Вы считаете, что с годами инструменты прогнивают, закостеневают или теряют гибкость и предпочитаете наиболее современные технологии, появившиеся на рынке не так давно. Возможно, крупные компании вынуждены придерживаться консервативных позиций. И их вполне можно понять с точки зрения бизнеса.
Коль уж моя статья старается характеризовать 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 это всё налажено не так плохо и уровень взаимопонимания постепенно повышается.
Например, главная бухгалтерская книга по юрлицам и аналитическая информация по кредитам физлиц начиная с даты, когда они начали накапливаться, весят примерно по 30 Тб. Есть много кластеров для различных бизнес-блоков. Примерный порядок величин на средний бизнес-кластер — это 20 нод и 1000 Тб.
В статье написано «В случае Hive поступившие данные дельты соединяются посредством Ab Initio Join с данными, которые были в таблице до обновления. Загрузчики данных в MDW (как в Hive, так и в RDBMS) не только вставляют новые данные из дельты, но и закрывают периоды актуальности данных, по первичным ключам которых поступила дельта. Кроме того, приходится переписать заново неизменившуюся часть данных. Но так приходится делать, поскольку в Hive нет операций delete или update.» Это более-менее даёт представление о том, почему Hive проигрывает. Более подробно расписывать, что происходит в какой трансформации, считаю не столь интересным излишним техническим копанием. Спасибо, ваш комментарий ценен тем, что помог обратить на это внимание.
Хорошо, когда таблицы Hive партиционированы, не бывает апдейтов задним числом и нужно просто подгружать транзакционные данные (например, проводки) в последнюю партицию. В случае же ЕСС у нас много непартиционированных таблиц, изменений «в прошлом» и т.д. Для такий целей GreenPlum подходит лучше. Это было в целом понятно из архитектуры Hive и GreenPlum. Соответствие ожиданиям полученного результата говорит о том, что все загрузки настроили верно и достигли оптимальной скорости загрузки в GreenPlum, полноценно использовав возможности многопоточной загрузки Ab Initio.
2)
Например, на странице jaceklaskowski.gitbooks.io/mastering-spark-sql/spark-sql-cost-based-optimization.html
рекомендуют вызывать для перекошенных столбцов сбор статистики командой
ANALYZE TABLE COMPUTE STATISTICS FOR COLUMNS,
включать режим spark.sql.cbo.enabled=true и пользоваться собранной статистикой.
Но у меня на практике это не взлетело.
Работы над этим решением имели разную интенсивность и ведутся около 4 лет. В виде сервиса у нас оформлен сервис метаданных (о модели данных, к которой обращается SMTL), остальное посмотрим по ситуации.
Язык SMTL, GUI, фреймворк на Java и генераторы - внутренняя разработка. Spec-to-graph - внешний продукт, который может быть заменён на что-либо другое. Элементарные операции и тест-кейсы к ним разработаны, так что пересесть при необходимости на какую-либо другую платформу - посильная задача.
Что касается потребителя: сгенерированный граф запускается из контрольного механизма shell-скриптом в кластерном режиме на нодах Hadoop, результаты складываются в HDFS и подхватываются ещё одним процессом (loader), которые опять-таки в кластерном режиме складывает данные в Hive.
Считаем, что hist1, hist2, hist3 подготовлены таким образом, что за один день по одному атрибуту может быть только одно изменение.
Если поменять ограничение и предположить, что, например, за одну секунду по одному атрибуту может быть только одно изменение, то в запросе надо написать «lead(start_dt — 1/24/60/60)».
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 это всё налажено не так плохо и уровень взаимопонимания постепенно повышается.
habr.com/ru/company/wrike/blog/275567
2)
Например, на странице jaceklaskowski.gitbooks.io/mastering-spark-sql/spark-sql-cost-based-optimization.html
рекомендуют вызывать для перекошенных столбцов сбор статистики командой
ANALYZE TABLE COMPUTE STATISTICS FOR COLUMNS,
включать режим spark.sql.cbo.enabled=true и пользоваться собранной статистикой.
Но у меня на практике это не взлетело.