🍔 Data Compaction
Pattern: Compactor
Стриминг пишет очень много мелких файлов, и эта проблема актуальна не только для hdfs, но и для s3. Потому что нужно перебирать много файлов, открывать/закрывать, скапливается куча меты для табличных форматов (delta lake, iceberg, hudi)
🧊 Решение - объединить в файлы побольше. В iceberg для этого есть процедура rewrite_data_files. Если таблица тяжелая, компакшн можно встроить в сам процесс загрузки. Или поставить на внерабочие часы, чтобы никому не мешать. Кстати, со стримингами у нас даже дважды компактится: каждый час и каждый день
После компакшена в iceberg можно почистить все ненужное через expire_snapshots - задаем время, раньше которого удаляются все снепшоты вместе с данными. Или просто подождать, пока оно само по ретеншену отвалится
☕️ Data Readiness
Pattern: Readiness Marker
Иногда потребителям данных нужно знать, что данные готовы
1й способ. Создавать файл по типу _SUCCESS в спарке отдельной таской в Airflow. Тогда потребители через FileSensor смогут мониторить появление файла
2й способ. Дождаться создания следующей партиции - это значит, что текущая закрыта
Тут используется pull - потребители сами чекают, готовы ли данные
⛅️ Event Driven
Pattern: External Trigger
А тут про push - загрузчик сам уведомляет, что данные появились
🌱🌱🌱🌱🌱
Очень прикольно, что даются описание и примеры для батча и для стриминга. И все с использованием самого популярного: Spark, Flink, Kafka, Airflow, Python, Scala, SQL, иногда с добавлением чисто западных штук
💐 Кстати, мне тут очень понравились несколько выражений из книги, первые два очень поэтичные:
Sad but true, but your data engineering life will rarely be a bed of roses.
However, life is not that rosy.
Always expecting the worst is probably not the best way to go through life, but it’s definitely one of the best approaches you can take to your data engineering projects.
#depatterns