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

😎

Как если бы Архитектор Данных была бы Doom Metal бандой

Еще вариации визуализации данных из комментов к

Как оно бывает, когда биг босс говорит, что у компании миллионы клиентов

Лет 10 назад одна компания, продававшая и подключавшая (в числе прочих услуг) iptv приставки, захотела потеснить Mediascope на рынке измерения телевизионной рекламы. Медиаскоп, на секундочку, это многолетний монополист, по которому в мире тв-рекламы меряют всех: от завалящих региональных канальчиков до «Первого канала».

Гендиректор этого продавца iptv серьезно заявлял: «у нас есть 2 миллиона приставок, а у Медиаскопа всего десяток тысяч панелистов, мы сделаем инструмент намного лучше». Для реализации амбициозного проекта позвали умных программистов из топовой Российской айти компании, потому что ГД компании-продавца iptv дружил с ГД айтишников и заранее ударил с ним по рукам, что делать будут вместе.

Когда два биг босса договорились, подчиненным остается брать под козырек и приступать к неохотному, но неизбежному исполнению. Но стоило дискуссии спуститься на один уровень иерархии ниже, оказалось, что приставок все же 200 тысяч. Ну напутал босс, бывает. Однако подчиненные ГД это тоже не тот уровень, чтобы данные отгрузить, поэтому диалог делегировали и еще ниже. Оказалось, что там все в шоке, что приставок 200к, ведь 20к было всего! В конечном счете до айтишников вместо обещанных миллионов дошло 12 тысяч (даже с зарплатой и то разрыв обещаний и факта не так драматичен), но самое веселое выяснилось в конце. Оказалось, что из 12 тысяч приставок только по 2 тысячам есть данные о составе домохозяйства (кто живет-то в квартире), причем в некоторых случаях в одну квартиру были записаны 50 и более человек.

Когда вы станете биг боссом (если еще не), обязательно помните, что числа, принесенные вам менеджером в отчете, могут быть реально на порядок выше чисел, которые он сам получил от своих подчиненных. И чем выше вы в иерархии, тем более беспросветное вранье к вам иногда приносят. Это очень грустный эффект, потому что как следствие он приводит к инфляции реальных достижений - в них тоже перестают верить, а разбираться становится лень, когда 9 из 10 утверждений об успехах сформулированы с большой натяжкой, творческим додумыванием, "правильным" способом подсчета и умелым стоянием рядом в нужное время в нужном месте.

P.S.: Медиаскоп по-прежнему стандарт измерения тв-рекламы, а ГД из истории по слухам успешно устроил свою жизнь в счастье вдали от Родины. Еще и до того, как его объявили в розыск. Как-никак матёрый был менеджер.

Когда-то меня чуть не уволили с первой работы спустя 1 месяц, когда я принес расчет, не совпадающий с видением генерального.

Спросили что-то вроде - какой % клиентов пользуется опцией Х. Ну и младший аналитик (который теперь архитектор) честно написал - число такое-то от общего количества НН пользователей. Проблема в том что число НН (реальных пользователей по которым хоть что-то есть) в 4 раза отличалось от отчетов генерального наверх.

С тех пор если меня спрашивали долю чего-то, я никогда не отображал исходные числа (числитель и знаменатель). Ну его нафиг, себе дороже.

Инсайты из рассказа Дмитрия Реймана (Авито) о Трино

Доклад: Trino 2 года спустя

Инсталляция

1️⃣2 года назад начата миграция из Вертики в Трино

2️⃣Разделение Compute - Storage на сервисах Trino + Ceph. Суммарно 15 кластеров Трино

3️⃣Данные поднимаются по протоколу S3 из Ceph. Формат данных ORC.

4️⃣Канал: теоретический пик 80 Гбайт/сек, реально достижимое значение 40 Гбайт/сек. В один запрос может разогнаться до 10 ГБайт/сек.

5️⃣Все новое создается в Trino уже сейчас.

6️⃣Нагрузка 50/50 Vertica / Trino

7️⃣Нагрузка от Trino в сторону Ceph - топ-1 из всех потребителей Ceph. Не все цефовцы это любят.

8️⃣Потребовалась конфигурация Ceph с выносом метаданных на NVMe диски


Нагрузка

1️⃣300 потребителей Ad-Hoc

2️⃣1 ПБ / день обрабатывается в Трино

3️⃣Свой оркестратор на 100к+ задач в день


Советы

1️⃣Всем кто строит Лейкхаус обязательно провести нагрузочный тест на Troughput от вычисления до хранения.

2️⃣(ТОП СОВЕТ) В архитектуре ETL действует правило - максимальная длина джоба = 1 час

