Общие сведения о приеме данных в Azure Data Explorer

Прием данных включает загрузку данных в таблицу в кластере. Azure Data Explorer обеспечивает допустимость данных, преобразует форматы по мере необходимости и выполняет такие операции, как сопоставление схемы, организация, индексирование, кодирование и сжатие. После приема данные доступны для запроса.

Azure Data Explorer предлагает однократный прием или создание конвейера непрерывного приема с использованием потоковой передачи или приема по очереди. Чтобы определить, что именно вам подходит, см. статьи Одноразовый прием данных и Непрерывный прием данных.

Примечание

Данные сохраняются в хранилище в соответствии с заданной политикой хранения.

Одноразовый прием данных

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

Существует несколько способов одноразового приема данных. Используйте следующее дерево принятия решений, чтобы определить наиболее подходящий вариант для вашего варианта использования:

"Схема, которая выступает в качестве дерева принятия решений для одноразового приема. При приеме исторических данных следует следовать указаниям, приведенным в документе Прием исторических данных. Если вы не используете исторические данные и используете поддерживаемый формат данных, рекомендуется использовать интерфейс Получения данных. Если данные имеют неподдерживаемый формат, можно интегрировать с Фабрика данных Azure или написать собственный пользовательский код с помощью клиентских библиотек Kusto. Статьи с рекомендациями по каждому из этих вариантов связаны непосредственно с этой блок-схемой".

Дополнительные сведения см. в соответствующей документации:

Выноска	Соответствующая документация
	Ознакомьтесь с форматами данных, поддерживаемыми azure Data Explorer для приема.
	См. форматы файлов, поддерживаемые для конвейеров Фабрика данных Azure.
	Сведения об импорте данных из существующей системы хранения см. в статье Прием исторических данных в Azure Data Explorer.
	В пользовательском веб-интерфейсе Azure Data Explorer можно получить данные из локального файла, Amazon S3 или службы хранилища Azure.
	Сведения об интеграции с Фабрика данных Azure см. в статье Копирование данных в Azure Data Explorer с помощью Фабрика данных Azure.
	Клиентские библиотеки Kusto доступны для C#, Python, Java, JavaScript, TypeScript и Go. Вы можете написать код для управления данными, а затем использовать библиотеку Приема Kusto для приема данных в таблицу azure Data Explorer. Данные должны быть в одном из поддерживаемых форматов перед приемом.

Непрерывный прием данных

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

Непрерывный прием данных включает настройку конвейера приема с потоковой передачей или приемом в очереди.

• Прием потоковой передачи. Этот метод обеспечивает задержку почти в реальном времени для небольших наборов данных на таблицу. Данные помечаются микропакетами из источника потоковой передачи, первоначально помещаются в хранилище строк, а затем передаются в экстенты хранилища столбцов. Дополнительные сведения см. в разделе Настройка приема потоковой передачи.

• Прием в очереди. Этот метод оптимизирован для высокой пропускной способности приема. Данные пакетируются на основе свойств приема, с небольшими пакетами, а затем объединяются и оптимизируются для быстрых результатов запросов. По умолчанию максимальные значения в очереди — 5 минут, 1000 элементов или общий размер 1 ГБ. Максимальный размер данных для команды приема в очереди составляет 6 ГБ. Этот метод использует механизмы повторных попыток для устранения временных сбоев и следует семантике обмена сообщениями "по крайней мере один раз", чтобы гарантировать, что сообщения не будут потеряны в процессе. Дополнительные сведения о приеме в очереди см. в статье Политика пакетной обработки приема.

Примечание

В большинстве сценариев рекомендуется использовать прием в очереди, так как это более производительный вариант.

Существует несколько способов настройки непрерывного приема данных. Используйте следующее дерево принятия решений, чтобы определить наиболее подходящий вариант для вашего варианта использования:

"Блок-схема для принятия решений о непрерывном приеме. Сначала определите тип и расположение данных. Для данных событий можно создать подключение к данным Центров событий или принимать данные с помощью Apache Kafka. Для данных Интернета вещей можно создать подключение к данным Центров Интернета вещей. Для данных в службе хранилища Azure можно создать подключение к данным Сетки событий. Для данных, хранящихся в других местах, проверка обзор соединителей, чтобы узнать, есть ли выделенный соединитель, который может соответствовать вашему варианту использования. Если это так, следуйте указаниям по использованию этого соединителя. В противном случае напишите пользовательский код с помощью клиентских библиотек Kusto. Статьи с рекомендациями по каждому из этих вариантов связаны непосредственно с этой блок-схемой".

