Архитектор Данных

Напомню и про свой доклад

https://vkvideo.ru/video-164978780_456239739

Внутри прожарка формата Iceberg - как оно устроено и почему именно так. Как получается (почти) транзакционная система хранения данных при хранении в нетранзакционном S3.

Во второй части короткий воркшоп.

Есть текстовая версия на Хабре. Статья вошла в топ хабрастатей от ВК 2025 года. Даже медальку в интранете дали 🏅

Для тех, кто хочет познакомиться поближе и пощупать технологии Iceberg, Lakehouse, DBT руками - приглашаю на курс. Стартуем 5 февраля

На тему альтернативных движков Spark - офигенный доклад со Smart Data 2025 от Евгения Глотова из Navio

Видео пока что за пейволом, но слайды (70 слайдов) можно посмотреть тут.

Спойлер - Евгений фанат Sail

https://github.com/lakehq/sail

В коментах вспомнили отличный доклад на Smart Data 2025. Ребята измерили, как на практике работает Comet (Rust), Velox (C++) движки Spark'а.

Слайды тут:
https://smartdataconf.ru/talks/8e248260514840208beaf9cf90cc0778/?referer=%2Fschedule%2Ftable%2F

На картинке спойлер, но посмотрите слайды, там больше деталей. Видео пока что за пефволом

01:15 - Улучшаем производительность нативного движка Spark
05:10 - Как исполняется код на Spark под капотом и его узкие места
08:45 - Векторизованная модель исполнения кода
10:39 - Comet - движок поверх Dafafusion + Arrow
27:10 - Интеграция Comet - Iceberg
31:36 - Как включить векторизованный движок при чтении Iceberg-Parquet

DataFusion Comet

Продолжаем разбор интересных докладов.

Сегодня - доклад с Iceberg Summit 2024 про движок Comet от Чао Сана (Chao Sum) Staff Engineer OpenAI

Comet - переписанный на Rust движок вычислений для Spark с векторизацией (SIMD). Включается как Drop-In Replace, если не может по какой-то причине, то сам фолл-бечится на Scala. В итоге получаем скорость Rust, не теряя богатство экосистемы Spark и его API. На бумаге.

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

Видео c таймкодами ниже в канале или на ВК. Оригинал Youtube - без таймкодов.

Ранее в разборах:

Часть 1 - Разбор нововведений Iceberg v3
Часть 2 - Streaming Data Lake - Redpanda

------------------------------------
------ Архитектор данных -------
------------------------------------

Хозяйке на заметку.

Если нейросеть тупит, просто повторите промпт еще разик

Meta[store] Mesh - ловите новый термин 😁

Ехал метастор через метастор, видит метастор в метасторе метастор...

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

А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.

Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.

Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.

Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.

Видите пльзу для себя, затеялись бы внедрять? :)

Есть любопытный Q&A по фиче Spark пайплайнов.

Подписчики мне справедливо попеняли, что речь идет не про Airflow DAG, а скорее про декларативное описание моделей и потоков данных, что больше похоже на DBT, SQLMesh.

Как раз окрестратор в этом дополнении предельно простой - из одной команды spark-pipeline run my.yaml. Полноценный шедулер (пока) никто не делает. Хотя в будущем, полагаю, появится какой-то аналог dbt run с его селекторами.

На философском уровне, как также верно отметили комментаторы, спарк постепенно из библиотеки, которая запускает Map-Reduce в памяти, превратился в неимоверный комбайн, который разве что кофе не варит. Наверное, это судьба всех успешных фреймворков.

Я честно говоря, жду когда появится альтернатива, которая будет себя позиционировать как SimpleSpark. Или DuckSpark 😁

Если знаете такую, напишите в коментах.

В Spark 4.1 появлся ... Airflow

В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)

На борту:

1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные
2️⃣ Пайплайн как объект. Описывается через YAML файл с SQL, Python кодом и необходимыми конфигами Спарка. Также объявляется каталог (Hive, Iceberg), с которым можно взаимодействовать и в который складывать результаты.
3️⃣ Команда spark-pipelines init с интерфейсом и аргументами как у Spark Submit. Отдельная команда spark-pipelines run.


Удобство

Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.

from pyspark import pipelines as sdp

@sdp.table
def ingestion_st():
return (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", "localhost:9092")
.option("subscribe", "orders")
.load()
)

К объявленной таким способом таблице можно обращаться дальше по пайплайну.

На SQL и того проще

CREATE STREAMING TABLE basic_st
AS SELECT * FROM STREAM samples.nyctaxi.trips;

Или пример с несколькими синками

-- create a streaming table
CREATE STREAMING TABLE customers_us;

-- add the first append flow
CREATE FLOW append1
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_west);

-- add the second append flow
CREATE FLOW append2
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_east);

Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.

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

Насладиться примерами можно в офф доке превью версии

Рубрика - Вредные советы

Люди с песьими головами или эта ваша аналитика глазами CTO

Расскажу об одном разговоре с моим тогдашним СТО, который многое для меня сделал понятным.

СТО был прекрасный, на 146% на своем месте. Трудились мы в небольшой компании, которая разрабатывала подписочный SaaS продукт. Главная задача СТО в такой компании - поддержание продукта работоспособным и быстрая выкатка новых фич, которые растят ARPU.