3️⃣(ТОП СОВЕТ) Также в архитектуре любого потребителя данных DWH - обязательный retry.

4️⃣Pandas to_sql - боль 🙂


Trino

1️⃣Голое Trino - не воин. Придется развернуть или дописать многое вокруг.

2️⃣fs.cache.enabled = true - включение локальных кешей в Трино (с 439 версии).

3️⃣Hive Metastore хоть и легаси, но используется для больших данных. Iceberg для относительно маленьких потребителей, где важна консистентность. Hive движок для Trino как будто чуть более оптимизирован по сравнению с Iceberg. Hive любит делать лишние листинги в объектный Storage, когда оно не нужно, что убивает S3.

4️⃣SDK Trino очень развитый. Авито используют для написания собственных движков чтения SQL. Также можно написать свои обертки для API, специфических БД в таблицы.

5️⃣ETL / ELT в Trino для 6NF (!) - ок! По крайней мере не хуже Вертики.

6️⃣Написали свой Trino Catalog для метаданных

7️⃣Иногда падает Трино Координатор. Но быстро восстанавливается, так как Stateless

Доклад тут

Все так, Кирилл!

Так и аналитика может быть имиджевой "карманной" функцией высокого менеджера в крупной компании. Вот у него есть личная группа очень умных аналитиков для лично его задач и консалтинга.

Такой аналитик - что-то среднее между консильери у дона мафии (влияние без власти) и эскортом (похвастаться тобой).

Тоже пусть карьеры 😎

Кубистический архитектор

Продолжая аналогию BI с такси

Мечты о беспилотном ETL это примерно то же что мечты о беспилотном такси. Вот был бы общественный транспорт по цене кастома - стало б хорошо.
И вроде бы, даже что делать понятно, и задача не кажется космически сложной.

Но как-то все не клеится.

До слова (первый вариант) потому что последнее поле надо будет закоментить с большей вероятностью чем первое.

А во втором случае запрос развалится если я вставлю — в четвертой строке

Пример:
До слова:
Select a1
,a2
,a3
,a4

После слова:
Select a1,
a2,
A3,
A4

Вот есть вайб-кодинг.

А есть ли вайб-администрирование СУБД?

Которое переходит в вайб продолбанный SLA и вайб восстановление из бекапа

MPP подход к DLH против DataLake

Тут как. По сути есть 2 подхода к Лейкхаусу

1. Со стороны MPP - взять готовую транзакционную машину и привести ее к хранению данных отдельно от движка в S3/HDFS. Потом придумать переиспользование этих же данных другими кластерами и другими движками.

2. Со стороны Лейка - взять (почти) готовое разделение Compute-Storage и привети к транзакционной машине.

Первый подход делают в Яндексе и Cloudberry c Гринпламом. Не сказать чтоб без успеха, но пока не довели. Doris идет тем же путем.

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

- уже распределенные движки Spark, Flink, Trino, которые приспособлены к работе отделенными от себя данными
- уже реализованный принцип один датасет + много разных движков чтения. В Хадупе так работает уже десяток лет.

То есть Лейк оказался архитектурно сильно ближе к лейкхаусному сценарию.

МРР слишком заперт в архитектуре классических БД, из которых они эволюционно возникли. Там надо побороть жесткое шардирование, там все расчитано, что с файлами можно работать на уровне блочки - в любой момент в любое место дописать или переписать.

По итогу - даже запишет Greenplum в S3 данные через драйвер-враппер (Yezzey). Как потом это прочитает другой кластер гринплмам, у которого другое число сегментов? И получился вроде и лейк, но в то же время это просто МРР с одной вынесенной куда-то таблицей, от которой другим чтецам пользы никакой.

А сдвинуть МРР с этой точки это переписать само ядро так что это будет уже что-то совсем другое. Долгий путь.

А ты такой холодный
Как Айсберг в даталейке

Запись вебинара

https://vk.com/video-164978780_456239739

Last Call

Записываемся на трансляцию вебинара по Айсберг!

Задаем интересующие вас вопросы в посте 👆

До встречи на трансляции или в записи!

Итак, что вы хотели бы узнать про Айсберг?

Тред вопросов.

Интересные затронем завтра на вебинаре.

Не все знают, но вот тут в телеграме есть неприметная кнопка, которая позволяет написать в личку владельцу канала.

Ну или можете просто в коменты задать вопрос, я стараюсь отвечать на содержательные технические темы.

Архитектор Данных pinned «Приветствую всех новоприбывших! Спасибо что присоединились! В предыдущих сериях про Лейкхаус или плейлист полезных видео. Первое. Вебинар о плюсах подхода лейкхауса + воркшоп как поднять Iceberg + Trino в облаке. Несколько устарел, так как добавилось много…»