Дополнительные сведения см. в соответствующей документации:

Выноска	Соответствующая документация
	Список соединителей см. в статье Общие сведения о соединителях.
	Создайте подключение к данным Центров событий. Интеграция с Центрами событий предоставляет такие службы, как регулирование, повторные попытки, мониторинг и оповещения.
	Прием данных из Apache Kafka, распределенной платформы потоковой передачи для создания конвейеров потоковой передачи данных в режиме реального времени.
	Создайте подключение к данным Центр Интернета вещей. Интеграция с Центрами Интернета вещей предоставляет такие службы, как регулирование, повторные попытки, мониторинг и оповещения.
	Создайте подключение к данным Сетки событий. Интеграция с Сеткой событий предоставляет такие службы, как регулирование, повторные попытки, мониторинг и оповещения.
	Ознакомьтесь с руководством по соответствующему соединителю, например Apache Spark, Apache Kafka, Azure Cosmos DB, Fluent Bit, Logstash, Open Telemetry, Power Automate, Splunk и т. д. Дополнительные сведения см. в статье Общие сведения о соединителях.
	Клиентские библиотеки Kusto доступны для C#, Python, Java, JavaScript, TypeScript и Go. Вы можете написать код для управления данными, а затем использовать библиотеку Приема Kusto для приема данных в таблицу azure Data Explorer. Данные должны быть в одном из поддерживаемых форматов перед приемом.

Примечание

Прием потоковой передачи поддерживается не для всех методов приема. Сведения о поддержке проверка документации по конкретному методу приема.

Прямой прием с помощью команд управления

Azure Data Explorer предлагает следующие команды управления приемом, которые будут принимать данные непосредственно в кластер, а не использовать службу управления данными. Они должны использоваться только для исследования и создания прототипов, а не в рабочих или больших объемах сценариев.

• Встроенный прием. Встроенная команда .ingest содержит данные, которые необходимо принять, являясь частью самого текста команды. Этот метод предназначен для импровизированного тестирования.
• Прием из запроса. Команды .set, .append, .set-or-append или .set-or-replace косвенно указывают данные для приема в качестве результатов запроса или команды.
• Прием из хранилища. Команда .ingest into получает данные для приема из внешнего хранилища, например Хранилище BLOB-объектов Azure, доступные кластером и указывающие на команду .

Сравнение методов приема

В следующей таблице сравниваются методы приема main:

Название метода приема	Тип данных	Максимальный размер файла	Потоковая передача, постановка в очередь, прямая	Самые распространенные сценарии	Рекомендации
Соединитель Apache Spark	Все форматы, поддерживаемые средой Spark	Без ограничений	Поставлено в очередь	Существующий конвейер, предварительная обработка в Spark перед приемом, быстрый способ создания безопасного конвейера потоковой передачи (Spark) из различных источников, поддерживаемых средой Spark.	Учитывайте стоимость кластера Spark. Если требуется функция пакетной записи, сравните возможности с предоставляемыми подключением к данным Data Explorer для службы "Сетка событий". Если требуется потоковая передача Spark, сравните возможности с предоставляемым подключением к данным для концентратора событий.
Фабрика данных Azure (ADF)	Поддерживаемые форматы данных	Без ограничений. Наследует ограничения ADF.	Триггер ADF в очереди или для каждого триггера ADF	Поддерживает неподдерживаемые форматы, такие как Excel и XML, и может копировать большие файлы из более чем 90 источников из perm в облако.	Для приема данных с помощью этого метода требуется относительно больше времени. ADF передает все данные в память, а затем начинает прием.
Сетка событий	Поддерживаемые форматы данных	1 ГБ без сжатия	Поставлено в очередь	Непрерывный прием из службы хранилища Azure, внешние данные в службе хранилища Azure	Прием можно активировать с помощью действий по переименованию или созданию BLOB-объектов
Концентратор событий	Поддерживаемые форматы данных	Н/Д	Постановка в очередь, потоковая передача	Сообщения, события
Взаимодействие с данными	*SV, JSON	1 ГБ без сжатия	Постановка в очередь или прямой прием	Однократный прием, создание схемы таблицы, определение непрерывного приема с помощью Сетки событий, массовый прием с помощью контейнера (до 5000 BLOB-объектов; без ограничений для приема данных за прошлые периоды)
Центр Интернета вещей	Поддерживаемые форматы данных	Н/Д	Постановка в очередь, потоковая передача	Сообщения, события, свойства Интернета вещей
Соединитель Kafka	Avro, ApacheAvro, JSON, CSV, Parquet и ORC	Без ограничений. Наследует ограничения Java.	Постановка в очередь, потоковая передача	Существующий конвейер, большой объем потребления из источника.	Предпочтение может определяться существующим использованием нескольких производителей или потребительских услуг или требуемым уровнем управления службами.
Клиентские библиотеки Kusto	Поддерживаемые форматы данных	1 ГБ без сжатия	Очередь, потоковая передача, прямая передача	Написание собственного кода в соответствии с потребностями организации	Программный прием оптимизирован для снижения затрат на прием (COG) за счет минимизации транзакций хранилища во время и после процесса приема.
LightIngest	Поддерживаемые форматы данных	1 ГБ без сжатия	Постановка в очередь или прямой прием	Перенос данных, исторические данные с скорректированными метками времени приема, массовый прием	С учетом регистра и пробелов
Logic Apps	Поддерживаемые форматы данных	1 ГБ без сжатия	Поставлено в очередь	Используется для автоматизации конвейеров.
LogStash	JSON	Без ограничений. Наследует ограничения Java.	Поставлено в очередь	Существующий конвейер, используйте зрелый, открытый код характер Logstash для большого объема потребления из входных данных.	Предпочтение может определяться существующим использованием нескольких производителей или потребительских услуг или требуемым уровнем управления службами.
Power Automate	Поддерживаемые форматы данных	1 ГБ без сжатия	Поставлено в очередь	Команды приема как часть потока. Используется для автоматизации конвейеров.

Сведения о других соединителях см. в статье Общие сведения о соединителях.

Разрешения

В следующем списке описаны разрешения, необходимые для различных сценариев приема.

• Для создания новой таблицы требуются по крайней мере разрешения пользователя базы данных.
• Чтобы принимать данные в существующую таблицу, не изменяя ее схему, требуются по крайней мере разрешения Ingestor базы данных.
• Чтобы изменить схему существующей таблицы, требуются по крайней мере разрешения Администратор таблицы или Администратор базы данных.

Дополнительные сведения см. в статье Управление доступом на основе ролей Kusto.

Процесс приема

В следующих шагах описывается общий процесс приема.

1. Задать политику пакетной обработки (необязательно): данные пакетируются на основе политики пакетной обработки приема. Инструкции см. в статье Оптимизация пропускной способности.

2. Задать политику хранения (необязательно): если политика хранения базы данных не подходит для ваших потребностей, переопределите ее на уровне таблицы. Дополнительные сведения см. в статье Retention policy (Политика хранения).

3. Создание таблицы. Если вы используете интерфейс получения данных, можно создать таблицу как часть потока приема. В противном случае создайте таблицу перед приемом в пользовательском веб-интерфейсе Azure Data Explorer или с помощью команды .create table.

4. Создание сопоставления схемы. Сопоставления схем помогают привязать поля исходных данных к столбцам целевой таблицы. Поддерживаются различные типы сопоставлений, включая форматы, ориентированные на строки, такие как CSV, JSON и AVRO, и форматы, ориентированные на столбцы, такие как Parquet. В большинстве методов сопоставления также можно предварительно создать в таблице.

5. Задать политику обновления (необязательно): некоторые форматы данных, такие как Parquet, JSON и Avro, позволяют выполнять простые преобразования времени приема. Для более сложной обработки во время приема используйте политику обновления. Эта политика автоматически выполняет извлечение и преобразование для полученных данных в исходной таблице, а затем принимает измененные данные в одну или несколько целевых таблиц.

6. Прием данных. Используйте предпочтительное средство приема, соединитель или метод для переноса данных.

См. также

• Общие сведения о соединителях
• Поддерживаемые форматы данных
• Поддерживаемые свойства приема
• Обзор политик