通过

Azure 数据资源管理器 POC playbook：大数据分析

本文介绍了一种高级方法，用于准备和运行有效 Azure 数据资源管理器概念证明 (POC) 项目。

在开始之前

本 playbook 可帮助你评估 Azure 数据资源管理器的使用，并且专为最适合 Azure 数据资源管理器的方案而设计。 在启动 POC 之前，使用以下方案确定 Azure 数据资源管理器是否为适合你的解决方案。

常规体系结构模式方案

  • 符合以下一个或多个特征的任何数据都应适合使用 Azure 数据资源管理器：
    • 容量大、速度快
    • 仅可追加的不可变数据
    • 数据静默：数据不会更改。 例如，在线商店的订单是静默数据的不错示例。
  • 命令和查询责任分离 (CQRS) 模式适用于 Azure 数据资源管理器的仅追加体系结构。
  • 事件寻源模式

其他方案

Azure 数据资源管理器也适用于以下方案：

准备 POC

POC 项目可帮助你做出有关在基于云的平台上实现大数据和高级分析环境的明智业务决策，该平台使用 Azure 数据资源管理器。

POC 项目将确定基于云的大数据和高级分析平台必须支持的关键目标和业务驱动因素。 它将测试关键指标并证明对数据工程、机器学习模型构建和培训要求的成功至关重要的关键行为。 POC 不适合部署到生产环境。 它是一个注重于关键问题的短期项目，其结果可被丢弃。

开始计划 Azure 数据资源管理器 POC 项目之前：

  • 确定组织在将数据移到云方面所要施加的任何限制或要制定的准则。
  • 确定大数据和高级分析平台项目的行政或业务发起人。 确保他们为迁移到云提供支持。
  • 确定在执行 POC 期间是否有技术专家和业务用户可为你提供支持。

在开始准备 POC 项目之前，建议先阅读 Azure 数据资源管理器文档。

到目前为止，你应该已经确定当前没有阻碍因素，然后你可以开始为 POC 做准备。 如果不熟悉 Azure 数据资源管理器，可参阅本文档，大致了解 Azure 数据资源管理器体系结构。

了解这些关键概念：

  • Azure 数据资源管理器及其体系结构。
  • 支持数据格式和数据源。
  • 用作 Azure 数据资源管理器项目的群集、数据库、表、具体化视图、函数。
  • 引入向导支持的引入方法和持续引入。
  • Azure 数据资源管理器中的身份验证和授权。
  • 与可视化解决方案（例如 Power BI、Grafana、Kibana 等）集成的本机连接器。
  • 创建外部表以从 Azure SQL/SQL Server、Azure Cosmos DB、Azure Monitor、Azure 数字孪生读取数据。

Azure 数据资源管理器会将计算资源与存储分离，以便你可以更好地管理数据处理需求和控制成本。 只需在使用计算时付费。 不使用时，只需支付存储费用。 通过 Azure 数据资源管理器的托管服务体系结构，可独立于存储缩放群集。 可以纵向扩展和缩减（垂直），也可以横向扩展和缩减（水平）。 还可以手动停止或自动停止群集，而不会丢失数据。 例如，可以纵向扩展群集以满足繁重的数据处理需求或大型负载，然后在不太密集的处理时间重新纵向缩减它（或完全关闭它）。 同样，可以在周末有效地缩放和停止群集，以降低成本。

设定目标

成功的 POC 项目需要规划。 首先确定为何要执行 POC，以充分了解真正的动机。 动机可能包括现代化、成本节省、性能改进或集成体验。 请务必阐述 POC 的明确目标，以及 POC 成功的条件。 问问你自己：

  • 你期望的 POC 输出是什么？
  • 如何处理这些输出？
  • 谁使用输出？
  • POC 成功的条件是什么？

请记住，POC 应该是快速证明有限一组概念和功能的简短而专注的工作。 这些概念和功能应代表整个工作负载。 如果你要证明很多的项，可能需要规划多个 POC。 在这种情况下，请定义 POC 之间的门限，以确定是否需要继续执行下一个 POC。 例如，执行一个 POC 来重点满足数据工程角色的需求，例如引入和处理。 执行另一个 POC 来侧重于机器学习 (ML) 模型开发。

在考虑 POC 目标时，请向自己提出以下问题以帮助形成目标：

  • 是否要从现有的大数据和高级分析平台（本地或云）迁移？
  • 是否要迁移，并希望在迁移过程中进行一些广泛的改进？ 例如，从弹性搜索迁移到 Azure 数据资源管理器进行日志分析，从 InfluxDB 或 Timescale DB 迁移到 Azure 数据资源管理器。
  • 是否要构建一个全新的大数据和高级分析平台（全新项目）？
  • 当前的痛点是什么？ 例如，可伸缩性、性能或灵活性。
  • 需要支持哪些新的业务要求？
  • 需要符合哪些 SLA？
  • 工作负载是什么？ 例如，ETL、批处理、流处理、机器学习模型训练、分析、报告查询或交互式查询？
  • 拥有项目的用户的技能是什么（是否应实施 POC）？ 例如，SQL、Python、PowerBI 或其他技能。

下面是一些 POC 目标设定示例：

  • 为何要执行 POC？
    • 我们需要知道，大数据工作负载的数据引入和处理性能将满足新 SLA 的需求。
    • 我们需要知道，接近实时的流处理是否可行，以及它可以支持多大的吞吐量。 （它是否会支持我们的业务需求？）
    • 我们需要知道，现有的数据引入和转换流程是否合适，以及需要在哪些方面进行优化。
    • 我们需要知道，是否可以缩短数据集成运行时间以及可以缩短多少时间。
    • 我们需要知道数据科学家是否可以生成和训练机器学习模型，并根据需要在 Azure 数据资源管理器中使用 AI/ML 库。
    • 迁移到基于云的 Azure 数据资源管理器是否会满足我们的成本目标？
  • 在此 POC 的结论中：
    • 我们将有数据来确定是否可以满足批处理和实时流式处理的数据处理性能要求。
    • 我们将测试支持我们用例的所有不同数据类型的引入和处理（结构化、半结构化和非结构化）。
    • 我们将测试一些现有的数据处理需求，并确定使用 Azure 数据资源管理器中的更新策略可以完成的工作。
    • 我们将测试数据引入和处理，并将有数据点来估计完成历史数据初始迁移和加载所需的工作量。
    • 我们将测试数据引入和处理，并且可以确定是否可以满足 ETL/ELT 处理要求。
    • 我们将获得见解，以更好地估计完成实现项目所需的工作量。
    • 我们将测试缩放和缩放选项，并具有数据点可更好地配置平台，以改进性价比设置。
    • 我们会列出可能需要进行更多测试的项。

计划项目

使用目标来确定特定的测试并提供确定的输出。 必须确保至少执行一项测试来支持每个目标和预期输出。 此外，确定特定数据引入、批处理或流处理以及将执行的所有其他进程，以便可以确定特定的数据集和代码库。 该特定数据集和代码库将定义 POC 的范围。

下面是使用 Azure 数据资源管理器评估的典型主题区域：

  • 数据引入和处理：数据源、数据格式、引入方法、连接器、工具、引入策略、流式引入与排队引入
  • 数据存储：架构、存储项目，例如表和具体化视图
  • 策略：例如分区、更新、合并
  • 查询和可视化
  • 性能：例如查询响应时间、引入延迟、弱一致性、查询缓存结果
  • 成本：总拥有成本 (TCO)
  • 安全性：例如身份验证、授权、数据访问、行级别安全性

注意

