Форсайт. Аналитическая Платформа - Работа с данными
Работа с данным осуществляется в графическом интерфейсе платформы.
Источники данных
- Многомерные источники данных: Microsoft Analysis Services, SAP NetWeaver BW, SAP HANA, OLE DB for OLAP;
- Промышленные реляционные СУБД: Microsoft SQL Server, Oracle, IBM DB2, Teradata, PostgreSQL, SQLite, ODBC или OLE DB-совместимые СУБД;
- Аппаратно-программные комплексы: Oracle Exadata, EMC Greenplum, BM Netezza, Teradata Data Warehouse Appliance, HP Vertica;
- Локальные источники данных и «настольные» СУБД: XML, JSON (в том числе через REST-сервис), DBF (dBase), CSV, TXT, VPF, Excel, Microsoft Access, Paradox;
- Поколоночные СУБД: Clickhouse, Tarantool.
Подготовка данных: для настройки взаимосвязей между источниками и приёмниками, а также промежуточных преобразований данных используется инструмент «Импорт, экспорт, преобразование данных».
Хранение и загрузка данных: инструмент «Импорт данных» предназначен для загрузки данных из произвольного источника в стандартный куб или в базу данных временных рядов. Платформа обеспечивает возможность работы с данными как напрямую из БД без предварительной перегрузки данных в хранилище репозитория платформы, так и организовать цепочки загрузки, валидации, согласования данных, если КХД/DWH отсутствует.
In-memory в платформе реализовано в двух вариантах:
- все данные сразу целиком загружаются в ОЗУ с полным предварительным прогревом;
- создается файловый кэш и далее из него в ОЗУ все время «переподкачивается» востребованная часть данных, а невостребованная постепенно вытесняется.
Для разных типов данных - разные технологии их хранения
Платформа «Форсайт» не является средством постоянного хранения больших объемов данных. Для этого мы всегда используем какую-либо внешнюю СУБД. Тут важно сделать уточнение, что для быстрой работы в нашем BI реализованы средства кэширования данных в ОЗУ (in-memory). Но это все же не способ длительного хранения данных, а скорее механизм быстрой обработки данных нашей платформой своими инструментами с высокой производительностью.
Таким образом, мы идем «по старинке» и для хранения данных используем БД от разных производителей: Oracle, MS SQL Server, PostgreSQL, Greenplum, Teradata, Vertica, ClickHouse, Hive, а также ряд проприетарных российских СУБД (PostgrePRO, Jatoba и линейку продуктов Arenadata). Для этого в платформе «Форсайт» реализован набор коннекторов. Для распространенных СУБД это нативные коннекторы на C++, остальные через ODBC. В случае с озёрами данных каждый источник целесообразно хранить в предназначенных для этого видах СУБД: реляционных, распределенных, колоночных и др. Далее объединение разных данных происходит уже на уровне многомерных кубов в ОЗУ средствами самой BI-платформы. Комбинация обработки данных «СУБД + оперативная память на BI» дает неплохой результат.
Часто разные источники одного многомерного OLAP-куба состоят из нескольких совершенно разных физических таблиц из разных баз данных. Например, исторические данные с длительной динамикой размещены в MPP-СУБД (что обеспечивает быстрое извлечение информации), а сценарии с эконометрическими расчетами прогнозов по этой динамике хранятся в реляционной СУБД (т.к. сценарии часто перечитываются и измененные данные требуется все время перезаписывать в БД маленькими порциями, а MPP плохо воспринимает micro-batch). В связи с этим для разных слоев данных приходится комбинировать разные СУБД, а итоговый аналитический срез данных объединяется уже на стороне BI в оперативной памяти.
ROLAP vs MOLAP vs HOLAP – что лучше для Data Lake
Успех решения такой задачи (сформировать из BI-платформы быстро работающий sql-запрос с большим количеством условий) состоит из двух составляющий. Первое – это правильный выбор СУБД. Для обработки разных видов данных важно и нужно использовать разные типы СУБД. Именно поэтому мы остаемся приверженцами ROLAP, сочетая его с частичным HOLAP или in-memory OLAP. Только такой вариант обработки информации (прямое обращение к исходным данным с их опциональным кэшированием в рамках каждой сессии), является самым оптимальным для связи «озеро данных + BI».
Конечно, намного проще для BI-платформы пойти по пути внутреннего хранения данных. Регулярно «перекладывать» 100% всей необходимой информации в адаптированные структуры данных (MOLAP), а также использовать только «удобную» для себя технологию СУБД или собственную систему полного кэширования данных. Таким путем сейчас идет ряд российских и международных BI-платформ. Но этот подход не всегда эффективно встраивается в уже существующую систему озера данных заказчика. Точнее, рядом создается второе озеро-дублер, и информация по заданному расписанию «клонируется» во второй водоем. Дополнительно, такой подход с озером-дублером совершенно не работает для потоковых данных или real-time BI.
Именно поэтому вы получите только первую половину успеха, если для конкретного слоя данных (горячие, теплые или холодные данные) правильно подберете тот или иной тип СУБД. Точнее, этот выбор лучше делать сразу, на этапе проектирования архитектуры озера данных, рассматривая его в сочетании с целевой BI-платформой, которую вы планируете использовать в будущем. Например, для создания фабрики данных и аналитического КХД мы рекомендуем использовать комбинацию линейки продуктов «Форсайт» и «Аренадата».
Большой гиперкуб сразу для нескольких СУБД
Важно отметить, что взаимодействие с таблицами БД через BI позволяет организовать гетерогенную взаимосвязь между разными типами СУБД (в том числе, когда эта гетерогенность самой СУБД не поддерживается или ее настройка/производительность сильно ограничена). Так как вся логика sql-запросов и финальная обработка данные обрабатываются в оперативной памяти BI сервера - то прямых связей или DB-link между СУБД не требуется. С точки зрения нескольких баз данных каждый шаг делается независимо.
Сначала платформа запросила из БД одну порцию данных, сформировали на ней измерение. Каждое измерение формируется независимо друг от друга, а значит, и СУБД могут быть разные. Далее отмеченные в SelectionSet элементы («отметка») через стратегию фильтрации используются в sql-запросах к данным. Результаты запросов с данными платформа тоже получает независимо (отдельно от каждой СУБД), и из них в оперативной памяти BI-сервера формирует итоговую многомерную матрицу куба. В том числе обрабатывает (агрегирует) пересечения точек-фактов.
Такой подход позволяет создавать в платформе «Форсайт» гетерогенные ROLAP-кубы разной степени сложности. Используя эту возможность, вы практически всегда сможете подключиться к любому озеру данных, не важно, какой технологический стек оно использует и какая структура хранения данных в нем организована.
Интересный момент при таком гетерогенном обращении BI-платформы к разным БД – это режим чтения и записи (корректировки) данных. Разные типы СУБД по-разному работают в этих режимах. Например, реляционная СУБД PostgreSQL быстро записывает небольшие порции измененных данных (micro-batch), но медленно считывает сложные аналитические запросы. Для MPP-СУБД Greenplum противоположная ситуация. За счет массово-параллельной архитектуры чтение данных выполняется с высокой скоростью, но обновление данных возможно только большим порциями (batch), что совершенно не подходит для режима ручной корректировок информации в отчетности или при расчете целого среза данных при помощи «продвинутой» аналитики (advanced analytics).
