Новая модель данных (Data Model) Tableau 2020.2
В последней версии Tableau 2020.2 представлена новая модель данных, которая существенно отличается от предыдущей. Сегодня, мы подробнее расскажем о том, как работает новая модель данных по сравнению с предыдущей, а также о некоторых проблемах, которые она решает.
Предыдущая модель данных
При использовании предыдущей модели данных (до версии Tableau 2020.2), мы выбирали таблицы, а также указывали тип объединения, как именно объединить выбранные таблицы.
Например, вот простая модель данных, которая объединяет таблицы Order и People на основе поля Region.
Давайте посмотрим на SQL, который при этом выполняется:
SELECT * FROM [Orders] INNER JOIN [People] ON [Orders].[Region] = [People].[Region]
Любые визуализации, которые мы создаем в Tableau при объединении таблиц Order и People, всегда будут использовать этот базовый SQL, даже если мы не включаем поля из таблицы People .
Например, давайте создадим очень простую гистограмму, которая показывает объем продаж по клиентам. Это сгенерирует следующий SQL:
SELECT [Customer Name], SUM([Sales]) FROM [Orders] INNER JOIN [People] ON [Orders].[Region] = [People].[Region] GROUP BY [Customer Name]
Два поля , которые используются в нашей визуализации, а именно Customer Name и Sales берутся из таблицы Order, то есть мы не используем поля из таблицы People. Тем не менее, SQL, сгенерированный Tableau, все еще включает соединение с таблицей People.
Этот подход имеет несколько недостатков.
Во-первых, это излишнее объединение таблиц, которое будет менее производительным, чем просто выбор данных из одной таблицы, которые действительно нужны для визуализации.
Во-вторых мы можем получить больше записей, чем нам действительно нужно. Чтобы продемонстрировать это, давайте рассмотрим вариант, в котором между нашими таблицами существует отношение «один ко многим» (one-to-many). Ниже, приведена альтернативная таблица данных Person с именем Person_Multiple :
Видно, что в этой таблице в каждом регионе есть два человека. Если использовать эту таблицу в нашей модели данных, то для нее будет выполнятся SQL, аналогичный описанному выше. Но так как в каждом регионе есть два человека, каждая запись в таблице Order будет дублироваться. Итак, мы получим 19 988 записей вместо 9 994 записей, которые находятся в таблице Order. А если речь идет о миллионных записях, можно представить к чему это может привести. Но эта разница в объеме данных является лишь частью проблемы — дублирование данных также влияет на агрегации.
Например, давайте снова создадим гистограмму, показывающую объемы продаж по клиентам. Выполняется почти тот же SQL (за исключением использования People_Multiple вместо People), но из-за дублирования записей наши итоговые агрегаты продаж удваиваются. Самым типичным решением этой проблемы является использование вычислений LOD (Level-of-Detail). К сожалению, вычисления LOD немного сложны и не всегда доступны для новых пользователей Tableau. Кроме того, некоторые пользователи могут даже не осознавать, что их объединение привело к дублированию данных, и, следовательно, они не знают, что им нужно решать эту проблему.
Примечание: есть другой способ решения проблемы дублирования записей- параметр «Assume Referential Integrity». Когда вы используете этот параметр, Tableau автоматически включает объединенную таблицу в запрос, только если на нее специально ссылаются поля в вашей визуализации. Это, конечно, приведет к более эффективному SQL. Но нужно также быть осторожными — если вы выберете эту функцию, но ваша база данных не будет иметь «ссылочной целостности», это может привести к неточным результатам.
Итак, три выявленные проблемы при использовании предыдущей модели данных:
1) Слишком сложный SQL — ненужное чрезмерное усложнение нашего SQL, которое влияет на производительность.
2) Дублированные записи — больше записей, чем нам нужно.
3) Потребность в вычислении LOD — необходимость использовать вычисления LOD для устранения дублирования данных в агрегатах.
Вывод: в предыдущей модели данных SQL может извлекать разные поля и может выполнять различные типы агрегации, но предложение FROM всегда будет включать все таблицы в вашей модели данных, которые вы выбрали при объединении.
Новая модель данных
Давайте рассмотрим новую модель данных в новой версии Tableau 2020.2. Использование «связей» (Relationships) означает, что Tableau будет генерировать уникальный SQL для каждого создаваемого вами представления (визуализации), который больше не будет включать все таблицы в вашей модели данных. Вместо этого он анализирует поля, которые используются в вашем представлении, и создает SQL, предназначенный для получения только тех данных, которые вам действительно нужны.
Ниже приведена модель данных с использованием «связей». Обратите внимание, что нет диаграммы Венна, которая показывает тип объединения. Это из-за того, что нам больше не нужно указывать тип объединения. Мы просто определяем связь между двумя таблицами. Но на данный момент эти таблицы остаются независимыми. Tableau не создает базовый SQL для использования в рабочей книге, как в старой модели данных. Мы просто устанавливаем связь между таблицами, которые будут использоваться.
Давайте еще раз построим нашу гистограмму объема продаж по клиентам. Используя новую модель данных, наш SQL будет выглядеть так:
SELECT [Customer Name], SUM([Sales]) FROM [Orders] GROUP BY [Customer Name]
Tableau автоматически определяет, что ни одно из полей People не используется в этом представлении, и поэтому исключил его из SQL. Это понятие, которое в Tableau называется «join culling» — в основном процесс, с помощью которого механизм обработки данных удаляет ненужные объединения.
Но что произойдет, если мы будем использовать поле из таблицы People в нашем представлении? Например, что если мы отразим записи только для Anna Andreadi (таблица People, поле Person)? Это сгенерирует следующий SQL:
SELECT [Customer Name], SUM([Sales]) FROM [Orders] INNER JOIN [People] ON [Orders].[Region] = [People].[Region] WHERE [Person] = 'Anna Andreadi' GROUP BY [Customer Name]
Поскольку мы использовали поле из таблицы People , Tableau сгенерировала объединение, используя связи, которые мы установили в модели данных.
Мы можем сразу же увидеть преимущества новой модели данных, а также генерируемых SQL,так как мы запрашиваем у базы данных только те данные, которые нам действительно нужны. Это приводит к повышению производительности запросов, решая первую проблему предыдущей модели данных.
Но как новая модель данных влияет на наши две другие проблемы — дублирование записей и потребность в вычислении LOD, — которые вызваны отношением «один ко многим» (one-to-many)?
Предыдущая модель данных объединяет таблицы, а только потом сохраняет данные, в новой модели данные таблиц хранятся вне зависимости от объединения. Таким образом, дублирование данных не является проблемой с точки зрения объема данных. Но это может быть проблемой, когда дело доходит до агрегации. Чтобы понять это, давайте изменим нашу модель данных, для этого будем использовать таблицу People_Multiple вместо People :
Теперь давайте снова построим нашу простую гистограмму объем продаж по клиентам. Когда мы сделаем это, наш SQL будет выглядеть так:
SELECT [Customer Name], SUM([Sales]) FROM [Orders] GROUP BY [Customer Name]
Итак, поскольку представление не содержит никаких полей из таблицы People_Multiple , Tableau автоматически отбирает соединения. И преимущество этого простого SQL в том, что SUM (Sales) не будет дублироваться и это даст нам фактическое значение без необходимости вычисления LOD.
Но что произойдет при использовании поля из таблицы People_Multiple? Добавим фильтр на Person = ‘Central Person 1’. Наш SQL при этом будет выглядеть так:
SELECT [Customer Name], SUM([Sales]) FROM [Orders] INNER JOIN ( SELECT [Orders].[Region] FROM [Orders] INNER JOIN [People_Multiple] ON [Orders].[Region] = [People_Multiple].[Region] WHERE [Person] = 'Central Person 1' GROUP BY [Orders].[Region] ) AS [Table 1] ON [Orders].[Region] = [Table 1].[Region] GROUP BY [Customer Name]
Видно, что этот запрос немного сложнее, чем любой, который мы рассматривали выше. Tableau автоматически определил, что в нашей таблице есть отношение «один ко многим» (one-to-many), поэтому Tableau избегает прямого соединения между таблицами Orders и People_Multiple, так как это может привести к дублированию записей. Вместо этого Tableau генерирует следующий подзапрос:
SELECT [Orders].[Region] FROM [Orders] INNER JOIN [People_Multiple] ON [Orders].[Region] = [People_Multiple].[Region] WHERE [Person] = 'Central Person 1' GROUP BY [Orders].[Region]
Этот запрос объединяет Orders и People_Multiple, избирая только поле Region — поле, на котором строятся наши связи с таблицами. Результатом этого конкретного SQL является один столбец и строка:
Затем он присоединяет это обратно к таблице Orders и подводит итоги продаж. Поскольку SQL избегает непосредственного объединения двух таблиц, мы не получаем дублирования данных, и агрегация имеет точное значение без необходимости выполнять сложные вычисления LOD.
Вывод: мы рассмотрели новую модель данных,и очень надеемся, что теперь вы лучше понимаете, как она работает , а также чем она отличается от предыдущей модели данных и какие проблемы решает. Таким образом новая модель данных устраняет ряд общих проблем, в том числе проблему, которая возникает при работе с отношениями «один-ко-многим» (one-to-many).
Источник: https://www.flerlagetwins.com/
Хотите узнать, как провести анализ и сделать отчеты быстро?
Нам доверяют:
