Вот поэтому и отказался от данного коммерческого направления на ближайшее время. Не зарекаюсь конечно, но вот выше @Kupkupich Вы правильно сказали, если "неизбежно" то по максимуму сужать домен данных и откатывать на нём. Ну или почту некритичную разгребать как пилот, а затем расширять спектр, но потихоньку.
Пессимизм конечно в Ваших словах, коллега )) ...но очень справедливый пессимизм, к сожалению. Много подобного видел за годы работы. Но отдать должное что "такое на везде", тоже надо. Часто отсутствие информации и банальная погоня за "модой" .. ну а что это если не "управленческая близорукость".. тоже "вопрос к обсуждению" тот еще.
Поддержу @qlever, на практике в среднем бизнесе самая большая проблема не стек и не методология, а то, что у мастер-данных нет хозяина по имени. «Контрагент» в CRM, бухгалтерии и логистике - три разных сущности, и каждый отдел уверен что прав. Пока не вырастишь Data Owner’ов на стороне бизнеса, до технологии и не доходишь - она вторична.
Вот совершенно верно - "прикидывать". Главное, на мой взгляд, сейчас не торопиться. Волна схлынет и останется то, по настоящему, полезное которое и нужно будет брать.
Спасибо. В эпоху восторженного хора главное - не присоединяться:). Думаю что полезного еще много будет от ИИ, это безусловно, но хайп огромный конечно. Буду продолжать.
Спасибо. Переводa этой пока нет, но английские адаптации делаю периодически в LinkedIn. Постараюсь подготовить в ближайшие пару недель - пришлю ссылку, как появится.
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 с этим разведением уровней. Разбор по уровням - ровно та правка, которой тексту имхо не хватает.
Спасибо за комментарий. В моем случае технология (Iceberg) является определяющей. Единственное чем она не обладает - это sql движком, и его роль исполняет Trino, и да, это тоже "технология".. я поменял парадигму для себя и это стало определяющим. Сегодня рабочим остался один подход - подход от "бизнеса и dataflow", иначе не выжить. Иначе бесконечная борьба с бизнесом и доказывание "кто умнее" и "у кого что больше".. 90% статей а интернете про эту "боль". Я от нее избавился... и вам желаю )) ... по сути, то что я описываю - это немного иная точка зрения на на корпоративные DWH.. именно она помогла мне решить главную задачу "бизнес хочет?" - "на держи". Минимальные сроки, стабильные etl, мгновенные отчеты, простейшие запросы от дашбордов. Заходите ко мне на сайт или на канал, там есть что почитать, буду рад всем. ... но все уважаемые комментаторы тоже правы ... возможно статью стоит переработать по стилистике.
Ну я бы не делил так категорично, я пишу про смещение парадигмы DWH. Если разобраться то LakeHouse Datаvault или Кимбалл это лишь разновидности DWH, DWH - это то место где ваши данные хранятся долго и накапливаются. Я пишу про подход. Про методологию. Тот жек Datavault интересен, но не более чем научный эксперимент, я остановил работы с Datavault когда понял что я делаю двойную работу, а зачем? Команда DWH имеющая datavault не успевает за изменениями которые требуют бизнес-задачи, отсюда поиск нового (ну или немного забытого старого). Почему не пошел datalake? потому что протухает, нет структуры управления. Lakehouse, на мой взгляд самая лучшая конструкция в текущей ситуации. Но многие живут "по старинке" их право. Вопрос в том, что является витринами и как с ними работать. В концепции LakeHouse нет нормального механизма "витринирования". Раньше им был SSAS например, но когда до него дошли руки тех кому он реально нужен - он методологически устарел. А ClickHouse - это на сегодня самая лучшая по цене/качеству технология витринирования данных, почему то не все это понимают, думают что клик - для хранения.. ну пусть думают, да, он может хранить, но не это его основная задача в DWH, и как раз об это многие спотыкаются.
По сути это и есть SCD2 "из коробки" вы храните всё историю изменений, в строке хранится продажа группы товара "хлеб" за 01.01.00 и продажа группы товара "хлеб черный" за 02.01.00 справочника нет.. всё хранится в eventdriven таблице одной широкой... и ключи и значения ;) .. справочник подгружается только один текущий по товарным группам, и о в том случае если бизнес хочет видеть исторические продажи в разрезе актуальных товарных групп. Это тот джой который кликхаус вполне "терпит"
Информация
В рейтинге
135-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Вот поэтому и отказался от данного коммерческого направления на ближайшее время. Не зарекаюсь конечно, но вот выше @Kupkupich Вы правильно сказали, если "неизбежно" то по максимуму сужать домен данных и откатывать на нём. Ну или почту некритичную разгребать как пилот, а затем расширять спектр, но потихоньку.
Пессимизм конечно в Ваших словах, коллега )) ...но очень справедливый пессимизм, к сожалению. Много подобного видел за годы работы. Но отдать должное что "такое на везде", тоже надо. Часто отсутствие информации и банальная погоня за "модой" .. ну а что это если не "управленческая близорукость".. тоже "вопрос к обсуждению" тот еще.
Поддержу @qlever, на практике в среднем бизнесе самая большая проблема не стек и не методология, а то, что у мастер-данных нет хозяина по имени. «Контрагент» в CRM, бухгалтерии и логистике - три разных сущности, и каждый отдел уверен что прав. Пока не вырастишь Data Owner’ов на стороне бизнеса, до технологии и не доходишь - она вторична.
Вот совершенно верно - "прикидывать". Главное, на мой взгляд, сейчас не торопиться. Волна схлынет и останется то, по настоящему, полезное которое и нужно будет брать.
Спасибо. В эпоху восторженного хора главное - не присоединяться:). Думаю что полезного еще много будет от ИИ, это безусловно, но хайп огромный конечно. Буду продолжать.
Спасибо. Переводa этой пока нет, но английские адаптации делаю периодически в LinkedIn. Постараюсь подготовить в ближайшие пару недель - пришлю ссылку, как появится.
Спасибо. Грустная правда. Но надежда! )) она и движет)).. а может кто-то сэкономит денег
Спасибо, приятно встретить «своих». SQL считает, модель формулирует - к этому опытом сходятся, теорией нет. Удачи проекту!
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 с этим разведением уровней. Разбор по уровням - ровно та правка, которой тексту имхо не хватает.
Спасибо за комментарий. В моем случае технология (Iceberg) является определяющей. Единственное чем она не обладает - это sql движком, и его роль исполняет Trino, и да, это тоже "технология".. я поменял парадигму для себя и это стало определяющим. Сегодня рабочим остался один подход - подход от "бизнеса и dataflow", иначе не выжить. Иначе бесконечная борьба с бизнесом и доказывание "кто умнее" и "у кого что больше".. 90% статей а интернете про эту "боль". Я от нее избавился... и вам желаю )) ... по сути, то что я описываю - это немного иная точка зрения на на корпоративные DWH.. именно она помогла мне решить главную задачу "бизнес хочет?" - "на держи". Минимальные сроки, стабильные etl, мгновенные отчеты, простейшие запросы от дашбордов. Заходите ко мне на сайт или на канал, там есть что почитать, буду рад всем. ... но все уважаемые комментаторы тоже правы ... возможно статью стоит переработать по стилистике.
Ну я бы не делил так категорично, я пишу про смещение парадигмы DWH. Если разобраться то LakeHouse Datаvault или Кимбалл это лишь разновидности DWH, DWH - это то место где ваши данные хранятся долго и накапливаются. Я пишу про подход. Про методологию. Тот жек Datavault интересен, но не более чем научный эксперимент, я остановил работы с Datavault когда понял что я делаю двойную работу, а зачем? Команда DWH имеющая datavault не успевает за изменениями которые требуют бизнес-задачи, отсюда поиск нового (ну или немного забытого старого). Почему не пошел datalake? потому что протухает, нет структуры управления. Lakehouse, на мой взгляд самая лучшая конструкция в текущей ситуации. Но многие живут "по старинке" их право. Вопрос в том, что является витринами и как с ними работать. В концепции LakeHouse нет нормального механизма "витринирования". Раньше им был SSAS например, но когда до него дошли руки тех кому он реально нужен - он методологически устарел. А ClickHouse - это на сегодня самая лучшая по цене/качеству технология витринирования данных, почему то не все это понимают, думают что клик - для хранения.. ну пусть думают, да, он может хранить, но не это его основная задача в DWH, и как раз об это многие спотыкаются.
По сути это и есть SCD2 "из коробки" вы храните всё историю изменений, в строке хранится продажа группы товара "хлеб" за 01.01.00 и продажа группы товара "хлеб черный" за 02.01.00 справочника нет.. всё хранится в eventdriven таблице одной широкой... и ключи и значения ;) .. справочник подгружается только один текущий по товарным группам, и о в том случае если бизнес хочет видеть исторические продажи в разрезе актуальных товарных групп. Это тот джой который кликхаус вполне "терпит"