Information
- Rating
- 1,967-th
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Разработчик баз данных, Архитектор баз данных
Ведущий
Базы данных
Apache Kafka
Высоконагруженные системы
PostgreSQL
Golang
Ну я бы не делил так категорично, я пишу про смещение парадигмы DWH. Если разобраться то LakeHouse Datаvault или Кимбалл это лишь разновидности DWH, DWH - это то место где ваши данные хранятся долго и накапливаются. Я пишу про подход. Про методологию. Тот жек Datavault интересен, но не более чем научный эксперимент, я остановил работы с Datavault когда понял что я делаю двойную работу, а зачем? Команда DWH имеющая datavault не успевает за изменениями которые требуют бизнес-задачи, отсюда поиск нового (ну или немного забытого старого). Почему не пошел datalake? потому что протухает, нет структуры управления. Lakehouse, на мой взгляд самая лучшая конструкция в текущей ситуации. Но многие живут "по старинке" их право. Вопрос в том, что является витринами и как с ними работать. В концепции LakeHouse нет нормального механизма "витринирования". Раньше им был SSAS например, но когда до него дошли руки тех кому он реально нужен - он методологически устарел. А ClickHouse - это на сегодня самая лучшая по цене/качеству технология витринирования данных, почему то не все это понимают, думают что клик - для хранения.. ну пусть думают, да, он может хранить, но не это его основная задача в DWH, и как раз об это многие спотыкаются.
По сути это и есть SCD2 "из коробки" вы храните всё историю изменений, в строке хранится продажа группы товара "хлеб" за 01.01.00 и продажа группы товара "хлеб черный" за 02.01.00 справочника нет.. всё хранится в eventdriven таблице одной широкой... и ключи и значения ;) .. справочник подгружается только один текущий по товарным группам, и о в том случае если бизнес хочет видеть исторические продажи в разрезе актуальных товарных групп. Это тот джой который кликхаус вполне "терпит"