Создание хранилища данных в реальном времени

Question

Я делаю личный проект, который состоит из создания полной архитектуры хранилища данных (DWH). В этом случае в качестве инструмента анализа ETL и BI я решил использовать Pentaho; он обладает множеством функциональных возможностей, позволяя создавать легкие панели, полные процессы интеллектуального анализа данных и кубы OLAP.

Я читал, что хранилище данных должно быть реляционной базой данных и понимать это. Я не понимаю, как достичь почти реального времени или полностью DWH в реальном времени. Я читал о стратегиях выталкивания и вытягивания, но мои выводы заключаются в следующем:

• Выбор СУБД не важен для создания DWH реального времени. Я имею в виду, что это возможно с MySQL, SQL Server, Oracle или любым другим. Поскольку я делаю это как личный проект, я выбираю MySQL.
• Ключевым фактором является частота планирования заданий, и это задача планировщика. Правильно ли это предположение? Я имею в виду, что ключом к созданию DWH в реальном времени является создание рабочих мест каждую секунду для каждого процесса ETL?

Если я ошибаюсь, можете ли вы мне помочь, чтобы понять это? И тогда, каким образом можно создать DWH реального времени? Является ли любой планировщик с открытым исходным кодом, который позволяет это? И какой-то не планировщик с открытым исходным кодом, который позволяет это?

Я очень смущен, потому что в некоторых ссылках говорится, что это невозможно, другие возможны.

Answer 1

Определение

Очень интересный вопрос. Прежде всего, следует определить, как должно быть «реальное время в реальном времени». В реальном времени на самом деле очень низкая задержка для входящих данных, но требуется хорошая архитектура в отправляющих системах, возможно, очередь событий или очередь сообщений и хорошая инфраструктура на принимающей стороне. Обычно это связано с каким-то слушателем и , толкающим из дебиллинговых систем.

Ближайшее время будет следующим «нижним» уровнем. Если мы говорим, что почти в реальном времени будет около 5 минут задержки макс, ваш подход может работать. Так, например, здесь вы могли бы вытащить каждую минуту или около того. Но имейте в виду, что вам нужна какая-то высокопроизводительная проверка, доступны ли новые данные и которые можно получить. Если эта проверка и тяга займет больше минуты, становится сложнее идти в ногу с данными. Действительно зависит от объема.

Realtime

Как я уже говорил, аналитика в реальном времени требует в лучшем случае очереди сообщений или автобус службы некоторые рабочие места твои могли бы подключиться и «слушать» для новых данных. Если новый новый пакет данных будет перенесен в конвейер, размер его, вероятно, будет очень небольшим, и его можно будет обрабатывать очень быстро.

Если для слушателей нет инфраструктуры, вам нужно приблизиться к реальному времени.

Near-режиме реального времени

Это та часть, где вы должны разработать более. Вы должны убедиться, что получите реальные небольшие пакеты данных, которые обычно будут своего рода дельта. Это можно сделать с помощью триггеров, если у вас есть доступ к базе данных. В противном случае вам придется тянуть время от времени, в то время как ваш «один раз», вероятно, будет очень частым.

Это может быть сделано в Linux, например, с помощью простого сопряжения или Windows с планированием событий. Просто имейте в виду, что время загрузки и обработки не должно превышать временное окно, которое вы получили до начала следующего задания.

Database

В конце концов, когда вы определили, что вы хотите достичь, и иметь общее представление о том, как реализовать дельту нагрузки или слушатель, вы правы - вы могли бы взять реляционную базу данных. Если вы заинтересованы в производительности и моделируете эту часть как Star Schema, вы также можете изучить системы на основе столбцов или базы данных на основе столбцов, такие как Apache Cassandra.

Планирование

Кроме того, для работы по расписанию, вы могли бы начать с стандартным средствами планирования Linux или Windows. Если вы код в Java, вы можете использовать позже нечто вроде кварца. Но это будет иметь место только для почти реального времени. В реальном времени требуется другая архитектура, как я объяснил выше.