#BigData #ETL
❌Сегодня рассмотрим, почему в потоковых конвейерах обработки данных на базе Apache NiFi случаются ошибки, и какие популярные стратегии и инструменты помогут идентифицировать эти проблемы, а также решить их.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/best-practices-for-error-handling-in-nifi-data-pipeline.html

#ETL #NiFi
🔥1 августа 2022 года вышел очередной выпуск самого популярного потокового ETL-маршрутизатора.
Что нового в Apache NiFi 1.17 для дата-инженера и администратора кластера: новые фичи, исправления ошибок и главные улучшения.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/nifi-1-17-release-overview.html

#AirFlow #ETL
🤖Зачем переходить с cron на AirFlow и как это сделать наиболее эффективно: практические тонкости планирования и оркестрации пакетных процессов для дата-инженера с примерами и лайфхаками.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/from-cron-to-airflow.html

#ETL #NiFi
🎁Мы часто делимся полезными лайфхаками и лучшими практиками администрирования и эксплуатации технологий Big Data.

Сегодня специально для обучения дата-инженеров рассмотрим, как лучше настроить репозитории Apache NiFi и параметры кластера, чтобы повысить производительность и надежность этого популярного ETL-маршрутизатора потока данных
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/nifi-tips-and-tricks-for-cluster-administrator.html

#AirFlow #ETL
👨🏻‍💻В этой статье для обучения дата-инженеров и администраторов кластера разберем способы организации совместного использования DAG-файлов при развертывании Apache AirFlow в Kubernetes. Чем хорош вариант с общими томами и почему от него лучше отказаться в пользу Git.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/shared-volumes-vs-git-sync-for-dag-management-in-airflow-on-kubernetes.html

#BigData #ETL #статьи
🍩Рассмотрим, что такое обратное давление и как этот механизм используется при потоковой обработке данных.
Также поговорим про визуализацию back pressure в GUI, математические модели прогнозирования пороговых значения и настройку конфигураций.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/nifi-back-pressure.html

#AirFlow #DevOps #ETL #статьи
👨🏻‍💻Дата-инженеры часто сталкиваются с изменением структуры конвейера обработки данных в Apache AirFlow, например, когда добавляются новые источники или приемники данных. Однако, менять DAG каждый раз при изменении внешних условий довольно утомительно.
Читайте далее, как автоматизировать реорганизацию DAG, используя JSON, YAML-файл или другую плоскую структуру данных для хранения динамической конфигурации рабочего процесса.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/dag-airflow-dynamic-configuration-through-yaml-file.html

#AirFlow #ETL #статьи
🟢Краткий обзор Apache AirFlow 2.4

Apache Airflow 2.4 содержит более 45 новых функций, 40 улучшений, 50 исправления ошибок и изменения в документации.

Ключевыми изменениями являются следующие:
✔️новая функция, которая позволяет разработчикам DAG создавать более мелкие, автономные группы цепочки, которые объединяются в крупный рабочий процесс. Эти наборы данных представляют собой абстрактную концепцию и пока не имеют возможности прямого чтения или записи, но они ускоряют планирование ETL-конвейеров, работая быстрее ExternalTaskSensor и TriggerDagRunOperator.
✔️упрощение управления конфликтующими зависимостями Python с помощью нового ExternalPythonOperator. Его декоратор @task.externalpython позволяет запускать функцию Python как задачу AirFlow в предварительно настроенной виртуальной среде или даже в совершенно другой версии Python.
✔️динамическое сопоставление задач теперь включает поддержку expandkwargs, чтобы назначить несколько параметров оператору, отличному от TaskFlow и преобразовать параметры непосредственно перед запуском задачи. Также добавлена поддержка дополнительных типов ввода для использования с функцией динамического сопоставления задач.
✔️Новый триггер CronTriggerTimetable делает синтаксис планирования AirFlow более похожим на cron, привычный большинству дата-инженеров.
✔️Наконец, сделаны значительные улучшения пользовательского интерфейса, включая возможность детализировать файлы журналов из представления сетки.

Еще Apache AirFlow 2.4 включает следующие добавления:
✔️декораторы @task.shortcircuit и @task.kubernetes
✔️команда удаления ролей в CLI и поддержка TaskGroup в ExternalTaskSensor
✔️экспериментальный parsingcontext, чтобы включить оптимизацию динамической обработки DAG в рабочих процессах
✔️отображение неконфиденциальных значений конфигурации во вкладке администрирования (Admin -> Configuration)
✔️имя оператора отдельно от класса, т.е. больше нет PythonDecoratedOperator при использовании TaskFlow.

Далее рассмотрим некоторые из этих новинок более подробно.

@BigDataSchool_ru
https://www.bigdataschool.ru/blog/airflow-2-4-release-overview.html

#BigData #ETL #статьи
🎢Как происходит балансировка нагрузки в кластере Apache NiFi.

В версии NiFi 1.8.0 балансировка нагрузки была добавлена ​​между каждым процессором в любом соединении, а также реализован способ настроить автоматическую балансировку нагрузки между узлами.
Также в Apache NiFi есть функция, позволяющая выводить из эксплуатации и отключать узлы от кластера, а также выгружать все их данные. Это особенно важно для Kubernetes и динамического масштабирования для обеспечения эластичности.
Эластичное масштабирование нужно для рабочих нагрузок, которые меняются в течение дня или года.
Чтобы соответствовать соглашениям об уровне обслуживания и срокам, можно увеличивать масштаб в пиковые периоды и уменьшайте его для экономии расходов.
Эта функция балансировки нагрузки демонстрирует возможности распределения большого набора данных или захвата неструктурированных данных в другом центре обработки данных, разделения и передачи, а затем использования привязки атрибутов к узлу для восстановления данных в определенном порядке.

Это случается, когда есть большой массив данных, экспортируемых из системы, например, дамп реляционной базы данных в один файл размером несколько терабайт. Нужен один узел NiFi, чтобы загрузить этот файл, а затем разбить его на более мелкие фрагменты, передать и отправить другим узлам для обработки. Иногда для упорядочивания записей требуется использовать атрибут для хранения связанных фрагментов, к примеру, одной таблицы на одном узле.

Также большим файлом может быть какой-либо архив, например, zip-файл, содержащий множество файлов разных типов, которые надо направить к одному и тому же узлу NiFi на основе корневого имени файла или типов вложенных файлов.

Поэтому при настройке соединения между процессорами, которые обрабатывают потоковые файлы, дата-инженеру следует выбрать стратегию балансировки:

✔️без балансировки нагрузки — это значение по умолчанию
✔️циклический режим (Round Robin) – потоковые файлы будут распределяться по кластеру в циклическом режиме. Если узел отключен от кластера или не может связаться с узлом, данные, поставленные в очередь для этого узла, будут автоматически перераспределены на другие узлы.
✔️один узел, когда все потоковые файлы будут распределены на один узел в кластере. Если же этот узел отключен от кластера или с ним невозможно связаться, данные, поставленные в очередь для этого узла, останутся в очереди до тех пор, пока узел снова не станет доступным. Все соединения, для которых настроена эта стратегия, будут отправлять данные на один и тот же узел.

Далее подробно рассмотрим стратегии балансировки и распределания данных.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/nifi-load-balancing.html

#AirFlow #ETL #статьи
✳️7 полезных практик работы с Apache AirFlow для дата-инженера

Эти рекомендации помогут дата-инженеру более эффективно эксплуатировать Apache AirFlow при проектировании конвейеров обработки данных:
✅использование словаря defaultargs позволяет указать аргументы по умолчанию для DAG, включая дату начала и частоту запуска, чтобы избежать жесткого кодирования этих значений и упростить их изменение в будущем
✅шаблонизация DAG может сделать их разработку более гибкой, позволяя избежать повторного написания одинакового кода
✅встроенные операторы AirFlow отлично подходят для выполнения общих задач, таких как выполнение SQL-запроса или передача данных между системами. Это позволяет избежать написания пользовательского кода и сделать DAG более удобными в сопровождении
✅функции ветвления и запуска AirFlow упрощают создание сложных рабочих процессов, позволяя создавать DAG с несколькими ветвями и зависимостями без усложнения управления этим конвейером
✅встроенная интеграция AirFlow с Git помогает отслеживать изменения в DAG и реализует совместную работу дата-инженеров в разных командах
✅встроенные функции ведения журналов и мониторинга AirFlow пригодятся, чтобы отслеживать DAG, устранять возникающие проблемы с конвейером обработки данных и быстро их исправлять.
Отдельно стоит сказать про некоторые операторы AirFlow, которые также пригодятся дата-инженеру.
Это рассмотрим далее.

