Моделирование данных BI — традиционные и новые подходы

Уважаемое сообщество,
Надеюсь, заголовок дает вам намек на то, о чем я хочу поговорить или мне нужен совет.

Я разработчик бизнес-аналитики с 3-летним опытом работы над крупными проектами бизнес-аналитики — некоторые из них были в сфере здравоохранения, а некоторые — в финансовой отрасли, когда я работал в IBM. На своей текущей работе я пришел в стартап-компанию, у компании есть оперативная БД по назначению продукта и данные находятся на БД SQL Server.

В течение 4 месяцев я тушил пожары по поводу всей массы, которую сделал мой предшественник, и теперь я готов к следующему шагу - моделированию операционных таблиц БД для БД DWH, чтобы иметь возможность извлекать и использовать данные для аналитических целей и целей BI.

У меня вообще нет никаких ресурсов, поэтому я сначала создам DWH на рабочей БД, а затем мое видение состоит в том, что DWH будет на БД Snowflake после того, как я получу ресурсы от своего технического директора.

Проблема моделирования.
Когда я решал проблему моделирования данных, я столкнулся с некоторой путаницей в правильном способе моделирования данных. Есть традиционный способ, которым я знаком с IBM, но есть моделирование Cloud DWH и гибридный подход. Моя модель должна быть гибкой, а данные должны извлекаться очень быстро.

Каков наилучший способ хранения и извлечения данных для аналитических целей?
Таблицы фактов с большим количеством измерений — нормализация подхода
ИЛИ
размещение всех данных, которые мне нужны с точки зрения детализации, в одно и то же время table (думая о будущем, переходя к Snowflake) У меня будет несколько таблиц, каждая с одной гранулярностью и своим миром.

Мне просто интересно услышать, что некоторые из вас реализовали в вашей компании, и если у вас есть совет или UC, которым вы можете поделиться, я много искал в Интернете, и то, что я увидел, представляет собой много предвзятой информации и очень запутанной - никто не действительно говоря, что работает в реальном мире.

Заранее спасибо!


comment
Похоже, вы находитесь на самых ранних этапах создания DWH, поэтому самое главное — выбрать один подход и придерживаться его. Я бы порекомендовал смоделировать его в звездообразной схеме (денормализованной). Даже если вы перейдете на Snowflake в будущем, это не означает, что вы должны просто свести все в одну таблицу фактов.   -  person Simon D    schedule 27.11.2019


Ответы (1)


Итак, два ключевых момента нормализации заключаются в уменьшении используемого дискового пространства и оптимизации извлечения данных; ни то, ни другое не имеет отношения к Snowflake. Хранение очень дешевое. И, что самое приятное, база данных самооптимизируется — в худшем случае вам, возможно, придется настроить ключи кластеризации для очень больших таблиц (см.: https://docs.snowflake.net/manuals/user-guide/tables-clustering-keys.html)

Я обнаружил, что большие таблицы с большим количеством столбцов работают лучше, чем множество небольших таблиц с соединениями. Например, при тестировании плоской таблицы с 10-миллионными строками с настроенным ключом кластеризации; это было примерно на 180% быстрее, чем получение того же набора результатов, но с более сложной моделью/многотаблицей.

Если вы ожидаете много обратной записи и требуете изменений на уровне объекта, вам все равно следует рассмотреть возможность нормализации, но в этом случае вам лучше использовать звездообразную схему.

person Janine Rawnsley    schedule 27.11.2019
comment
Так что в моем случае я какое-то время буду на SQL-сервере. Вы рекомендуете использовать звездную схему, используя факты и измерения? С другой стороны, как лучше всего поддерживать таблицу в рабочем состоянии с изменениями из Operation DB? На моей предыдущей работе я выполнил полное обновление и слияние с поиском. На моей текущей работе у меня нет ресурсов и времени для завершения процесса полного обновления, поэтому на данный момент я каждую ночь выполняю усечение для всех таблиц. - person Aviv Netel; 02.12.2019