Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Логика QlikView подразумевает RELOAD информации из источников с некой периодичностью. Однако существуют задачи, которые требуют немедленно отображать изменения: состояния фондовых рынков, отчеты о пробках или ДТП в городе и т. п. Отчет, сформированный 15 мин назад можно отправлять в мусорку.
Например, в Hadoop за это отвечает новомодный Apache Spark, который представляет собой InMemory хранилище, куда ассинхронно "прилетают" данные, на основе которых пересчитываются агрегации и т. п. Но Qlik также является InMemory-хранилищем и даже поддерживает динамические апдейты. В примерах апдейты формируются внутри системы из действий пользователя. Но в моем случае изменения должен создавать внешний скрипт.
Как на практике реализовать что-то похожее на http://www.zoomdata.com/demos/ ?
Не думаю, что стоит ориентироваться на Dynamic Updates. Стоимость обновления данных (затраты вычислительных ресурсов) в режиме Dynamic Updates в ассоциативной модели могут быть значительными при больших объемах данных. Т.к. внесение любого изменения потребует перерасчета всей модели данных.
Если требуется получать данные в реальном времени из какого-то источника "по запросу", в режиме реального времени, то можно использовать механизм Direct Discovery.
Применение Direct Discovery позволяет Qlik-у запрашивать данные по ODBC из любого источника так, как это делают инструменты любых других производителей.Очевидно, что в этом случае для данных получаемых в режиме Direct Discovery, будут свойственны все ограничения стандартных ODBC-источников, например, отсутствие ассоциативной модели, невозможность применения к ним set-анализа, ограниченный набор функций агрегирования (только реализуемые средствами ODBC-источника), зависимость от быстродействия источника данных и производительности каналов связи, жесткое описание измерений и мер и т.п.
Если же требуется еще и обновление объектов визуализации без участия пользователя, то это можно делать простейшим сценарием JavaScript, обновляющим браузер с требуемой периодичностью.
Согласен. Видимо придется часть логики переложить на внешнюю подсистему, как в примере Jethro