@BigDataSchool_ru
https://www.bigdataschool.ru/blog/best-practices-for-dag-design-and-airflow-operators.html

#BigData #ETL #статьи
2 способа организации конвейеров инкрементной загрузки данных

Инкрементный ETL (Extract, Transform and Load) для классического DWH стал обычным явлением с источниками CDC (сбор данных об изменениях).
Но для озера данных инкрементный ETL сложен из-за невозможности обновления данных и выявления измененных данных в больших таблицах.
На высоком уровне инкрементный ETL означает перемещение новых или измененных данных между источником и местом назначения. Инкрементный ETL можно либо запланировать как задание, либо запустить непрерывно для доступа к новым данным с малой задержкой.
Данные могут перемещаться и преобразовываться в нескольких таблицах, каждая из которых может использоваться для разных целей.

Уточним, что термин «инкремент» здесь означает не единицу поставки бизнес-ценности, как в продуктовом подходе и Agile, а изменение относительно предыдущего состояния.
Однако, организация конвейеров инкрементных загрузки больших таблиц фактов/событий в корпоративное озеро является достаточно сложной задачей.

Существует два основных способа инкрементного чтения данных: максимальная отметка времени, что популяризируется инструментом dbt, а также разделение по дате, что часто используется с AirFlow и Hive.

Чтение данных путем нахождения максимальной временной метки состоит из 2-х этапов:
✔️если таблицы не существует, вся ее история вычисляется за один раз
✔️если таблица существует, к ней отправляется запрос, чтобы найти последнюю обработанную метку времени, а затем использовать ее для фильтрации исходных данных восходящего потока.

В качестве примера возьмем данные о событиях пользовательского поведения и рассмотрим дальше.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-implement-data-pipeline-for-incremental-loading.html

#ETL #NiFi #статьи
Главные новинки Apache NiFi 1.22.0: обзор июньского релиза

Основные моменты выпуска 1.22.0 включают:
✔️Агенты MiNiFi теперь могут общаться с серверами C2
✔️Добавлены новые процессоры
✔️Процессор PutDatabaseRecord
✔️Некоторые компоненты и функции помечены как устаревшие или удалены

Релиз 1.22.0 содержит не так много новых фич, но некоторые из них достаточно интересные.
В частности, реализовано предоставление метрик JMX из NiFi JVM. Это необходимо, чтобы предоставлять системные данные безопасным способом через конечную точку REST API со списком атрибутов JMX Bean.

Большинство процессоров NiFi используют внешние библиотеки, которые могут регистрировать компоненты JMX, такие как процессоры Kafka и пр. Использование таких системных метрик пригодится в отладке конвейера данных.

Доступная информация зависит от зарегистрированных Bean-компонентов и обычно связана с показателями производительности, такими как частота запросов/ответов, задержка, размер запроса, количество запросов или специфичными для инструмента параметрами, такими как скорость фиксации или время синхронизации/присоединения для Kafka.

Также добавлена служба контроллера, которые рассмотрим далее

@BigDataSchool_ru
https://bigdataschool.ru/blog/nifi-1-22-0-release-overview.html

#BigData #ETL #статьи
Архитектура конвейеров обработки данных: ETL/ELT-процессы

Конвейер данных — это целая система из скриптов, сервисов, хранилищ данных и технологий работы с ними, которая собирает, упорядочивает, преобразует и маршрутизирует данные.

Высокоуровневая архитектура конвейера данных описывает представление процессов и преобразований, которым подвергается набор данных на протяжении всего своего жизненного цикла, начиная с начального этапа сбора и заканчивая моментом использования.

Ее детализация на более низком уровне абстракции включает описание и настройки специфичных инструментов и фреймворков, которые решают отдельно взятые задачи конвейера, например, извлечение данных из внешней реляционной базы или преобразование форматов с помощью операторов Apache AirFlow или процессоров NiFi.

