Данные концентраторов событий в хранилище данных SQL (Synapse)

мы пытаемся интегрировать данные концентратора событий (EH) (~ 200 МБ и 50 тыс. сообщений в минуту) в промежуточную область хранилища данных SQL (DW).

До сих пор мы пытались решить эту проблему, напрямую считывая данные EH с помощью функции Azure (AF) и выводя их в Synapse, но мы достигли максимального количества одновременных открытых сеансов DW (512 для‹ DWU500c). Мы также пытались увеличить maxBatchSize, который считывается из EH, чтобы уменьшить количество необходимых сеансов на стороне DW, но это, похоже, делает AF довольно нестабильным.

Сегодня я нашел это руководство в документации Microsoft, которая отделяет EH от AF с помощью функции захвата EH и сетки событий (EG) для запуска AF при каждой записи файла Blob. Итак, правильно ли я предполагаю, что это должно резко уменьшить максимальное количество одновременных открытых сеансов в DW, поскольку мы говорим о гораздо больших размерах пакетов, когда AF считывает захваченные файлы Blob, которые могут быть размером до 500 МБ?

Какие преимущества есть между одним решением и другим? Есть ли у вас какие-либо другие передовые методы для достижения этой цели?

Спасибо заранее!


azure-synapse azure-functions azure-eventhub azure-eventgrid azure-eventhub-capture
person Adrian Grassl    schedule 04.07.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Расходы

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

В прошлом они также пытались передать нам Фабрику данных для загрузки данных из Datalake в Synapse. Функции Azure смехотворно дешевле по сравнению с фабрикой данных.

Не принимайте предписанные Azure шаблоны за чистую монету, они отлично подходят для получения идей по интеграции, но я бы проверил стоимость и попытался оптимизировать.

Самый дешевый, о котором я могу думать:

Если у вас есть контроль над источником ваших данных, подумайте о том, чтобы вместо этого записать их в файлы csv / parque / orc в datalake.

Затем вы можете использовать функции Azure, запускаемые по таймеру, чтобы периодически загружать их в Synapse, используя КОПИРОВАТЬ В.

Будущее:

AFAI понимает направление архитектуры (я не работаю в Microsoft и не имею официальных знаний), они пытаются выдвинуть команду COPY как будущее загрузки Polybase (что является предпочтительным способом загрузки данных в Synapse / DW).

В общем, вы хотели бы покопаться / поспрашивать, чтобы узнать, какие подфункции чего-то в предварительном просмотре уже являются GA. Например. Сам Synapse находится в предварительной версии и, как ожидается, будет GA к EO 2020, но Synapse Pool - это GA. COPY INTO находится в предварительной версии, но поддержка загрузки файлов csv с помощью COPY INTO - это GA и так далее ...

Они также запустили Azure Stream Analytics, снова предварительная версия, но похоже на будущее потоковой передачи данных в Synapse или из EventHub между различными источниками и местами назначения, которые он поддерживает. Вот некоторые шаблоны решений.

HTH

person Kashyap    schedule 10.07.2020