Архитектор Данных – Telegram
Архитектор Данных
1.09K subscribers
144 photos
8 videos
2 files
116 links
Алексей, архитектор данных из ВК.

Большие данные и облака.

Для связи @alexbelozersky
Download Telegram
Выступаю на Arenaday 2025

Ровно через неделю, 22 апреля состоится большая ежегодная конференция Аренадата - ArenaDay 2025.

Совместно с архитекторами Аренадаты мы подготовили доклад об эффективном обеспечении отказоустойчивости кластеров ArenaDB.

Не так сложно организовать полноценную вторую площадку данных, имея x2-x3 бюджета основной. Но мы пошли дальше и предлагаем решение, которое использует механизмы облака для сокращения бюджета на DR. Причем даже этот резерв не будет бесполезно «греть воздух», а может быть переиспользован для задач аналитики и разработки.

Какие темы раскроем
⁃ Как перестать бояться отказов и начать использовать данные в реальных бизнес-процессах. И причем тут резервная площадка.
⁃ Что может предложить облако для отказоустойчивости данных
⁃ Как организовать ADB DR без кратного роста расходов на инфраструктуру данных
⁃ Как автоматизировать переключение между площадками с помощью сервисов облака
⁃ Как составить детальный DR-план, организовать DR-учения и не бояться отказов
⁃ Как переиспользовать вторую площадку для других задач: Dev/Test окружений, песочниц для разработчиков, сервинга данных для ML и LLM.

No system is safe. Даже самые крутые ЦОДы от ведущих мировых и российских компаний иногда падают. Даже самые безопасные системы ловят вирусов-шифровальщиков.

В мою бытность Head of Analytics меня не один и не два раза выручал тот факт, что у меня есть логический бекап данных в какой-то другой системе. Иметь рабочие механизмы данных в ситуации когда вся инфраструктура вашей компании испытывает проблемы - это гигантский бонус в вашу карму. Вы надежные, вам можно доверить серьезные бизнес-процессы.

22 апреля, вторник, Секция «Гибридное хранилище», 16:30
👍114🔥2
ArenaDay 2025

22 апреля доклад прочитать не получилось из-за срочных встреч. Лучшая в мире команда архитекторов данных подхватила и доклад, и непростую технологическую идею облачного DWH DR!

Основные тезисы доклада.

📈 По мере роста дата офиса ценность данных для бизнеса неизбежно растет. Растут и потери от простоя хранилища данных.

🔬 Greenplum и ArenadataDB - отличная база данных, терпимая ко многим типам отказа оборудования. Но это все еще одна СУБД, опирающаяся на один ЦОД. КХД все еще подверженно отказам.

☁️ Облако дает несколько инструментов для отказоустойчивости.

1️⃣ Первое, это бекап в s3. В инструмент Arenadata Backup Manager можно просто прописать эндпоинты и ключи облачного s3, и это будет работать.
2️⃣ Второе интереснее - это возможность поднять в облаке горячий резерв кластер. Причем, облако обладает гибким подходом к инфраструктуре и умеет на лету по API или по Terraform менять состав инфраструктуры. Одним небольшим скриптом можно массово растить или схлопывать в размере Виртуальные Машины.

Мы можем при основном кластере в 1000 ядер гринплама поднять в облаке DR площадку на 100 ядер и применять в нее все изменения с основного кластера раз в день или раз в час.

💎 В критическом случае отказа основного кластера или ЦОД мы приходим в облачный кластер и командуем ему расшириться до 1000 ядер для принятия нагрузки.
Платим же все это время за фактически потребленные ядро-часы.

🔬 Так с помощью технологий можно значительно повысить отказоустойчивость данных без кратного раздувания бюджета.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍63🔥2
Forwarded from Data Engineering Digest
Пётр Гуринов и Сергей Куприков: Опыт внедрения Lakehouse в компании Лемана Тех.

Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s

Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH)

Кому будет интересно:

- Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться.

---

Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись.

---

🔍 Проблемы старой архитектуры
- Greenplum (Shared Nothing):
- Данные невозможно оторвать от compute
- Ограниченная масштабируемость
- Высокие затраты на хранение

- Pipeline до внедрения DLH:

Источники собираются в Kafka. Flink вычитывает данные, складывает их в S3 в формате avro (слой raw). Далее Spark трансфармирует данные в parquet, складывает данные
в S3 (слой ods). Оттуда данные попадают в GP, который является единой точкой входа всех сотрудников компании (любой сотрудник магазина может запросить доступ к DWH).


---

🚀 Переход на Lakehouse
Требования к новой платформе:

✔️ Open Source
✔️ Разделение compute/storage
✔️ Cloud-ready/cloud agnostic
✔️ Низкий порог входа

Выбранный стек:

- Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников)
- Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake)
- Хранение: S3
- Метаданные: HMS (планы на переход к Nessie для branch-поддержки)

---

⚙️ Реализация:
- Кластеры Trino:
- Ad hoc (пользователи/BI)
- ETL (тех.учетки)
- DQ (Data Quality)

Интеграция:

- Аутентификация через Keycloak + AD
- Управление доступом: file-based ACL

---

🛠 Проблемы и решения
Ограничения технологий:
- Нет коннектора Trino → Greenplum (ходят через Master)
- Iceberg: нет мультитранзакций, сложности с типами данных
- Trino: нет временных таблиц, legacy spill-файлы

🛠 Мониторинг:
- Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana.
-Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется.
Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset
- Кастомный сбор метрик запросов через Kafka → ClickHouse

🛠 Управление инфраструктурой:
- GitOps + ArgoCD + Vault
- Автоматические откаты

---

📊 Результаты
Экономия:
- Хранение дешевле в 10+ раз
- Быстрое масштабирование в Kubernetes
- Независимое масштабирование и отсутствие необходимости резервировать место заранее.

Производительность:
- Ускорение расчетов витрин
- Легкий переход запросов с GP на Trino
- Аналитики получают дополнительную точку входа для доступа к данным
- Разные вычислительные движки могут использовать одни и те же данные.
---

🔮 Планы
- Замена HMS на Nessie
- Продуктивизация SCD2-таблиц
- Автоскейлинг Trino на основе метрик
- Копирование Iceberg-таблиц в Greenplum
- Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only

---

💡 Вывод:
Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.
7🔥73
LLM Text to SQL

Работаем над технологией конвертации аналитического запроса на естественном языке в SQL и далее в ответ. Используем демо базу авиаперелетов от Postgres PRO.

Пока по моим наблюдениям такой бот максимально напоминает стажера-аналитика. На фото типичная ошибка джуна: перепутал время заказа билета с временем перелета. Только на джуна ты наорешь, и он исправится, а LLM так и останется глупеньким. Ну и самостоятельную работу джуну поручать нельзя.
👍7😁52👏1
Стримить данные в S3

В контексте развития лейкхауса часто возникает мысль - а было бы круто стримить данные сразу в S3! (Еще бы лучше прямо в айсберг формат с прогоном через метастор, но это мечты-мечты)

Шорт-лист вариантов, как это можно сделать.

1. S3Sink коннектор Kafka Connect.
https://github.com/Aiven-Open/s3-connector-for-apache-kafka
2. S3Stream для AutoMQ. AutoMQ - совместимый с форматом Кафки Cloud Native стриминг
https://www.automq.com/docs/automq/architecture/s3stream-shared-streaming-storage/overview
3. WarpStream - целая платформа вокруг этой идеи. Куплена Конфлюентом.

Honorable mentions

Обещания от Кафки KIP-1150 - disk-less topics. Звучит круто, подождем еще годочка три.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1150%3A+Diskless+Topics

TableFlow - подключаем топики Kafka как объекты в Iceberg Metastore. Не пуш, а пулл, но сгодится. Похоже, доступно только для проприетарного Confluent.

Кто стримится в лейк - расскажите как именно!
👍8
Последняя линия ментальной обороны (1/2)

Знакомо ли вам чувство крайней эмациональной усталости? Это когда угнетают проблемы, которые ты в спокойном состоянии легко бы решил. Или когда бомбишь от ситуаций, которые того явно не стоят? Некоторые еще на людей начинают бросаться, когда коллеги и близкие того не заслуживают.
Я работаю с энтерпрайзом, так что мне это состяние вполне знакомо 😄

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

Истории, с которых полыхал буквально полчаса назад, делятся в голове на категории:
а) вообще не стоят внимания и ни на что не влияют,
б) можно отложить, срочность и важность надумана,
в) понятно, как делать или к кому обратиться за помощью.

Чтобы было одновременно важно, срочно и притом непонятно как - это все-таки редкость.

В большинстве случаев простой прием с прогулкой работает, и можно жить дальше.
Но случается и так, что прогулки по дворам не помогают. Все настолько плохо, что простые методы разгрузки не спасают. Так жестко навалилось, что эмоциональные патроны кончились.
👍104🤔1💯1
Последняя линия ментальной обороны (2/2)

Как последняя линия ментальной обороны я достаю одно базированное видео. Оно довольно старое. Возможно вы видели его на ютубе лет 10 назад. Это речь на выпускном Техасского университета от одного из старших выпускников, высокорангового американского "лампаса". Кто разбирается в форме, сможет сказать точно, кажется, это двухзвездный адмирал. Пропускаем американизмы про изменения мира к лучшему, америакнскую мечту, обязательную вставку про дайверсити и переходим к базе.

В базовой части адмирал делится, как он проходил подготовку в лагере морских котиков SEAL. И успешно прошел, что очень полезно для карьеры. Он дает не то чтобы сверх много деталей, но сразу же вспоминается и "Цельнометаллическая оболочка", и "Майор Пейн". 90% рекрутов не выдерживают физических страданий и ментальных унижений и уходят в процессе подготовки.

Несколько банальных солдафонских истин:

1️⃣ Бывают ситуации, где ты неизбежно попадаешь под раздачу. Неважно, насколько ты хорош, неважно, что ты все делаешь правильно, неважно насколько стараешься. (Пример с инспекцией формы)
2️⃣ В сложном деле ты неизбежно где-то серьезно облажаешься. И тогда в твой и так адский график добавляется еще дополнительная тяжелая работа, боль и страдания. (Пример с "цирком"). Надо научиться не ломаться ментально от неберущихся авралов.
3️⃣ Людей оценивают по результатам (Шлюпочная команда). Результат часто не коррелирует с внешним видом или первым впечатлением.
4️⃣ Тебя и правда могу сожрать акулы. В серьезном деле ты столкнешься с опасными ситуациями или опасными людьми. Страх этих встреч надо преодолеть.
5️⃣ В самый ответственный момент надо быть лучшей версией себя. (Минирование судна)
6️⃣ Порой единственное что отделяет успех от неудачи, это надежда и вера в свет в конце туннеля.

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

Из видео я черпаю две мысли.

Первая. Как бы тебя сейчас не плющило, это ничто по сравнению с лагерем морских котиков. Причем, в лагере все находятся добровольно и в любой момент могут его покинуть. Одна из фишек буткемпа в том, что в любой момент можешь положить каску на плац, позвонить в колокол, и все прекратится. Никто никогда не скажет дурного слова - все знают, что это звздец.
Еще раз, люди добровольно берут на себя куда большие страдания, чем ты сейчас.
В мире есть вещи, ради которых стоит расплющиться. Может и твоя история, от которой ты так картинно изнемогаешь, одна из них?

Вторая. В любом большом деле бывают случайности не в твою пользу. Залеты и прилеты неизбежны и часто несправедливы. Местами надо просто смириться с этим и перетерпеть.

Мне комбинация этих супер-простых мыслей часто дает глоток воздуха, мой внутренний бомбист утихает на всемя. Раз в полгода - самое то.

Само видео тут.
👍9🤨3😁2👎1🔥1😱1
Ситуационный центр данных

То, чего как правило нет.

Должен отвечать на вопросы:

⁃ Какой сейчас статус прогрузки данных?
⁃ Какие инциденты активны? Какого типа: мисы по SLA, ошибки качества, нарушения контрактов, недоступность источников. Кто ответственный и какой текущий статус?
⁃ Потребление ресурсов ХД, ЕТЛ и других систем данными различного типа, качества и различных владельцев
⁃ Текущие Request For Change
⁃ Текущие контракты на поставку данных и история их (не)исполнения

