Azure 数据资源管理器数据引入概述

数据引入是用于将数据记录从一个或多个源加载到 Azure 数据资源管理器中的表的过程。 引入后,数据即可用于查询。

下图显示了用于在 Azure 数据资源管理器中运行的端到端流,以及不同的引入方法。

数据引入和管理方案的概览。

Azure 数据资源管理器数据管理服务负责数据引入,并执行以下过程:

Azure 数据资源管理器从外部源拉取数据,并从挂起的 Azure 队列读取请求。 将数据分批或流式传输到数据管理器。 批数据流入相同的数据库和表中,以优化引入吞吐量。 Azure 数据资源管理器验证初始数据并在必要时转换数据格式。 进一步的数据操作包括匹配架构、组织、编制索引、编码和压缩数据。 数据根据设置的保留策略保留在存储中。 然后,数据管理器将数据引入提交到引擎,在那里数据可供查询。

支持的数据格式、属性和权限

批量引入与流式引入

  • 批量引入执行数据批处理,并针对高引入吞吐量进行优化。 此方法是引入的首选且性能最高。 数据根据引入属性进行批处理。 然后合并小批次的数据,并针对快速查询结果进行优化。 可以在数据库或表上设置引入批处理策略。 默认情况下,最大批处理值为 5 分钟、1000 项,或者 1 GB 的总大小。 批量引入命令的数据大小限制为 6 GB。

  • 流式引入是来自流式处理源的正在进行的数据引入。 流式引入针对每个表的小型数据允许近乎实时的延迟。 数据最初引入到行存储,然后移动到列存储盘区。 可以使用 Azure 数据资源管理器客户端库或某个受支持的数据管道来完成流式引入。

引入方法和工具

Azure 数据资源管理器支持多种引入方法,每种方法都有自己的适用场景。 这些方法包括引入工具、各种服务的连接器和插件、托管管道、使用 SDK 的编程引入,以及直接引入。

使用托管管道的引入

对于希望通过外部服务进行管理(限制、重试、监视器、警报等)的组织而言,使用连接器可能是最合适的解决方案。 排队引入适合大数据量。 Azure 数据资源管理器支持以下 Azure Pipelines:

使用连接器和插件的引入

使用 SDK 的编程引入

Azure 数据资源管理器提供可用于查询和数据引入的 SDK。 通过在引入期间和之后尽量减少存储事务,编程引入得到优化,可降低引入成本 (COG)。

可用的 SDK 和开放源代码项目

工具

  • 引入向导:可让你创建和调整各种源类型的表,从而快速引入数据。 引入向导会根据 Azure 数据资源管理器中的数据源自动推荐表和映射结构。 该向导可用于一次性引入,或通过事件网格在引入数据的容器上定义持续引入。

  • LightIngest :用于将即席数据引入 Azure 数据资源管理器的命令行实用工具。 该实用工具可以从本地文件夹或 Azure Blob 存储容器提取源数据。

引入控制命令

使用命令将数据直接引入引擎。 此方法会绕过数据管理的服务,因此仅应用于探索和原型设计。 不要在生产或大容量方案中使用此方法。

  • 内联引入:向引擎发送控制命令 .ingest inline,要引入的数据是命令文本自身的一部分。 此方法用于临时测试目的。

  • 从查询引入:向引擎发送控制命令 .set、.append、.set-or-append 或 .set-or-replace,将数据间接指定为查询或命令的结果。

  • 从存储引入(拉取) :向引擎发送控制命令 .ingest into,数据存储在某个外部存储(例如 Azure Blob 存储)中,可供引擎访问,命令也可以指向它。

比较引入方法和工具

