Подключение к данным Сетки событий
Прием Сетки событий — это конвейер, который прослушивает службу хранилища Azure и информирует Azure Data Explorer о необходимости извлечения информации при возникновении событий, на которые создана подписка. Azure Data Explorer предлагает возможность непрерывного приема данных из службы хранилища Azure (хранилище BLOB-объектов и ADLSv2) с подпиской на службу Сетка событий Azure для уведомлений о создании или переименовании BLOB-объектов и потоковой передачи таких уведомлений в Azure Data Explorer через Центр событий Azure.
Конвейер приема данных Центра событий проходит через несколько этапов. Вы создадите целевую таблицу в Azure Data Explorer, в которую будут приниматься данные в определенном формате. Затем вы создадите подключение к данным службы "Сетка событий Azure" в Azure Data Explorer. Для подключения к данным в Сетке событий необходимо указать сведения о маршрутизации событий, например таблицу для отправки данных и сопоставление таблиц. Вам также нужно указать свойства приема, которые описывают данные для приема, целевую таблицу и сопоставление. Вы можете создать пример данных и отправить BLOB-объекты или переименовать их, чтобы проверить подключение. Удалите BLOB-объекты после приема.
Приемом данных в Сетке событий можно управлять с помощью портала Azure, мастера приема, программно на C# или Python либо с помощью шаблона Azure Resource Manager.
Общие сведения о приеме данных в обозревателе данных Azure см. в разделе Обзор приема данных Azure Data Explorer.
Механизмы проверки подлинности подключения к данным сетки событий
Подключение к данным на основе управляемых удостоверений (рекомендуется): используйте его для максимальной защищенности при подключении к источникам данных. Оно обеспечивает полный контроль над возможностью получения данных из источника данных. Для установки подключения к данным сетки событий с помощью управляемого удостоверения требуются следующие действия.
- Добавьте управляемое удостоверение в кластер.
- Предоставьте разрешения управляемому удостоверению в источнике данных. Чтобы получить данные из служба хранилища Azure, управляемое удостоверение должно иметь по крайней мере разрешения чтения данных BLOB-объектов хранилища в учетной записи служба хранилища Azure.
- Предоставьте разрешения управляемому удостоверению в концентраторе событий. Чтобы получить уведомления BLOB-объектов из концентратора событий, управляемое удостоверение должно иметь разрешения Центры событий Azure приемника данных на Центры событий Azure.
- Задайте политику управляемого удостоверения в целевых базах данных.
- Создайте подключение к данным с помощью проверки подлинности управляемого удостоверения для получения данных.
Внимание
- Если разрешения управляемого удостоверения удаляются из источника данных, подключение к данным больше не будет работать и не сможет получить данные из источника данных.
- Если локальная проверка подлинности отключена в существующем пространстве имен Центров событий, в котором передаются уведомления BLOB-объектов, необходимо использовать проверку подлинности управляемого удостоверения для подключения к данным и правильно настроить ресурсы. Дополнительные сведения см. в статье "Известные проблемы сетки событий".
Подключение к данным на основе ключей: если для подключения к данным не указана проверка подлинности управляемого удостоверения, подключение по умолчанию используется для проверки подлинности на основе ключей. Подключения на основе ключей получают данные с помощью строки подключения к ресурсу, например строки подключения Центров событий Azure. Azure Data Explorer получает строка подключения ресурса для указанного ресурса и безопасно сохраняет его. Затем строка подключения используется для получения данных из источника данных.
Внимание
Если ключ поворачивается, подключение к данным больше не будет работать и не сможет получить данные из источника данных. Чтобы устранить проблему, обновите или повторно создайте подключение к данным.
Формат данных
- См. раздел Поддерживаемые форматы.
- См. раздел Поддерживаемые сжатия.
Исходный размер несжатых данных должен быть частью метаданных большого двоичного объекта, иначе Azure Data Explorer оценит его. Максимальный размер файла без сжатия составляет 6 ГБ.
Примечание.
Подписку на уведомления в службе "Сетка событий" можно настроить в учетных записях хранения Azure для
BlobStorage
,StorageV2
или Data Lake Storage 2-го поколения.
Свойства приема
Вы можете указать свойства приема данных большого двоичного объекта с помощью метаданных большого двоичного объекта. Можно задать следующие свойства:
Свойство | Description |
---|---|
rawSizeBytes |
Размер необработанных (несжатых) данных. Для Avro/ORC/Parquet это размер до применения сжатия для конкретного формата. Укажите исходный размер данных, задав для этого свойства размер несжатых данных в байтах. |
kustoDatabase |
Имя целевой базы данных с учетом регистра. По умолчанию данные принимаются в целевую базу данных, связанную с подключением к данным. Это свойство используется для переопределения базы данных по умолчанию и отправки данных в другую базу данных. Для этого необходимо сначала настроить подключение в виде подключения к нескольким базам данных. |
kustoTable |
Имя существующей целевой таблицы с учетом регистра. Переопределяет набор Table на панели Data Connection . |
kustoDataFormat |
Формат данных. Переопределяет набор Data format на панели Data Connection . |
kustoIngestionMappingReference |
Имя существующего сопоставления приема, которое будет использоваться. Переопределяет набор Column mapping на панели Data Connection . |
kustoIgnoreFirstRecord |
Если задано значение true , Kusto игнорирует первую строку большого двоичного объекта. Для игнорирования заголовков используйте данные в табличном формате (CSV, TSV или аналогичные). |
kustoExtentTags |
Строка, представляющая теги, которые будут присоединены к результирующему экстенту. |
kustoCreationTime |
Переопределяет время создания экстента для большого двоичного объекта в формате строки ISO 8601. Используется для выполнения задним числом. |
Маршрутизация событий
При создании подключения к данным в кластере вы задаете маршрутизацию для отправки принимаемых данных. По умолчанию используется маршрутизация к целевой таблице, указанной в строке подключения, которая связана с целевой базой данных. Маршрутизация по умолчанию для данных также называется статической маршрутизацией. Вы также можете указать альтернативную маршрутизацию для данных с помощью свойств данных событий.
Маршрутизация данных событий в альтернативную базу данных
По умолчанию маршрутизация данных в альтернативную базу данных отключена. Чтобы отправить данные в другую базу данных, необходимо сначала настроить подключение в виде подключения к нескольким базам данных. Это можно сделать в портал Azure, C#, Python или шаблоне ARM. Пользователь, группа, субъект-служба или управляемое удостоверение, используемые для поддержки маршрутизации базы данных, должны иметь по крайней мере роль участника и разрешения на запись в кластер. Дополнительные сведения см. в статье "Создание подключения к данным сетки событий" для Azure Data Explorer.
Чтобы указать альтернативную базу данных, задайте свойство приема базы данных.
Предупреждение
Указание альтернативной базы данных без настройки подключения в виде подключения к данным для нескольких баз данных приведет к сбою приема.
Маршрутизация данных событий в альтернативную таблицу
При настройке подключения хранилища BLOB-объектов к кластеру Azure Data Explorer укажите свойства целевой таблицы:
- Имя таблицы
- формат данных;
- mapping
Вы также можете указать свойства целевой таблицы для каждого BLOB-объекта, используя его метаданные. Данные будут динамически маршрутизироваться, как задано свойствами приема.
В следующем примере показано, как задать свойства приема для метаданных BLOB-объекта перед их отправкой. BLOB-объекты направляются в разные таблицы.
Кроме того, можно указать целевую базу данных. Подключение к данным в Сетке событий создается в контексте определенной базы данных. Поэтому эта база данных представляет маршрутизацию базы данных по умолчанию для подключения к данным. Чтобы отправить данные в другую базу данных, задайте свойство приема KustoDatabase и настройте подключение к данным в виде подключения к нескольким базам данных. По умолчанию маршрутизация данных в другую базу данных отключена (запрещена). Задание свойства приема для базы данных, отличающейся от базы данных подключения к данным, без разрешения маршрутизации данных к нескольким базам данных (настройка подключения в виде подключения данных к нескольких базам данных) приведет к сбою приема.
Дополнительные сведения см. в разделе Отправка BLOB-объектов.
var container = new BlobContainerClient("<storageAccountConnectionString>", "<containerName>");
await container.CreateIfNotExistsAsync();
var blob = container.GetBlobClient("<blobName>");
// Blob is dynamically routed to table `Events`, ingested using `EventsMapping` data mapping
await blob.SetMetadataAsync(
new Dictionary<string, string>
{
{ "rawSizeBytes", "4096" }, // the uncompressed size is 4096 bytes
{ "kustoTable", "Events" },
{ "kustoDataFormat", "json" },
{ "kustoIngestionMappingReference", "EventsMapping" },
{ "kustoDatabase", "AnotherDB" }
}
);
await blob.UploadAsync(BinaryData.FromString(File.ReadAllText("<filePath>")));
отправка больших двоичных объектов;
Вы можете создать BLOB-объект из локального файла, задать свойства приема в метаданных BLOB-объекта и передать его. Примеры см. в разделе "Использование подключения к данным сетки событий".
Примечание.
- Мы настоятельно рекомендуем использовать для
BlockBlob
создания данных, так как использованиеAppendBlob
может привести к неожиданному поведению. - Использование пакета SDK хранилища Azure Data Lake 2-го поколения требуется использовать
CreateFile
для отправки файлов иFlush
в конце с параметром закрытия.true
Подробный пример правильного использования пакета SDK Data Lake 2-го поколения см. в разделе "Использование подключения к данным сетки событий". - Активация приема после
CopyBlob
операции не поддерживается для учетных записей хранения, для которых включена функция иерархического пространства имен. - Если конечная точка концентратора событий не подтверждает получение события, служба "Сетка событий Azure" активирует механизм повтора. В случае сбоя повторной попытки доставки Сетка событий может доставить недоставленные события в учетную запись хранения, используя процесс перемещения в очередь. Дополнительные сведения см. в разделе Доставка и повторные попытки доставки сообщений сетки событий.
Переименование BLOB-объектов
При использовании ADLS 2-го поколения можно переименовать BLOB-объект, чтобы активировать прием BLOB-объектов в Azure Data Explorer. Например, см. раздел "Переименовать большие двоичные объекты".
Примечание.
- Переименование каталогов возможно в ADLSv2, но оно не запускает события переименованные большие двоичные объекты и прием больших двоичных объектов внутри каталога. Чтобы получить большие двоичные объекты после переименования, переименуйте непосредственно нужные большие двоичные объекты.
- Если вы определили фильтры для отслеживания определенных объектов при создании подключения к данным или при создании ресурсов Сетки событий вручную, эти фильтры применяются к пути к конечному файлу.
Удаление BLOB-объектов с помощью жизненного цикла хранилища
Azure Data Explorer не удаляет BLOB-объекты после приема. Для управления удалением BLOB-объектов используйте жизненный цикл хранилища BLOB-объектов Azure. Рекомендуется хранить BLOB-объекты от трех до пяти дней.
Известные проблемы с Сеткой событий
Работа без локальной проверки подлинности
Если локальная проверка подлинности отключена в пространстве имен Центров событий, которое содержит концентратор событий, используемый для потоковых уведомлений, выполните следующие действия, чтобы обеспечить правильность потоковой передачи данных из хранилища в концентратор событий с помощью управляемых удостоверений:
- Назначьте управляемое удостоверение, назначаемое системой, системной статье сетки событий учетной записи хранения. Дополнительные сведения см. в разделе "Включение управляемого удостоверения" для системных разделов.
- Предоставьте разрешения отправителя управляемого удостоверения, назначив ему роль Центры событий Azure отправителя данных в концентраторе событий. Дополнительные сведения см. в статье "Добавление удостоверения в роли Azure" в местах назначения.
- Убедитесь, что подписка "Сетка событий" использует управляемое удостоверение для доставки событий. Дополнительные сведения см. в разделе "Создание подписок на события" с использованием удостоверения.
Кроме того, настройте подключение к данным сетки событий для использования проверки подлинности управляемого удостоверения, чтобы Azure Data Explorer могли получать уведомления из концентратора событий.
Настройка приема сетки событий для файлов, экспортированных из Azure Data Explorer
При использовании Azure Data Explorer для экспорта файлов, используемых для приема в сетке событий, обратите внимание на следующее:
- Уведомления в службе "Сетка событий" не срабатывают, если строка подключения, указанная для команды экспорта, или строка подключения, предоставленная внешней таблице, является строкой подключения в формате ADLS 2-го поколения (например,
abfss://filesystem@accountname.dfs.core.windows.net
), но в учетной записи хранения не включено иерархическое пространство имен. - Если в учетной записи не включено иерархическое пространство имен, для строки подключения нужно использовать формат Хранилища BLOB-объектов (например,
https://accountname.blob.core.windows.net
). Экспорт работает должным образом даже при использовании строки подключения ADLS 2-го поколения, но уведомления не будут срабатывать, а прием Сетки событий не будет работать.
Эмуляция событий хранилища из пользовательских компонентов
При использовании пользовательских компонентов для эмулирования событий служба хранилища Azure события эмулированные события должны строго соответствовать схеме событий Хранилище BLOB-объектов Azure, так как Azure Data Explorer отбрасывает события, которые не могут быть проанализированы пакетом SDK сетки событий.