Суть любого конвейера данных сводится к реализации ETL/ELT-процессов, включая следующие этапы:
✅сбор исходных данных из внешних источников – устройств, ПО, файловых хранилищ или баз данных посредством прямого обращения к ним или через вызовы API.
В случае асинхронной потоковой обработки данных могут использоваться брокеры сообщений, такие как Apache Kafka, Pulsar, RabbitMQ и пр., которые обеспечивают передачу событий от приложений-продюсеров к системам-потребителям с минимальным риском потери или дублирования данных.
✅Прием данных: собранные данные переносятся на уровень хранения для дополнительной подготовки перед анализом. Уровень хранения может принимать форму реляционной базы данных или файлового/объектного хранилища, т.е. озера данных.
На этом этапе данные могут быть каталогизированы и профилированы, чтобы дать представление об их схемах, а также статистическую информацию, такую как кардинальность и пропущенные значения.
Кроме того, информация о происхождении может быть записана для документирования того, как данные изменялись с течением времени.
✅Преобразование данных с помощью процедур агрегирования, очистки и обработки, чтобы привести их в соответствие с установленными стандартами организации и подготовить к дальнейшему анализу.
Сюда же входит изменение форматов файлов, сжатие и разделение данных. На этом этапе данные из различных источников могут быть объединены и обогащены, чтобы ускорить их обработку потребителями.
✅Потребление данных, когда обработанные данные передаются в производственные системы для оперативного использования.
Чтобы все компоненты этого конвейера данных работали слаженно, необходимо обеспечить непрерывный мониторинг, обработку ошибок и поддержку целостности.

Как это сделать с помощью обработки исключений, и какие исключения бывают в конвейерах обработки данных, рассмотрим далее.

@BigDataSchool_ru
https://bigdataschool.ru/blog/exception-handling-in-data-pipelines.html

#ETL #статьи
От ETL к ELT и обратно: предыстория

Архитектура конвейеров обработки данных претерпела несколько итераций от ETL, ELT, XX ETL (Reverse ETL, Zero-ETL) до EtLT. 
Если экосистема Hadoop в основном полагалась на ELT-методы (извлечение, загрузка, преобразование), появление хранилищ и озер данных, работающих в реальном времени сделало ELT устаревшим. 

Впрочем, исторически первой архитектурой конвейера обработки данных считается ETL. Она основана на появлении корпоративных хранилищ данных в 1990-хх гг. Билл Инмон, автор методологии DW 2.0, определил Data Warehouse как архитектуру хранения данных для разделенных субъектов, где данные классифицируются и очищаются во время хранения.

В то время большинство источников данных были структурированными реляционными базами, а хранилища преимущественно работали с OLTP-кейсами для запросов и хранения истории. Обработка сложных ETL-процессов с такими базами данных была не так-то проста. Чтобы решить эту проблему, появилось множество ETL-инструментов (Informatica, Talend, Kettle и пр.), которое упростило интеграцию сложных источников данных и повысило эффективность рабочих нагрузок хранилища данных.

Классическая ETL-архитектура обеспечивала плавную интеграцию сложных источников данных и переносила почти половину операций работы с хранилищем на ETL-инструменты. Поэтому почти 20 лет, с 90-хх гг. XX века до конца первого десятилетия XXI века включительно архитектура ETL считалась отраслевым стандартом инженерии данных. Однако, из-за высокой степени вовлечения профессиональных дата-инженеров, которые работали со специализированными ETL-инструментами, цикл обработки бизнес-требований становится довольно длинным.

Поэтому примерно с 2005 года начала активно развиваться архитектура ELT. Появились системы с массивно-параллельной обработкой (MPP, Massively Parallel Processing) и распределенные технологии, что привело к постепенному переходу от ETL к ELT. Наиболее яркими примерами здесь можно назвать продукты компании Teradata и Hadoop Hive, которые сосредоточились на прямой загрузке данных в промежуточный уровень хранилища без сложных преобразований, таких как объединение и группировка.

Далее выполнялась обработка с использованием SQL или HQL из промежуточного уровня в атомарный уровень данных, далее в уровень агрегации и представления. Решения Teradata работали со структурированными данными, а Hadoop с неструктурированными.

Использование высокопроизводительных вычислений хранилища данных для обработки больших объемов данных повышает рентабельность инвестиций в оборудование. Сложная бизнес-логика может обрабатываться с помощью SQL-запросов, с которыми знакомы большинство аналитиков и дата-инженеров.

Далее поговорим про архитектуру данных EtLT

@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-etlt-data-acrhitecture.html

#ETL #статьи
Архитектура данных EtLT: появление и развитие

Архитектуру EtLT можно считать повторным открытием ETL с ориентацией на современные вызовы: работа со множеством различных источников данных в реальном времени.

