✨ Иван Клименко (Arenadata) — CDC в банке от источника до хранилища с применением продуктов Arenadata

Ссылка на выступление:

https://youtu.be/nfZdDzr_Y_Y?si=l69ZPYfI0_j5souJ
Или
https://vk.com/video-147464741_456239459

Сложность: 1/3 (уверен, будет понятно, даже если не знаете, что такое CDC)
Кому будет интересно:
• Всем DE. Отличный кейс внедрения cdc.

Иван Клименко рассказал о внедрении CDC (Change Data Capture) в банке Синара с использованием продуктов Arenadata. Основной фокус был на оптимизации загрузки данных из операционных баз в Greenplum.

🔍 Основные моменты:
1️⃣ Что такое CDC:
• CDC отслеживает изменения в базе данных (например, Oracle) и переносит их в целевые системы (Greenplum).
• Используется для инкрементальной загрузки данных, что позволяет избежать полной перезагрузки таблиц.
• Debezium был выбран как оптимальное решение благодаря гибкости, поддержке. Все использованные решения - open source или входят в Arenadata.
2️⃣ Проблемы до внедрения CDC:
• Данные загружались напрямую через PXF, что вызывало проблемы с большими таблицами и не укладывалось в SLA.
• Ежедневная перезагрузка больших таблиц без инкрементальных полей была неэффективной.
3️⃣ Архитектура решения:
• Используется экосистема Arenadata Streaming: Kafka, Nifi и Greenplum.
• Данные из Oracle через Debezium попадают в Kafka, затем преобразуются и загружаются в Greenplum.
4️⃣ Оптимизация пайплайна:
• Переход на бинарный формат Avro вместо JSON для уменьшения объема данных.
• Разделение процесса на два независимых потока для улучшения производительности.
• Использование JOLT Transform для приведения данных к плоскому виду.
5️⃣ Производительность:
• Прирост производительности на исторических данных более чем в 100 раз.
• Загрузка таблицы с 1,6 миллиардами записей занимает менее 10 минут.
• Debezium увеличил нагрузку на Oracle на 7-10% в пиковые дни.
6️⃣ Работа с Greenplum:
• Данные из Kafka загружаются в Greenplum через внешние таблицы и коннектор Kafka2ADB. Конечные витрины сгружаются в Kafka с помощью ADB2kafka коннектора.
• Для минимизации нагрузки на мастер-ноду используется рандомное распределение данных между сегментами и количество партиций в Кафка, кратное количеству сегментов в GP.
• Рекомендуется удалять или архивировать сырые данные.
7️⃣ Первичная загрузка:
• Первичная загрузка данных осуществляется через PXF, что позволяет избежать проблем с локализацией таблиц и схем.
• Возможны дубли данных, но система умеет с ними работать.

💡 Плюсы решения:
• Инкрементальная загрузка: Уменьшает время загрузки и нагрузку на источники данных.
• Масштабируемость: Использование Kafka и Greenplum позволяет эффективно распределять данные.
• Производительность: Значительное ускорение загрузки и обработки данных.

⚠️ Минусы и ограничения:
• Нагрузка на источники: Debezium незначительно увеличивает нагрузку на операционные базы данных и требует обсуждений с ИБ и инфраструктурой.
• Сложность настройки: Требуется тщательная настройка коннекторов и пайплайнов.

📌 Ответы на вопросы:
1️⃣ Использование коннекторов Confluent и их безопасность:
• Используются только библиотеки, выложенные под лицензией Apache. Платные решения Confluent не применяются. Все использованные решения open source или входят в поставки Arenadata.
2️⃣ Почему не использовали Oracle для хранилища?
• Решение связано с политикой импортозамещения.
3️⃣ Как распределяются данные между сегментами в Greenplum при загрузке из Kafka?
• Рекомендуется использовать рандомное распределение, чтобы данные из партиций Kafka сразу попадали на свои сегменты. В противном случае потребуется редистрибуция. Количество партиций в Кафка должно быть кратно количеству сегментов в GP.
4️⃣ Производительность коннектора Kafka:
• За 15 секунд считывается около миллиона записей в формате JSON.
5️⃣ Первичная загрузка через PXF:
• Включается Debezium, данные загружаются через PXF. Возможны дубли, но система умеет с ними работать.