Но как правило хорошо если есть графана с данными о статусах пайплайнов из Airflow да таблица размеров объектов в КХД.
👍85💯3
А бывает и наоборот
😁173👍3
Forwarded from Некстджен и Усиление+ (Yuri Krupenin)
Хозяйке на заметку: облачный бэкап файлов абсолютно бесплатен, если использовать файловую систему WhenFS, которая будет хранить ваши данные в гугл-календаре, кодируя их base64-чанками и запихивая в названия встреч. Это лучший подход, я уверяю вас.
😁54🤝32
Лучший на всем Западе облачный Гринплам

Бывают моменты, когда хочется подвести черту под некоторыми этапами.

Два года мы с командой делали лучший облачный Гринплам.

Что нам удалось достигнуть
1️⃣ Мы поняли, что этот не самый простой для облачной среды сервис можно заставить хорошо работать. И что конкретно для этого надо сделать.
2️⃣ Мы разобрались с процессами поддержки на нескольких уровнях. От дежурных к внутренним экспертам и далее до вендора. Несколько раз влетали в серьезные аварии, один раз поднимались из бекапа. Было непросто и в техническом, и в человеческом плане, но у нас получилось выйти на новый этап.
3️⃣ Сделали простой но эффективный мониторинг ГП. Не бог весть что, но кастомизируемо и шлет алерты по типовым проблемам вроде отвала сегментов, забитии дисков, очередях в ресурсных группах - там, где 90% проблем. И по 90% проблемам мы стремимся к проактивной реакции на возникающие проблемы. Принцип Парето в действии.
4️⃣ Вместе с клиентами проработали, как правильно применить Гринплам по назначению. Как известно, от СУБД до КХД еще очень большая дорога, и мы научились ее проходить, а где-то даже и пробегать.

Если Лейкхаус это пока что платформа для экспериментов, то Гринплам - отраслевой стандарт. Машина тяжелая, но хорошая, убойная.

Хочу сказать огромное спасибо всем, кто был с нами на этом пути.
🧗‍♂️ Клиентам - за терпение
💯 Вендору (Аренадата) - за отличный продукт и поддержку в трудных ситуациях.
😎 Команде - за буйство в хорошем смысле. Вашу храбрую дружину, предпочту я многотысячному войску!

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

🚀🚀🚀🚀🚀🚀
Но в то же время, реальность требует развиваться в новые технологии. Для меня это Лейкхаус и аналитические приложения стека LLM.

Всем побед!
👍123👏3
Нашел самый полезный курс для Архитекторов.

От alma mater %)
😁20🤣3🫡31
Отвечу на вопрос от уважаемого подписчика

1️⃣ Нет никакой сложности оркестрации DBT + Airflow. Есть подготовленные DBT-операторы, которыми очень приятно пользоваться.

2️⃣ Dagster модный, вот про него и пишут. 😎 Лично им мало пользовался, все же Airflow стандарт, но не предвижу никаких проблем или особенностей в оркестрации DBT проекта и на Dagster тоже. Что в лоб, что по лбу.

3️⃣ Правильно - как удобнее. В не сильно большой команде удобнее в монорепо DAGs + DBT. Тогда в одном коммите видны все изменения пайплайнов.

Когда команда больше, то может быть удобнее разделить. Одна команда делает DBT проект для общего пользования, другие подключают его через DBT Packages. Или когда один AF оркестрирует несколько DBT проектов: для лейка(-хауса) и для КХД с разным стеком.

4️⃣ Не, DBT не для миграций.

5️⃣ На кластере Airflow в любом случае должна быть синхронизрованная кодовая база на всех мастерах и воркерах.

Спасибо за вопрос!
64👍4🔥2
Офис данных (сущ.) - Группа людей, осознанно и целенаправленно развивающая стек обработки данных.

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

Не обязательно отдел/департамент/руководитель, но обязательно кто-то способный ответить на вопросы:
- какие типовые проблемы есть?
- какой план борьбы с ними?
- какая в целом стратегия?
- как повысить эффективность обработки данных?

А в идеале:
- как превратить данные из центра затрат в центр прибыли?
👍6👏32