Популяризации архитектуры EtLT с 2020 года послужили следующие факторы:
✔️распространение SaaS-решений, облачных и гибридных источников данных;
✔️ориентация корпоративных хранилищ и озер данных на обработку в реальном времени;
✔️федерализация больших данных нового поколения;
✔️распространение приложений ИИ;
✔️фрагментация сообщества корпоративных данных.

В современной архитектуре данных появилось новое поколение технологий, направленных на ускорение загрузки данных, исключение их перемещения между различными хранилищами данных и выполнение сложных запросов напрямую через коннекторы. 
Например, TrinoDB и OneHouse на базе Apache Hudi. Эти инструменты отлично подходят для кэширования данных и оперативных запросов к различным источникам.

Кроме того, появление ChatGPT в 2022 году привело к использованию ИИ-моделей в различных бизнес-приложениях. 
Однако, узким местом для развертывания таких приложений стало предоставление данных, которое было решено озерами данных и федерализацией больших данных для хранения данных и запросов. 

Однако традиционные ETL, ELT и потоковая обработка не могут быстро интегрировать различные источники данных, не поддерживают разнообразные требования к данным, необходимые для обучения ИИ.
Наконец, растет разнообразие пользователей данных от дата-инженеров до аналитиков различных категорий и специалистов по ИИ.

EtLT улучшает классические архитектуры ETL и ELT, сочетая обработку данных в реальном времени с пакетной обработкой для соответствия требованиям к хранилищам и озерам данных в реальном времени с учетом многообразия пользователей и потребности в использовании приложений ИИ.
▶️На этапе извлечения (Extract) EtLT поддерживает традиционные локальные базы данных, файловые хранилища, а также API SaaS и бессерверные источники данных. Эта архитектура может выполнять CDC в реальном времени для реляционной базы данных и потоковой обработки в реальном времени, например, Kafka Streams, а также поддерживает многопоточное чтение разделов.
▶️Этап нормализации данных и их предварительного преобразования (t, transform) быстро изменяет сложные и разнородные данные, извлеченные из разных источников, в структурированный вид, чтобы загрузить их в целевое хранилище. CDC реализуется через разделение, фильтрацию и изменение форматов полей, поддерживая пакетную и потоковую парадигмы.
▶️Этап загрузки (Load) связан не только с загрузкой данных: он также включает в себя адаптацию структур и содержимого источника данных в соответствии с целевым объектом данных. На этом этапе обрабатываются изменения структуры данных (Schema Evolution) в исходном коде и выполняются эффективные методы загрузки пакетных и потоковых данных, такие как массовая загрузка, Reverse ETL и JDBC.
▶️Этап преобразования (Transform) обычно реализуется с помощью SQL в реальном времени или в пакетном режиме с использованием сложных бизнес-правил, характерных для бизнес-приложений или ИИ.

Существует несколько реализаций EtLT с открытым исходным кодом, например, dbt, Apache Dolphin и SeaTunnel. В частности, SeaTunnel включает поддержку крупномасштабных моделей, что позволяет им напрямую взаимодействовать с более чем 100 поддерживаемыми источниками данных, начиная от традиционных баз данных и SaaS. Также SeaTunnel поддерживает обучение крупномасштабных моделей и векторных баз данных, обеспечивая беспрепятственное взаимодействие между большими языковыми моделями, позволяя использовать ChatGPT для прямого создания SaaS-коннекторов.

@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-etlt-data-acrhitecture.html

#ETL #статьи
Как работает Neo4j-ETL

В рамках развития своих продуктов, таких как графовая СУБД Neo4j и экосистема элементов вокруг нее (Graph Data Science, Neo4j Bloom, Neo4j Browser и пр.), компания-разработчик реализует проект Labs – сборник новых идей и гипотез.
После тестирования в Labs исходный код проекта становится общедоступным, а сам проект переводится в статус официального проекта Neo4j или объявляется устаревшим. Проекты Labs активно разрабатываются и поддерживаются онлайн-сообществом, но при нахождении в этом репозитории компания Neo4j не предоставляет для библиотеки или приложения никаких соглашений об уровне обслуживания или гарантий в отношении обратной совместимости и устаревания.

Впрочем, несмотря на отказ от ответственности, среди проектов Labs есть довольно интересные инструменты для работы с графами. Например, инструмент Neo4j-ETL, который упрощает загрузку данных из реляционных баз в графовую СУБД. Он позволяет получить графовую модель из реляционной метамодели, чтобы затем адаптировать ее под задачи анализа графов.
Помимо такого преобразования, этот инструмент также выполняет фактический импорт данных. Для интерактивного моделирования и импорта CSV-файлов можно воспользоваться инструментом Neo4j Data Importer.

Neo4j-ETL поддерживает управление несколькими соединениями РСУБД, может автоматически извлекать метаданные из реляционной базы данных, позволяет получить графовую модель, а также визуально редактировать метки, типы отношений, имена и типы свойств.
Инструмент визуализирует текущую модель данных в виде графа, позволяет сохранить отображение в формате JSON, получить соответствующие данные в CSV-формате из реляционных баз данных и запустить массовый или онлайн-импорт. Средство поддерживает популярные реляционные СУБД MySQL и PostgreSQL, а также может использовать собственный JDBC-драйвер в версии Enterprise для подключения к другим хранилищам.

С Neo4j-ETL весь процесс конвертации реляционных данных в графовую модель сводится к следующим шагам:
✔️Настройка соединения с реляционной базой данных;
✔️Запуск импорта данных в Neo4j;
✔️Проверка сопоставления схемы и корректировка графовой модели данных.

Есть несколько различных способов, с помощью которых инструмент ETL может импортировать данные в Neo4j, в зависимости от состояния графовой базы данных. Если база данных активна, т.е. работает, то используется прямой доступ (Online Direct), который запускается через BOLT-соединение для импорта, превращая результаты SQL-запросов в параметры Cypher.

Также можно запустить пакетный режим онлайн с использованием CSV-файлов для пакетного импорта через BOLT-соединение. Если база данных закрыта, т.е. не работает, быстрее всего будет массовый импорт – автономный загрузчик, запускаемый через утилиту neo4j-admin.

@BigDataSchool_ru
https://bigdataschool.ru/blog/neo4j-etl-and-migrations.html

#ETL #статьи
ТОП-10 целей Apache NiFi 2.0

Чтобы повысить безопасность, снизить сложность и внедрить новые функции, NiFi 2.0 сфокусирован на сокращении технического долга.
Согласно принципам семантического управления версиями, мажорный выпуск предоставляет возможность внесения критических изменений, которые исключают обратную совместимость с предыдущими версиями.

15 декабря 2022 года комитет по управлению проектом Apache NiFi проголосовал за принятие следующих основных целей нового мажорного релиза:

✔️внедрить поддержку Java 11 вместо Java 8. В частности, для Jetty 10 требуется и OpenSAML 4 требуется Java 11. Поддержка Java 8 в Kafka 3 прекращена в сентябре 2021 года, а в Spring 6 – в ноябре 2022 г.
✔️удалить устаревшие компоненты и свойства компонентов, включая процессоры и службы контроллеров, помеченные как неподдерживаемые или замененные лучшими альтернативами. Удаление устаревших свойств компонента позволит сохранить существующие процессоры, устраняя при этом дублирующиеся параметры конфигурации. Например, свойства PGP в EncryptContent и связанные с ними возможности теперь реализованы в EncryptContentPGP и DecryptContentPGP. Свойства Keytab непосредственно в процессорах, поддерживающих Kerberos, а KeytabCredentialService заменены на KerberosUserService.
✔️удалить компоненты, интегрирующиеся с необслуживаемыми сервисами и/или их устаревшими версиями без технической поддержки;
✔️удалить ненужные классы и методы, например, PersistentProvenanceRepository, Стандартный RecordWriter NiFiLegacyCipherProvider и связанные с ним методы шифрования supportExpressionLanguage() без аргументов, пользовательские классы InputStream и OutputStream.
✔️заменить представление внутренней конфигурации потока в файле flow.xml.gz на flow.json.gz. В NiFi 1.16.0 представлен flow.json.gz для хранения конфигурации потока с использованием классов модели версионных компонентов. Более простой JSON-формат снижает затраты на сохранение конфигурации и синхронизацию нескольких представлений и уже используется в NiFi, NiFi Stateless и NiFi Registry.
✔️удалить дублирующиеся функции и элементы, например, шаблоны XML, замененные JSON-представлениями и реестр переменных, замененный контекстом параметров;
✔️обновить внутренние ссылки на API Java — перенос внутреннего использования классов util.Date в java.time обеспечит большую точность анализа и форматирования. Это предполагает рефакторинг использования классов DateTimeFormatter и java.time в компонентах, ориентированных на записи.
✔️Реорганизация стандартных компонентов для уменьшения размера и объема процессоров и пакетов NAR Standard Services. Компоненты со специализированными зависимостями будут перемещены из стандартных процессоров (SFTP, HTTP, JSON, Netty) в отдельные пакеты.
✔️Внедрение инструментов миграции для обновления потоков, включая автоматическую миграцию для переназначения свойств и функций, преобразования шаблонов XML в определения потока JSON.