📌 Выводы:
Внедрение CDC с использованием Debezium, Kafka и Greenplum позволило значительно улучшить процесс загрузки данных.

Скрин архитектуры Data Platform банка из последнего поста.

Пожалуйста, делитесь нашими постами с коллегами)

✨ Наталья Журавлева — Как быстро запустить каталог данных на примере DataHub

Ссылка на выступление: https://youtu.be/nCt4gYVQdqc?si=Fbwab0cQxgMl4g3a
или
https://vkvideo.ru/video-147464741_456239425

Сложность: 2/3 (Техники очень мало, но теория и концептуальное погружение в доклад требуется. В фоне смотреть тяжело, нужно погружаться)

Кому будет интересно: Аналитикам и архитекторам. Если Вам интересна только техника - пропускайте доклад, примеров по технике и коду в нём нет. Но я очень рекомендую доклад посмотреть, так как Наталья очень интересно рассказывает про проблемы всех хранилищ и как облегчить боль непосредственных пользователей от работы с ними. И не могу не отметить, что Наталья очень захватывающе рассказывает, одно удовольствие её слушать :)


---

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

---

🔍 Ключевые идеи доклада:

1️⃣ Проблемы без каталога данных:
- Дублирование данных и непонимание структуры
- Зависимость от экспертов и "устных традиций"
- Документация в Confluence быстро устаревает

2️⃣ Логическая модель — фундамент каталога:
- Три уровня моделирования:
• Концептуальный (бизнес-сущности)
• Логический (атрибуты и связи)
• Физический (реализация в БД)
- В якорной модели логическую схему можно сгенерировать в полу автоматическом режиме
- Хранится в YAML-файлах с версионностью через merge-реквесты

3️⃣ Процесс работы с моделью:
1. Аналитик описывает сущность в YAML
2. Разработчик реализует маппинг на физическую модель
3. Каталог автоматически подхватывает изменения

4️⃣ Выбор технологий:
- Отказ от Confluence в пользу специализированного решения
- Выбор DataHub вместо OpenMetadata
- Интеграция проверок качества данных (DQ)

---

💡 Преимущества подхода:
✅ Сокращение времени на документирование на 60%
✅ Автоматическое обновление каталога
✅ Обнаружение ошибок в существующей логике хранилища
✅ Единый источник правды для всех команд

---

⚠️ Сложности и ограничения:
- Создание логической модели требует времени
- Трудности единой модели для всех хранилищ
- Необходимость дополнительных инструментов моделирования

---

📌 Практические советы:
1. Начинайте с логической модели, пишите документацию всегда и сразу.
2. Автоматизируйте процесс наполнения каталога
3. Для разных хранилищ используйте разные модели
4. Внедряйте DQ-проверки прямо в каталог

---

🤔 Ответы на вопросы из зала:

Q: Как бизнес-пользователи работают с каталогом?
A: Через концептуальный уровень, который описывает данные в бизнес-терминах

Q: Почему выбрали DataHub?
A: Сравнивали с OpenMetadata — DataHub показался более зрелым решением

Q: Сколько ресурсов потребовалось?
A: Команда из 6 аналитиков, 1 разработчика и 1 DevOps за 6 месяцев

---

📌 Выводы:
Внедрение каталога данных через логическую модель и DataHub значительно упростило работу с данными в компании.

Следующий Digest доклада будет в выходные про шикарный EL инструмент - airbyte.

Пока рекомендую фоном посмотреть дискуссию про будущее Greenpum на T-Meetup: https://www.youtube.com/watch?v=EXRLqI9mx54&list=PLLrf_044z4Jp8l6GauGEmbZXIwABfrbRQ

✨ Александра Попова — Airbyte: 2 года в продакшене

Ссылка на выступление: https://youtu.be/fgaBGc3VWWQ?si=jvH4kmqF8lyjc70-
или
Ссылка на выступление: https://youtu.be/fgaBGc3VWWQ?si=jvH4kmqF8lyjc70-

Сложность: 2/3 (Практико-ориентированный доклад, требует базового понимания ETL-процессов)

