Пилот lakehouse
Пилот переноса сырого слоя событий из кластера Hadoop в облачный lakehouse на Iceberg, S3, Spark и Trino, проверенный в двух облаках на реальных данных.
attributes
- role
- lead engineer
- source
- рабочий проект, код закрыт
Задача
Сырые события парсер читает из Kafka и хранит в Parquet на HDFS в кластере CDH 6.3 с Hive 2.1, Impala и Kerberos. Пилот проверял, можно ли перенести этот слой в облачный lakehouse: таблицы Iceberg в S3-совместимом хранилище, Spark для загрузки и Trino для запросов.
Решение
Первый этап шел в VK Cloud с managed-метастором Iceberg (JDBC-каталог), Trino и S3. Второй этап повторил схему в Yandex Cloud: Managed Metastore (Hive Metastore), Managed Trino, Object Storage и Data Proc.
- Поток: Spark Structured Streaming читает Kafka микробатчами до 1 млн сообщений и пишет сырую таблицу Iceberg с полезной нагрузкой в map<string,string> и партициями по приложению, событию и дате
- Типизированный слой: сырая таблица раскладывается в отдельную таблицу на каждую пару приложения и события, с определением типов и эволюцией схемы. К концу сентября 2025 года в этом слое было 1486 таблиц для 25 приложений
- История: около 14 ТБ Parquet-файлов за 2025 год скопированы из HDFS в S3 в 20 параллельных потоков с маркерами успешной загрузки, затем зарегистрированы в Iceberg через add_files без перезаписи данных
- Обслуживание таблиц через Trino: expire_snapshots и remove_orphan_files
- Прототипы для небольших загрузок: запись батчей PyArrow через pyiceberg и чтение через pyarrow.dataset
- Между облаками данные копировались через rclone, ежедневная выгрузка из HDFS держала второй этап в актуальном состоянии
Стек
Apache Iceberg 1.7 и 1.8, Spark 3.5, Trino 468 и 476, Kafka, PyArrow 20, pyiceberg 0.9, Hive Metastore, S3-совместимое хранилище, rclone, GNU parallel.
Моя роль
Lead engineer: спроектировал архитектуру пилота в обоих облаках, сделал загрузку из Kafka и перенос истории, вел учет проблем, найденных в пилоте.
Результат
Пилот работал на реальных данных: поток событий из Kafka и история за 2025 год, около 14 ТБ. Он же показал ограничения схемы: лимиты записи в Trino (1 ГБ памяти на узел, 100 writers), рост метаданных при массовых вставках и сбои managed-сервисов на первом этапе. Переход отложен, сырой слой остается на CDH.