Текущая SQLAlchemy dataset model (SqlaTable) — Семантическая модель Superset
Текущая семантическая модель в Superset очень проста. Изначально Superset создавался как пользовательский интерфейс для изучения источников данных (таблиц) Druid. В то время Druid не поддерживал SQL, и запросы приходилось выполнять с использованием собственного интерфейса на основе JSON. Из-за отсутствия поддержки SQL при добавлении источника данных в Superset типы столбцов приходилось выводить из их имен, и пользователи могли вручную переопределять их. Кроме того, из-за характера хранилища Druid пользователям также приходилось указывать временной столбец, какие столбцы можно фильтровать, а какие можно группировать, чтобы предотвратить выполнение дорогостоящих запросов.
Пользователи также могли добавлять в источник данных новые метрики и производные столбцы, что было важной функцией, поскольку их нельзя было просто определить на лету с помощью SQL. Метрики, столбцы и метаданные, описывающие столбцы, хранились (и остаются) в модели под названием DruidDatasource. Это описание базовой таблицы и дополнительные метаданные стали семантическим слоем Superset.
После того, как была добавлена поддержка SQL, была введена новая модель под названием SqlaTable. Новая модель представляет собой таблицу в базе данных, поддерживаемую SQLAlchemy, и содержит дополнительные метаданные, аналогичные аналогу Druid: типы столбцов, метки, свойства (группируемые/фильтруемые/временные), а также дополнительные метрики и столбцы, определенные с помощью SQL.
Одна из основных проблем с текущей реализацией наборов данных заключается в том, что они недостаточно отличимы от таблиц, а наборы данных представляют собой лишь очень тонкий слой вокруг таблиц. Наборы данных не могут быть названы, вместо этого они наследуют имя базовой таблицы. Из-за этого невозможно иметь два набора данных, указывающих на одну и ту же таблицу. Поскольку они так тесно связаны, пользователи не понимают разницы между таблицей и набором данных, а общий источник путаницы заключается в том, почему пользователь может запрашивать таблицу в SQL Lab, но не может визуализировать ее в представлении Explore.
Некоторые из этих недостатков были устранены путем введения виртуальных наборов данных, наборов данных, которые вместо указания на таблицу определяются выражением SQL. Виртуальным наборам данных можно присваивать имена, а несколько виртуальных наборов данных могут указывать на одну и ту же таблицу, что позволяет разным командам выбирать наборы данных в соответствии со своими потребностями. Хотя это явно шаг в правильном направлении, виртуальные наборы данных также не являются отдельной сущностью в кодовой базе (они по-прежнему используют модель SqlaTable), и между ними и физическими наборами данных, а также ими и базами данных по-прежнему много путаницы.
Кроме того, процесс создания виртуального набора данных неясен: пользователям нужно зайти в лабораторию SQL, написать запрос, выполнить его и нажать «Исследовать», чтобы создать набор данных. Во время этого процесса у них очень мало контроля над создаваемым набором данных, им разрешено только выбирать имя, хотя позже они могут редактировать другие атрибуты. Помимо этого потока, нажатие «+ Набор данных» позволяет создавать только физические наборы данных, но не виртуальные.
На следующей диаграмме показана текущая модель набора данных SQLAlchemy (SqlaTable), а также связанные сущности.
Несколько замечаний:
- Физические наборы данных имеют отношение 1:1 к представлениям и таблицам в данной базе данных (синий цвет).
- Виртуальные наборы данных, как и запросы, имеют неявные отношения n:n с представлениями и таблицами (обозначены пунктирными линиями). Поскольку модели нет, Table-связь существует только в SQL-запросе, присутствующем в этих моделях. Superset уже может анализировать SQL и извлекать таблицы, на которые ссылаются из соображений безопасности, поэтому явное представление этой связи должно быть простым.
- Столбцы и метрики, которые здесь не показаны, очень похожи на наборы данных. Объект столбца может указывать непосредственно на столбец в данной таблице, аналогично тому, как работают физические наборы данных; и производный столбец имеет неявную связь n:n со столбцами через expression.
- Большинство диаграмм имеют отношение n:1 к наборам данных. «Несколько линейных диаграмм» и «Множественные слои Deck.gl» имеют связь n:n с диаграммами, но это особый случай, поэтому связь не представлена на диаграмме.
Перспектива изменений Datasets в Apache Superset
[SIP-68] A better model for Datasets
Источник: Блог superset-bi