Кому будет интересно:
- Архитекторам и простым инженерам, которые понимают, как дотащить данные от источника в хранилище.

---

Александра поделилась опытом внедрения и эксплуатации Airbyte в СберЗдоровье с 2022 по 2024 год. Airbyte - один из мощных инструментов modern data stack, очень рекомендую к ознакомлению)

---

🔍 Ключевые моменты внедрения:

1️⃣ Проблемы до Airbyte (2021):
- Разнородные скрипты для забора данных
- Неэффективное управление ETL-процессами
- Отсутствие стандартизации

2️⃣ Выбор Airbyte:
- Большое комьюнити и готовые коннекторы
- Python CDK для кастомных разработок
- Поддержка инкрементальной синхронизации и CDC (на базе Debezium)

3️⃣ Архитектурные особенности:
- Микросервисная архитектура (ядро на Java, коннекторы на Python/Java)
- Развертывание в Kubernetes с разделением статических/динамических подов

---

⚙️ Функциональность Airbyte:
✔️ Методы синхронизации:
- Full refresh
- Incremental (с дедупликацией)
- CDC (PostgreSQL, MySQL, SQL Server, MongoDB)

✔️ Расписания:
- По временному интервалу
- Cron (добавлен в 2023)
- Ручной запуск

---

🛠 Практический опыт:

Проблемы и решения:
1. Отсутствие коннектора к Greenplum → Разработан кастомный коннектор на основе PostgreSQL
2. Потеря точности времени → Переход на CDC для инкрементальных синхронизаций
3. Ограничения UI → Использование API и YAML-конфигов для управления
4. Проблемы с расписанием → Решены в новых версиях airbyte через cron
5. Мониторинг → Настройка через sql-exporter

Производительность:
- Обработка до 100 ГБ данных
- Разделение нагрузки в Kubernetes
- Оптимизация через cleanup-политики

---

📊 Текущая архитектура (2024):
- Источники: БД (через CDC) и API
- Назначения: Greenplum, ClickHouse (с предварительным созданием ReplicatedMergeTree-таблиц)
- Оркестрация: Dagster для управления пайплайнами

---

💡 Преимущества Airbyte:
✅ Упрощение ETL-процессов
✅ Готовая поддержка 300+ коннекторов
✅ Гибкость через Python CDK
✅ Удобство мониторинга

⚠️ Ограничения:
- Нет встроенного механизма бэкфила
- Требует доработок для специфичных случаев
- Cloud-функции (ролевая модель) недоступны в open-source

---

🤔 Ответы на вопросы:

Q: Почему Airbyte вместо Airflow?
A: Готовые коннекторы и унификация процессов

Q: Как решается проблема бэкфила?
A: Периодической полной перезаписью данных

Q: Проблемы с CDC?
A: Нет проблем со скоростью репликации

Q: Почему не PXF для Greenplum?
A: Ограничения ИБ и сложность поддержки

---

📌 Выводы:
Airbyte отлично подходит для:
- Забора данных из БД и API
- Стандартизации ETL-процессов
- Быстрого старта с минимальной разработкой

Не подходит для:
- Стриминговых сценариев
- Сложных бэкфил-процессов

И приятный бонус. Александра любезно согласилась ответить на Ваши вопросы по докладу про airbyte в комментариях к этому посту)

✨ Пётр Гуринов и Сергей Куприков: Опыт внедрения Lakehouse в компании Лемана Тех.

Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s

Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH)

Кому будет интересно:
- Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться.

---

Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись.

---

🔍 Проблемы старой архитектуры
- Greenplum (Shared Nothing):
- Данные невозможно оторвать от compute
- Ограниченная масштабируемость
- Высокие затраты на хранение

- Pipeline до внедрения DLH:

Источники собираются в Kafka. Flink вычитывает данные, складывает их в S3 в формате avro (слой raw). Далее Spark трансфармирует данные в parquet, складывает данные
в S3 (слой ods). Оттуда данные попадают в GP, который является единой точкой входа всех сотрудников компании (любой сотрудник магазина может запросить доступ к DWH).
   

---

🚀 Переход на Lakehouse
Требования к новой платформе:
✔️ Open Source
✔️ Разделение compute/storage
✔️ Cloud-ready/cloud agnostic
✔️ Низкий порог входа

