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

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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