И тут появляется аналитика. Далее - описание процесса из глаз СТО, практически цитата.

Приходят какие-то люди с песьими головами. Говорят что-то непонятное, что-то просят, и довольно много. Я честно, не понимаю в этих ваших КХД, ETL, Data Governance, и почему все так сложно и дорого. Я другими вещами занят, у меня SLA продукта должен быть 100%, потому что каждое падение это отток подписок. Мне выкатки без багов нужны, у меня беклог на 4 года вперед, а вилки на разработчиков низкие, потому что мы маленькие и живем скромно.

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

Договорились мы в итоге, что по минимуму у нас будет а) Postgres на 5 ТБ, так как в компании есть компетенции постгресовых ДБА, б) сервисы для Airflow, Jupyter для ETL, Аналитиков и простого BI (!), в) небольшая квота DevOps+DBA для поддержания и развития этого стека. С тем и прожили следующие 2 года, до тех пор как команда аналитиков не стала 20 человек, и появились некоторые бюджеты на более взрослые системы и решения.

«Люди с песьими головами» остались со мной навсегда.

Вы, бывает, варитесь в своем пузыре, вам кажется, что все понимают и разделяют ваши проблемы. Метрики-отчеты и пайплайны, а теперь и ЛЛМ, очевидны и понятны в своей ценности - кажется вам. Но для большинства ваших технических коллег вы непонятные Псоглавцы (Кинокефалы). А главная ваша ценность глазами высоких менеджеров - это «чтобы от меня отстали с этой ерундой».

Нашел нейросетку подобрее

Да, так значительно лучше 🐈

О, это мы можем, знаем практикуем.

Считайте, что я дата-сомелье

Вдогонку немного старая, но вряд ли утратившая актуальность статья про RedPanda

https://habr.com/ru/articles/746138/

Основной вывод - в скрине. Сервис из-за своей архитектуры требует определенных тепличных условий для работы. В то время как та же Kafka неприхотлива весьма.

Почему речь про Scylla - потому что RedPanda построена на той же сишной архитектуре Seastar

00:00 - Ода продукту RedPanda.
05:46 - RedPanda Iceberg Topics. Topic-Table интеграция
08:21 - StreamHouse - что это?
15:58 - StreamHouse as a Service
19:28 - Техническая сторона интеграции Topic-Table, Redpanda-Iceberg

Смотрим Iceberg Summit 2025 - Часть 2

Сегодня видео с громким названием Fully managed Streaming Data Lake in the Iceberg, но именно здесь я сэкономил вам время, потому что 2/3 доклада это маркетинговый питч продукта RedPanda.

RedPanda - интересный продукт из мира стриминга, и здесь они много говорят о добавленной интеграции с айсбергом и как они хорошо решают задачи построения Стрим-Хауса там где стандартные методы Kafka-Connect-Sync справятся хуже. Техническая часть короткая по времени, но все равно любопытная. Ее можно смотреть с 19:28

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


Что сделали инженеры Redpanda, их заявка на успех

🔬 Exactly Once доставка данных из топика RedPanda в таблицу Iceberg

🔬 Где Kafka + Kafka Connect это два отдельных сервиса, которые могут рассинхронизироваться с неприятными последствиями, в экосистеме RedPanda это одна система. Она и работает в режиме брокера, и синхронно заливает данные в хранилище Айсберг

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

🔬 Есть трейд-офф между а) лагом между таблицей и топиком и б) размером итоговых паркетов и манифестов у айсберга. Мы можем писать часто и за счет этого минимизировать лаг, но тогда итоговые манифесты и паркеты будут маленькие. RedPanda утверждает, что в их системе этот трейд-офф можно задавать на уровне каждого стрима данных

🔬 Реализация Dead Letter. На тот случай, если по какой-то причине данные невозможно записать в Айсберг, есть отдельное чистилище для таких сообщений и данных. Почему нельзя записать? Потому что устаревшая схема, ошибки сериализации и т.д. Айсберг строго типизированный и если договорились, что число, то там должно быстро строго число, а если приехала строка, то фейл. Вот эти фейловые строки хорошо куда-то складывать для прозрачности и возможности дальнейшего процессинга, а не просто получать молча пропуски в данных.

🔬 Очень кратко заявили про сквозной менеджмент схем. Он совместим с Kafka Registry - на этом все

🔬 Очень кратко про совместимость в Iceberg Catalog. Совместим с REST. Дифирамбы совместимости с Snowflake, шпилька в сторону BigQuery. Сразу видно, с кем дружат и с кем нет


Ода продукту RedPanda

🐼 Drop-In Replacement для Kafka. Совместима с Kafka API
🐼 Быстрее, так как C++ и Raft Consensus
🐼 Более богатый набор фичей для построения пайплайнов, LowCode Yaml преобразования и джойны данных
🐼 Переписанный на C++ движок с логикой 1 поток на 1 ядро
🐼 Raft Consensus
🐼 Собственные либы для работы с форматами ProtoBuf, AVRO, Parquet и схемами всех этих форматов

Видео с тайм-кодами постом ниже или на ВК Видео. Оригинал на Ютубе.

Часть 1 - Разбор нововведений Iceberg v3

------------------------------------
------ Архитектор данных -------
------------------------------------

Вот и закончилась первая четверть XXI века.

С праздником, дорогие. Спасибо что вы здесь.