Выбранный стек:
- Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников)
- Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake)
- Хранение: S3
- Метаданные: HMS (планы на переход к Nessie для branch-поддержки)

---

⚙️ Реализация:
- Кластеры Trino:
- Ad hoc (пользователи/BI)
- ETL (тех.учетки)
- DQ (Data Quality)

Интеграция:
- Аутентификация через Keycloak + AD
- Управление доступом: file-based ACL

---

🛠 Проблемы и решения
Ограничения технологий:
- Нет коннектора Trino → Greenplum (ходят через Master)
- Iceberg: нет мультитранзакций, сложности с типами данных
- Trino: нет временных таблиц, legacy spill-файлы

🛠 Мониторинг:
- Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana.
-Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется.
Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset
- Кастомный сбор метрик запросов через Kafka → ClickHouse

🛠 Управление инфраструктурой:
- GitOps + ArgoCD + Vault
- Автоматические откаты

---

📊 Результаты
✅ Экономия:
- Хранение дешевле в 10+ раз
- Быстрое масштабирование в Kubernetes
- Независимое масштабирование и отсутствие необходимости резервировать место заранее.

✅ Производительность:
- Ускорение расчетов витрин
- Легкий переход запросов с GP на Trino
- Аналитики получают дополнительную точку входа для доступа к данным
- Разные вычислительные движки могут использовать одни и те же данные.
---

🔮 Планы
- Замена HMS на Nessie
- Продуктивизация SCD2-таблиц
- Автоскейлинг Trino на основе метрик
- Копирование Iceberg-таблиц в Greenplum
- Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only

---

💡 Вывод:
Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.

Отдельного поста заслуживают ответы на вопросы по выступлению команды Лемана Тех про LakeHouse. Я, пользуясь случаем, выражу благодарность комании querify labs (cedrus data) за организацию митапа. И, конечно, ребятам из Лемана Тех за то, что поделились своим опытом и готовы ответить на Ваши вопросы в комментариях к этому посту.

---

Как разделили ресурсы?
Ресурсные группы не настраивали, нагрузку разделили по разным кластерам.

Сравнение производительности Greenplum и Trino?
Trino медленнее Greenplum примерно на 20%, если у GP всё на SSD.

Рассматриваете ли Paimon как каталог?
Пока не тестировали, хотим подходить к вопросу с каталогом итеративно.

Почему выбрали Avro?
Технология удовлетворяла всем требованиям и хорошо знакомы с этой технологией, есть опыт работы.


Данные отправляют вам или вы их запрашиваете?
Команды не настраивают ничего сами, сервисная служба настраивает Debezium, дальше всё льётся в общую шину, а платформа данных уже самостоятельно забирает данные.

Как боретесь с большим количеством файлов в S3?
Сейчас поддерживаем вручную, планируется автоматизация.

Используете ли FTE (Fault-tolerant execution)?
Не используем, слишком медленно — просто перезапускаем при падениях.

Какой функционал Iceberg используете для ускорения запросов?
Индексы не накидывали, используем партиционирование и бакетирование. С сортировкой экспериментировали - большого эффекта не дала.

Как обеспечиваете high availability?
Пока всё в ручном режиме, координатор ни разу не падал.

Почему выбрали HMS?
Нужен был один каталог для работы с паркетами и Iceberg — HMS это закрыл.

---

Задавайте свои вопросы по выступлению) Тема очень актуальная и животрепещущая) Пётр и Сергей, по возможности, ответят на них)

✨ Валентин Пановский — Миграция на Iceberg: как кролик съел зеленую сливу и не умер

Сложность: 1/3 (Интересная историческая справка в начале , нет сложного кода, в который необходимо вникнуть. Докладчик рассказывает понятным и доступным языком)

https://www.youtube.com/watch?v=YWD7WcfFfk8

Валентин Пановский поделился опытом миграции с монолитного Greenplum на разделенную Lakehouse-архитектуру с Iceberg в страховой компании.

🔍 Проблемы старой системы

Монолитная DWH на Greenplum:
Высокая стоимость (лицензии + оборудование)
Сложности с масштабированием
Ограниченная гибкость для аналитиков
Гетерогенная среда:
50-70 ТБ данных за 4 года
Разные источники: MongoDB, Kafka, классические БД
🚀 Выбор новой архитектуры

