Привет, Хабр! Меня зовут Наталья Горлова, я архитектор данных. Отвечала за систему хранения и обработки данных в CDEK.
Несколько лет назад мы поняли, что продукты, на которых работало хранилище, перестали нас устраивать: не устраивала гибкость разработки и скорость поставки данных. C тех пор произошло множество изменений, которыми хочется поделиться с сообществом.
Расскажу, как платформа данных CDEK развивалась, и к чему мы пришли на конец 2024 года. Эта статья — ретроспектива моей почти шестилетней работы и текущих реалий нашей платформы данных.
Содержание
2017 год. В начале было слово — «BI»
Ну что ж, начнём с начала. В 2017 году вся операционная и аналитическая отчётность строилась внутри монолита на MySQL и C++.
Бизнес активно рос, за почти два десятка лет работы компании c 2000 года накопилось достаточно много данных, которые на OLTP СУБД MySQL и выгрузках в excel стало сложно анализировать. СДЭК — крупная логистическая компания, данных и процессов много, и всё это нужно контролировать и развивать.
Один из архитекторов подумал и предложил OLAP‑кубы BI (сравнение OLTP vs OLAP). Это было хорошим решением. Вдохновившись статьёй коллег, в качестве пилотной СУБД для хранилища выбрали OLAP СУБД Vertica (её бесплатная версия до 1 Тб, на тот момент) и модель данных ядра хранилища AnchorModel. Anchor Modeling — гибкий метод моделирования, подходящий для работы с постоянно растущими объемами данных, которые меняются по структуре или содержанию. Якорная модель позволяет воспользоваться преимуществами высокой степени нормализации, при этом оставаясь интуитивно понятной и быстро расширяемой. Подробнее про формы хранения данных можно ознакомиться в этой статье.
Для обработки данных использовали бесплатную версию PDI. Если говорить просто: открыли базу‑источник, что‑то оттуда забрали, преобразовали и положили в КХД.
Визуализация OLAP кубов — бесплатная версия Pentaho server.
В качестве пилота реализовали несколько ключевых кубов данных для направления «Коммерция»: Продажи и Выполнение. Бизнес остался доволен скоростью и гибкостью отчётов, дал добро на формирование команды BI.
В 2018 году прорабатывали бизнес‑объекты и формировали ядро хранилища данных — сердце DWH. Также параллельно разрабатывали новые отчёты.
2019 год. Первый переезд
В 2019 году я присоединилась к команде. BI развивался, всё работало отлично. Пока мы не упёрлись в максимально доступный в триальной версии Vertica объём в 1 Тб.
Нужно было искать новое хранилище. Изучив разные решения, архитектор выбрал IBM DB2. Купили лицензию. Управились в два дата‑инженера за четыре месяца: переписали SQL‑скрипты и прогрузили данные, научились работать с новой СУБД, по дороге собрали ряд шишек с новым диалектом и настройкой кластера (DB2 подняли в кластере из 3-х нод).
Как выяснилось потом, выбор DB2 был не самым удачным решением. Через несколько лет мы переехали на Greenplum, но об этом ниже.
Что стоило сделать лучше?
Привлекать DBA. При выборе СУБД к DBA не обратились. Отсутствие экспертизы привело к ряду аварий и одной потере хранилища с полным восстановлением данных из источников. Тот, кто хоть раз восстанавливал хранилище с нуля, поймет. Это было непросто и вызвало простой в работе аналитики на неделю.
2020 год. Clickhouse
Количество данных и отчётов росло, мы дошли до объёма в 20 Тб.
Количество OLAP‑кубов выросло до 15 и появились первые дашборды — интерактивные панели данных, которые в удобном для анализа виде предоставляли информацию для принятия решения.
Подготовка данных не успевала завершиться до начала работы бизнеса. Расчеты и отчеты начали пересекаться, замедлилась скорость формирования отчётов, появились блокировки при обновлении данных. Пользователям это не нравилось. Изучив проблему и варианты решений, я предложила перенести витрины отчётов в Clickhouse — столбцовую СУБД для онлайн‑обработки аналитических запросов (OLAP).
DWH осталось на DB2, слой Report переехал на Clickhouse. Дашборды стали формироваться моментально и не мешали подготовке данных. Пользователи остались довольны.
2021 год. Superset для дашбордов
С развитием BI интерес пользователей к удобной форме отчетности вырос. В результате мы внедрили продвинутую платформу для визуализации данных Superset и набрали команду аналитиков, чтобы помогать бизнесу быстро и качественно принимать решения на основе данных.
2022-2024 год. Airflow и Greenplum — трансформация хранилища
К началу 2022 года перед нами встали следующие вызовы.
Скорость обновления данных не устраивала бизнес. Количество отчётов росло, и полный пересчёт за вчера заканчивался к вечеру, что приводило к отставанию в 2 дня отчетов для бизнеса и не соответствовало требованиям к скорости поставки данных в сутки.
Управлением расчётом. Запуск задач Pentaho по Cron не позволял гибко перезапускать и отслеживать их выполнение, управлять расчётом.
В 2022 году IBM DB2 ушло с российского рынка и остановило поддержку. На тот момент наше хранилище выросло до 30 Тб.
-
Команда DWH — узкое горлышко. Дата инженеров мало. Кол‑во аналитиков и запросов на данные выросло. Нам нужны были инструменты self-service для аналитики.
Нам нужно было менять хранилище и подход к поставке данных. Проанализировали функциональные и нефункциональные требования.
Ключевые изменения
1. В качестве хранилища выбрали Greenplum
Подробнее о нём можно узнать из этого текста, а как с ним жить с точки зрения DBA — из этого. Я считаю Greenplum хорошим решением для классического хранилища с небольшим объёмом данных (десятки терабайтов).
2. Переехали на Airflow c Pentaho
Это дало нам визуализацию потоков и гибкость в управлении.
В Airflow (на момент выхода статьи 2.10.3) мы настроили генерацию трансформаций (DAG) через YAML‑конфиги. В итоге больше 1000 процессов поддерживаются десятком базовых генераторов, всё остальное определяют сами аналитики через конфиги YAML. Конфигурация похожа на dbt, но внутри на python больше адаптации под наши потребности. Управлять потоками данных стало проще.
Airflow мне сразу понравился своей гибкостью и визуальной составляющей. Команда со мной согласилась.
3. Отказались от Anchor Model в пользу гибрида 3НФ с элементами DataVault
Anchor Model красивая, гибкая, но, увы, рост количества таблиц, приводит к росту количества JOIN и замедляет расчёт витрин. Новые требования отчетов с максимальным отставанием в 3 часа, сложность расчетов, стабильность и полнота источников публикуемых данных привели к тому, что мы отказались от высокой нормализации в пользу скорости в виде микса 3НФ c элементами DataVault. В результате сформировали следующие слои данных:
4. Внедрили Kafka и контракт на публикацию данных вместо прямого забора из БД
К тому моменту CDEK перешёл с монолита на MySQL и C++ на микросервисы PostgreSQL и Java. Все модули обменивались данными через корпоративную шину данных. Для аналитики подняли Kafka и согласовали контракты на поставку данных. Таким образом, мы стали частью общей системы обмена данными и перестали получать ошибки из‑за изменений в БД источника. Это был сложный и важный шаг для повышения надёжности доставки данных в DWH.
5. Организовали быструю поставку сырых данных AS IS в RAW (Stage‑слой) раз в 15 минут в течение дня
Позволило заранее подгружать данные в хранилище и быстрее обновлять витрины ночью, так как данные уже загружены в RAW‑слой. Также часть простых витрин строится на данных, которые напрямую загружаются из Kafka в Clickhouse. Это позволило быстро отвечать на вопросы бизнеса (lambda‑архитектура).
6. Перешли с полного пересчёта на дельта‑обновление слоёв RAW (stage) → DDS (3НФ) → CDM
Частично у нас получилось перевести расчет витрин слой REP на дельта обновление с полного пересчета. Это сильно ускорило обновление данных. Там, где не получается вывести дельту, мы обновляем партициями глубиной в согласованный с бизнесом период. Настраиваем S3 в качестве сырого/холодного слоя данных.
7. Ввели каталог данных Datahub
Чтобы дата‑аналитики и ML‑команда могли сами находить данные в хранилище и по всей системе. Следим за документированием хранилища на уровне кода и описанием источников данных.
8. Внедрили и настроили Data Quality (проверку качества данных) в каждом слое от ядра до конечных витрин, с элементами self-service
Аналитики сами могут определять проверки и получать уведомление о проблемах. Закрепили ответственных за витринами на уровне кода. DQ‑инженер настроил дашборды и уведомления по нарушению SLA и ошибкам поставки данных в каналы Mattermost.
DQ проверки описываются в конфиг файле и встраиваются в DAG. Код проверок написан на Python, визуализация — в Superset.
9. Написали документацию по всем генераторам и конфигурациям
Обучаем работе со всеми СУБД и инструментами в рамках нашей гильдии BigData.
10. Развиваем self-service инструменты поставки данных
Источники знают и несут ответственность за поставку данных в платформу, продуктовые дата‑инженеры и аналитики определяют данные в хранилище, формируют запросы для расчета бизнес‑витрин, добавляют проверки на данные. Все это проходит ревью дата‑инженеров команды ядра и валидируется CI/CD в GitLab. У дата‑инженеров ядра появилось больше времени на развитие инструментов и автоматизации процессов. На это нас вдохновил подход DataMesh.
В итоге к концу 2024 года у нас получилась следующая платформа данных:
Новая платформа — возможности
-
Ускорение обновления данных
Отчёты для бизнеса готовы к началу рабочего дня — это было главной целью.
Общая длительность обновления отчётов 6 часов. При этом кол‑во ежедневно обновляемых отчётов значительно выросло (больше 170), плюс осталось несколько ключевых OLAP‑кубов. Также появились дополнительные потоки отчётов, обновляемых в течение дня с разным SLA (раз в 15 минут, 2–3 часа).
-
Гибкие обслуживание и нагрузка хранилища
Разделение хранилища (Greenplum) и BI (Clickhouse+Superset) позволило не влиять на скорость формирования бизнес‑отчётов и обслуживать хранилище незаметно для бизнеса.
-
Повышение доверия к данным
Благодаря внедрению DQ: проверки качества данных на ключевых этапах и быстрые уведомления о проблемах, получилось повысить доверие к данным для дата‑аналитиков и бизнеса.
-
Сокращение TTM новых отчетов
За счет self-service инструментов TTM новых отчетов теперь зависит от источника и аналитика данных, не упирается в ограничение одной команды дата‑инженеров (TTM от 1–7 дней).
-
Снижение количества инцидентов от источников
Контракт на поставку данных и прозрачность процесса уменьшил кол‑во инцидентов из‑за изменения источника.
-
Независимость от вендора
Open source инфраструктура сократила расходы на платформу, больше не нужно платить за лицензию вендору.
Что стоило сделать лучше? Небольшая ретроспектива
-
Лучше продумывать кодовую базу проекта
Когда стала архитектором, начала настраивать процессы: дизайн‑ревью, стандарты, валидацию качества кода и конфигураций, но к тому времени накопилось достаточно расхождений в форматах генераторов, которые тормозили автоматизацию.
-
Не бояться пробовать новое и внимательнее смотреть на готовые решения
2 года назад щупала dbt, но не решилась вводить из‑за уже написанных решений и других фокусов проекта. Сейчас немного об этом жалею. Но рада, что когда‑то настояла и внедрила airflow и clickhouse.
-
Прорабатывать мастер‑данные и потоки данных (Data Governance)
Долгое время BI жил в стороне от операционных процессов. Модули не знали, что мы делаем и как их изменения влияют на отчеты. Много времени ушло на то, чтобы это преодолеть и встроиться в общую систему поставки данных. Включайте в работу с данными как можно больше заинтересованных сторон, не замыкайте на одной команде всю ответственность. Внедряйте стандарты и self‑service инструменты.
-
Данные должны приносить пользу
Учите пользователей работать с данными. При выборе хранилища изучайте требования, источники данных и ресурсы. Учитывайте рост и требования на поставку данных. Не всегда красивые концепции других компаний дают лучший результат (Anchor Model). Ищите своё решение. Если для бизнеса история не нужна, то не тратьте ресурсы на её хранение.
-
Data quality — это важно
Контроль качества данных — это важный элемент в борьбе за доверие к данным. Не стоит им пренебрегать.
-
Команда — ключ к успеху
Я верю, что команда — ключ к успеху.
Всё началось с BI и пары кубов. Выросло в несколько сотен дашбордов, тысячи пользователей, команды ML‑инженеров и аналитиков данных, хранилища больше 30 Тб. Ежедневно на новую платформу данных поступают десятки гигабайтов, более 1000 ETL‑процессов запускаются самостоятельно в Airflow.
Всё это благодаря людям, которые работают над платформой данных. Сейчас команда ядра состоит из восьми дата‑инженеров, системного аналитика, DevOps и DQ‑инженера, нескольких разработчиков на Python и Java.
Я благодарна каждому, с кем успела поработать. У команды DWH впереди большие планы.
В следующих сериях расскажем про дашборды в Superset и ML‑платформу. С удовольствием отвечу на вопросы в комментариях!
Комментарии (36)
mrgervant
19.02.2025 15:01Вот сколько читаю такие статьи, то только и надеюсь что в моей компании выделят ресурсы на рефакторинг всей системы DWH. А то судя по всему наши ETL-процессы для сильных духом: загрузчики пишутся каждый раз практически с нуля на Python без каких-либо библиотек для дата-инжиниринга, а стартует всё через cron linux-а. Про другие вещи молчу.
Что лукавить - хочется поучаствовать для личного роста в трансформациях как в статье.
Респект автору.
Ivan22
19.02.2025 15:01умение вовремя отказатсья от DataVault - признак взрослости архитектора DWH
Hyperplasia
19.02.2025 15:01Вроде бы наоборот частично перешли на него. А "взрослые" архитекторы dwh, что нынче выбирают?
de_natafka Автор
19.02.2025 15:01Привет!
я не могу сказать за всех, но из своего опыта отмечу, что метод моделирования надо выбирать исходя их ваших требований , источников и ресурсов . В первую очередь нужно сформировать функциональные и не функциональные требования, оценить вектор развития аналитики и ограничения компании. Исходя из требований можно подобрать подходящую архитектуру.
Яндекс делал гибрид волта и якоря, например https://habr.com/ru/companies/yandex/articles/557140/
Архитектура дело творческое.
Kilinsky_MA
19.02.2025 15:01Подскажите, airflow не тормозит с 1000 дагов? Как оптимизировали file processing для ямлов?
de_natafka Автор
19.02.2025 15:01Привет! Отличный вопрос.
Я люблю airflow , но с генераций были проблемы. Технически у нас около 400 физических дагов , остальное генерятся из yaml конфигов. https://airflow.apache.org/docs/apache-airflow/stable/howto/dynamic-dag-generation.htmlС генераторами мы ловили проблемы с тем, что даги пропадали и тригерный процесс не мог их найти и запустить. Оказалось , что шедулер не успевал за один проход обработать код всех дагов и не добавлял их в методанные БД.
Что делали :
1) увеличивали некоторые параметры
# Количество секунд, по истечении которых анализируется файл DAG. Обновления в базах данных отображаются через этот интервал.
AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL: "480",
# Сколько времени пройдет до истечения тайм-аута DagFileProcessor, который обрабатывает dag-файл
AIRFLOW__CORE__DAG_FILE_PROCESSOR_TIMEOUT: "360"
# Частота (в секундах) сканирования директории с дагами на появление новых файлов. По-умолчанию 5 мин.
AIRFLOW__SCHEDULER__DAG_DIR_LIST_INTERVAL: "600",
# Планировщик может запускать несколько процессов параллельно для анализа групп данных
AIRFLOW__SCHEDULER__PARSING_PROCESSES: "40",
2) Разделяли по слоям генераторы и улучшали кодовую базу согласно рекомендациям, что помогло снизить нагрузку на шедулер https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html
3) По ресурсам на текущий момент scheduler - 4 cpu, 8 ram airflow развернут в Kubernetes. У нас настроен автодеплой через CI/CD после мержа в мастер. Ежедневно проходит с десяток релизов)
На данный момент работает 1092 дага , которые запускаются почти все ежедневно.
Kilinsky_MA
19.02.2025 15:01Благодарю за подробный ответ
de_natafka Автор
19.02.2025 15:01Спасибо за вопрос.
Я наверное еще отмечу, что у нас есть боевой инстанс airflow, про него я ответила выше. Есть песочница аналитиков - это отдельный инстанс, где аналитики могут сами собирать ad-hoc витринки и проверять гипотезы не влияя на бой. Есть тестовые инстансы airflow , которые поднимаются под задачи дата инженеров. Получилось достаточно удобно.
Ninil
19.02.2025 15:01Спасибо. Интересно было почитать.
В качестве вывода я ещё бы добавил, что решения 2017-2019 года наводят на мысли о низкой компетенции архитекторов и одновременной экономии на хотя бы временом привлечении консультантов для выботки архитектуры и стратегии. Сделал в голове пометку про такую особенность работы в СДЭК :-)ПыСы многое из того что вы в конце статьи преподносите как достижение 2025, для нас (хороший консалтинг) было стандартом "by default" ещё в 2015м
de_natafka Автор
19.02.2025 15:01Привет! Спасибо за комментарий.
«Historia magistra vitae (история — учительница жизни)». В то время 2017-2019 компания больше разбиралась в операционной работе и аналитика только развивалась. Были выбраны решения, которые позволили стартануть аналитику и это хорошо. Были сделаны ошибки и мы их учли.
То что команда вышла на современный стек и смогла ,не останавливая работу аналитики, переехать на новое хранилище и инструменты, я считаю, это здорово.
Я согласна, что на рынок надо смотреть и надо брать лучшее. Сама часто посещаю конференции и смотрю на решения других компаний. Так же важно ориентироваться на возможности и требования твоей компании. Текущего решения для данного уровня аналитики было достаточно, дальше будет больше.
Про стратегию в СДЭК. Я могу отметить, что компания шагнула вперед. В СДЭК есть арх совет, есть стратегия на уровне компании. На стратегической сессии мы формировали вместе с CDO стратегию по развитию аналитики и дата платформы на 2025 год. Из хорошего в компании есть гибкость и мало бюрократии. Я напрямую работала с каждым в команде, мы вместе формировали решения , которые обсуждали на дизайн ревью.
Senecaminor
19.02.2025 15:01Блестящая карьера архитектора и эталонное развитие архитектуры!
Ivan22
19.02.2025 15:01Эталонная была если бы сразу подумали что 1тб Vertica мало, а платить за больше не будем. Не подумали. Или если бы сразу чуть подумали на тему что DB2 это днище, но не подумали. Кстати и с Greenplum тоже придется съезжать, так что тоже не додумали. Так себе эталон. Разве что респект за признание ошибок :)
P.s. я уж молчу про датавольт
krids
19.02.2025 15:01DB2 это отличная MPP СУБД для DWH/OLAP-задач. Другое дело, что платить за нее в 2019-ом при наличии уже бесплатного Greenplum никакого смысла не было. Ну а строить DB2 DPF-кластер на 30 ТБ без DBA это прям классическая история про "слабоумие, отвагу, кроилово и пападалово".
vdshat
19.02.2025 15:01Редко встретишь отдельный Data Quality слой. За это, прям, низкий поклон. В одной очень толстой конторе на меня смотрели как на умалишенного только за предложение, хотя бы проверить качество данных и соответствие их требованиям, не говоря уже за полный контроль и автоматизацию проверки.
Честно говоря, странно, что вплоть до 2022 года были архитектура и решения из 90х. Прям жалко, что столько тратилось средств и ресурсов впустую. Хорошо, что вы пришли к взвешенному решению. Удачи и успехов!
Ivan22
19.02.2025 15:01DQ это инструмент. Он имеет смысл в реализации ПОСЛЕ того как появляется механизм владельцев данных. Когда у каждой витрины есть владелец, которому прилетает за косяки в его витрине, то он первый же и приходит с просьбой: "Ребята, а давайте как-то автоматизируем проверки, а мне надоело руками каждый день сидеть качество данных сверять". И тут и появляется DQ слой. Это нормальная эволюция data governance.
А ненормальная, когда наоборот, никакого Data Ownership-а нету, а команда DWH решила сделать DQ. Сделать-то сделали - только кто им пользоваться будет?? Если витрины (или любые другие дата продукты) ничьи - кому аларм слать при фейле проверок??? Девелоперам чтоли?? Ха-ха.
vdshat
19.02.2025 15:01DWH не имеет смысл без целевой аудитории. Да, есть подход: "Давайте все подряд хранить (с непонятным качеством), а потом разберемся". Но это помойка, а не хранилище данных.
Недавно был наглядный пример с битой по кошельку. При заливке данных в дата сервис из Oracle в MSSQL терялась точность. Т.к. контора была крупная и количество нулей в цифрах было внушительным набегало ощутимо. В отчетности этого сразу и не увидеть, т.к. все думали, что таких "косяков" в 21 веке не должно быть. Но выявили именно на интеграционных тестах разработчики. Скандал знатный был!
Ivan22
19.02.2025 15:01Не путай целевую аудиторию и владельцев данных. Это разные люди. Целевая аудитория у тебя может быть и вообще CEO всего энтерпрайза, которому каждоеу утро долежен отчет прилетать свежий. Это же не значит что он же и владелец витрины в которой это все считается и еще и за DQ её отвечает. Целевая аудитория как раз практически всегда есть, ибо иначе кто вообще бюджет выделять будет на DWH. А вот владельцы дата продуктов могут и отсутствовать
vdshat
19.02.2025 15:01Вот именно. Кто платит - тот и заказывает музыку. А все промежуточные звенья вторичны. Но как раз тот же СЕО может не до конца или вообще не видеть ценность этих данных. И не потому, что он тупой, а потому, что эти данные реально не имеют ценности для бизнеса, а являются чьей-то хотелкой для распила денег на среднем уровне.
Живой пример. Одна контора ежегодно платит крупной аудиторской фирме за формирование гос. отчетности круглую сумму. Отчеты с технической точки зрения абсолютно несложные. Менеджер среднего звена выступает с предложением сделать собственное решение и формировать отчеты самостоятельно. Мы реализуем проект. Проходит демонстрация на ура. Компания ежегодно может сэкономить солидную сумму. Менеджер осваивает бюджет в рамках дозволенного и идет на повышение. Все довольны. Продакшн. Следующая версия и т.д.
Через 3 месяца все сворачивается: возвращаем все назад! С точки зрения бизнеса и компании никакого выигрыша нет, т.к. свое решение требует поддержки, а отказ от части услуг аудиторской фирмы грозит имиджевыми издержками.
Конечный владелец есть всегда бизнес, а не средние прослойки. Многие отчеты среднего звена делаются "для галочки" или красивых графиков для презентаций, но не влияющих ни на что.
McKinseyBA
19.02.2025 15:01Пока мы не упёрлись в максимально доступный в триальной версии Vertica объём в 1 Тб. Нужно было искать новое хранилище. Изучив разные решения, архитектор выбрал IBM DB2. Купили лицензию.
Поржал в голос над выбором и компетентностью архитектора)
модель данных ядра хранилища AnchorModel
Собрался поржать второй раз, но вы и сами поняли, что не туда свернули)))
По итогу - ценой неоднократного перепила data стэка получилось решение, соответствующее текущим реалиям. Вопрос может и не по адресу, но интересно, а инцидент мая 2024 на DWH и ETL обвязку как-то повлиял?
Shirshakov
19.02.2025 15:01вы и сами поняли, что не туда свернули)))
Не демонизируйте AnchorModel. На момент выбора якорной модели она неплохо себя показывала. Тогда компания переезжала с монолита на микросервисы, поэтому максимальная гибкость была очень кстати.
Архитектура хранилища существует не в вакууме, а в инфраструктуре компании. И если окружение меняется, то меняется и архитектура хранилища.а инцидент мая 2024 на DWH и ETL обвязку как-то повлиял?
Нет, не повлиял. Только немного подвинул сроки.
McKinseyBA
19.02.2025 15:01Не демонизируйте AnchorModel
Ее и демонизировать не нужно - реалии расставили все по местам так, что даже евангелисты этой модели в России были вынуждены сокращать косты на нее. А последние 5 лет львиная доля больших проектов хранилищ создается в DataVault 2.0. Остальное - "по звезде".
Нет, не повлиял. Только немного подвинул сроки.
Жаль, что компания так и не рассказала, что там было и как. Но этот риторический вопрос, наверное, не к вам
EvgenyVilkov
19.02.2025 15:01Делать по принципу "все побежали и я побежал" не всегда правильно и хорошо. Если про ДВ20 пишут и рассказвают об успешном успехе это не значит что он в реальности этот успех есть.
EvgenyVilkov
19.02.2025 15:01На вашей архитектурной схеме на тот момент зя якорем идет 3нф. Внимание вопрос - а зачем вам якорь тогда? Просто вы скопировали архитектуру якорь+вертика из авито. ИМХО сейчас опять копируете - выбираете дата волт а под ногами система для расчета, которая не иммет join оптимизаций.
de_natafka Автор
19.02.2025 15:01Привет!
На момент старта DWH действительно скопировали с Авито.
Сейчас у нас нет чистого волта. В 3 пункте я говорила, что есть элементы и возможность развития в волт. Сейчас больше 3НФ и только некоторые таблицы связей и атрибутов вынесены отдельно, так как есть сложные источники у который так проще хранить и обновлять данные.
На данный момент хранилище хорошо покрывает бизнес: все ключевые элементы загружены и используются аналитикой.
EvgenyVilkov
19.02.2025 15:01Это хорошо. Но, есть ощещение, что вы на очередном промежуточном шаге, а не в целевой архитектуре и платформе. Время покажет
Ivan22
19.02.2025 15:01не иммет join оптимизаций.
С чего это? У них все джоины в гринпламе делаются, там все более менее с джоинами. А кликхаус это так - кэш для репортинга.
EvgenyVilkov
19.02.2025 15:01В ГП все плохо с джойнами. Лучше чем в КХ конечно, тк они хотя бы есть. Но гораздо хуже чем в любом современном движке вроде трино, Дорис, старрокс или импала.
Ivan22
19.02.2025 15:01"современном" ??? Современный у нас это Snowflake или Databricks. Impala давно уже легаси
EvgenyVilkov
19.02.2025 15:01у вас это где? В РФ и российских обалчных PaaS? :) Трино, Дорис, Старрокс тоже легаси?
Что кстати делает Импалу легаси? Отсуствие популярного чата в телеграмме? :)
Ivan22
19.02.2025 15:01у нас в AWS. И тут в AWS я никаких impal не видел давно.
Да и в Azure тоже
Что кстати делает Импалу легаси
Сейчас все что не Claude Native - это уже легаси.
VitaminND
Спасибо, очень интересно! Есть чему поучиться.
Также были для меня неожиданности, например "4. Внедрили Kafka и контракт на публикацию данных вместо прямого забора из БД" - есть над чем мне подумать.