请使用以下常见问题解答帮助你规划 POC。

  • 如何为 POC 群集选择 SKU？
    使用为 Azure 数据资源管理器群集选择 SKU 指南来帮助你为 POC 群集选择 SKU。 启动 POC 时，建议从较小的 SKU 入手，并在开始测试和捕获结果时根据需要纵向扩展 SKU。
  • 创建 POC 群集时，如何选择缓存期？
    为了提供最佳查询性能，引入的数据将缓存在本地 SSD 盘上。 这种性能级别并非始终必需，通常可将较少查询的数据存储在更便宜的 Blob 存储上。 对 Blob 存储中的数据运行查询的速度较慢，但在许多情况下，这是可以接受的。 了解这一点可以帮助你确定在本地 SSD 中保存数据所需的计算节点数，并继续满足查询性能要求。 例如，如果要更频繁地查询 x 天的数据（基于引入时长），保留 y 天的数据且很少查询它，可在缓存保留策略中将 x 指定为热缓存保留期值，并将 y 指定为总保留期值。 有关详细信息，请参阅缓存策略。
  • 创建 POC 群集时，如何选择保持期？
    保持期是可供查询的热缓存数据和冷缓存数据的组合。 根据合规性或其他法规要求，基于所需的数据保留时间选择数据保持期。 可以使用热窗口功能预热存储在冷缓存中的数据，以便为任何审计操作提供更快速的查询。 有关详细信息，请参阅使用热窗口查询冷数据。

下面是规划中所需具体程度的示例：

  • 目标 A：我们需要知道，根据定义的 SLA 是否可以满足对批数据引入和批数据处理的要求。
  • 输出 A：我们将具有数据，可确定已排队的数据引入和处理是否可满足批量数据处理要求和 SLA。
    • 测试 A1：处理查询 A、B 和 C 被标识为良好的性能测试，因为它们通常由数据工程团队执行。 此外，它们代表了整体数据处理需求。
    • 测试 A2：经确定，处理查询 X、Y 和 Z 是良好的性能测试，包含近乎实时的流处理要求。 此外，它们代表了基于事件的整体流处理需求。
    • 测试 A3：将这些查询在不同规模的群集（群集 SKU、实例数）中的性能与从现有系统中获得的基准进行比较。
  • 目标 B：我们需要知道我们的业务用户是否可以在此平台上构建其仪表板。
  • 输出 B：我们将使用不同的可视化选项、连接器和 Kusto 查询来测试群集中的一些现有数据仪表板和视觉对象。 这些测试将有助于确定哪些仪表板可以迁移到新环境。
    • 测试 B1：将使用 Azure 数据资源管理器数据创建特定视觉对象，并对其进行测试。
    • 测试 B2：测试现用 KQL 函数和运算符以满足要求。
  • 目标 C：我们将测试数据引入，并将使用数据点执行以下操作：
    • 估计向 Azure 数据资源管理器群集进行历史数据初始迁移所需的工作量。
    • 规划历史数据迁移方法。
  • 输出 C：我们将测试并确定环境中可实现的数据引入速率，并且可以确定数据引入速率是否足以在可用时间窗口内迁移历史数据。
    • 测试 C1：测试不同历史数据迁移方法。
    • 测试 C2：测试使用 LightIngest、从 Blob 存储或 Data Lake Store 持续引入从数据源到群集的数据传输。 有关详细信息，请参阅引入历史数据。
  • 目标 D：我们将测试增量数据加载的数据引入速率，并将具有数据点，可估计数据引入和处理时间窗口。
  • 输出 D：我们将测试数据引入速率，并且可以确定使用确定的方法是否可满足数据引入和处理要求。
    • 测试 D1：测试每天、每小时和准实时数据引入和处理。
    • 测试 D2：在运行最终用户查询时执行连续（排队或流式）数据引入和处理。

务必通过添加多个测试方案来优化测试。

以下是一些测试方案：

  • Azure 数据资源管理器测试 A：我们将跨多个群集 SKU 大小（存储优化或计算优化）和不同数量的群集实例执行数据引入、处理和查询。
  • Azure 数据资源管理器测试 B：我们将使用仪表板和查询工具（如 Azure 数据资源管理器 Web UI）从群集查询已处理的数据。