Требования:
✔️ Разделение storage/compute
✔️ Open Source решения
✔️ Снижение TCO (полная окупаемость к 2025)

Выбранный стек:

Хранение: S3 (Яндекс.Облако) + Iceberg
Compute: Trino (основной) + Greenplum (легаси)
Оркестрация: Dagster + dbt
Каталог: OpenMetadata
⚙️ Реализация

1️⃣ Миграция данных:

Таблицы переносились "в лоб" через Airflow. Самая большая таблица - до 60 ГБ).
Основной объем — инкрементально (T+1)
2️⃣ Слои данных:

Raw → ODS → DDS → Витрины
Исторические данные: срезы раз в неделю + архив (6 месяцев)
3️⃣ Интеграции:

MongoDB: CDC через Debezium → Kafka → Greenplum (PXF)
Trino: Нативные коннекторы (проще чем в GP)
🛠 Проблемы и решения

Деградация JOIN-ов: До 27% в не-OLAP сценариях
Кастомные типы данных: Обработка на ETL-уровне
Хранимые процедуры: Пришлось переписывать витрины
Безопасность: Реализована через Trino + Keycloak
📊 Результаты

✅ Экономия:

Снижение затрат на лицензии и оборудование
Хранение в 10+ раз дешевле
✅ Гибкость:

Разные движки (Trino/GP) работают с одними данными
Легкое масштабирование в Kubernetes
🔮 Планы

Переход с HMS на Nessie (branch-поддержка)
Внедрение Data Vault вместо 3NF
Автоскейлинг Trino на основе метрик

🤔 Ответы на вопросы

Q: Как настраивали ИБ?
A: Вопросы изоляции и безопасности решались на уровне trino через системы аутентификации и политик доступа.

Q: Как решали проблему неконсистентных типов?
A: На ETL-уровне. MongoDB оставили как есть (легаси)

Q: Почему Parquet, а не ORC?
A: Лучшая производительность в наших тестах

Q: FTE не пробовали?
A: Нет, проще перезапускать (макс. запрос — 45 мин)

Q: Используете ли динамическое партиционирование?
A: Пока в бэклоге

💡 Вывод:
Миграция на Iceberg — сложный, но окупаемый процесс. Главные плюсы: гибкость, экономия и возможность использовать лучшие инструменты для разных задач.

✨ Татьяна Дидова — Как мы тестировали 5 способов загрузки данных в Greenplum и что из этого вышло

Сложность: 1/3 (Желателен минимальный опыт работы с Greenplum. Тем, кто в GP погружен максимально, вряд ли будет интересно, разве что про то, что sparkом тоже можно писать в GP, не через мастер)

YouTube:
https://www.youtube.com/watch?v=7EcieM3XoXE

VK Video:
https://vkvideo.ru/video-147464741_456239454

Татьяна Дидова, Tech Lead Data Engineer в АЭРО, знакомит слушателей со способами загрузки данных в GP.

🔍 Первый кейс: миграция с Oracle на Greenplum - "реализовать не хуже, чем есть на Oracle"
🔍 Второй кейс: Заказчика не устраивает процесс загрузки в ClickHouse, необходима реализация на Greenplum, результат должен быть сильно лучше.

Условия:
1️⃣ На первом проекте сотни баз, на втором - около десятка.
2️⃣ Количество баз данных и объем данных растет, объем выгружаемых данных отличается между источниками: в одном источнике десятки гигабайт, в другом - тысячи строк.
3️⃣ При создании базы данных на Greenplum, как правило, есть возможность выбрать оптимальный для данного случая способ загрузки, но при постановке задачи сделать не хуже или лучше, чем уже есть при использовании других технологий, были сформулированы требования по времени загрузки.

⚙️ Способы загрузки данных

non-parallel: Insert, Copy

✅ Нужен один сервер для развертки кода загрузчика
✅ Удобство отладки
⭕️ Высокая нагрузка на
мастер-узел
⭕️ Низкая эффективность при большом объеме данных

parallel:

1️⃣ PXF:

✅ Прямое подключение к источнику
✅ Достаточно знать SQL и credentials для подключения к источнику
⭕️ Сложность администрирования
⭕️ Сокращение ресурсов сегмента
⭕️ Повышение требований к источнику
⭕️ credentials в запросе создают проблемы с информационной безопасностью

2️⃣ Gpfdist:

✅ Оптимизация под работу с Greenplum
✅ Параметризация загрузки данных по сегментам
⭕️ Требовательность к производительности сети
⭕️ Необходимость управления несколькими экземплярами при больших объемах
⭕️ Масштабируемость ограничена
⭕️ Контроль портов

3️⃣ Spark-connector:

✅ Поддержка сложных трансформаций
✅ Расширение спектра источников
⭕️ Сложная первичная настройка
⭕️ Возможны проблемы с совместимостью
⭕️ Скорость загрузки может быть снижена

Далее в докладе приводится сравнение по времени загрузки, нагляднее всего отраженное в презентации.

🛠 Варианты ускорения:

🔨Общие:
1️⃣ Удалить индексы перед загрузкой данных. Иногда пересоздать индексы быстрее, чем постепенно обновлять имеющиеся.
2️⃣ Отключить автоматический сбор статистики
3️⃣ Запустить VACUUM, если при загрузке были ошибки

🪛 Частные случаи:
INSERT: попробовать COPY
COPY: запустить несколько COPY
PXF: оптимизация данных в источнике; изменение batch-size
Gpfdist: использовать PIPE; не сжимать передаваемые данные по возможности
Spark: расширить используемые ресурсы для execute node; изменить batch-size

📝 Архитектура 1:
Spark используется для больших загрузок, маленькие загрузки идут посредством COPY
📝 Архитектура 2: Источники - это postgreSQL, используется PXF для загрузки.

❔Ответы на вопросы:
Q: На чем была написана загрузка?
A: Использовался Python, так как логика первого проекта была зашита в DAG Factory. Во втором проекте PXF подключения генерировались с помощью скриптов на Python, позже PXF загрузки переехали на dbt.

Q: Делались ли замеры по использованию памяти?
A: Делались, но сконцентрировались на времени загрузки

💡Выводы:
<1 млн строк ➡️ non-parallel

>1 млн строк ➡️ parallel:
Высокая нагрузка при загрузке данных ➡️ PXF не подойдет
Файлы CSV/TSV ➡️ может подойти Gpfdist
Регулярные большие объемы данных ➡️ Spark connector

Николай Ижиков — One More Way to Make Backup in Ignite

Сложность: 3/3 (Обязательно к прослушиванию, если вам интересна работа с OLTP-нагрузкой и технические подробности снятия бэкапов)

Николай Ижиков, Platform V DataGrid Tech Lead, а также контрибьютор в Apache Kafka и участник PMC Apache ignite, рассказывает нам, как реализованы бэкапы в Platform V DataGrid, а главное — про cache dumps.

YouTube: https://www.youtube.com/watch?v=A3EkvdGK4Jg
VK Видео: https://vkvideo.ru/video-147464741_456239442

🔍 Условия:
Кластер процессинга: 32 узла, 700 ГБ RAM на узел, 40к RPS на узел.
Кластер токенизатора: 5 узлов, 550 ГБ RAM на узел, 500к RPS.

⚙️Падение СУБД

1️⃣ Однонодовая СУБД — после падения приложение не работает, Запросы не обслуживаются, данные теряются при простое.
2️⃣ Распределенная СУБД — спектр последствий разный. Может снижаться перфоманс, может теряться часть данных.

⚙️Метрики восстановления после аварии

Recovery Point Objective — целевая точка восстановления, после которой мы теряем данные. Мы оцениваем время, в течение которого мы теряем данные за этой точкой.

Recovery Time Objective — с её помощью мы оцениваем время, затраченное на восстановление системы после аварии.

🛠 Способы формирования бэкапов (рекомендуется изучить презентацию к докладу):

1️⃣ Apache Ignite: ребаланс данных, позволяет сохранить данные, если количество упавших нод меньше бэкап-фактора.

2️⃣ DataGrid: при ребалансе данных распределение партиций такое, что у стойки есть дублер. Позволяет восстановиться при падении стойки.

