Comments 7
Боже мой. Все в кучу, перемешать и взболтать... Вы сами писали это или LLM "помогал". Инмон и Кимбал поставлены в один раз с Дата Валтом и Якорным моделированием... Вы хоть понимаете абсурдность этого?
Не понятен Ваш комментарий и скорее всего из-за этого, что я пытался донести "х", а Вы поняли "y". Давайте выравниваться в понимании: Ваш комментарий направлен на раздел 2, сравнение методологий. Моделируем ситуацию: Вы работаете в крупном холдинге, где открывается новое направление и стоит задача построить DWH для данного направления. Задача подготовить архитектуру решения, ее защитить не только технологически, но и бизнесово (это деньги и время). Пытаюсь в сравнительной таблице донести, что: 1) есть разные методологии DWH и выбор методологий влияет на разные грани процесса : 2.1) Что вы строите 2.2) Как вы это строите 2.3) Какая квалификации команды нужна, ее навыки и какие роли должны быть 2.4) От выбора зависит, когда бизнес увидет первые результаты, данные, отчеты, визуализацию данных, чтобы понимать как действовать 2.5) Что будет, если бизнес начнет изменять бизнес процессы и так далее. Ваш комментарий читаю как: "сравнивать по предложенным критериям методологии DWH не корректно". Если комментарий понял правильно, то поясните, пожалуйста: какой алгоритм выбора методологию DWH считаете правильным?
У вас в статье фундаментальная ошибка в том, то вы подходы Инмона и Кимбалла ставите в один ряд (по сути - противопоставляете) с Data vault и Anchor modelling (кстати, а почему 3NF вы отсюда выкинули???). Еще с натяжкой терпимо "для сельской местности" или для презентации ничего не понимающему бизнесу, но не для технического портала как хабр, где статьи пишутся профессионалами для профессионалов. Вы сравниваете красное с круглым.
Если совсем упрощать в паре слов, то выбор стоит "Инмон vs Кимбал" - тут все понятно (надеюсь) - это именно разные МЕТОДОЛЛОГИЧЕСКИЕ подходы к построению и ХД, причем во многом еще и ОРГАНИЗАЦИОННЫЕ. Кимбал - это по сути "витрины первыми, собственно они и являются КХД". Инмон же говорит "строим сначала детальный слой - единую версию правды, и уже потом витрины". Эти подходы не противопоставляются Data vault и Anchor modelling, они стоят над ними.
Data vault и Anchor modelling (и забытая вами 3NF) - это подходы к построению ФИЗИЧЕСКОЙ модели данных ДЕТАЛЬНОГО слоя данных ХД. И любой из них отлично сочетается как минимум с подходом Инмона.
Ну и раз вы тут говорите про подходы к проектированию физической модели, то почему не упомянуты звезды и снежинки? Они уже про слой витрин данных и так же отлично сочетается с подходам и Инмона, и Кимбалла.
Как видите, все написанное выше никак не противоречит вашей задаче "подготовить архитектуру решения, ее защитить не только технологически, но и бизнесово".
Давайте дальше выравниваться в определении.
Пункт 1. Как понял ваш тезис из комментария «Data Vault» и «Anchor Modeling» — это не методологии, а способ моделирования ядра. Давайте обратимся к первоисточнику, например:
1.1. «Building a Scalable Data Warehouse with Data Vault 2.0. Chapter The Data Vault 2.0 Methodology»
1.2. «Anchor Modeling» - можно ознакомиться с докладом из первоисточника, которые представлены в разделе 10 «Related Research». Ссылка
Пункт 2. «Статья противопоставляет методология» - не совсем так – это сравнение, которое так же можете найти в докладе Anchor Modeling в разделе 10, где есть сравнение, и в книге «Building a Scalable Data Warehouse with Data Vault 2.0. Chapter Introduction to Data Warehousing».
Пункт 3. «Почему не указана третья нормальная форма». Нормальная форма – это свойство связей в реляционной модели данных объектов(таблиц), которая присуща не только DWH, но и OLTP. Нормальная форма – это не методология проектирования DWH.
Пункт 4. Почему не указана «звезда» и «снежинка». Важно ввести «систему координат», что такое «звезда» и «снежинка». Их часто сопоставляют «Кимбалл – Звезда (star)» и «Инмон – Снежинка (snowflake)». И тут важно понять – вы имеете ввиду способ/паттерн создания слоя Data Mart над core? Если да, то именно поэтому не включены в сравнении методологий.
Пункт 5. «"Инмон vs Кимбал" - тут все понятно (надеюсь) - это именно разные МЕТОДОЛЛОГИЧЕСКИЕ подходы к построению и ХД, причем во многом еще и ОРГАНИЗАЦИОННЫЕ» - вы дублируете, что написано в сравнительной таблице раздела 2. «Бизнес-логика подхода» / «Процесс проектирования».
Как я понял ваш комментарий – вы не согласны с материалом, что является нормальным при обсуждении сложных вопросов. Чтобы дискуссия была профессиональной, предлагаю к терминам прикладывать первоисточники, которая может подтвердить альтернативное мнение.
Спасибо, что аргументированно отвечаете!
На самом деле не вижу смысла продолжать дискуссию, так как по ощущениям у нас с вами разный бэкграунд. Я внедрил 7 (8е в процессе щас и уже маячит на горизонте 9е в планах) разных DWH/Data Platform в разных организациях, работая непосредственно в полях, и на практике в каждодневной работе сталкиваясь со всеми подходами и методолгиями, упомянутыми вами, обсуждая все это с другими архитекторами, на практике сталкиваясь с плюсам и минусами того или иного паттерна, в том числе принимая во внимание используемый тех стек ( это тоже влияет на выбор подхода кстати )
Вы же, осмелюсь предположить на основании статьи и ваших ответов, скорее решаете задачу формального написания и защиты какого-то внутреннего документа (возможно, который будет потом мало общего имеет с действительностью "в полях", но зато выполнить функцию ЖПП отлично:)) И такое встречал на одном проекте, когда менеджеры жили в одной реальности, а все остальные - в другой))) Было забавно) Ну и пишите этот документ опираясь на теоретические статьи про "космические корабли в большом театре", не до конца понимая как эти теоретические концепты потом выливаются в конкретную архитектуру и физ. модель. Для подобных документов ссылка на какой то авторитетный источник куда важнее практики. Тут согласен.
Мой опыт (и моя база) — это было IT-направление data, а сейчас фокус сместился на работу быть "мостом" между бизнесом и ИТ. Наш опыт разный не по степени «практичности», а по фокусу: вы — на глубокой технической реализации, я — на том, чтобы правильные технические решения были выбраны, поняты бизнесом и реализованы в нужные сроки с учётом всех вводных/неопределенностей/проблем и т.п.. Например:
1. На старте было одно требование/заказ, а потом оно резко меняется от заказчика и причем координально, и видишь всю боль команды архитектуры "да как же так, оговаривали другое" - это как раз пункт Раздела 1. Утвердите требования к системе. Это призыв для команд и, по моему мнению, значительно растит доверие между IT и бизнесом.
2. Когда есть заказ "мы пока точно не можем сообщить, что необходимо, но давайте вы выберете самое гибкое, самое быстрое, самое масштабируемое, покажете, что получилось и потом вот уточним" и это в свою очередь требует очень высокую квалификацию команду, а ее может не быть или ушли сильные - это как раз про пункт Раздел 3. Data Vault и Anchor Modeling.
Далее, падая в супер деталь каждого подхода, понимаешь как это сложно и это правда: а сколько и по каким правилам должен быть создан Sat в DV (как группировать, по типу SCD, чтобы избежать все в одном, по логическим блокам и т.п.). Как правильно шардировать, чтобы корректно и правильно работало соединение таблиц и движение между узлами, подбор СУБД, чтобы достичь join elimination. Какой тип RAID выбрать, какой тип хранения (row/column), при этом уместиться в бюджет и так далее, и так далее и еще десятки вопросов.
Цель статьи - поделиться опытом и важными вопросами, которые необходимо понять двум сторонам "на старте".
Спасибо за ваше мнение, был интересный диалог.
Дополнение.
Вот вам, менеджменту, хорошо бы услышать нас, архитекторов, и как раз озадачится приближением подобных документов к чему-то реально полезному для проекта;) А то так и будем жить в двух параллельных реальностях
Утвердить методологию DWH, практическое руководство для менеджмента