Однажды в жизнь Пети прочно и надолго входит Маша. У Маши есть пара закадычных друзей - Wildberies, Ozon, Yandex.Market и т.п. Потом у Маши с Петей появляется совместный проект - джун. Джун еще ничего не сделал, а не наго Маша уже запланировала бюджет в 5-6 Петиных зарплат.
И вот Петя уже не ходит в офис - он работает удаленно, потому что надо быть дома, всегда на подхвате у джуна (сеньор на подхвате у джуна). Петя уже начинает понимать, что 300к - вроде бы неплохо, а по факту мало. И начинает Петя становиться тимлидом, или архитектором, или еще одним сеньором на параллельной работе. И Петя четко фиксирует все траты - он сделал с Машей совместный счет. Статистика говорит, что как бы он не старался сократить расходы, покупается только самое необходимое, ну и еда.
Иногда Петя и Маша заказывают пиццу, чтобы вечером ее сожрать, ибо джун весь день работал усердно, и к вечеру сил ни у Маши ни у Пети не остается... И когда снимать квартиру становится совсем уже невозможно, Петя идет в банк, дает согласие и уходит в рабство на 10-15 лет. Ночью, перед тем как заснуть, он пытается вспомнить, как это - жить одному на 300к в месяц, пить крафтовое пивко вечером, собирать Lego.... Но посмотрев на сосредоточенно-пыхтящее личико джуна, спящую Машу, он понимает - до этого у него и жизни то и не было. А рабство банку - ерунда, найду еще одну подработку...
Где сравнение-то? Какие критерии? Какие показтели? Эксперимент?
Вы привели поток NiFI, но не привели код DAG. Поток для вставки в ClickHouse в принципе не оптимальный. Если у вас стоит задача - разными инструментами извлечь данные и положить их на шару, то так и напишите, не вводите в заблуждение. Заголовок статьи - кликбейтный и не соответствует содержимому.
После сохранения содержимого CSV в файл, который может читать ClickHouse (директория /var/lib/clickhouse/user_files), и установки необходимых для формирования запросов атрибутов (определения таблицы и партиции из имени файла) выполняются последовательно запросы для создания таблицы, удаления старых данных и вставки новых. Процесс завершается удалением файла из директории пользовательских файлов ClickHouse.
Зачем вы делаете какой-то велосипед?
Все запросы можно выполнить из NiFi через PutSQL, т.о. у вас сразу появится структура данных. Зачем просто копируете данные на диск, если можете сразу вставить их в таблицу ClickHouse. Вы ранее создали соединение JDBC, применяется PutDatabaseRecord чтобы сразу внести прочитанные данные в базу, без промежуточного сохранения файла. Это будет очень быстро, и не потребуется дополнительных операций.
Основное отличие от настроек для СУБД, драйвера для которых встроены в NiFi, — это необходимость указать имя класса драйвера (Database Driver Class Name), а также путь к jar-файлу этого драйвера. Более подробно про подключение можно прочитать в официальной документации ClickHouse.
В общем процесс загрузки содержимого CSV-файлов в ClickHouse выглядит следующим образом:
А зачем вы настраивали соединение с базой данный? К чему вообще раздел про JDBC подключение, если вы его не применяете?
Гарантирование доставки данных, загруженных в NiFi, достигается за счет применения концепции файлов потока (Flow File), которые объединяют в себе содержимое (данные, загруженные в NiFi из внешней системы) и атрибуты (метаданные, которые можно добавлять к файлам в самом NiFi) и которые сохраняются на жесткий диск, чтобы не допустить их потери в случае отключения питания.
Тоже, весьма спорное утверждение, что это все достигается за счет FlowFile. Следует помнить, что контент, который хранится в репозитории контента, пишется каждый раз заново при любом изменении, тем самым никуда не пропадая в случае сбоя. Ссылка на контент хранится в атрибутах FlowFile, которые хранятся в оперативной памяти. А отказоусточиваость достигается за счет того, что любые изменения FlowFile сохраняются в репозитории флоуфайлов, в построенном в виде Write-Ahead Log, т.е. при сбое NiFI может "раскрутить" все состояния FlowFile и точно узнать, в какой очереди они были. Для точного понимания механизма рекомендую почитать NiFI in Depth, разделы Effect of System Failure on Transactions и Deeper View: FlowFiles in Memory and on Disk
В ETL задачах очень часто необходимо использовать джойны.
В своей практике не встречал, где нужен JOIN. Если требуется на лету соединять несколько источников/потоков данных, это действительно не про NIFI. Например, Flink с этим прекрасно справится. В этом случае я всегда задаю один вопрос - вы точно уверены в выборе инструмента? Все остальные задачи решаемы за счет обогащения.
На мой взгляд Nifi удобный инструмент, если нужно приземляьть в реальном времени данные из очередей, перед этим трансформировать их, скажем из json в parquet, оповестить некий сервис о пришедших данных. Возможно, даже будет удобен для микробатчей. Максимум - для заполнения Staging Area
Вы сами говорите об области применения, где достаточно много трансформаций, параллельных процессов.
Дальше, когда нужно запускать тяжелые батчи, вроде создания DWH или DataMart, использовать NiFi будет уже тяжеловато.
Для этих целей существует другой ряд инструментария. Когда данные в Stage попали, область ответсвенности NIFI закончилась. Данные доставили. Вся последующая магия через внутренние преобразования в БД, которые окрестрируются, например, Airflow.
Ну и обработка в flow-файлах, как вы правильно отметили, не прибавляет скорости обработки. Кроме того, насколько я помню, они даже без сжатия хранятся.
Укажите кодек Avro в настройке Writer. Данные будут сжаты. Из коробки поддерживается deflate, bzip2, snappy, xz, zstandard. Т.о. контент будет занимать меньше места. Однако это влияет на обработку, т.к. для изменения записи идет их распаковка и упаковка.
Вполне удобный ETL инструмент, с возможностью собственного расширения. Довольно широкий спектр задач, которые можно решить без единой строчки кода. Есть своя ниша.
Разве не будет концептуально правильней для инсерт селекта использовать какой-то процессор, который выполняет именно явно указанный sql-statement типа insert into my_table select ..., а не подхватывает строки из потока, как PutDatabaseRecord (как я понял)?
Я не понял вашей мысли.
Основная цель - не перекачать данные из одной таблицы в другую, а перекачать данные из одного источника (базы), в другую. При этом между ними нет связи, т.е. нельзя сослаться на них в одном запросе.
Смысл применения PutDatabaseRecord как раз и состоит в том, что этот процессор позволяет выполнить встану батчем, то есть за один проход вставить все то, что лежит в контенте. В зависимости от вашей целевой системы и настроек драйвера JDBC, вы можете или завесить свою систему, или же наоборот, оптимизировать вставку данных в таблицы. Что касается описанного в статье случае, то целевой был MsSql Server, и как показал профайлер, формировались запросы BULK INSERT, далее шли данные. Размер одного батча - 100 тыс строк, время вставки - менее 1 секунды (порядка 0,7-0,6с, в зависимости от нагрузки на сервер). В две разные таблицы можно вставлять параллельно.
В Pentaho DI на больших порциях входных данных у нас были проблемы, переделали итого на выполнение sql.
Если есть возможность применить PXF, Linked Server или иные технологию связности баз данных, то подобный запрос будет более выгоден по ресурсам. Однако для оркестрации такого подхода я бы применял Airflow или подобную им вещь.
ЗЫ Нет в заначке каких-то ссылок на обучающие материалы по NiFi? Что-то, что самому пригодилось.
Го в группу, поиск по ссылкам даст много чего интересного.
Коллега, а почему DataBricks? Все, что представлено, является бесплатным решением.К тому же, все представленные сервисы можно замостить у себя, без ухода в облака. С точки зрения безопасников, это просто Must Be.
В NiFi есть практика разделять контент и конфигурацию? Т.е. выносить реквизиты тех же соединений с БД, смтп-сервера и тп в отдельный файл?
Да. Соединение с БД выносится отдельным сервисом, создающим соединение. Что касается паролей - тут сложнее. Применяется Sensetive свойства, можно хранить непосредственно в процессе соединение, либо в параметрах (шифрованных). Вообще, в NIFI данные разделены на контент (записи, данные, которые надо обработать) и атрибуты (метаданные, имена топиков, идентификатор самого сообщения, количество записей в файле, идентификатор фрагмента и т.д.). Т.о. обработка разделяется на два типа - работает с контентом, и работа с атрибутами.
ЗЫ Видел ответ в 1 части, для уточнения: не рассматривали другие визуальные ETL-инструменты, так же сделанные на джаве, Talend или Pentaho DI?
В компании сразу нацелились на Apache Nifi. Но для себя я смотрел разные инструменты. Pentaho очень похож на NIFI, только в нем нет своего оркестратора. Talend хорош, но не зашел. Хотя и не скрою, инструмент, в некоторых аспектах мощнее NIFI, особенно маппинг полей при трансформациях.
Согласен с Вами. Все-таки MS Office вылизан, и продолжает развиваться, задавая мейнстрим офисного пакета. Не все продукты из состава пакета прям вот супер, часть просто не нужна. Но вот Word и Excel, да и PowerPoint - это три столпа.
Есть и иная сторона медали - практически в любом гос.органе, где есть документооборот, есть стандарт - Word (иногда 2003), Times New Roman 14 и т.д. И никак иначе. То же самое касается многих журналов, принимающих статьи только в Word.
У меня два года назад заблокировали аккаунт MS. В сообщении о блокировке было сказано, что я нарушил какие-то требования. Служба поддержки ничего внятного не ответила. Долгая переписка в Twitter тоже результатов не дала. При восстановлении аккаунта пробовал разные способы, вплоть до того, что поросился друзей посмотреть историю последнего общения в скайпе, и сообщить мне точные даты последних сообщений.
При этом аккаунт был личным, была настроена двухэтапная авторизация. Аккаунту было более 10 лет, использовался активно, в первую очередь для всяких подписок на MS, обучения и разработки под Windows/Azure. Восстановить аккаунт не удалось. Приложение генератор кодов исправно генерит коды. Смс приходит. Но не восстанавливает аккаунт, не снимается блокировка.
Что я потерял:
В моем OneDrive хранилось довольно много информации, в том числе фотографии, которые я делал еще на Htc Hd7, и которые я так и не перенес в другое хранилище.
К аккаунту был подключен Azure, за который я платил деньги. Деньги исправно снимались, сервисы работали, управлять ими мог через другие аккаунты, но вот изменить тарифы, платежные системы и передать права владельца - не получилось, так как аккаунт был заблокирован.
Итог - не пользуюсь MS и их продуктами. Исключений два - по работе СУБД MsSQL, и диссертацию перекидывал в Word.
Есть еще вопрос про web.proxy - что применяете? Как настроили балансировку? Пускаете на все ноды в UI или только на определенную? Сертификаты для каждой ноды собственные или на кластер одни и те же? Если это будет в следующей статье, то подождем
Спасибо. Сколько лет вам понадобилось для обкатки технологии и окончательного оформления? Не планируете выставить в виде сервиса?
В данный момент тоже задумываемся об автоматизации задач анализа источников и дальнейшей загрузки. У нас сначала аналитик напишет S2t табличку, потом я делаю stage слой и реализую загрузку из источников с помощью NIFI, дальше подключаются разработчики БД - из stage формируют RDV и витрины. Автоматизируем потихоньку, но общего, чтобы от источника и до витрины, пока не создали.
Насколько я понимаю, Manager DN - учетная запись, под которой NIFI идет в LDAP, запрашивает данные о пользователях. У вас эта же учётка является админом, выполняющим начальную настройку. У себя сделал так - создал учётку для NIFI, админы запретили все все что можно, кроме авторизации и запроса даных из каталога LDAP. А initial admin указал себя)
Однажды в жизнь Пети прочно и надолго входит Маша. У Маши есть пара закадычных друзей - Wildberies, Ozon, Yandex.Market и т.п. Потом у Маши с Петей появляется совместный проект - джун. Джун еще ничего не сделал, а не наго Маша уже запланировала бюджет в 5-6 Петиных зарплат.
И вот Петя уже не ходит в офис - он работает удаленно, потому что надо быть дома, всегда на подхвате у джуна (сеньор на подхвате у джуна). Петя уже начинает понимать, что 300к - вроде бы неплохо, а по факту мало. И начинает Петя становиться тимлидом, или архитектором, или еще одним сеньором на параллельной работе.
И Петя четко фиксирует все траты - он сделал с Машей совместный счет. Статистика говорит, что как бы он не старался сократить расходы, покупается только самое необходимое, ну и еда.
Иногда Петя и Маша заказывают пиццу, чтобы вечером ее сожрать, ибо джун весь день работал усердно, и к вечеру сил ни у Маши ни у Пети не остается...
И когда снимать квартиру становится совсем уже невозможно, Петя идет в банк, дает согласие и уходит в рабство на 10-15 лет.
Ночью, перед тем как заснуть, он пытается вспомнить, как это - жить одному на 300к в месяц, пить крафтовое пивко вечером, собирать Lego.... Но посмотрев на сосредоточенно-пыхтящее личико джуна, спящую Машу, он понимает - до этого у него и жизни то и не было. А рабство банку - ерунда, найду еще одну подработку...
Где сравнение-то? Какие критерии? Какие показтели? Эксперимент?
Вы привели поток NiFI, но не привели код DAG.
Поток для вставки в ClickHouse в принципе не оптимальный. Если у вас стоит задача - разными инструментами извлечь данные и положить их на шару, то так и напишите, не вводите в заблуждение. Заголовок статьи - кликбейтный и не соответствует содержимому.
Зачем вы делаете какой-то велосипед?
Все запросы можно выполнить из NiFi через PutSQL, т.о. у вас сразу появится структура данных. Зачем просто копируете данные на диск, если можете сразу вставить их в таблицу ClickHouse. Вы ранее создали соединение JDBC, применяется PutDatabaseRecord чтобы сразу внести прочитанные данные в базу, без промежуточного сохранения файла. Это будет очень быстро, и не потребуется дополнительных операций.
А зачем вы настраивали соединение с базой данный? К чему вообще раздел про JDBC подключение, если вы его не применяете?
Тоже, весьма спорное утверждение, что это все достигается за счет FlowFile.
Следует помнить, что контент, который хранится в репозитории контента, пишется каждый раз заново при любом изменении, тем самым никуда не пропадая в случае сбоя.
Ссылка на контент хранится в атрибутах FlowFile, которые хранятся в оперативной памяти. А отказоусточиваость достигается за счет того, что любые изменения FlowFile сохраняются в репозитории флоуфайлов, в построенном в виде Write-Ahead Log, т.е. при сбое NiFI может "раскрутить" все состояния FlowFile и точно узнать, в какой очереди они были.
Для точного понимания механизма рекомендую почитать NiFI in Depth, разделы Effect of System Failure on Transactions и Deeper View: FlowFiles in Memory and on Disk
А как же DSL? А JOLT? Наконец, Groovy?
В общем, не раскрыто понятие "гибкой работы".
Привет.
Согласен полностью. Но цель была сказать, что драйвер надо расположить в месте, куда есть доступ.
Можно, а также можно самим генерировать запросы. Но все-таки ExecuteSql предназначен для SELECT
Тема отдельного разговора про обогощение. Будет отдельная статья
Попытаюсь вам оппонировать.
В своей практике не встречал, где нужен JOIN. Если требуется на лету соединять несколько источников/потоков данных, это действительно не про NIFI. Например, Flink с этим прекрасно справится. В этом случае я всегда задаю один вопрос - вы точно уверены в выборе инструмента? Все остальные задачи решаемы за счет обогащения.
Вы сами говорите об области применения, где достаточно много трансформаций, параллельных процессов.
Для этих целей существует другой ряд инструментария. Когда данные в Stage попали, область ответсвенности NIFI закончилась. Данные доставили. Вся последующая магия через внутренние преобразования в БД, которые окрестрируются, например, Airflow.
Укажите кодек Avro в настройке Writer. Данные будут сжаты. Из коробки поддерживается deflate, bzip2, snappy, xz, zstandard. Т.о. контент будет занимать меньше места. Однако это влияет на обработку, т.к. для изменения записи идет их распаковка и упаковка.
Обоснуйте.
Вполне удобный ETL инструмент, с возможностью собственного расширения. Довольно широкий спектр задач, которые можно решить без единой строчки кода. Есть своя ниша.
Я не понял вашей мысли.
Основная цель - не перекачать данные из одной таблицы в другую, а перекачать данные из одного источника (базы), в другую. При этом между ними нет связи, т.е. нельзя сослаться на них в одном запросе.
Смысл применения PutDatabaseRecord как раз и состоит в том, что этот процессор позволяет выполнить встану батчем, то есть за один проход вставить все то, что лежит в контенте. В зависимости от вашей целевой системы и настроек драйвера JDBC, вы можете или завесить свою систему, или же наоборот, оптимизировать вставку данных в таблицы. Что касается описанного в статье случае, то целевой был MsSql Server, и как показал профайлер, формировались запросы BULK INSERT, далее шли данные. Размер одного батча - 100 тыс строк, время вставки - менее 1 секунды (порядка 0,7-0,6с, в зависимости от нагрузки на сервер). В две разные таблицы можно вставлять параллельно.
Если есть возможность применить PXF, Linked Server или иные технологию связности баз данных, то подобный запрос будет более выгоден по ресурсам. Однако для оркестрации такого подхода я бы применял Airflow или подобную им вещь.
Го в группу, поиск по ссылкам даст много чего интересного.
Коллега, а какую альтернативу СУБД для аналитического хранилища вы рассматриваете?
Коллега, а почему DataBricks?
Все, что представлено, является бесплатным решением.К тому же, все представленные сервисы можно замостить у себя, без ухода в облака. С точки зрения безопасников, это просто Must Be.
Да. Соединение с БД выносится отдельным сервисом, создающим соединение. Что касается паролей - тут сложнее. Применяется Sensetive свойства, можно хранить непосредственно в процессе соединение, либо в параметрах (шифрованных). Вообще, в NIFI данные разделены на контент (записи, данные, которые надо обработать) и атрибуты (метаданные, имена топиков, идентификатор самого сообщения, количество записей в файле, идентификатор фрагмента и т.д.). Т.о. обработка разделяется на два типа - работает с контентом, и работа с атрибутами.
В компании сразу нацелились на Apache Nifi. Но для себя я смотрел разные инструменты. Pentaho очень похож на NIFI, только в нем нет своего оркестратора.
Talend хорош, но не зашел. Хотя и не скрою, инструмент, в некоторых аспектах мощнее NIFI, особенно маппинг полей при трансформациях.
Это две разные сущности.
Первая - формирует отчеты в формате прометея
Вторая - отправляет отчет о Provenance на другой инстанс Nifi
Согласен с Вами. Все-таки MS Office вылизан, и продолжает развиваться, задавая мейнстрим офисного пакета. Не все продукты из состава пакета прям вот супер, часть просто не нужна. Но вот Word и Excel, да и PowerPoint - это три столпа.
Есть и иная сторона медали - практически в любом гос.органе, где есть документооборот, есть стандарт - Word (иногда 2003), Times New Roman 14 и т.д. И никак иначе. То же самое касается многих журналов, принимающих статьи только в Word.
У меня два года назад заблокировали аккаунт MS. В сообщении о блокировке было сказано, что я нарушил какие-то требования. Служба поддержки ничего внятного не ответила. Долгая переписка в Twitter тоже результатов не дала. При восстановлении аккаунта пробовал разные способы, вплоть до того, что поросился друзей посмотреть историю последнего общения в скайпе, и сообщить мне точные даты последних сообщений.
При этом аккаунт был личным, была настроена двухэтапная авторизация. Аккаунту было более 10 лет, использовался активно, в первую очередь для всяких подписок на MS, обучения и разработки под Windows/Azure. Восстановить аккаунт не удалось. Приложение генератор кодов исправно генерит коды. Смс приходит. Но не восстанавливает аккаунт, не снимается блокировка.
Что я потерял:
В моем OneDrive хранилось довольно много информации, в том числе фотографии, которые я делал еще на Htc Hd7, и которые я так и не перенес в другое хранилище.
К аккаунту был подключен Azure, за который я платил деньги. Деньги исправно снимались, сервисы работали, управлять ими мог через другие аккаунты, но вот изменить тарифы, платежные системы и передать права владельца - не получилось, так как аккаунт был заблокирован.
Итог - не пользуюсь MS и их продуктами. Исключений два - по работе СУБД MsSQL, и диссертацию перекидывал в Word.
Есть еще вопрос про web.proxy - что применяете? Как настроили балансировку? Пускаете на все ноды в UI или только на определенную?
Сертификаты для каждой ноды собственные или на кластер одни и те же? Если это будет в следующей статье, то подождем
Спасибо. Сколько лет вам понадобилось для обкатки технологии и окончательного оформления? Не планируете выставить в виде сервиса?
В данный момент тоже задумываемся об автоматизации задач анализа источников и дальнейшей загрузки. У нас сначала аналитик напишет S2t табличку, потом я делаю stage слой и реализую загрузку из источников с помощью NIFI, дальше подключаются разработчики БД - из stage формируют RDV и витрины. Автоматизируем потихоньку, но общего, чтобы от источника и до витрины, пока не создали.
Отличная статья, коллега.
Небольшое замечание (м.б. вы специально так сделали).
В настройках провайдера указано
Насколько я понимаю, Manager DN - учетная запись, под которой NIFI идет в LDAP, запрашивает данные о пользователях. У вас эта же учётка является админом, выполняющим начальную настройку.
У себя сделал так - создал учётку для NIFI, админы запретили все все что можно, кроме авторизации и запроса даных из каталога LDAP. А initial admin указал себя)
Очень круто все выглядит. Немного непонятно, указанные продукты (GUI, генераторы) - ваши внутренние разработки или есть готовые продукты?
Также не совсем понятно, кто является конечным потребителем кода, какой сервис/система выполняет в итоге работу?