Размерное моделирование в столбчатых базах данных

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

С точки зрения витрины данных (допустим, для организации отдел хочет только отслеживать рост продаж в Интернете, а некоторые другие отделы хотят сосредоточиться на производительности торговых точек), как я могу разработать архитектуру, которая может обрабатывать загрузку данных и предоставлять простые данные доступ. Я знаю, как на его основе можно легко спроектировать витрину данных, и конечному пользователю вообще не нужно беспокоиться о расчетах.

У меня был опыт работы с SSAS (OLAP), в котором все вычисления в большом хранилище данных уже вычислены, и обычный бизнес-пользователь может напрямую подключиться к кубу и анализировать данные с помощью инструмента самообслуживания BI (так же просто, как перетаскивание) на с другой стороны, столбчатые базы данных, похоже, следуют подходу ELT и оставляют все вычисления либо на запросах (представлениях), либо на инструменте отчетности.

Поскольку у меня есть опыт работы с SQL Server, я предполагаю, что мой запрос (например, ниже)

SELECT 
  region,
  state,
  City,
  Country,
  SUM(Sales_Amount),
  AVG(Discount_Sale),
  SUM(xyz)
  ....
FROM Columnar_DataTable

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

Итак, уместно ли создавать OLAP поверх столбчатых баз данных с многомерным моделированием или лучше сначала загрузить данные, а затем отфильтровать / преобразовать их в инструменте отчетности? Учитывая, что большинство инструментов самостоятельной бизнес-аналитики уже помните об этом и ограничьте использование потребления данных (например, версия сообщества Power BI для настольных ПК допускает 10 ГБ на набор данных) и заставляет пользователя выполнять свои собственные вычисления.

  • Если мы разделим данные на несколько таблиц, тогда все инструменты отчетности, в любом случае, потребуют связи между таблицами для фильтрации.

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


data-warehouse olap dimensional-modeling reporting data-modeling
person Zerotoinfinity    schedule 25.02.2019    source источник
comment
Возможно, это больше похоже на самостоятельный ответ, чем вы ищете, но информация Amazon Redshift Data Warehouse о столбчатом хранилище данных (docs.aws.amazon.com/redshift/latest/dg/). Столбцовое хранилище для таблиц базы данных резко снижает общие требования к вводу-выводу диска и является важным фактором оптимизации аналитики. производительность запроса. Хранение информации таблицы базы данных в виде столбцов уменьшает количество запросов дискового ввода-вывода и уменьшает объем данных, которые необходимо загрузить с диска.   -  person saritonin    schedule 25.02.2019

Ответы (2)


arrow_upward
4
arrow_downward

Запросы бизнес-анализа часто включают вычисление агрегатов для показателей, таких как общие суммы продаж и средняя скидка, которые вы указали в качестве примера.

Структуры данных OLAP полезны для этих случаев использования, поскольку агрегаты могут быть предварительно вычислены и сохранены, тем самым требуя меньше вычислений и операций ввода-вывода во время запроса и ускоряя шаблоны запросов, используемые в этих случаях использования.

Подход OLAP получил распространение (также) потому, что типичная реляционная база данных была менее производительной в этих сценариях, и OLAP оказался эффективной оптимизацией.

Подход к базе данных по столбцам (в базах данных, ориентированных на аналитику) также предназначен для оптимизации этих вариантов использования, в основном путем структурирования и хранения данных таким образом, чтобы из хранилища считывались только выбранные столбцы, такие как метки и меры для агрегатов. Это требует меньшего количества операций ввода-вывода и является одной из основных причин того, почему столбчатые форматы обеспечивают высокую производительность для этих случаев использования (другие - сложное разбиение на разделы, параллельная обработка, сжатие и метаданные, как в Apache Parquet).

Итак, что касается вашего вопроса, я бы сказал, что вам следует беспокоиться только о предварительных вычислениях агрегатов в столбчатой ​​базе данных, если вы испытываете низкую производительность в сценариях специальных запросов и не можете решить ее более быстрыми способами (например, кешированием, правильным разделением и сжатием) . Но это также зависит от того, какой формат базы данных / saas / файла вы используете.

Что касается размерного моделирования, это другой вопрос. Если вы используете столбчатый формат файла, такой как Parquet, на самом деле может быть желательно (в зависимости от пользователя и варианта использования) использовать что-то вроде Hive для создания (мета) размерной модели над файлами, чтобы, например, вы можете предоставить пользователям таблицы базы данных и интерфейс SQL вместо группы файлов.

Что касается PowerBI, как и большинство инструментов отчетности, вы можете использовать его в режиме прямого запроса, если пользователи действительно будут работать с наборами данных размером более 10 ГБ.

PS: в базе данных по столбцам этот конкретный фрагмент SQL не будет «сканировать всю таблицу», он будет сканировать только выбранные вами столбцы; это часть оптимизации столбчатого дизайна.

person jmng    schedule 26.02.2019

arrow_upward
-1
arrow_downward

Ваш рост продаж SQL не имеет смысла. Рост продаж отслеживается во времени, но вы не определили временную часть в своем SQL. Например, если бизнес хочет отслеживать еженедельные или ежемесячные продажи, вы создаете либо еженедельную таблицу фактов, либо ежемесячную таблицу фактов, рассчитываете еженедельные или ежемесячные продажи и сохраняете в этой таблице фактов. Таким образом, вы добавляете еженедельные или ежемесячные данные в таблицу фактов, чтобы отчет просто считывал их из таблицы фактов. У вас есть даты, которые представляют начало недели / месяца и конец недели / месяца в таблице фактов, чтобы отчет мог их использовать. При таком подходе к разработке отчет будет работать быстрее, потому что он не выполняет никаких вычислений, а показывает обобщенные данные.

person Sam Kaz    schedule 26.02.2019