Построение модели
BI-система QlikView имеет весь необходимый инструментарий, позволяющий выполнять загрузку, очистку и преобразование данных из различных источников, т.е. выполнять всё то, что называется классическим ETL (Extraction|Transformation|Load).
Причем гибкость и скорость работы ETL в QlikView легко дает фору многим именитым конкурентам. В частности, я могу привести большое количество примеров заказчиков, где ИТ-шники намучавшись с не вполне удачными реализациями ETL конкурентов, втихую, а часто и в открытую используют QlikView для загрузки и очистки данных, которые потом загружают в хранилище.
У QlikView нет своего хранилища данных. Как жить?
То, что QlikView не имеет собственного хранилища — это не минус и не плюс, это просто факт. Дальше лишь вопрос в понимании того, как работает QlikView в сравнении с другими инструментами.
Подчеркну сразу, что я не сторонник шапкозакидательства фразами типа: «хранилища не нужны никому принципиально».
Для построения хранилищ у заказчика могут быть сформированы свои и достаточно веские аргументы. Однако, в части аналитики очень часто созданием хранилища вуалируют ограничения OLAP (On-Line Analytical Processing, Аналитическая обработка в реальном времени).
ОLAP без хранилища, действительно, не строят. Но это не означает, что аналитика возможна только на OLAP. QlikView легко и эффективно показывает, как делается прекрасная аналитика без OLAP.
Дело в том, что любые инструменты, кроме QlikView, просто неспособны работать без промежуточного хранилища, ибо сами они не способны выполнять подготовку данных для конечного пользователя.
Именно поэтому все инструменты, кроме QlikView, требуют создания хранилища (сбор и очистка данных), а затем и построения OLAP-кубов, позволяющих хоть как-то ускорить работу конечного пользователя с собранными данными.
Очевидно, что необходимость создания хранилища и построения серьезных OLAP-кубов требует существенных затрат как в части оборудования и лицензий на ПО, так и в части трудозатрат специалистов.
А если хранилище уже есть?
QlikView может работать несколькими способами.
- Если в организации уже построено хранилище, то QlikView без проблем сможет забрать данные из него просто как из одного из возможных источников данных.
- Но если хранилища нет, то для предоставления возможности анализа данных системе QlikView не требуется построение хранилищ.
И ни в одном из сценариев для QlikView не требуется OLAP. QlikView способен работать, забирая данные непосредственно из источников.
При этом подчеркну, что физически забирая данные из источников, QlikView может и должен сохранять данные в промежуточных файлах.
Но в отличие от специализированных хранилищ, файлы QlikView — это действительно просто файлы, специальная структура которых позволяет загружать данные с очень высокой скоростью (в
Обновление данных
В части обновления данных — обновление необходимо как в любом хранилище, так и в QlikView. Если мы хотим работать с актуальными данными, то их нужно по расписанию обновлять из первоисточников.
И здесь QlikView ничем не отличается от принципов обновления данных в любых хранилищах — они могут обновляться по расписанию, по внешнему событию, каскадно и еще кучей разных способов.
Поэтому фраза оппонента «потребуется постоянно поддерживать соединение с системами источниками» лишена любого смысла.
Загружать и обновлять данные из первоисточников придется как при реализации хранилища, так и при реализации на QlikView. И уж тем более смешно предполагать то, что QlikView постоянно «мучает» запросами первоисточники данных. Мне было бы смешно даже предположить, что серьезная аналитическая система может подобным образом относиться первоисточникам данных.
Скорость внедрения для заказчика
Можно долго спорить на техническом уровне, однако практика — лучший судья.
И практика показывает, что за время проекта в
За это же время решения, базирующиеся на хранилищах и OLAP, как правило, могут похвастаться только началом настройки хранилища и попытками написать техническое задание «на все случаи жизни».
Очевидно, что для конечного пользователя в течение всего этого времени ценность хранилища и технического задания к нему — равна нулю.
OLAP-у и не снилось
В части моделирования данных, замечу, что OLAP — довольно старая технология. Безусловно, ее пытаются усовершенствовать, но ее архитектурные ограничения принципиально неспособны дать функциональность, сопоставимую с QlikView в части простоты и одновременно гибкости моделирования данных.
Например, OLAP предполагает жесткое определение измерений и измеряемых величин. На практике это означает, что возможные пути анализа данных определяются только ИТ-специалистом, а не пользователем, понимающим суть этих данных.
Именно поэтому при использовании OLAP сотрудники отделов ИТ и конечные пользователи постепенно начинают ненавидеть друг друга. И ненависть эта растет пропорционально объему задач, которые пытаются решать ИТ-специалисты, т.к. OLAP порождает только конфликты интересов.
Конечный пользователь хочет большую гибкость и далеко не всегда может сформулировать, что он хочет получить. ИТ-специалист же наоборот — требует максимальной определенности, т.к. он просто не может построить OLAP-куб без четкого определения измерений, измеряемых величин и порядка работы с ними.
В итоге все приходит к тому, что ИТ-специалисты, прикрываясь сложными техническими заданиями, просто закрываются от бизнес-пользователей.
В ассоциативной модели данных QlikView (это не OLAP) у пользователя отсутствуют ограничения на измерения и измеряемые величины.
Также в QlikView отсутствуют жестко определенные пути анализа. Конечный пользователь просто работает со взаимосвязанным множеством данных, описывающим его объект управления.
Образно говоря, конечный пользователь «крутит» данные сам как угодно, рассматривая интересующие его данные в ЛЮБОЙ проекции, пришедшей ему в голову. И без необходимости написания дополнительных технических заданий.
Про быстродействие и интерактивность говорить вообще бессмысленно — в природе нет OLAP, способного соревноваться с QlikView в части гибкости, быстродействия, интерактивности.
Опять же, здесь нужно быть аккуратным в терминах и не заниматься шапкозакидательством. Обращаю внимание на то, что модель данных должна строиться в любой системе, включая и QlikView.
И эту модель в любой системе почти всегда строят специалисты ИТ, ибо только они знают достаточное количество деталей, позволяющих правильно загрузить данные из нужных источников и связать их в общую модель.
Ключевое различие в моделях QlikView и OLAP проявляется позже — когда с моделью начинают работать пользователи.
И отличия эти просты: работая с моделью QlikView, пользователь просто не замечает ее — с его точки зрения она «сама по себе правильно работает», т.к. она не вносит ограничений в его работу. Пользователь лишь указывает, что и как он хочет считать и сравнивать.
Используя же OLAP, пользователю приходится все время натыкаться на ограничения, вызванные тем, что под его очередную пришедшую в голову мысль, IT-шник не смог предварительно рассчитать данные. И ведь действительно, он не мог этого сделать, т.к. не знал, что именно понадобится пользователю в данный момент. А без предварительного расчета OLAP не работает.
Использование созданной модели данных конечными пользователями
Функционал QlikView не идет ни в какое сравнение с функционалом ЛЮБОГО конкурента, использующего пару: любое хранилище + OLAP.
Об этом бессмысленно говорить — пользователи попробовавшие использовать QlikView на своих данных, просто больше не хотят возвращаться в ограничения OLAP.
Самое смешное, что пользователи почти никогда не могут сформулировать, что им нравится помимо быстродействия и интерактивности, но они однозначно голосуют за использование ассоциативной модели QlikView в сравнении с любыми вариантами OLAP.
И происходит это потому, что QlikView показывает не только данные — он еще и показывает как они взаимосвязаны. То есть в отличие от OLAP, QlikView сразу дает ответ на вопросы: «что мы видим?» и «почему мы видим именно это?», таким образом позволяя докопаться до сути вопроса.
Более того, интерфейс пользователя QlikView не только дает ответы, он еще и ПОБУЖДАЕТ пользователя: «ну задай мне еще вопрос» или ПРОВОЦИРУЕТ: «что, посложнее ничего придумать не мог?».
То есть QlikView превращает анализ данных в своеобразную игру на понимание того, что показывают данные и на раскрытие тайн в них.
И я не видел ни одного пользователя, которого бы не увлекла эта таинственная игра. В итоге пользователи начинают работать с данными самостоятельно и увлеченно, а не принужденно, по пинку сверху.
Инфраструктура под OLAP и QlikView
В части нагрузочных характеристик картина еще интереснее.
OLAP позволяет повысить быстродействие, ускоряя ответы на запросы пользователей только лишь за счет того, что предварительно рассчитывает данные в заданных ему разрезах.
Однако когда пользователи массово начинают работать даже с предварительно рассчитанными данными, ограничениями становятся как производительность самого OLAP-хранилища, так и сетевой инфраструктуры. И это ограничение невозможно обойти, так как подобная обработка запросов является архитектурным ограничением OLAP.
Именно поэтому при большом количестве пользователей время отклика на любое действие пользователя становится почти невозможно прогнозировать — оно становится очень многопараметрическим, т.к. зависит от того, как нагружают OLAP (CPU+RAM), сетевую и дисковые подсистемы другие пользователи.
QlikView же, загружая все данные в оперативную память, все расчеты выполняет именно там, не задействуя дополнительно ни сетевую, ни дисковую подсистемы при обслуживании пользователей.
Поэтому нагрузочные характеристики серверов QlikView не только легко рассчитываются, но и легко сохраняются и масштабируются при решении задач любой сложности: при увеличении сложности расчетов, увеличении объема данных, увеличении количества пользователей.
- Если у вас есть вопросы по внедрению бизнес-аналитики, обращайтесь к нашим специалистам >>
- Заказать бесплатную демонстрацию возможностей QlikView >>
- Пилотный проект на QlikView за 1-3 дня с вашими данными >>
