Comments 12
А у вас параллельно существует SCD2 и вот этот прием?
Что хранится в широкой таблице stage?
Не текущее состояние справочника. Состояние на момент совершения транзакции. Если вчера товар назывался «Хлеб», а сегодня его в справочнике переименовали в «Хлеб ржаной» - запись о вчерашней продаже в stage останется с «Хлеб», ровно так, как было фактически.
По сути это и есть SCD2 "из коробки" вы храните всё историю изменений, в строке хранится продажа группы товара "хлеб" за 01.01.00 и продажа группы товара "хлеб черный" за 02.01.00 справочника нет.. всё хранится в eventdriven таблице одной широкой... и ключи и значения ;) .. справочник подгружается только один текущий по товарным группам, и о в том случае если бизнес хочет видеть исторические продажи в разрезе актуальных товарных групп. Это тот джой который кликхаус вполне "терпит"
Например, были продажи в Магазине, он принадлежал Структуре1, потом структура поменялась, но транзакций не было - как теперь определить, к какой структуре относится этот магазин?
Тут только ведение времязависимого справочника Магазин-Структура с полями "Дата с..." (и иногда "Дата по...") поможет. Т.е. классический SCD2.
Интересно, но что-то вы как-то перемешали и переопределили привычные термины, например stage тот же. В итоге где-то читаешь и кажется что просто описываете классическую трехслойную архитектуру в каких-то просто "своих"терминах, а в следующем абзаце уже вообще не понимаешь как это соотноситься со всеми принятыми арх стандартами и подходами. Вроде пишете про DWH, но откуда то появляются айсберги и паркеты с Трино. В итоге ощущение полной каши и смешения всего и вся. Так вы DWH смотрите, Даталейк, Лейкхауз или ещё что-то? Почему для по сути того, что называют ядром/detail data store/silver используете термин Stage (если я вас правильно понял)? Опять же, несколько раз упоминаете Датабрикс в связке с Айсбергом, но молчите про нативную для него Дельту. А совет “использовать Databricks‑as‑serving” читается очень смешно, учитывая стоимость Датабрикса - если уж его использовать, то надо его использовать по полной. И это точно не альтернатива Кликхаусу для serving layer. У Датабрикс и Кликхауса совсем разные ТТХ… И далее по тексту в том же духе…
Ну я бы не делил так категорично, я пишу про смещение парадигмы DWH. Если разобраться то LakeHouse Datаvault или Кимбалл это лишь разновидности DWH, DWH - это то место где ваши данные хранятся долго и накапливаются. Я пишу про подход. Про методологию. Тот жек Datavault интересен, но не более чем научный эксперимент, я остановил работы с Datavault когда понял что я делаю двойную работу, а зачем? Команда DWH имеющая datavault не успевает за изменениями которые требуют бизнес-задачи, отсюда поиск нового (ну или немного забытого старого). Почему не пошел datalake? потому что протухает, нет структуры управления. Lakehouse, на мой взгляд самая лучшая конструкция в текущей ситуации. Но многие живут "по старинке" их право. Вопрос в том, что является витринами и как с ними работать. В концепции LakeHouse нет нормального механизма "витринирования". Раньше им был SSAS например, но когда до него дошли руки тех кому он реально нужен - он методологически устарел. А ClickHouse - это на сегодня самая лучшая по цене/качеству технология витринирования данных, почему то не все это понимают, думают что клик - для хранения.. ну пусть думают, да, он может хранить, но не это его основная задача в DWH, и как раз об это многие спотыкаются.
Прошу прощения, но в этом вашем ответе вы опять все скопом в кучу смешали как в вашей статье и даже не видите этого. Попробую объяснить вам все же, если не видите сами. Сейчас у вас в одном контексте оказываются:
DWH / Data Lake / Lakehouse — как архитектурные парадигмы
Kimball / Data Vault — как методологии моделирования
Iceberg / Delta / Parquet / Trino / Databricks / ClickHouse — как конкретные инструменты
«Datalake протухает» — это не свойство, а следствие плохого governance И т.п.
Когда всё это обсуждается как будто это одно и то же, теряется смысл терминов (вы к тому же ещё используете какую-то странную, не общепринятую терминологию) и становится непонятно, о каком уровне вообще речь. В целом создаётся ощущение, что описывается какая то конкретная легаси-реализация, сложившаяся “в силу исторических причин” , но с переопределённой почему-то терминологией без понимания архитектуры и на основании её делается какое-то обобщённый, далёкий от реальности, вывод.
Ninil, Mapar, VitaminND, спасибо. Перечитал ветку. Согласен по главному: я смешал уровни абстракции, и в тексте это читается как каша. Развожу явно, без этого спор бесконечен.
Уровней три, и они про разное. Парадигма хранения (DWH, Data Lake, Lakehouse) - это про то, где и с какими гарантиями физически лежат данные. Методология моделирования (Инмон, Кимбалл, Data Vault) - про то, как организованы таблицы внутри слоя. Она ортогональна парадигме и зонам не конкурент: методология живёт внутри слоя, а не вместо него. Ядро по Data Vault и витрины по Кимбаллу поверх Lakehouse абсолютно законны, тут Mapar прав, противопоставлять зоны методологиям получилось криво. Движки и форматы (Iceberg, Parquet, Trino, ClickHouse) методологию не диктуют вовсе. Iceberg стал определяющим в моём конкретном проекте в силу преимуществ, а не «вообще».
По терминологии тоже по делу. То, что я зову Stage, в общепринятых терминах ближе к core / detail data store / silver, а не к staging. Классический staging - это транзитный буфер загрузки: данные из источников падают в него на время ETL и затираются на следующей загрузке, истории там нет. Моё Stage держит бизнес-логику, SCD2-историю и является источником правды, это другой слой. Имя сложилось исторически в моей реализации, выносить его в статью как общий термин было ошибкой, отсюда и ощущение, что я переопределяю стандарты.
VitaminND, по вашему примеру. Здесь два класса отчётов, и их надо разделить, иначе спор не кончится. Первый, фактовая аналитика «продажи по магазину или структуре». Каждая строка факта заморозила атрибут на момент события: продажа 01.01 ушла как «ХЛЕБ», продажа 02.01 как «ХЛЕБ ЧЁРНЫЙ». Дашборд агрегирует факты и корректен по построению. «Структура сменилась, а транзакций не было» для такого дашборда не проблема, а её отсутствие: нет фактов, нечего переотносить. «По текущей структуре» решается джойном одного актуального справочника по ключу, SCD2 тут не нужен. Второй класс, отчётность по состоянию связи самой по себе, без привязки к факту. «Под какой структурой был магазин в марте» для оргструктуры, аренды, штатки, где транзакции нет вообще. Вот здесь да, нужен времязависимый справочник магазин-структура с valid_from/valid_to, классический SCD2. Это другой класс отчёта, а не дыра в схеме: когда такое требование есть, в stage добавляется темпоральный справочник под него, но согласитесь, такой класс отчетов как отдельное тз или закрывается отдельной таблицей фактов . Статья этот класс не покрывала. Здесь я был неточен, а не неправ.
Про Data Vault. Формулировку не снимаю, уточняю границу. В моих проектах это был реальный production-эксперимент: прогнал, закрыл, возвращаться не планирую. Причина простая. Сначала моделируешь сырой слой со всей историей изменений, а потом, поскольку читать из него аналитику невозможно трудно ;), моделируешь поверх ещё один слой витрин. Моделирование делается дважды, и команда не успевает, да и работа двойная, сначала разгреби на песок потом собери. Это вывод по моему сегменту, не приговор методологии. Там, где регулятор требует полный журнал всех изменений данных (банки под ЦБ, фарма, драг металлы), Data Vault на своём месте, и кто на нём живёт, живёт обоснованно.
В статью добавлю UPD с этим разведением уровней. Разбор по уровням - ровно та правка, которой тексту имхо не хватает.
Упрощенно. Из кучи систем ИТ-ландшафта компании со своими SQL-табличками (их "безумным числом") строят DWH со своими табличками SQL. В надежде, что в новых табличках SQL будет «порядок» и «прямая» дорожка к BI («хорошим витринам»). Иногда внедряют даже несколько DWH. Только все эти lakehouse, Data Lake, Data Warehouse иногда делают просто еще одну (новую) «свалку данных» («болото данных»). Даже если эта "новая" и более быстродействующая, то суть не меняется. Полагаю, что концепт «Данные как на ладони» (к тому "Высококачественные данные" и т.п.) на SQL не решаем перекладываем из одних SQL-таблиц в другие SQL – «DWH-ашные».
Видимо сочетание Data Quality (его «технологической части», включая каталог данных, MDM и другого) и инструментов semantic DWH сможет лучше решить эту проблему. Есть исследования на эту тему?
Странная статья, с одной стороны интересный практический опыт, с другой стороны своя терминология. Например, Stage слой в терминологии автора, очень похож на детальный (Core) слой.
Так же не понятно зачем структуру/количество слоев противопоставлять технологиям представления данных внутри слоя (тот же Data Vault). Нормальная ситуация, когда ядро делают по Инмону (тот же Data Vault его вариация), а слой витрин по Кимбалу.
Тут конечно можно ответить, что Инмон и Кимбал это именно технологии построения всего хранилища, но они давно уже стали нарицательными именно для подходов организации таблиц внутри слоев.
Ну и привязка к технологиям мне кажется в теории построения хранилища не очень уместна, я конечно понимаю, что "clickhouse не тормозит, но" заставляет специфично строить DWH, но при этом сравниваются именно технологические подходы к проектированию в которых конкретные технологии не заложены.
P.S. Автор часто пишет "мы", хотелось бы понять опыт какой компании тут изложен
Спасибо за комментарий. В моем случае технология (Iceberg) является определяющей. Единственное чем она не обладает - это sql движком, и его роль исполняет Trino, и да, это тоже "технология".. я поменял парадигму для себя и это стало определяющим. Сегодня рабочим остался один подход - подход от "бизнеса и dataflow", иначе не выжить. Иначе бесконечная борьба с бизнесом и доказывание "кто умнее" и "у кого что больше".. 90% статей а интернете про эту "боль". Я от нее избавился... и вам желаю )) ... по сути, то что я описываю - это немного иная точка зрения на на корпоративные DWH.. именно она помогла мне решить главную задачу "бизнес хочет?" - "на держи". Минимальные сроки, стабильные etl, мгновенные отчеты, простейшие запросы от дашбордов. Заходите ко мне на сайт или на канал, там есть что почитать, буду рад всем. ... но все уважаемые комментаторы тоже правы ... возможно статью стоит переработать по стилистике.
Вы сравниваете теплое с мягким. Iceberg вообще никак не влияет на подходы к построению хранилища и не мешает строить звезды Кимбала или DataVault, это просто ортогональные вещи.
Подход "бизнес хочет?" - "на держи" - это так вообще лет 10 уже как, и например, Data Vault ровно для этого.
В целом, простите, я пока наблюдаю какой то сумбур, не с точки зрения подхода, а с точки зрения уровней абстракции, вы скачeте и путаете вместе физическое хранение, движки, подходы к проектированию слоев, сами слои и методологии построения.
Попробуйте для себя разделить эти вещи и тогда народ к вам потянется, идеи интересные, но плохо сформулированные.
DWH в 2026: четыре зоны вместо Inmon, Kimball и Data Vault 2.0