Direct Discovery или работа с большими данными в Qlik Sense
QlikSense (далее QS) – приложение, предоставляющее пользователю богатую коллекцию инструментов визуализации, исследования и анализа данных, поддерживающее интеграцию с различными источниками.
Пользователь без специальных знаний легко сможет в несколько кликов загрузить данные и создать в нём свое первое приложение. Интерфейс при этом возьмет на себя всю “грязную” работу за пользователя и, в первую очередь, создаст скрипт загрузки данных из источника в собственное хранилище QS.
Созданный скрипт в упрощенном виде будет содержать следующие инструкции, в чем можно самостоятельно убедиться в меню “Редактор загрузки данных”:
Вот тут и можно разглядеть потенциальную проблему, а именно ситуацию, когда таблица источника данных будет содержать действительно большое количество записей (например, 10 млн или больше) и при этом данные в источнике обновляются ежедневно. Ведь скрипт в этой редакции каждый раз инициирует их загрузку в полном объеме в хранилище QS. Становится очевидным, что такой подход работы с источником/базой данных, названный кстати “in-memory”, подойдет для относительно небольших уже подготовленных, сгруппированных и предварительно рассчитанных данных, но совершенно не годится для большого объема сырых данных.
Вот было бы здорово, если бы был способ не загружать все эти столбцы/записи в QS и при этом иметь возможность обращаться за ними к источнику непосредственно при работе нашего приложения и при этом еще и переложить на СУБД источника расчет мер (агрегатов).
И оказалось, что о реализации такой возможности в QS позаботились и назвали эту технологию Direct Discovery.
Итак, скрипт загрузки данных, созданный по умолчанию с директивой LOAD, нам больше не подходит, его нужно исправить, чтобы задействовать технологию Direct Discovery:
Под ключевым словом dimension указывается список полей, которые будут выступать в качестве измерений, т.е. полями группировки в приложении QS. При выполнении скрипта загрузки именно они и только их уникальные значения из базы данных будут загружены в хранилище QS.
Рассмотрим на простом примере.
Предположим, что есть большой журнал операций за год на 100 млн. строк и я хочу группировать в своем приложении операции по дате и виду операции. Тогда с применением подхода Direct Discovery в QS будут загружены только 365 строк с датами и некоторое количество строк с видами операций (например, 100 шт.), которые встречаются в таблице. При этом на этапе загрузки выделение уникальных значений полей (distinct) выполняет СУБД, а в QS уже передаются подготовленные данные.
В разделе detail указываются поля, которые можно будет отобразить в табличных виджетах приложения QS, значения этих полей предварительно не загружаются в QS, а вычитываются из источника уже во время работы приложения (отображения таблиц).
В разделе measure нужно указать список числовых полей, которые используются приложением QS в расчете мер. При этом вычисление агрегата (sum, mean, min, max, count и т.д.) осуществляется также на стороне СУБД на этапе отображения значения меры в приложении QS.
Как видите, многие задачи при таком подходе делегируются СУБД, разгружая сервер QS и экономя сетевой трафик. Конечно, в таком случае многое зависит уже от производительности СУБД.
А что там со сравнением отзывчивости интерфейса при работе приложений, использующих разные походы? Для проверки я создал два приложения с одинаковым функционалом, но разными подходами работы с одним и тем же источником данных (в моем случае это таблица в GreenPlum). Разницы в скорости работы приложений совершенно не почувствовал, а вот время загрузки данных по понятным причинам при использовании Direct Discovery оказалось в 10-15 раз меньше и разрыв только увеличивался при добавлении новых данных в источник.
Подводя итоги, приведу сравнительную таблицу рассмотренных походов:
Обе технологии имеют как преимущества, так и недостатки, и при разработке в QS нужно применять наиболее подходящий в конкретной ситуации подход, и, конечно же, ничто не мешает комбинировать их в одном приложении.