你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure 数据资源管理器数据引入概述
数据引入涉及将数据加载到群集中的表中。 Azure 数据资源管理器确保数据有效性,根据需要转换格式,并执行架构匹配、组织、索引、编码和压缩等操作。 引入后,数据可供查询。
Azure 数据资源管理器使用流式引入或排队引入提供一次性引入或建立连续引入管道。 若要确定哪种方案适合你,请参阅 一次性数据引入 和 连续数据引入。
注意
数据根据设置的 保留策略保留在存储中。
一次性数据引入
一次性引入有助于传输历史数据、填写缺失数据,以及原型制作和数据分析的初始阶段。 此方法有助于快速集成数据,而无需连续的管道承诺。
有多种方法可以执行一次性数据引入。 使用以下决策树来确定最适合你的用例的选项:
有关详细信息,请参阅相关文档:
标注 | 相关文档 |
---|---|
请参阅用于引入的 Azure 数据资源管理器支持的数据格式。 | |
请参阅Azure 数据工厂管道支持的文件格式。 | |
若要从现有存储系统导入数据,请参阅如何将历史数据引入 Azure 数据资源管理器。 | |
在 Azure 数据资源管理器 Web UI 中,可以从本地文件、Amazon S3 或 Azure 存储获取数据。 | |
若要与 Azure 数据工厂 集成,请参阅使用 Azure 数据工厂 将数据复制到 Azure 数据资源管理器。 | |
Kusto 客户端库 可用于 C#、Python、Java、JavaScript、TypeScript 和 Go。 可以编写代码来操作数据,然后使用 Kusto 引入库将数据引入 Azure 数据资源管理器表。 在引入之前,数据必须处于 受支持的格式 之一。 |
持续数据引入
在需要从实时数据中获得即时见解的情况下,连续引入非常出色。 例如,连续引入可用于监视系统、日志和事件数据以及实时分析。
连续数据引入涉及设置具有流式引入或排队引入的引入管道:
流式引入:此方法可确保每个表的小型数据集的准实时延迟。 数据从流式处理源以微批引入,最初放置在行存储区中,然后传输到列存储区。 有关详细信息,请参阅 配置流式引入。
排队引入:此方法针对高引入吞吐量进行优化。 数据基于引入属性进行批处理,然后合并小批,并针对快速查询结果进行优化。 默认情况下,最大排队值为 5 分钟、1000 个项目或总大小为 1 GB。 排队引入命令的数据大小限制为 6 GB。 此方法使用重试机制来缓解暂时性故障,并遵循“至少一次”消息传送语义,以确保过程中不会丢失任何消息。 有关排队引入的详细信息,请参阅 引入批处理策略。
注意
对于大多数方案,我们建议使用排队引入,因为它是性能更高的选项。
可通过多种方式配置连续数据引入。 使用以下决策树来确定最适合你的用例的选项:
有关详细信息,请参阅相关文档:
标注 | 相关文档 |
---|---|
有关连接器的列表,请参阅 连接器概述。 | |
创建事件中心数据连接。 与事件中心集成可提供限制、重试、监视和警报等服务。 | |
从 Apache Kafka 引入数据,这是一个分布式流式处理平台,用于生成实时流数据管道。 | |
创建IoT 中心数据连接。 与 IoT 中心的集成提供限制、重试、监视和警报等服务。 | |
创建事件网格数据连接。 与事件网格集成提供限制、重试、监视和警报等服务。 | |
请参阅相关连接器的指南,例如 Apache Spark、Apache Kafka、Azure Cosmos DB、Fluent Bit、Logstash、Open Telemetry、Power Automate、Splunk 等。 有关详细信息,请参阅 连接器概述。 | |
Kusto 客户端库 可用于 C#、Python、Java、JavaScript、TypeScript 和 Go。 可以编写代码来操作数据,然后使用 Kusto 引入库将数据引入 Azure 数据资源管理器表。 在引入之前,数据必须处于 受支持的格式 之一。 |
注意
并非所有引入方法都支持流式引入。 有关支持详细信息,检查特定引入方法的文档。
使用管理命令直接引入
Azure 数据资源管理器提供以下引入管理命令,这些命令将数据直接引入群集,而不是使用数据管理服务。 它们应仅用于探索和原型制作,而不应用于生产或大批量方案。
- 内联引入: .ingest 内联命令 包含要作为命令文本本身一部分引入的数据。 此方法用于临时测试目的。
- 从查询引入: .set、.append、.set-or-append 或 .set-or-replace 命令 间接指定要引入的数据作为查询或命令的结果。
- 从存储中引入:.ingest into 命令获取要从外部存储引入的数据,例如Azure Blob 存储,群集可访问,并由命令指向。
比较引入方法
下表比较了main引入方法:
引入名称 | 数据类型 | 文件大小上限 | 流式处理、排队、直接 | 最常用场景 | 注意事项 |
---|---|---|---|---|---|
Apache Spark 连接器 | Spark 环境支持的每一种格式 | 无限制 | 已排队 | 在引入现有管道前在 Spark 上进行预处理,是从 Spark 环境支持的各种源创建安全的 (Spark) 流式处理管道的快速方法。 | 考虑 Spark 群集的成本。 对于批量写入,请与适用于事件网格的 Azure 数据资源管理器数据连接进行比较。 对于 Spark 流式处理,请与适用于事件中心的数据连接进行比较。 |
Azure 数据工厂 (ADF) | 支持的数据格式 | 不受限制。 继承 ADF 限制。 | 已排队或按 ADF 触发器 | 支持不支持的格式,如 Excel 和 XML,并且可以从 90 多个源复制大型文件,从 perm 复制到云 | 在引入数据之前,此方法的用时相对较长。 ADF 将所有数据上传到内存,然后开始引入。 |
事件网格 | 支持的数据格式 | 1 GB,解压缩 | 已排队 | 从 Azure 存储持续引入,Azure 存储中的外部数据 | 可通过 Blob 重命名或 Blob 创建操作触发引入 |
事件中心 | 支持的数据格式 | 空值 | 排队、流式处理 | 消息,事件 | |
获取数据体验 | *SV、JSON | 1 GB,解压缩 | 排队或直接引入 | 一次性、创建表架构、使用事件网格定义持续引入、对容器进行批量引入(最多 5,000 个 blob;使用历史引入时无限制) | |
IoT 中心 | 支持的数据格式 | 空值 | 排队、流式处理 | IoT 消息,IoT 事件,IoT 属性 | |
Kafka 连接器 | Avro、ApacheAvro、JSON、CSV、Parquet 和 ORC | 不受限制。 继承 Java 限制。 | 排队、流式处理 | 现有管道,源产生的消耗很大。 | 首选项可由多个生成者或使用者服务的现有使用或所需的服务管理级别决定。 |
Kusto 客户端库 | 支持的数据格式 | 1 GB,解压缩 | 排队、流式处理、直接 | 根据组织需求编写自己的代码 | 编程引入经过优化,通过最大程度地减少引入过程中和引入过程之后的存储事务, (COG) 降低引入成本。 |
LightIngest | 支持的数据格式 | 1 GB,解压缩 | 排队或直接引入 | 数据迁移、具有调整的引入时间戳的历史数据、批量引入 | 区分大小写和区分空间 |
逻辑应用 | 支持的数据格式 | 1 GB,解压缩 | 已排队 | 用于自动化管道 | |
LogStash | JSON | 不受限制。 继承 Java 限制。 | 已排队 | 现有管道使用 Logstash 的成熟开放源代码特性,从输入 () 进行大量消耗。 | 首选项可由多个生成者或使用者服务的现有使用或所需的服务管理级别决定。 |
Power Automate | 支持的数据格式 | 1 GB,解压缩 | 已排队 | 引入命令作为流的一部分。 用于自动化管道。 |
有关其他连接器的信息,请参阅 连接器概述。
权限
以下列表描述了各种引入方案所需的权限:
- 若要创建新表,至少需要数据库用户权限。
- 若要将数据引入现有表而不更改其架构,至少需要数据库引入器权限。
- 若要更改现有表的架构,至少需要表管理员或数据库管理员权限。
有关详细信息,请参阅 Kusto 基于角色的访问控制。
引入过程
以下步骤概述了常规引入过程:
(可选) 设置保留 策略:如果数据库保留策略不适合你的需求,请在表级别重写它。 有关详细信息,请参阅保留策略。
创建表:如果使用“获取数据”体验,则可以在引入流中创建表。 否则,请在 Azure 数据资源管理器 Web UI 或使用 .create table 命令引入之前创建表。
创建架构映射: 架构映射 有助于将源数据字段绑定到目标表列。 支持不同类型的映射,包括面向行的格式(如 CSV、JSON 和 AVRO)和面向列的格式(如 Parquet)。 在大多数方法中,还可以 在 表上预先创建映射。
(可选) 设置更新策略 :某些数据格式(如 Parquet、JSON 和 Avro)可实现简单的引入时转换。 若要在引入过程中进行更复杂的处理,请使用 更新策略。 此策略会自动对原始表中的引入数据执行提取和转换,然后将修改后的数据引入到一个或多个目标表中。
引入数据:使用首选的引入工具、连接器或方法引入数据。
相关内容
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