下面是有助于你规划 POC 的任务的高级示例：

Sprint 任务
0 向客户团队展示和演示 Azure 数据资源管理器
0 使用 Azure 数据资源管理器定义客户想要实现的业务方案
0 定义数据源、引入方法、数据保留、数据缓存、SLA、安全性、网络、IAM 等方面的技术要求
0 定义关键性能度量值，例如查询性能预期、延迟、并发请求数、引入吞吐量、数据时效性
0 使用 Azure 数据资源管理器及其数据引入器和使用者定义高级体系结构
0 定义 POC 范围
0 定义 POC 规划和时间线
0 定义 POC 评估条件、设置优先级并权衡
1 定义要测试的查询并设置优先级
1 为每个用户组定义数据访问规则
1 估计一次性（历史）数据引入量和每日数据引入量
1 定义数据保留、缓存和清除策略
1 定义创建群集时所需的配置元素，例如流式处理、Python/R 插件、清除
1 查看源数据格式、结构、架构
1 查看、优化、修订评估条件
1 基于 Azure 数据资源管理器的 Azure 定价计算器构建定价方案
2 根据体系结构设计创建群集和所需的数据库、表和具体化视图
2 向相关用户分配数据访问权限
2 实现分区和合并策略（如果需要）
2 实现一次性数据引入，通常是历史数据或迁移数据
2 安装并配置查询工具（如果需要）
2 使用数据资源管理器 Web UI 测试对引入数据的查询
2 测试更新和删除方案
2 测试与 PowerBI 的连接
2 测试与 Grafana 的连接
2 配置数据访问管理规则
2 实现持续引入
2 建立与事件中心/Iot 中心/事件网格的数据连接
3 在 Azure 数据资源管理器仪表板或 Grafana 中实现自动刷新仪表板以实现准实时监视
3 定义如何执行负载测试
3 根据从以前的冲刺阶段和已完成的积压工作项中获得的经验，优化引入方法和流程
3 Grafana 仪表板上的性能评估
3 根据并发性和预期负载要求执行负载测试
3 验证成功条件
3 查看评分
3 测试引入不同格式数据的能力
3 验证 POC 结果

评估 POC 数据集

使用确定的特定测试，选择一个数据集来支持测试。 花些时间评审此数据集。 应该验证该数据集在内容、复杂性和规模方面是否能够充分代表将来的处理。 不要使用太小（小于 1 GB）的数据集，因为它不能提供具有代表性的性能。 相反，也不要使用太大的数据集，因为 POC 不应该变为完整数据迁移。 请务必从现有系统获取适当的基准，以便可以使用它们进行性能比较。 检查数据集是否与受支持的数据格式保持一致。 然后，根据引入方法（排队或流式），可按适当大小的批次引入数据集。

重要

在将任何数据迁移到云之前，请确保与业务所有者核实是否有任何阻碍因素。 在将数据移动到云之前，确定应处理的任何安全或隐私问题或任何数据混淆需求。

创建高级体系结构

根据提议的未来状态体系结构的高级体系结构，确定构成 POC 的一部分的组件。 高级未来状态体系结构可能包含许多数据源、大量的数据使用者、大数据组件，以及机器学习和人工智能 (AI) 数据使用者。 POC 体系结构应明确确定 POC 的构成组件。 重要的是，它应该确定不构成 POC 测试的一部分的任何组件。

如果你已在使用 Azure，请确定可在 POC 期间使用的任何现有资源（Microsoft Entra ID、ExpressRoute 等）。 另外，确定组织使用的 Azure 区域。 现在是确定 ExpressRoute 连接的吞吐量，并与其他业务用户核实你的 POC 是否消耗其中一部分吞吐量而不会对生产系统造成不利影响的好时机。

有关详细信息，请参阅大数据体系结构。

确定 POC 资源