3️⃣ Apache Ignite: CDC обеспечивает асинхронную логическую репликацию данных. RPO ➡️ секунды, RTO ➡️ 0. Данные реплицируются в другой кластер через WAL, доступ к данным открывается после перемещения сегмента в архив. Из-за этого RPO сдвигается.

4️⃣ Data Grid: Online CDC внутри ноды есть буфер данных, который наполняется событиями и из него данные стримятся в соседний кластер. RPO ➡️ 0, RTO ➡️ 0. Растет потребление памяти, при переполнении используется классический CDC через WAL.

5️⃣ Снапшоты в Apache Ignite: системный процесс PME делает stop the world. Начатые транзакции заканчиваются, новые стоят на паузе. В этот момент происходит копирование партиций, изменения пишутся отдельно, после снятия резервной копии изменения накладываются поверх снимка. RPO ➡️ часы, RTO ➡️ 0

6️⃣ Apache Ignite: инкрементальный снапшот снимает только изменения в данных, но часто. Система не блокируется. RPO ➡️ минуты, RTO ➡️ минуты. В докладе даны ссылки на статьи по этому механизму.

🔮 Cache dump

📝Задачи и качества метода:
1️⃣ консистентный бэкап in-memory кэшей с учетом транзакций без прерывания пользовательской нагрузки;
2️⃣ Восстановление данных на любую топологию;
3️⃣ Поддержка CLI;
4️⃣ API offline обработка

⚙️⚙️ Механизм снятия дампа:
1️⃣ Stop the world
2️⃣ Данные консистентны; запуск писателей дампа
3️⃣ Для сохранения консистентности установка listener'ов на изменения кэша
4️⃣ Запуск транзакций
5️⃣ Итерация по партициям и запись row by row
6️⃣ Запись данных listener'ом

🪛 Тонкости:
1️⃣ Откатиться, если где-то ошибка — Distributed Process.
2️⃣ Не перегрузить ноды системным процессом - прежде всего операции пользователя.
3️⃣ Запоминание изменений каждого ключа — это дорого по памяти.

📝 Эффективная фильтрация:
1️⃣ Итератор по партиции не транзакционный
Listener должен сохранить entry до изменения
2️⃣ Итератор сортированный (B+дерево)
3️⃣ У каждой записи есть уникальная версия. Версия выдается на primary.

❔Ответы на вопросы:

Q: cache dump можно снимать не только для in-memory cache, но и для персистентного кэша?
A: Можно, вопрос целесообразности. Для persistent cache есть более подходящие способы.
Q: Уточнение по процессу: если версия ключа более новая, то итератор её пропускает. Как все значения ключей попадают в запись бэкапа?
A: Если версия старше версии в момент снятия, то эти данные либо пришли после запуска процесса снятия бэкапа, либо старые данные были изменены во время снятия и эти изменения записаны listener'ом.

Бронислав Житников — NiFi. Пишем код для codeless-системы

Сложность: 2/3 (Если NiFi не
трогали - пропускайте данный доклад. Это отличное подспорье для углубленного знакомства с NiFi)

📺: https://youtu.be/Lnta1yPIMrY?si=cuGJLbmET3cQvadf
📺 :VK

🔍 Условия:

1️⃣ В NiFi может не хватать встроенных процессоров
2️⃣ Иногда нужно избежать приземления данных на диск и для этого несколько процессоров собрать в один
3️⃣ Встроенный процессор иногда стоит доработать, либо исправить в нем ошибки

⚙️ Путь к необходимости писать код:

1️⃣ ExecuteStreamCode — позволяет запустить внешний скрипт
2️⃣ ExecuteScript — дает доступ к внутренним фишкам NiFi
3️⃣ ScriptedService — позволяет изменить часть логики
4️⃣ ScriptedProcessor — позволяет прописать всю логику процессора

🛠 Устройство NiFi:
Для написания кода в большинстве случаев придется работать с NiFi API (Processors&Service)

1️⃣ ScriptEngine: докладчик рекомендует писать скрипты сразу на Groovy, так как Jython не даст свободы использования Python и при этом даст ограничения в работе с API
2️⃣ Можно писать свои модули сразу на Java
3️⃣ В версии 2.0 ожидается написание модулей на Python

