Обновление плейлиста Lakehouse!

Выложили доклад маэстро Озерова (@cedrusdata) на Smart Data 2025.

Владимир здесь делает обзор на стейт и развитие экосистемы Iceberg. Часть материалов была здесь на канале раньше в этом перезаливе. Там же можно посмотреть и само видео от создателей и контрибьюторов Айсберга на английском с таймкодами.

Это про Variant, geo data, row lineage, row_id.

Потом Владимир идет дальше и касается уже предполагаемых фич Iceberg v4/v5.

Что есть нового:

1️⃣ Внесение вьюх в стандарт Айсберга. Сейчас вьюшка это просто хранимая строка SQL, и проблема в том, что в разных движках SQL разный. Вьюха записанная в Spark SQL не будет работать в Trino или StarRocks. Поэтому сообществу нужно изобрести промежуточный сериализованный стандарт хранения вьюхи, которая будет хранить что-то вроде плана ее выполнения.

2️⃣ Материализованные вьюшки. Тут не легче - нет способа валидировать что таблицы, от которых зависит матвью, обновились.

3️⃣ UDF. Есть гиганский документ с очень сложным пропозалом, как сделать стандартизированный вид хранимых UDF. Интересно, что в спаке-то справились с этой задачей!

4️⃣ Iceberg Wide Tables. Сейчас под айсбергом лежит одномерный массив паркетов. То есть каждый паркет содержит примерно все колонки таблицы. Но что делать, если в таблице 1000 или 10000 колонок! Такие приложения уже вполне есть, например в области фиче сторов для МЛ. Было бы неплохо уметь разбивать массив колонок таблицы на несколько логических блоков и хранить их в разных паркетах.

5️⃣❗️Транзакции! Многостейтовые и много-объектные транзакции.

6️⃣ Securable Objects или по-простому RBAC. Сейчас в стандарте Айсберга нет единого способа сделать ролевую модель, и разные движки, команды и метасторы колхозят что-то свое. Цитата: "Добавлять это в стандарт - это форма безумия. Надеюсь не сделают"

7️⃣ FGAC - Fine Grained Access Control. Маскирование, колоночные гранты и так далее. Строчные авто-фильтры - Васе можно смотреть только строки по своему региону/отделу. Идея в том, что права отправляется на движок, и движок его применяет. Или не применяет, потому что не умеет. От этого движки делятся на Trusted / Non Trusted. Ах да, снова надо придумать универсальный метод описания пермишенов.

8️⃣ Disaster Recovery на уровне логических объектов айсберга: таблиц, манифестов, снапшотов и т.д. Первое, что надо сделать - научить метадату работать по относительным путям. Здесь я вообще не понимаю, как так вышло, что я не могу перенести Айсберг таблицу в соседний бакет S3 или с S3 на папку и оно перестанет работать потому что во всей метадате прописано s3://myonebucket/

9️⃣ REST Planning. Как насчет сделать функционал в Iceberg REST каталоге для того, чтобы можно было кинуть в него запрос и получить план. Или хотя бы список паркетов которые он реально будет читать по запросу SELECT SUM(rev) FROM SALES WHERE [my-filter]. Как было бы удобно разрабатывать движки. И это почти готово!

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

Из зала мой первый вопрос - что нужно сделать S3 как софту, чтобы Iceberg экосистеме было комфортно с ним общаться.
Ответ: STS, Vended Credentials.

———————————————————————-

Приглашаю ознакомиться с плейлистом по Лейкхаус на ВК, и подписаться на него. Туда я добавляю свои стримы и интересные доклады ведущих экспертов. А также на канал Архитектор Данных на ВК Видео.

———————————————————————-

Философское - облако и разделение труда (4)

В начало цикла - Части 1-3

Как добиться роста кооперации.

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

Если вы владелец или топ-менеджер платформы или сервиса, подумайте, как сделать, чтобы ваши клиенты захотели с вами кооперироваться. Подумайте, как для них нарастить выгоду от сотрудничества с вами и как снизить риски.

Как снизить риски в продукте

1️⃣ Начинайте с малого. Все клиенты из моего пула в облаке стартовали с небольших проектов и второстепенных сервисов. Тогда ваши клиенты точно будут знать, что именно вам можно доверить, а что нет. А ваши факапы не станут смертельными для сотрудничества.

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

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

2️⃣ Продукт должен убирать собственные риски. Такие «второстепенные» функции ИТ-продукта как мониторинги, обсервабилити, безопасность - часто делается по остаточному принципу после «важных» фичей продукта. Это бич типичного российского ИТ-изделия.

Так вы получаете прекрасный и функциональный (но это не точно) продукт, которым невозможно пользоваться на практике. А ну как сломается, и что с этим делать? Как вот этому у которого нет базового дашборда мониторинга (зеленый - хорошо, красный - плохо), поручить критичные бизнес-процессы?


Давайте небольшой чеклист про риски.

*️⃣Вы продумали, что делать, когда в вашем изделии все пойдет не так. У вас можно заметить проблемы на ранних подступах.
*️⃣У вас есть документация, как это чинить, вы проводите обучение ответственных сотрудников заказчика, объясняете как пользоваться вашим изделием правильно и по назначению.
*️⃣У вас есть база знаний типовых поломок и плохих ситуаций, что к ним может привести и как с ними бороться.
*️⃣У вас есть качественная и быстрая поддержка. Вы готовы бросить все и сорваться чинить критическую проблему заказчика. Второй бич почти всех российских вендоров - поддержка вида «ну напишите нам в телегу или на почту, там разберемся»

Чеклист можно продолжить.

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

Думайте об этом, носите мысль в сердце своем.