В следующий раз поговорим про важные возможности и ключевые изменения.

@BigDataSchool_ru
https://bigdataschool.ru/blog/perspectives-of-nifi-2-0-coming-soon.html

#ETL #статьи
Важные возможности и ключевые изменения

В Apache NiFi 2.0 ожидается поддержка Python, что очень порадует многих дата-инженеров и разработчиков. Впрочем, использовать Python в этом ETL-фреймворке можно уже сейчас.

Также будет добавлена возможность запуска группы процессов с использованием NiFi Stateless – компонента, который обеспечивает механизм потока данных с меньшим масштабом и набором функций. Он не включает пользовательский интерфейс для создания или мониторинга потоков данных, а просто запускает потоки данных, созданные с помощью приложения NiFi.
NiFi Stateless может хранить все данные в памяти или использовать дисковый репозиторий для содержимого FlowFile, чтобы избежать необходимости использования очень больших куч Java.

Однако, данные не будут восстановлены после перезапуска, что и обусловливает название компонента – без сохранения состояния. Использование NiFi Stateless на уровне группы процессов позволит реализовать транзакционные сценарии потокового конвейера обработки  данных, когда поток следует рассматривать как единую транзакцию. Это пригодится в случае захвата измененных данных (CDC, Change Data Capture).

Также ожидается улучшение движка обработки правил (Rules Engine), который дает рекомендации проектировщику потока данных по настройке компонентов, опираясь на лучшие практики современной дата-инженерии.

Как уже было отмечено, вместо XML-представлений будут использоваться JSON-структуры. Шаблоны XML хранятся в памяти NiFi, а также в постоянном определении потока (файлы flow.xml.gz и flow.json.gz), и это вызвало множество проблем у пользователей с десятками или сотнями массивных шаблонов с тысячами компонентов. Удаление всего этого повысит стабильность NiFi и улучшит использование памяти.

При переходе на новую версию придется экспортировать шаблоны в виде определений JSON или создать версию шаблонов в экземпляре реестра NiFi. Лучше использовать реестр NiFi вместе с самим фреймворком, чтобы контролировать версии и определения потока данных для совместного и повторного использования.
Для этого, если шаблон представляет собой группу процессов, можно перетащить его на холст, а затем через контекстное меню экспортировать его как определение потока (файл JSON) или запустить контроль версий в реестре NiFi. Если шаблон не является группой процессов, а представляет собой непосредственно поток с компонентами, нужно перетащить группу процессов, затем перейти в эту группу процессов и перетащить туда шаблон.
Далее можно вернуться к родительской группе процессов, содержащей шаблон, и экспортировать ее как определение потока или запустить для нее контроль версий.

Переменные и реестр переменных исчезнут, поскольку они имеют множество ограничений, таких как необходимость поддержки языка выражений в свойстве для ссылки на переменную и невозможность хранения конфиденциальных значений. 
Вместо этого будут использоваться контексты параметров, которые поддерживают концепцию провайдеров. Например, провайдер контекста параметров для получения значений параметров из внешних хранилищ, таких как HashiCorp, хранилища облачных провайдеров и пр.

Стратегия планирования на основе событий была экспериментальной опцией, доступной на некоторых процессорах. Поскольку она не принесла каких-либо существенных улучшений производительности, в версии NiFi 2.0 ее не будет.
Вместо этой стратегии следует использовать стратегию планирования на основе таймера. Для более простого отслеживания удаленных и устаревших компонентов в NiFi есть специальный файл журнала nifi-deprecation.log, который содержит их перечисления.

Наконец, для обновления зависимостей в пользовательских компонентах, в набор CLI-инструментов NiFi 2.0 будет добавлена команда рекурсивного изменения текущих версии всех экземпляров компонента на более новые.

@BigDataSchool_ru
https://bigdataschool.ru/blog/perspectives-of-nifi-2-0-coming-soon.html