⚙️ Шаги создания Processor:

1️⃣ Чтение Developers Guide
2️⃣ Применение Maven-Archetype — быстрый старт разработки, есть только часть процессоров и сервисов
3️⃣ Заполняем аннотации — могут определять поведение процессора, наполнять документацию, определять ключевые методы
4️⃣ Заполняем OnScheduled
5️⃣ Заполняем OnTrigger

⚙️ Аннотации поведения:

1️⃣ @InputRequirement — требует ли входящей очереди (обязательна, допустима, недопустима)
2️⃣ @TriggerWhenEmpty — требуется ли FlowFile. Позволяет запускаться процессору без файлов во входящей очереди. Для процессоров без входящих очередей не имеет смысла
3️⃣ @PrimaryNodeOnly — запуск только на ведущей ноде. Пригодится для процессоров без входящих очередей
4️⃣ @SupportBatching — возможность запускать длительный Run, снимая нагрузку с планировщика

⚙️ Аннотации документирования:

1️⃣ @CapabilityDenoscription — описание процессора
2️⃣ @UseCase — редко встречается, но очень помогают пользователям
3️⃣ @ReadAtrribute/@WriteAttribute — описывает, какие атрибуты приходят на вход и оказываются на выходе из процессора
4️⃣ @SeeAlso — справка о дополнительных источниках

📝 Расширенное документирование:
1️⃣ в каталоге resoursces создать docs, там создать каталог с полным именем процессора
2️⃣ Создать файл additionalDetails.html

🪛 Важные элементы разработки:

1️⃣ Properties — важно определить, как параметры обрабатываются; работают ли они с сервисами и с какими; определить наличие dynamic properties; настроить валидаторы и обязательность указания параметров
2️⃣ Relationships — заполнить имя, описание, обязательно указать настройку "выключен по умолчанию"
3️⃣ Lifecycle — c @OnAdded начинается создание экземпляра процессора;
@Onscheduled — запуск процессора, при перезапуске NiFi так же вызывается
@OnUnscheduled — остановка процессора, если его запуск больше не запланирован. Часть тредов могут быть активны после вызова метода с этой аннотацией. Лучше избегать применения в логике для выключения процессора
@OnStopped — следует применять эту аннотацию к методу, срабатывающему при полной остановке процессора
@OnRemoved — удаление экземпляра процессора
@OnShutdown — избегать использования в логике, так как NiFi чаще останавливается нештатно

⚙️⚙️ OnTrigger — метод построения логики работы процессора

1️⃣ Проверить наличие файла
2️⃣ Помнить об экземплярах вызова, изменяемые данные должны быть внутри OnTrigger
3️⃣ Расчет только из атрибутов
4️⃣ Не изменять атрибуты во время изменения контента
5️⃣ Не забывать отправлять файлы в следующие отношения или удалять
6️⃣ session.penalize — позволяет определить период, когда файл не подлежит обработке, используется для обработки ошибок
7️⃣ context.yield — в случае отсутствия отклика БД процессор может не запускаться какое-то время, даже если расписание на него выставлено
8️⃣ ProcessSession — управляет обработкой файла
9️⃣ ProcessContext — определяет доступ к информации из процессора и среды

Продолжение предыдущего поста. Выводы и ответы на вопросы не влезли)

📝 Чего избегать:
1️⃣ С осторожностью соединять процессоры
2️⃣ Не усложнять процессор в погоне за оптимизацией

❔Ответы на вопросы:

Q: Где брать готовые процессоры для NiFi
A: Ожидать сервис от коммьюнити, сейчас никак
Q: Можно ли отладить процессор в IDE?
A: в NiFi есть эмуляция процессов, можно написать тест там. Возможно открыть PortDebug, поможет если уже процессор работает, но ведет себя аномально.
Q: Как часто ты рекомендуешь использовать систему логгирования?
A: Использую всегда. Трейсы пишу всегда, когда есть ошибки, ворнинги пишу, но стараюсь не перегружать ими.
Q: Как дебажить ScriptedProcessor?
A: Если его не выпилят в 2.0, я напишу функционал и выложу. для Groovy такое уже есть