明确确定支持 POC 所需的技术资源和时间承诺。 POC 需要：

  • 一名业务代表，负责监督要求和结果。
  • 一名应用程序数据专家，负责 POC 数据溯源，并提供现有流程和逻辑的知识。
  • 一名 Azure 数据资源管理器专家。 如有必要，你可以要求 Microsoft 联系人进行安排。
  • 一名专家顾问，负责优化 POC 测试。 如有必要，你可以要求 Microsoft 联系人进行安排。
  • POC 项目的特定组件需要的资源，但不一定需要在 POC 期间使用。 这些资源可能包括网络管理员、Azure 管理员、Active Directory 管理员、Azure 门户管理员等。
  • 确保预配所有必需的 Azure 服务资源并授予所需的访问级别，包括对存储帐户的访问权限。
  • 确保帐户拥有从 POC 范围内的所有数据源检索数据所需的数据访问权限。

提示

建议聘请专家顾问来协助完成 POC。 请联系 Microsoft 帐户团队或全球范围内的专家顾问，他们可以帮助你评估、计算或实现 Azure 数据资源管理器。 你也可以在 Stack Overflow 上使用 Azure 数据资源管理器标签发布问题。

设置时间线

查看 POC 计划详细信息和业务需求，以确定 POC 的期限。 对完成 POC 目标所需的时间进行实际的估算。 完成 POC 所需的时间受 POC 数据集大小、测试的数量和复杂性以及要测试的接口数量的影响。 如果你估计 POC 的运行时间超过四周，请考虑缩小 POC 范围，以便注重于优先级最高的目标。 在继续之前，请务必获得所有资源主管和发起人的批准和承诺。

将 POC 付诸实施

我们建议遵循任何生产项目的纪律和严谨性来执行 POC 项目。 根据计划运行项目并管理更改请求流程，以防 POC 范围不受控制地扩大。

下面是一些高级任务的示例：

  1. 创建 Azure 数据资源管理器群集以及 POC 计划中确定的所有 Azure 资源。

  2. 加载 POC 数据集：

    • 通过从源中提取数据或在 Azure 中创建示例数据，使数据在 Azure 中可用。 若要在 Azure 数据资源管理器中对引入数据功能进行初始测试，请使用获取数据体验。
    • 测试计划用于将数据引入群集的连接器/集成方法。

  3. 编写 Kusto 查询以查询数据：

  4. 执行测试：

  5. 优化查询和群集：

  6. 监视故障排除和性能：

  7. 估算定价：

    • POC 结束时，应使用 POC 中学到的内容估算满足要求的群集的成本。

  8. 关闭 POC：

    • 记录 POC 阶段的结果、获得的经验以及成果，包括在 POC 期间应用的基准、配置和优化。
    • 清理 POC 期间创建的任何不再需要的 Azure 资源。

    提示

    如果决定继续使用 Azure 数据资源管理器，并打算将其迁移到生产环境，建议保持 POC 群集运行。 这将有助于你设置生产群集，确保不会丢失 POC 期间可能应用的配置和优化。

解释 POC 结果

完成所有 POC 测试后，请评估结果。 首先评估是否满足 POC 目标，并收集了所需的输出。 确定是否需要进行更多测试或者是否有任何问题需要解决。

从 POC 迁移到生产环境

如果决定继续在使用 Azure 数据资源管理器，并打算将 POC 池迁移到生产环境，强烈建议保持 POC 群集运行，并使用它来设置生产群集。 这将有助于确保不会丢失 POC 期间可能应用的配置和优化。

在将 POC 群集迁移到生产环境之前，强烈建议你考虑、设计和决定以下因素：

  • 功能和非功能要求
  • 灾难恢复和高可用性要求
  • 安全要求
  • 网络要求
  • 持续集成/持续部署要求
  • 监视和支持要求
  • Azure 数据资源管理器重点人员培训
  • 访问控制要求
  • 架构、数据模型和数据流要求
  • 引入要求
  • 可视化要求
  • 数据和见解消耗要求
  • 测试要求

相关内容