#ETL #статьи
Моментальные снимки: периодическая выгрузка данных из исходных таблиц

Полная периодическая выгрузка данных из одной или нескольких таблиц – это, пожалуй, самый простой метод извлечения изменяемых данных. 
По своей сути результат полной выгрузки представляет собой так называемый полный моментальный снимок, фиксирующий состояние базы данных на конкретный момент времени. Он очень прост для реализации и довольно эффективен для небольших таблиц и нечасто изменяющихся измерений.
Однако, производительность операций снижается по мере увеличения размера исходной таблицы, и не сохраняется история изменения данных, поскольку каждый раз при выполнении конвейера извлечения происходит перезагрузка данных.

Вместо создания полного моментального снимка, что занимает много времени на большой базе данных, можно делать это частями, ограничив период извлечения.
Например, извлекать только данные за последние несколько месяцев. Разумеется, этот шаблон извлечения требует наличия отметки времени для фильтрации последних записей. Так можно избежать многократного извлечения больших неизмененных исторических данных. Такой метод довольно эффективен для небольших и средних таблиц со множеством исторических записей. Но он предполагает дополнительные операции вычисления дублей и обеспечения согласованности данных по сравнению с методом полного моментального снимка.

Кроме того, изменение и удаление данных фиксируется только за охватываемый период. Этот подход основан на наличии столбца отметки времени изменения в исходной таблице, который всегда должен быть корректен при добавлении или изменении записи в источнике. Также при реализации этого метода может потребоваться проверка схемы данных.

На практике метод неполного моментального снимка подходит для использования в сценариях, где большая таблица разделяется по месяцам, и использование месяца в качестве предиката может ускорить операцию извлечения, чем группировка по отметке времени. Также этот способ подходит, если данные в источнике могут быть изменены вручную: тогда просто надо извлечь данные с более длительным сроком хранения.

В заключение разговора про моментальные снимки отметим, что можно делать полный моментальный снимок и сохранять результат в отдельном репозитории, указав версию создания. Так можно отслеживать историю изменения данных. Часто этот подход реализуется в виде отдельного конвейера для сохранения текущего состояния исходных таблиц в отдельном наборе данных.
При этом в итоге будет сохранено два набора данных: один содержит всю историю с повторяющимися данными, а другой  — содержит только текущее состояние БД.

Таким образом, часть данных в разных репозиториях будет дублироваться, занимая место на дисковом пространстве. Поэтому придется применять такие политики хранения, чтобы периодически удалять старые данные для освобождения места. Кроме того, операция создания моментального снимка на больших объемах данных выполняется довольно долго. Таким образом, этот метод не подходит для больших и быстро меняющихся наборов данных или измерений.

@BigDataSchool_ru
https://bigdataschool.ru/blog/news/how-to-extract-data-from-relational-databases.html

#ETL #статьи
Что такое гонка данных в дата-инженерии

Одна из главных особенностей распределенных систем – это задержка между обновлением одних и тех же данных на разных компонентах. Это очень важно при реализации конвейеров обработки данных, которые зависят друг от друга.

Проектирование таких ETL-конвейеров усложняется, если есть строгие требования к последовательности обработки данных и ссылочной целостности. А когда данные поступают с разной скоростью из разных источников с различными соглашениями об уровне обслуживания, возникает так называемая гонка данных.

Вообще состояние гонки или неопределенность параллелизма довольно характерно для распределенных систем стека Big Data из-за большого количества сервисов и огромного количества событий.

Гонка данных является одним из случаев состояния гонки, возникающим при параллельном выполнении кода в многопоточном режиме, когда поведение системы зависит от того, в каком порядке выполняются части кода.

Проблемы параллелизма обычно незаметны при разработке и тестировании, а проявляются только в производственных средах на высоких рабочих нагрузках.

Если поведение системы зависит от последовательности событий, которая не является детерминированной и явно не контролируется, состояние гонки рано или поздно возникнет. Это характерно для многопоточных и многопроцессорных систем, а также проявляется в конвейерах обработки данных в виде гонки данных, когда один процесс обращается к фрагменту данных, который в это время изменяется другим процессом.

Чтобы понять, как это может случиться, чем опасно и какие способы позволят избежать этого, далее по ссылке рассмотрим практический пример.

@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/how-to-avoid-race-conditions-in-etl-pipelines.html