Звёзд: 1Звёзд: 2Звёзд: 3Звёзд: 4Звёзд: 5 (1 оценок, среднее: 5,00 из 5)
Загрузка...

Large Data Sets в QlikView — подходы к разработке

Подходы к обработке больших данных в QlikView

Large Data Sets в QlikView — в данной статье описываются основные подходы к обработке больших данных в приложении QlikView (эта статья не относится к Big Data). Эта статья описывает лишь три основных подхода. Существуют другие подходы, но они будут рассмотрены позже. Qlik может обрабатывать очень большие наборы данных. Однако, для оптимизации работы пользователя и использования ресурсов оборудования, которое требуется для QlikView, Вы можете выполнить несколько вариантов работ.

Допустим, у Вас есть большой набор данных по заказам в размере 1 миллиарда строк. Вам необходимо обеспечить высокоуровневые показатели для высшего руководства, разработать инструменты для анализа тенденций для бизнес-аналитиков, а также предоставить детальную информацию для сотрудников, которые занимаются обработкой операционной информации по заказам. Существует несколько подходов к отображению данных. Рассмотрим три подхода.

Только детальная таблица фактов

Использование только детальной таблицы фактов позволяет QlikView сделать всю работу для того, чтобы отобразить детальную информацию и суммарные показатели от низшего уровня детализации до высокоагрегированного уровня. Преимущества — простота. Это самое простое решение для реализации кода. Вы просто подключаетесь к низшему уровню таблице Orders (возможно, на уровне SKU) в модели данных, а затем проектируете все высокоуровневые метрики, диаграммы с трендами и детальные таблицы, и настраиваете выборки (фильтры) в документе QVW. Недостатки — QlikView будет необходимо агрегировать 1 миллиард строк детальной информации с каждым кликом по фильтрам. QlikView это может сделать, но производительность приложения будет не очень хорошая, а требуемые ресурсы потребуются значительные.
one_detailed_table

QlikView Document Chaining – что это такое?

Document Chaining (метод цепного взаимодействия документов) — это подход к построению взаимодействия двух документов QVW. Первый документ имеет таблицу Orders с детальными данными (это основная таблица фактов), другой документ имеет предварительно агрегированную таблицу Orders (таблица фактов для второго документа). Предположим, что у нас есть только два этих документа QVW. Ниже приведена схема, которая показывает модель данных из «Summary QVW» и модель данных из «Detail QVW». Обратите внимание, что значения измерений являются одинаковыми в этих двух моделях. Основное различие между документами заключается в таблице фактов. Пользователи могут начать работать с агрегированного документа, который показывает верхнеуровневую информацию.

Если пользователи хотят «просверлиться» в детальные данные, Вы можете воспользоваться подходом Document Chaining в QlikView, чтобы переместить выборки (фильтры) из одного QVW документа в другой QVW документ, а затем открыть второй документ. Пользователь будет видеть новые диаграммы, вкладки и ему не нужно будет знать как фильтры перемещаются из одного документа QVW в другой. Это означает, что Вы будете использовать таблицу фактов с 1 миллиардом строк, когда пользователям это нужно. Остальная работа по обработке данных будет вестись на предварительно агрегированной версии таблицы заказов, которая может быть значительно меньше, чем 100 миллионов строк. Document Chaining подробно описан в справочном руководстве QlikView и в ряде других документов QlikView.
Преимущества — данный подход оптимизирует использование аппаратных ресурсов и скорость реакции на запросы пользователей к навигации и диаграммам QlikView. Потому что выборки пользователей и навигация предоставляются для конкретных нужд, Вам не нужно тратить ресурсы процессора и оперативной памяти для постоянной обработки 1 миллиарда строк детальных данных, когда пользователь в этом не нуждается.
Недостатки — таблицы (QVDs) необходимо предварительно агрегировать и обеспечивать обслуживание для данного подхода. Этот подход намного сложнее, чем разработка приложения с одной таблицей фактов Orders.
document_chaining

Triggered Action – Взаимосвязь таблиц через триггеры

“Triggered Action” подход — это использование предварительно агрегированной суммарной таблицы в дополнение к подробной таблице в одной модели данных QVW документа. На схеме, которая приведена ниже, показан один из способов использования предварительно агрегированной информации в той же модели данных (рядом с детализированной таблицей). В модель данных загружается предварительно агрегированная таблица в качестве data island (у данной таблицы отсутствуют взаимосвязи с другими таблицами модели данных). Затем, соответствующие выборки в детальной таблице фактов переносятся на предагрегированную таблицу фактов с помощью триггеров (triggered Action).

Преимущества — этот вариант не требует второго документа QVW и не требуется document chaining для того, чтобы использовать обе версии (детальной и суммарной) большой таблицы данных.
Недостатки — этот вариант потребует некоторых настроек в QVW, чтобы вызвать действия, которые передадут выборки из одной таблицы в другую. Так как QVW документ изменяется с течением времени, Вам придется отслеживать, куда и когда должны направлены быть действия триггера.
triggered_action_qlikview Пожалуйста, обратите внимание: Существует еще больше вариантов, с помощью которых Вы можете удовлетворить данные потребности, описанные в этой статье. Это всего лишь 3 метода, которые показывают особенности и возможности QlikView для управления очень большими наборами данных.

Ключевые факторы, которые влияют на модель:

  • Уникальные колонки данных;
  • Уникальные записи в ключевых полях.

Оба последних способа могут оказать влияние на размер памяти в модели данных и на использование приложений пользователями.


Звёзд: 1Звёзд: 2Звёзд: 3Звёзд: 4Звёзд: 5 (1 оценок, среднее: 5,00 из 5)
Загрузка...

Комментарии:

2 комментария

  1. Выражение «Big Data» замылено. Когда встречаешь такое в тексте, сразу ищешь где же тут Слон С Ушами (hadoop)

    Я правильно понимаю что млрд строк нужно грузить в Клик в любом случае ?

    1. Женя, вообщем исправил Big Data на первоисходное Large Data. Виноват в подмене понятий, признаю 🙂 Хотя для обработки Big Data тоже есть свои подходы, но об этом в другой раз. Млрд строк можно грузить в Qlik, но не нужно 🙂 Точнее не нужно все в один документ пихать и пытаться все это отдать десяткам пользователей (а то и сотням).

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *