Транзакционные данные в озере данных

У нас есть несколько исходных систем, отправляющих данные. В идеале мы должны собирать необработанные данные, поступающие из источников, и хранить их в озере данных. Затем мы должны обработать необработанные данные в структурированном формате. Теперь пользователи могут обновлять эти данные через внешнее приложение.

Я думаю о том, чтобы поместить rdbms поверх обработанных данных, а затем вывести журналы аудита из rdbms в озеро данных и объединить обработанные данные и журналы аудита, чтобы создать окончательное представление для отчетности. Или rdbms также можно использовать для аналитики.

Или мы можем перенести все данные, изначально хранившиеся в rdbms, запустить изменения в rdbms и извлечь данные из rdbms в озеро данных. Но нет особого смысла вводить озеро данных.

Пожалуйста, предложите.

Спасибо,


azure-data-lake sql-data-warehouse
person Lokesh Lal    schedule 27.06.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

ADLA НЕ ориентирована на потребителя, а это означает, что вы не будете подключать к ней интерфейсную систему. Если вопрос "что нам делать", я не уверен, что кто-то сможет ответить на него за вас, но, похоже, вы на правильном пути.

Что я могу сделать, так это рассказать вам, что мы делаем:

  1. Необработанные данные (файлы CSV или TXT) поступают в хранилище BLOB-объектов.
  2. Сценарии U-SQL извлекают эти данные и сохраняют их в таблицах Data Lake Analytics. [Кляксы могут быть удалены в этот момент].
  3. Мы выводим обработанные данные по мере необходимости в «расходуемые» источники, такие как СУБД. Есть несколько способов сделать это, но в настоящее время мы выводим текстовые файлы с разделителями по конвейеру в хранилище BLOB-объектов и используем Polybase для импорта в SQL Server. YMMV.

Для меня имеет смысл извлекать данные сначала в Data Lake, а затем в RDBMS.

person Joel Cochran    schedule 03.07.2018
comment
Спасибо Джоэл за вклад. - person Lokesh Lal; 11.07.2018