Строим машину времени для данных (SCD-2) на движке Trino под управлением Airflow

В сфере искусственного интеллекта произошло заметное событие. VasiliyS178 25 минут назад Строим машину времени для данных (SCD-2) на движке Trino под управлением Airflow Средний 11 мин 33 Блог компании X5 Tech Data Engineering * SQL * Big Data * Open source * Туториал Привет, на связи Василий Самарин, ведущий инженер данных в Х5 Tech. Это моя вторая статья по теме построения SCD-2-таблиц. Если вы еще не знакомы с SCD-2-таблицами, то рекомендую заглянуть в мою первую статью, где рассказывается про то, когда и зачем можно и нужно их использовать, и подробно разбирается пример для PySpark и Hive.

Сегодня SCD-2-таблицы не только остаются актуальными для медленно меняющихся данных, но и, на мой взгляд, становятся гораздо проще в реализации благодаря новым технологиям и инструментам. С того момента, когда я писал свою предыдущую статью про построение SCD-2-таблиц на PySpark 2. 4 и Hive, прошло около года, и мне снова поручили пересобрать эту же витрину, но уже в ходе миграции в наше новое хранилище данных.

Технические детали

Да, в X5 постоянно что-то меняется, внедряются новые технологии и инструменты. Это одна из причин, почему мне нравится здесь работать. Итак, в этой статье мы будем:строить Iceberg-таблицы с типом SCD-2 с помощью Trino с использованием SQL и Python;попутно освоим прекрасные функции merge, MD5 и другие полезные инструменты;напишем свой собственный оператор для Airflow для автоматизации ETL-процесса.

Полный код SQL-запросов оператора для AirflowПолный код SQL-запросов для создания и наполнения всех необходимых исходных таблиц, итеративного наполнения SCD-2-таблицы данными, а также код оператора для Airflow вы найдёте в моём репозитории. Для понимания общего контекста сначала немного расскажу про Lakehouse DMP 2. Наш новый LakehouseТекущее хранилище данных на базе Greenplum исчерпало возможности масштабирования.

У централизованной модели управления были узкие места — команды не справлялись с бэклогом, а сложный процесс внесения изменений замедлял поставку дата-продуктов. Кроме того, существующая архитектура не позволяла обеспечивать необходимую оперативность данных (T-1) из-за многоэтапной «перекладки» информации между системами хранения. 0 решает эти проблемы переходом на архитектуру Lakehouse с декомпозицией на независимые дата-хабы (Data Mesh).

Технологически разделяется слой хранения данных (object storage на базе открытых стандартов) и вычислительный слой (Trino, Spark, Flink), что обеспечивает гибкое горизонтальное масштабирование без крупных инфраструктурных вложений. Организационно вместо единого хранилища данных внедряется федеративная модель: автономные команды-владельцы дата-хабов самостоятельно разрабатывают и поддерживают дата-продукты, публикуя данные через формализованные дата-контракты. Это снимает нагрузку с центральной команды и ускоряет time-to-market для аналитических решений.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.