Транзакционные данные в озере данных - PullRequest
0 голосов
/ 27 июня 2018

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

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

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

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

Спасибо

1 Ответ

0 голосов
/ 03 июля 2018

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

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

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

Для меня имеет смысл сначала поместить данные в озеро данных, а затем во второй СУБД.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...