Почему витрина это не одна таблица?
Меня до глубины души поразил случай, когда давеча товарищ из дата сферы(лично не знакомы, судя по контексту - не бизнес точно), настойчиво в официальной переписке требовал от меня объяснений, чего это я ему тут описания 30+ таблиц скинула и посмела назвать это одной витриной! Как же меня бомбило, вы бы видели. Эту статью я написала для него!:)
В последние годы за счет кратного увеличения объема информации и людей которые с ней работают - наблюдаю сильное обесценивание системного подхода к работе с данным, если кратко - “ загрузим, а потом разберемся”. Этап анализа делается на бегу и зачастую интегрирован в процесс производства(увеличиваем кол-во релизов, делаем задачу кусочками) этого требует необходимости быстро выдавать результат. Есть свои плюсы (mvp) и минусы(бардак). Также тенденция во многом связана с тем, что сотрудники 21-26 лет, как сказал мой хороший друг - “дети Hadoop” в целом не работали с реляционными базами данных.
Итак, разберемся
- Что такое витрина? Почему это нетривиальный вопрос даже для профи?
- Системные подходы к проектированию данных в Хранилищах
- Почему нарисованные модели данных спасут мир?
- Есть ли золотая середина между скоростью разработки и структурированным подходом проектированию?
Что такое Витрина данных?
Базово, витрина - это логическое объединение набора таблиц(сущностей) с колонками(атрибутами) и связями между ними, которое отвечает на запрос бизнес задачи(задач) или покрывает определенную предметную область(продажи, hr).
В реальности это 20% ответа, особенно когда дело касается не производства(собрать эти таблички), а, например, сопровождения, развития, распространения и попыток структурирования багажа знаний компании. Конфигурации и скоупы таблиц, объединяемых в витрины интерпретируются довольно индивидуально. Это зависит от очень неожиданных вещей, например от организационной структуры компании. Бывает, что департамент в компании говорит, что все таблицы которые он использует - это их одна большая витрина, хотя данные могут быть несогласованны и даже не связаны между собой. А бывает, что каждый уважающий себя аналитик делает свою таблицу и называет ее отдельной витриной.
В маленьких компаниях сильно проще - обычно там есть 1-2 core data команды, которые могут договориться по поводу того, что такое витрина.
Возвращаясь к системности, для меня это когда вы изначально понимаете от чего может зависеть скоуп данных, который вам потребуется собрать в витрину, эти же моменты влияют и на процесс проектирования.
Рубрика очевидное и невероятное.
Очевидное - обычно у команд нет проблем в понимание важности этих вопросов.
- Сколько бизнес задач будут решать над витриной, будут ли ей пользоваться заказчики разных функциональных направлений?
- Какой предполагается объем данных (инишиал и инкремент)?
- Проверены ли бизнес гипотезы на ручных выгрузках(прототипирование)? чтобы не забыть маленькую но очень гордую таблицу
- Как результат расчета соотносится с уже существующими витринами, должен ли он с чем то сходиться ?
- Есть ли подобные витрины в вашей организации? крайне полезно посмотреть там алгоритмы связей
- Какие требования к скорости расчета и стабильности поставки данных? Какие зависимости по поставке данных с источника?
- Какие у вас платформенные ограничения(железо то купили уже)?
Невероятное - часто забывают в процессе принятия решений
- Как быстро потребуется( и потребуется ли) добавлять новые сущности и атрибуты ?
- Какая предполагается типология запросов от пользователей, и какой у них технический уровень?
- Какая команда будет развивать и сопровождать?Это может влиять не только на стандарты разработки, но и на сложность модели данных.
- Каким образом, как часто и где вы будете организовывать доступ к витрине? Нужна ли поставка данных в другие системы и в каком режиме? (обычно это называется solution архитектура)
- Какие будут уровни конфиденциальности?( для них могут потребоваться дополнительные слои view)
Если вы осознали большую часть ответ на вопросы, запускайте проектирование.
Системные подходы к проектированию данных в Хранилища
Модель данных бывает концептуальная, логическая, физическая))) Ладно ладно, я не буду погружаться в такую замечательную теорию, хотя безусловно она и есть база. Меня научили проектированию данных в институте - это был один из любимейших предметов, хотя над книжкой Диго Светланы Михайловны “Основы баз данных” - я засыпала почти так же хорошо, как над высшей математикой.
И все таки никуда не деться без обращения к классикам проектирования хранилищ данных Инмону, Кимбаллу, и прости господи Линстедту. Кто не слышал про таких, но хочется разобраться, нужно прочитать если не книжки, то статьи. Оставлю ссылку на неплохую статью( не со всем согласна, но все таки)https://moluch.ru/archive/310/70003/
Если кратко сформулировать сугубо мое мнение к этим подходам, получиться следующее:
Инмон
3НФ - максимальная нормализация и единая интерпретация данных для всей компании. Для больших организаций - считаю утопичной идей, бизнес растет быстрее чем вы можете закрыть организационные аспекты работы над такой моделью. Для некоторых витрин, когда, например заказчик очень плохо понимает, что хочет - вы сами разбираетесь как правильно интерпретировать данные с источника, нормализуете (например, в некоторых системах даже сущность клиента может быть раскидана по 10кам разных таблиц)- тем самым создаете себе отличный плацдарм для будущих более осмысленных требований заказчика.
Кимбалл
Звездочка, Снежинка - максимальная ориентированность на конкретную бизнес задачу, таблицы фактов со справочниками вокруг. Если задача действительно локальная и не предполагается использовать витрину для других функций бизнеса это самый простой и быстрый вариант. Но учтите, что просто так добавить атрибуты в таблицы фактов у вас врятли получится. Придется делать initial перезагрузки больших таблиц - что иногда крайне проблемно. Ну и главное, будете готовы к отсутствию целостности и непротиворечивости относительно других витрин в компании.
Линстедт
Data Vault - гибрид предыдущих двух подходов с HUB, SATELLITE. lINK и расширенным осознанием необходимости хранения технической истории.
Это все таки больше про базу хранилища, чем про конкретную витрину, но я фанат Data Vault, поэтому расскажу. Если запросы бизнеса часто меняются и требуются новые разрезы данных - масштабировать во все стороны модель разработанную по данному подходу - одно удовольствие.
Ограничение - на некоторых технических платформах потом очень сложно реализовывать большое количество соединений для получения бизнес результата. Так же бизнесу будет не очевидна картинка модели( те 3 страшных слова, которые я перечислила чуть выше)
“DS подход” (мое название))
Абсолютно плоские таблицы. Тут нужно не забывать, что для человеческого восприятия широкая таблица сложно осознается. Но это огромный плюс для распространения данных не погруженным в анализ систем людям, и уменьшения количества ошибок при интерпретации.
И новинка сезона - скоростные витрины - как таковое это не методология проектирования, но тут все строится вокруг самой быстрой части данных - потока событий, а остальные таблицы в целом добавляются максимально близко к подходу Кимбалла.
По факту процесс проектирования должен строиться на базе глубоко стратегического видения именно бизнес драйверов. И конечно максимально переиспользовать практики и стандарты уже разработанные в компании.
Будет отдельная статья, где покажу пример создания модели в разных методологиях на основание одной входной информации, а пока картинка модели данных в 3НФ из интернета (Power designer - one love):
Взята с сайта: https://studbooks.net/2018370/informatika/razrabotka_fizicheskoy_modeli_dannyh
Почему нарисованные модели данных спасут мир?
Только то что сразу бросается в лицо:
1. “Прочитать” такую модель можно за 5 минут. Я видела огромные модели по + 100 объектов, но это все равно проще чем смотреть эти 100 таблиц в словаре в базе и пытаться понять, что вообще к чему.
2. Кардинальность связи видна моментально - она всегда играет огромную роль.
3. Модель дисциплинирует с точки зрения Name Convention (правил наименования объектов) - потому что видно ;)
4. Анализировать глобальные проблемы и перекосы в данных можно на уровне отлова ошибок(когда всем больно) и на уровне логики модели (когда всем видно).
5. Объяснить бизнес заказчику суть, решить в какой задачи можно использовать, и какие фрагменты нужно распространять обязательно вместе - 100% удобнее имея модель.
6. Ну и главное! Когда ты смотришь на список из N-ого количества витрин и думаешь, что проще сделать свою заново, чем разобраться есть ли то что тебе нужно в этих витринах -, максимально ценный ресурс, человек который может нормально - русским языком объяснить, что, где и как. Обычно это системный аналитик, и эти люди никогда не сидят без дела.Они решают новые бизнес задачи и очень не любят каждому рассказывать, что там в этой таблице и как ее объединить с другой. Нельзя делать этих людей узким горлышком.
Есть ли золотая середина между скоростью разработки и структурированным подходом проектированию?
Простой ответ - НЕТ.
От дата людей сейчас действительно требуют очень большой скорости, потому что данные это самый быстро развивающийся актив бизнеса, дающий качественное преимущество. Если он сам качественный :)
Пару предложений как эту золотую середину нащупывать
- Идеальный вариант это автоматизация процессов проектирования и разработки. Модель рисуется и описывается в case средствах, оттуда генерируется код структур физических таблиц и документация по описанию. Код накатывается на среды - все везде совпадает - счастье есть. Правда это не особо работает для hadoop (обожаю, сарказм ;) )
- Если требования бизнеса растут быстрее чем есть возможность грамотно осмысливать и описывать модель - бейте таблицы на базовые - которые будет переиспользоваться всеми и какие то специфические справочники или агрегаты - для локальных заказчиков и их осмысливайте, проектируете и описывайте с меньшем приоритетом.
- Если даже на описание базы не хватает ресурсов. Проговаривайте ключевые бизнес драйверы в витрине, т.е. на какие показатели будут смотреть в первую очередь и начинайте с этих блоков данных(кажется простой совет, но ему не так просто следовать, это же нужно заказчику устроить допрос с лампочкой и на 5 раз он сам осознает и сознается)
- Если с ресурсом совсем совсем плохо, придумайте простые инструменты - идеально то что можно расшарить на всех участников команды сразу (супер простой пример - таблицы в google docs), чтобы как минимум фиксировать описания таблиц и атрибутов, ключей связей (PK,FK) в связке со схемами БД и физическим наименованиями таблиц.
успехов нам всем, друзья, ILOVEDATA