Комментарии 39
Спасибо, очень интересно! Есть чему поучиться.
Также были для меня неожиданности, например "4. Внедрили Kafka и контракт на публикацию данных вместо прямого забора из БД" - есть над чем мне подумать.
Вот сколько читаю такие статьи, то только и надеюсь что в моей компании выделят ресурсы на рефакторинг всей системы DWH. А то судя по всему наши ETL-процессы для сильных духом: загрузчики пишутся каждый раз практически с нуля на Python без каких-либо библиотек для дата-инжиниринга, а стартует всё через cron linux-а. Про другие вещи молчу.
Что лукавить - хочется поучаствовать для личного роста в трансформациях как в статье.
Респект автору.
умение вовремя отказатсья от DataVault - признак взрослости архитектора DWH
Вроде бы наоборот частично перешли на него. А "взрослые" архитекторы dwh, что нынче выбирают?
Привет!
я не могу сказать за всех, но из своего опыта отмечу, что метод моделирования надо выбирать исходя их ваших требований , источников и ресурсов . В первую очередь нужно сформировать функциональные и не функциональные требования, оценить вектор развития аналитики и ограничения компании. Исходя из требований можно подобрать подходящую архитектуру.
Яндекс делал гибрид волта и якоря, например https://habr.com/ru/companies/yandex/articles/557140/
Архитектура дело творческое.
тем более если планируешь делать его на гринплам.
Подскажите, airflow не тормозит с 1000 дагов? Как оптимизировали file processing для ямлов?
Привет! Отличный вопрос.
Я люблю 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 дага , которые запускаются почти все ежедневно.
Благодарю за подробный ответ
Спасибо за вопрос.
Я наверное еще отмечу, что у нас есть боевой инстанс airflow, про него я ответила выше. Есть песочница аналитиков - это отдельный инстанс, где аналитики могут сами собирать ad-hoc витринки и проверять гипотезы не влияя на бой. Есть тестовые инстансы airflow , которые поднимаются под задачи дата инженеров. Получилось достаточно удобно.
Спасибо. Интересно было почитать.
В качестве вывода я ещё бы добавил, что решения 2017-2019 года наводят на мысли о низкой компетенции архитекторов и одновременной экономии на хотя бы временом привлечении консультантов для выботки архитектуры и стратегии. Сделал в голове пометку про такую особенность работы в СДЭК :-)
ПыСы многое из того что вы в конце статьи преподносите как достижение 2025, для нас (хороший консалтинг) было стандартом "by default" ещё в 2015м
Привет! Спасибо за комментарий.
«Historia magistra vitae (история — учительница жизни)». В то время 2017-2019 компания больше разбиралась в операционной работе и аналитика только развивалась. Были выбраны решения, которые позволили стартануть аналитику и это хорошо. Были сделаны ошибки и мы их учли.
То что команда вышла на современный стек и смогла ,не останавливая работу аналитики, переехать на новое хранилище и инструменты, я считаю, это здорово.
Я согласна, что на рынок надо смотреть и надо брать лучшее. Сама часто посещаю конференции и смотрю на решения других компаний. Так же важно ориентироваться на возможности и требования твоей компании. Текущего решения для данного уровня аналитики было достаточно, дальше будет больше.
Про стратегию в СДЭК. Я могу отметить, что компания шагнула вперед. В СДЭК есть арх совет, есть стратегия на уровне компании. На стратегической сессии мы формировали вместе с CDO стратегию по развитию аналитики и дата платформы на 2025 год. Из хорошего в компании есть гибкость и мало бюрократии. Я напрямую работала с каждым в команде, мы вместе формировали решения , которые обсуждали на дизайн ревью.
Блестящая карьера архитектора и эталонное развитие архитектуры!
Эталонная была если бы сразу подумали что 1тб Vertica мало, а платить за больше не будем. Не подумали. Или если бы сразу чуть подумали на тему что DB2 это днище, но не подумали. Кстати и с Greenplum тоже придется съезжать, так что тоже не додумали. Так себе эталон. Разве что респект за признание ошибок :)
P.s. я уж молчу про датавольт
Редко встретишь отдельный Data Quality слой. За это, прям, низкий поклон. В одной очень толстой конторе на меня смотрели как на умалишенного только за предложение, хотя бы проверить качество данных и соответствие их требованиям, не говоря уже за полный контроль и автоматизацию проверки.
Честно говоря, странно, что вплоть до 2022 года были архитектура и решения из 90х. Прям жалко, что столько тратилось средств и ресурсов впустую. Хорошо, что вы пришли к взвешенному решению. Удачи и успехов!
DQ это инструмент. Он имеет смысл в реализации ПОСЛЕ того как появляется механизм владельцев данных. Когда у каждой витрины есть владелец, которому прилетает за косяки в его витрине, то он первый же и приходит с просьбой: "Ребята, а давайте как-то автоматизируем проверки, а мне надоело руками каждый день сидеть качество данных сверять". И тут и появляется DQ слой. Это нормальная эволюция data governance.
А ненормальная, когда наоборот, никакого Data Ownership-а нету, а команда DWH решила сделать DQ. Сделать-то сделали - только кто им пользоваться будет?? Если витрины (или любые другие дата продукты) ничьи - кому аларм слать при фейле проверок??? Девелоперам чтоли?? Ха-ха.
DWH не имеет смысл без целевой аудитории. Да, есть подход: "Давайте все подряд хранить (с непонятным качеством), а потом разберемся". Но это помойка, а не хранилище данных.
Недавно был наглядный пример с битой по кошельку. При заливке данных в дата сервис из Oracle в MSSQL терялась точность. Т.к. контора была крупная и количество нулей в цифрах было внушительным набегало ощутимо. В отчетности этого сразу и не увидеть, т.к. все думали, что таких "косяков" в 21 веке не должно быть. Но выявили именно на интеграционных тестах разработчики. Скандал знатный был!
Не путай целевую аудиторию и владельцев данных. Это разные люди. Целевая аудитория у тебя может быть и вообще CEO всего энтерпрайза, которому каждоеу утро долежен отчет прилетать свежий. Это же не значит что он же и владелец витрины в которой это все считается и еще и за DQ её отвечает. Целевая аудитория как раз практически всегда есть, ибо иначе кто вообще бюджет выделять будет на DWH. А вот владельцы дата продуктов могут и отсутствовать
Вот именно. Кто платит - тот и заказывает музыку. А все промежуточные звенья вторичны. Но как раз тот же СЕО может не до конца или вообще не видеть ценность этих данных. И не потому, что он тупой, а потому, что эти данные реально не имеют ценности для бизнеса, а являются чьей-то хотелкой для распила денег на среднем уровне.
Живой пример. Одна контора ежегодно платит крупной аудиторской фирме за формирование гос. отчетности круглую сумму. Отчеты с технической точки зрения абсолютно несложные. Менеджер среднего звена выступает с предложением сделать собственное решение и формировать отчеты самостоятельно. Мы реализуем проект. Проходит демонстрация на ура. Компания ежегодно может сэкономить солидную сумму. Менеджер осваивает бюджет в рамках дозволенного и идет на повышение. Все довольны. Продакшн. Следующая версия и т.д.
Через 3 месяца все сворачивается: возвращаем все назад! С точки зрения бизнеса и компании никакого выигрыша нет, т.к. свое решение требует поддержки, а отказ от части услуг аудиторской фирмы грозит имиджевыми издержками.
Конечный владелец есть всегда бизнес, а не средние прослойки. Многие отчеты среднего звена делаются "для галочки" или красивых графиков для презентаций, но не влияющих ни на что.
Очень интересно! Спасибо!
Пока мы не упёрлись в максимально доступный в триальной версии Vertica объём в 1 Тб. Нужно было искать новое хранилище. Изучив разные решения, архитектор выбрал IBM DB2. Купили лицензию.
Поржал в голос над выбором и компетентностью архитектора)
модель данных ядра хранилища AnchorModel
Собрался поржать второй раз, но вы и сами поняли, что не туда свернули)))
По итогу - ценой неоднократного перепила data стэка получилось решение, соответствующее текущим реалиям. Вопрос может и не по адресу, но интересно, а инцидент мая 2024 на DWH и ETL обвязку как-то повлиял?
вы и сами поняли, что не туда свернули)))
Не демонизируйте AnchorModel. На момент выбора якорной модели она неплохо себя показывала. Тогда компания переезжала с монолита на микросервисы, поэтому максимальная гибкость была очень кстати.
Архитектура хранилища существует не в вакууме, а в инфраструктуре компании. И если окружение меняется, то меняется и архитектура хранилища.
а инцидент мая 2024 на DWH и ETL обвязку как-то повлиял?
Нет, не повлиял. Только немного подвинул сроки.
Не демонизируйте AnchorModel
Ее и демонизировать не нужно - реалии расставили все по местам так, что даже евангелисты этой модели в России были вынуждены сокращать косты на нее. А последние 5 лет львиная доля больших проектов хранилищ создается в DataVault 2.0. Остальное - "по звезде".
Нет, не повлиял. Только немного подвинул сроки.
Жаль, что компания так и не рассказала, что там было и как. Но этот риторический вопрос, наверное, не к вам
На вашей архитектурной схеме на тот момент зя якорем идет 3нф. Внимание вопрос - а зачем вам якорь тогда? Просто вы скопировали архитектуру якорь+вертика из авито. ИМХО сейчас опять копируете - выбираете дата волт а под ногами система для расчета, которая не иммет join оптимизаций.
Привет!
На момент старта DWH действительно скопировали с Авито.
Сейчас у нас нет чистого волта. В 3 пункте я говорила, что есть элементы и возможность развития в волт. Сейчас больше 3НФ и только некоторые таблицы связей и атрибутов вынесены отдельно, так как есть сложные источники у который так проще хранить и обновлять данные.
На данный момент хранилище хорошо покрывает бизнес: все ключевые элементы загружены и используются аналитикой.
не иммет join оптимизаций.
С чего это? У них все джоины в гринпламе делаются, там все более менее с джоинами. А кликхаус это так - кэш для репортинга.
В ГП все плохо с джойнами. Лучше чем в КХ конечно, тк они хотя бы есть. Но гораздо хуже чем в любом современном движке вроде трино, Дорис, старрокс или импала.
"современном" ??? Современный у нас это Snowflake или Databricks. Impala давно уже легаси
у вас это где? В РФ и российских обалчных PaaS? :) Трино, Дорис, Старрокс тоже легаси?
Что кстати делает Импалу легаси? Отсуствие популярного чата в телеграмме? :)
у нас в AWS. И тут в AWS я никаких impal не видел давно.
Да и в Azure тоже
Что кстати делает Импалу легаси
Сейчас все что не Claude Native - это уже легаси.
Ну во первых в РФ особый ламповый мир без датабрикс и сноуфлейк. В этом особом православии на серьезных щщах на петабайты рисуют святую троицу гринплам-хадуп-кликхаус и ждут успешного успеха.
Во вторых в том самом дивном "не дружественном мире" про гринплам давно там видели и слышали? или про терадату?
. В третьих, у вас претензия почему то к импале, хотя в моем сообщении она была четвертой по упоминаю. Личное? Фантомные боли?
В 4-х она давно уже клауд реди
ну во-первых соболезную, во-вторых импалу я хоть чутка видел, потому за неё и зацепился, а в третьих в современном мире и террадата и импала где-то на одном уровне легаси находятся. А рынок сейчас реально делят сноуфлейк с датабриксом.
В 4-х она давно уже клауд реди
а мужики-то не знают.
p.s. Точнее знают, но поезд уже ушел.
.
Отличная статья. Спасибо!
Спасибо. Интересно читать с чего началась аналитика в СДЭКе)
Трансформация платформы данных: от пары кубов до хранилища > 30 Тб и 1000 ETL-процессов