引入名称 数据类型 文件大小上限 流式引入,批量引入,直接引入 最常用场景 注意事项
引入向导 *sv, JSON 1 GB,解压缩(参见备注) 通过直接引入将文件批处理到容器、本地文件和 blob 一次性、创建表架构、使用事件网格定义持续引入、对容器进行批量引入(最多 5,000 个 blob;使用历史引入时无限制)
LightIngest 支持所有支持 1 GB,解压缩(参见备注) 通过 DM 批量引入或直接引入引擎 数据迁移,含已调整引入时间戳的历史数据,批量引入(无大小限制) 区分大小写,区分有无空格
ADX Kafka Avro、ApacheAvro、JSON、CSV、Parquet 和 ORC 不受限制。 继承 Java 限制。 批量引入,流式引入 现有管道,源产生的消耗很大。 首选项可能取决于已使用的“多个生成者/使用者”服务,或者服务托管方式。
ADX 到 Apache Spark Spark 环境支持的每一种格式 无限制 批处理 在引入现有管道前在 Spark 上进行预处理,是从 Spark 环境支持的各种源创建安全的 (Spark) 流式处理管道的快速方法。 考虑 Spark 群集的成本。 对于批量写入,请与适用于事件网格的 Azure 数据资源管理器数据连接进行比较。 对于 Spark 流式处理,请与适用于事件中心的数据连接进行比较。
LogStash JSON 不受限制。 继承 Java 限制。 连接器的输入是 Logstash 事件,连接器的输出是使用批处理引入的 Kusto。 现有管道利用 Logstash 的成熟开源特性,输入中消耗很大。 首选项可能取决于已使用的“多个生成者/使用者”服务,或者服务托管方式。
Azure 数据工厂 (ADF) 支持的数据格式 无限制 *(每个 ADF 限制) 批量引入或者按 ADF 触发器引入 支持通常不受支持的格式及大型文件,可从 90 多个源进行复制,可从本地复制到云 在引入数据之前,此方法的用时相对较长。 ADF 将所有数据上传到内存,然后开始引入。
IoT 中心 支持的数据格式 空值 批量引入,流式引入 IoT 消息,IoT 事件,IoT 属性
事件中心 支持的数据格式 空值 批量引入,流式引入 消息,事件
事件网格 支持的数据格式 1 GB,解压缩 批处理 从 Azure 存储持续引入,Azure 存储中的外部数据 可通过 Blob 重命名或 Blob 创建操作触发引入
.NET SDK 支持所有格式 1 GB,解压缩(参见备注) 批量引入,流式引入,直接引入 根据组织需求编写自己的代码
Python 支持所有格式 1 GB,解压缩(参见备注) 批量引入,流式引入,直接引入 根据组织需求编写自己的代码
Node.js 支持所有格式 1 GB,解压缩(参见备注) 批量引入,流式引入,直接引入 根据组织需求编写自己的代码
Java 支持所有格式 1 GB,解压缩(参见备注) 批量引入,流式引入,直接引入 根据组织需求编写自己的代码
REST 支持所有格式 1 GB,解压缩(参见备注) 批量引入,流式引入,直接引入 根据组织需求编写自己的代码
Go 支持所有格式 1 GB,解压缩(参见备注) 批量引入,流式引入,直接引入 根据组织需求编写自己的代码

注意

在上表中进行引用时,引入支持的最大文件大小为 6 GB。 建议引入 100 MB 到 1 GB 的文件。

引入过程

根据需要选择最适合的引入方法后,执行以下步骤:

  1. 设置批处理策略(可选)

    批处理管理器根据引入批处理策略对引入数据进行批处理。 在“引入”之前定义批处理策略。 请参阅引入最佳做法 - 优化吞吐量。 批处理策略更改最多可能需要 5 分钟才能生效。 该策略根据三个因素设置批限制:自创建批处理以来经过的时间、项目累积数量 (blob) 或总的批大小。 默认情况下,设置为 5 分钟/1000 个 Blob/1 GB,首次达到限制时生效。 因此,将示例数据排入队列以用于引入时,通常会有 5 分钟的延迟。

  2. 设置保留策略

    将数据引入 Azure 数据资源管理器中的表必须遵循该表的有效保留策略。 除非在表上显式设置,否则有效保留策略派生自数据库的保留策略。 热保留是群集大小和保留策略的功能。 引入超过可用空间的数据将强制首先进入的数据进行冷保留。

    确保数据库的保留策略符合你的需求。 如果并非如此,请在表级别显式重写它。 有关详细信息,请参阅保留策略

  3. 创建表

    为了引入数据,需要事先创建一个表。 使用以下选项之一:

    注意

    如果记录不完整或者无法将字段解析为所需的数据类型,则将使用 NULL 值填充相应的表列。

  4. 创建架构映射

    架构映射有助于将源数据字段绑定到目标表列。 映射允许根据定义的属性,将不同源中的数据引入同一个表。 支持不同类型的映射,行导向(CSV、JSON 和 AVRO)和列导向 (Parquet)。 在大部分方法中,可以在表上预先创建映射并从引入命令参数进行引用。

  5. 设置更新策略(可选)

    一些数据格式映射(Parquet、JSON 和 Avro)支持简单且有用的引入时间转换。 如果方案需要在引入时进行更复杂的处理,请调整更新策略,该策略支持使用查询命令的轻型处理。 更新策略自动对原始表上的引入数据运行提取和转换,并将生成的数据引入到一个或多个目标表。

  6. 引入数据

    可以使用命令或引入向导将示例数据引入你在数据库中创建的表中。 要引入自己的数据,可以从一系列选项中进行选择,包括引入工具到各种服务的连接器和插件托管管道使用 SDK 的程序化引入以及直接访问引入

后续步骤