你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 中使用云规模分析的引入过程
Azure 提供了多项服务，用于将数据引入和发布到原生和第三方平台。 可以使用不同的服务，具体取决于卷、速度、种类和方向。 这些服务包括：
- Azure 数据工厂是为所有数据应用程序（源对齐）需求和技能水平而构建的服务。 编写自己的代码或在直观的视觉环境中构建、提取、加载和转换流程（无需代码）。 凭借 90 多个以原生方式构建且免维护的连接器，可在不增加成本的情况下直观集成数据源。 工程师可以使用专用终结点和链接服务安全地连接到 Azure 平台即服务 (PaaS) 资源，且无需使用 PaaS 资源的公共终结点。 工程师可使用集成运行时将管道扩展到第三方环境（如本地数据源和其他云）。
其中一些连接器支持用作源（读取）或接收器（写入）。 Azure 原生服务、Oracle、SAP 以及其他服务可用作源或接收器，但并非所有连接器都支持它。 在这些情况下，可以使用通用连接器，例如开放式数据库连接 (ODBC)、文件系统或 SSH 文件传输协议 (SFTP) 连接器。
Azure Databricks 是基于Apache Spark 的快速、简单、协作型分析服务。 对于大数据管道，可以通过数据工厂将数据（原始或结构化数据）以批的形式引入 Azure，或者使用 Apache Kafka、Azure 事件中心或 IoT 中心进行准实时的流式传输。 此数据位于数据湖中，以便在 Azure Data Lake Storage 中长期持久存储。 在工作流中，Azure Databricks 可以从多个数据源读取数据。
Microsoft Power Platform 提供了成百上千种服务的连接器，这些服务可能是事件、计划或推驱动的服务。 Microsoft Power Automate 可以处理事件并触发针对单个记录或小型数据卷优化的工作流。
专有的原生和第三方工具提供了用于与专用系统和准实时复制集成的利基功能。
- Azure Data Share 支持组织与多个外部客户和合作伙伴安全地共享数据。 创建数据共享帐户并添加数据产品后，可将客户和合作伙伴邀请到数据共享。 数据提供程序始终可以控制其共享的数据。 可以通过 Azure Data Share 轻松管理和监视共享了哪些数据、共享的时间，以及共享的人员。
重要
每个数据登陆区域都有一个元数据引入资源组，该资源组存在于具有与数据无关的引入引擎的企业中。 如果没有此框架引擎，唯一建议的资源是部署 Azure Databricks 分析工作区，数据集成将以此来运行复杂引入。 有关潜在的自动化模式，请参阅与数据无关的引入引擎。
Azure 数据工厂的引入注意事项
如果具有与数据无关的引入引擎，则应为引入和处理资源组中的每个数据登陆区域部署一个数据工厂。 数据工厂工作区应对用户锁定，只有托管标识和服务主体有权访问以进行部署。 数据登陆区域操作应有读取访问权限，以允许管道调试。
数据应用程序可以有自己的数据工厂来进行数据移动。 在每个数据应用程序资源组中都拥有一个数据工厂，只允许从 Azure DevOps 或 GitHub 部署管道，从而支持完整的持续集成 (CI) 和持续部署 (CD) 体验。
所有数据工厂工作区将主要使用数据工厂中的托管虚拟网络 (VNet) 功能或将自托管集成运行时用于数据管理登陆区域内的数据登陆区域。 强烈建议工程师使用托管 VNet 功能安全连接到 Azure PaaS 资源。
但是，可以创建更多的集成运行时，用于从本地、第三方云和第三方软件即服务 (SaaS) 数据源引入。
Azure Databricks 的引入注意事项
本指南详细说明了以下方面的信息：
在开发过程中，集成操作都应该有自己的 Azure Databricks 环境，然后才能在测试和生产期间签入要部署到单个 Azure Databricks 工作区的代码。
数据应用程序（与源一致）资源组中的数据工厂应提供用于调用 Azure Databricks 作业的框架。
服务主体有助于将数据湖装载到此工作区中。 有关详细信息，请参阅模式 1 - 通过服务主体访问。
数据应用程序团队可在 Azure Databricks 上部署简短的自动作业，并期望其群集快速启动、执行作业和终止。 建议设置 Azure Databricks 池，以缩短群集为作业启动所用的时间。
建议组织使用 Azure DevOps 来实现新管道的部署框架。 该框架将用于创建数据集文件夹、分配访问控制列表，以及在强制执行或不强制执行 Databricks 表访问控制的情况下创建表。
流引入
组织可能需要支持发布者生成高速事件流的场景。 对于这种模式，建议使用消息队列（例如事件中心或 IoT 中心）来引入这些流。
事件中心和 IoT 中心是可缩放的事件处理服务，可在具有低延迟和高可靠性的情况下接收并处理大事件量和数据。 事件中心旨在成为大数据流式处理和事件引入服务。 IoT 中心是一项托管服务，充当消息中心，用于在 IoT 应用程序与所管理的设备之间进行双向通信。 从那里，数据可以定期导出到数据湖（批），并通过 Apache Spark 流式处理、Azure 数据资源管理器、流分析或时序见解使用 Azure Databricks 进行准实时处理。
在用例的特定登陆区域内，最后一个事件中心或 Apache Kafka 登陆区域应将其聚合数据发送到其中一个数据登陆区域中的数据湖的原始层，并发送到与数据登录区域中的数据应用程序（与源一致）资源组相关的事件中心。
监视引入
现成的 Azure 数据工厂管道监视可用于监视数据工厂管道中的异常并对其进行故障排除。 它可减少开发自定义监视和报告解决方案的工作量。
内置监视是将 Azure 数据工厂用作主要业务流程工具的主要原因之一，Azure Policy 可帮助自动执行此设置。
将数据源映射到服务
本部分中的指南会将引入和处理服务映射到通常需要从 Azure 引入或发布的源。
引入服务：
| ID | 机制 | 注意 |
|---|---|---|
| A | 数据工厂 | 内置和通用（ODBC、SFTP 和 REST）连接器 |
| B | Azure Databricks | 自定义代码（JDBC、JAR 等） |
| C | 第三方 | WANdisco、Qlik sense 和 Oracle GoldenGate |
| D | 其他 | 例如，原生功能 |
| E | Microsoft Power Platform 和 Azure 逻辑应用 | Microsoft Power Automate 连接器 |
到服务的数据源映射：
| 提供程序 | 类型 | 已托管 | 类别 | 说明 | 完全加载的引入 | 增量负载引入 | 实时引入 | 完全加载的出口 | 增量负载出口 | 实时出口 |
|---|---|---|---|---|---|---|---|---|---|---|
| Oracle | 表格 | IaaS | 数据库 | GoldenGate 到 Azure Data Lake Storage | A, B | A, B | C | A, B | A, B | C |
| Microsoft SQL Server | 表格 | IaaS | 数据库 | SAP 横向转换和 Qlik | A, B | A, B | C、D2 | A, B | A, B | C、D2 |
| MySQL | 表格 | IaaS | 数据库 | SAP 横向转换和 Qlik | A, B | A, B | C、D2 | A, B | A, B | C、D2 |
| SAP BW/4HANA | 表格 | IaaS | 数据库 | SAP 横向转换和 Qlik | A、B、C、D | A、B、C、D | C | - | - | - |
| SAP HANA | 表格 | IaaS | 数据库 | SAP 横向转换和 Qlik | A、B、C、D | A、B、C、D | C | A, B | A, B | - |
| Apache Impala | 表格 | IaaS | 数据库 | - | A, B | A, B | - | B | B | - |
| Microsoft SharePoint | 列出 | SaaS | 记录存储 | - | A、E | A、E | E | A、E | A、E | E |
| REST | REST | 各种 | REST | XML、JSON、CSV | A、B、E | A、B、E | A、B、E | A、B、E | A、B、E | A、B、E |
| Microsoft Outlook | 电子邮件 | SaaS | REST | XML、JSON、CSV | E | E | E | E | E | E |
根据目标，Azure 数据库迁移服务可从本地和第三方数据库（如 Microsoft SQL Server、PostgreSQL、MySQL 或 Oracle）复制到基于 Azure 的数据存储。