手册

数据以固定表格布局（行和列）和预定义架构组织，例如产品目录或财务记录。

→表示为结构化数据。

原因: 结构化数据符合严格的架构，非常适合关系数据库 (OLTP)。与半结构化数据 (JSON/XML) 和非结构化数据（图像/音频）形成对比。

数据具有一定的组织结构（标签、键），但缺乏严格的架构。每个记录可以有不同的字段，例如物联网传感器 JSON 文档。

→表示为半结构化数据（例如 JSON、XML）。

原因: JSON 和 XML 具有自描述性，与结构化数据的固定架构相比，提供了灵活性。非常适合 NoSQL 数据库和数据湖。

存储没有预定义架构或组织结构的大文件，例如 MRI 扫描、视频或音频录音。

→表示为非结构化数据。

原因: 这种数据类型无法存储在传统的行/列数据库中。需要对象存储，例如 Azure Blob Storage。

区分日常操作工作负载和历史分析工作负载。

→OLTP（联机事务处理）用于大容量、低延迟事务（例如电子商务订单）。OLAP（联机分析处理）用于对大型历史数据集执行复杂查询（例如销售趋势分析）。

原因: OLTP 系统经过规范化并针对快速写入进行优化。OLAP 系统经过非规范化（星形架构）并针对快速读取和聚合进行优化。

为数据仓库选择数据集成模式。

→当转换逻辑复杂且在加载前在暂存服务器上完成时，使用 ETL（提取、转换、加载）。使用 ELT（提取、加载、转换）将原始数据加载到强大的目标系统（例如 Synapse Analytics）中，并利用其计算能力进行转换。

原因: ELT 是现代云模式，它利用目标数据存储（数据仓库/数据湖仓）中可扩展的计算能力，并简化了数据摄取。

分配数据平台任务的职责。

→数据工程师：构建和维护 ETL/ELT 管道。数据库管理员：管理数据库安全性、性能和可用性。数据分析师：创建报告和可视化（例如 Power BI）以获取业务洞察。

原因: 明确定义的角色至关重要。主要区别在于构建（工程师）、管理（DBA）和分析（分析师）。

处理具有不同延迟要求的大量数据。

→批处理用于处理静止数据，按计划间隔（例如夜间报告）进行处理。流处理用于处理动态数据，数据到达时连续处理（例如实时欺诈检测）。

原因: 关键权衡是延迟与成本/吞吐量。流处理提供低延迟，但需要始终在线的资源。批处理具有高延迟，但对于大批量数据而言具有成本效益。

为数据仓库设计架构以支持分析查询。

→使用星形架构，它由一个中心事实表（包含数值度量）和连接到它的多个维度表（包含描述性属性）组成。

原因: 这种非规范化结构最大程度地减少了分析查询的连接，与规范化 (OLTP) 架构相比，提高了性能。对于大多数 BI 工具而言，它比雪花架构更简单、更快。

选择分析的中心存储库。

→使用数据湖（例如 Azure Data Lake Storage）以其原始格式（读时模式）存储大量原始数据。使用数据仓库（例如 Synapse Dedicated SQL 池）存储结构化、已处理的数据用于 BI 和报告（写时模式）。

原因: 数据湖为数据科学和原始数据探索提供了灵活性。数据仓库为商业智能提供了高性能和结构。

为新的云原生应用程序需要一个完全托管的关系数据库，而无需管理底层基础设施。

→使用 Azure SQL Database。

原因: 它是一个 PaaS 产品，具有自动修补、备份和高可用性。非常适合不需要操作系统级别访问的标准 SQL 工作负载。

参考↗

对使用 SQL Server Agent、跨数据库查询或 Service Broker 等实例范围功能的本地 SQL Server 工作负载进行“提升和转移”迁移。

→使用 Azure SQL 托管实例。

原因: SQL MI 提供了与本地 SQL Server 引擎近乎 100% 的兼容性，最大程度地减少了迁移更改。Azure SQL Database 不支持这些实例级功能。

参考↗

将 SQL Server 数据库迁移到 Azure，需要完全控制操作系统、特定 SQL Server 版本或 PaaS 支持有限的功能（例如某些 CLR 程序集）。

→在 Azure 虚拟机上使用 SQL Server。

原因: 此 IaaS 选项提供了最大的兼容性和控制力，但与 PaaS 产品不同，它要求用户管理操作系统、修补和备份。

应用程序具有间歇性、不可预测的使用模式，并伴有较长的空闲期。需要在非活动期间最大程度地降低成本。

→使用 Azure SQL Database 的无服务器计算层。

原因: 无服务器根据需求自动扩展计算资源，并可以自动暂停数据库，在空闲期间仅对存储计费。非常适合可变工作负载。

参考↗

为具有可变工作负载的不同租户 (SaaS) 托管多个小型数据库。需要共享资源以降低成本。

→使用 Azure SQL Database 弹性池。

原因: 弹性池允许多个数据库共享一组预分配的资源（DTU 或 vCore），为多租户应用程序提供经济高效的解决方案。

数据库预计将增长到 4 TB 以上（最高 100 TB），并且无论大小如何，都需要快速扩展和近乎即时的备份和恢复。

→使用 Azure SQL Database 的超大规模服务层。

原因: 超大规模服务层为超大型数据库 (VLDB) 使用独特的分布式架构，突破了其他层的尺寸限制，并提供了恒定时间数据库操作。

为微服务应用程序部署托管 PostgreSQL 数据库，需要区域冗余高可用性以及计算和存储的独立扩展。

→使用适用于 PostgreSQL 的 Azure 数据库 - 灵活服务器。

原因: 灵活服务器是推荐的产品，与旧的单一服务器模型相比，它提供了区域冗余高可用性、自定义维护窗口和更好的成本优化。

保护敏感数据（例如信用卡号），使其在静态、传输中以及在使用中（内存中）的服务器上保持加密。即使是 DBA 也不能看到明文数据。

→使用 Always Encrypted。

原因: Always Encrypted 是一种客户端加密技术，密钥由客户端持有，确保数据永远不会在服务器上解密。TDE 仅保护静态数据。

需要在查询结果中向非特权用户隐藏敏感数据（例如，只显示社会安全号的最后四位），而无需更改存储的数据。

→使用动态数据掩码。

原因: DDM 根据用户权限在查询时应用掩码规则。它是一种限制数据暴露的安全功能，而不是加密功能。

通过在区域中断时启用自动故障转移到辅助区域，确保一组 Azure SQL Database 的业务连续性。

→配置自动故障转移组。

原因: 自动故障转移组提供一个统一的侦听器终结点，在故障转移后自动重定向流量，从而简化了灾难恢复的应用程序设计。它比从异地冗余备份恢复具有更低的 RPO/RTO。

需要以经济高效的方式存储大量非结构化数据，例如视频文件、图像、备份和日志。

→使用 Azure Blob Storage。

原因: Blob Storage 是一种对象存储服务，针对存储 PB 级的非结构化数据进行了优化。它不适用于结构化查询工作负载。

参考↗

优化具有不同访问模式的数据的存储成本。

→使用 Azure Blob Storage 访问层：热层（频繁访问）、冷层（不常访问，>30 天）、存档层（很少访问，>180 天）。

原因: 层级提供了成本权衡：热层存储成本最高但访问成本最低。存档层存储成本最低但访问成本最高，且检索延迟最长（数小时）。

根据 Blob 的使用期限或上次访问时间自动将 Blob 在热、冷和存档层之间移动以优化成本。

→在存储帐户上配置生命周期管理策略。

原因: 这自动化了分层过程，确保数据始终位于最具成本效益的层，无需手动干预。

迁移使用 SMB 文件共享的本地应用程序。多个 VM 需要挂载并访问同一个共享文件夹。

→使用 Azure 文件存储。

原因: Azure 文件存储在云中提供完全托管的文件共享，可通过 SMB 和 NFS 协议访问，使其成为本地文件服务器的直接替代品。

构建一个用于大数据分析的数据湖，该数据湖需要高效的目录级别操作和细粒度的、类似 POSIX 的访问控制。

→使用 Azure Data Lake Storage Gen2。

原因: ADLS Gen2 在 Blob Storage 的基础上增加了分层命名空间（用于原子目录操作）和对 POSIX 兼容 ACL 的支持，这对于 Spark 等大数据框架中的性能和安全性至关重要。

全球应用程序需要个位数毫秒级的读/写延迟、自动多区域复制以及 NoSQL 数据库的水平扩展。

→使用 Azure Cosmos DB。

原因: Cosmos DB 专为全球分布式、关键任务应用程序设计，提供开箱即用的全球分发、有保证的低延迟 SLA 和多种一致性模型。

参考↗

为新的 Cosmos DB 应用程序选择数据模型和 API。

→使用 NoSQL API（文档）、MongoDB API（文档）、Apache Gremlin API（图）、Table API（键值）或 Apache Cassandra API（宽列）。

原因: 选择最适合您的数据模型和现有应用程序堆栈的 API。对于新的基于 JSON 的应用程序使用 NoSQL，对于关系密集型数据使用 Gremlin，对于迁移现有工作负载（MongoDB、Cassandra、Table Storage）使用其他 API。

为 Cosmos DB 应用程序平衡读取一致性、可用性和性能。

→从五种一致性级别中选择：强、有限过期、会话（默认）、一致前缀、最终。

原因: 强一致性提供最高的一致性但延迟最高。最终一致性提供最低的延迟但一致性最弱。会话一致性最常用，保证用户在其会话中读取自己的写入。

下游服务需要近实时地响应 Cosmos DB 容器中创建或更新的任何数据（例如，更新搜索索引）。

→使用 Cosmos DB 更改源。

原因: 更改源提供了一个持久的、有序的更改日志。它通常由 Azure Function 消费，以构建事件驱动架构，而无需轮询数据库。

需要在操作型 Cosmos DB 数据上运行复杂的分析查询，而不会影响事务型工作负载的性能 (HTAP)。

→启用 Azure Cosmos DB 分析存储并使用 Azure Synapse Link。

原因: 分析存储是您的事务数据的完全隔离、自动同步的列式表示。它允许通过 Synapse 进行分析查询，而不会消耗事务请求单位 (RU)。

以非常低的成本存储大量简单的、结构化的非关系数据（例如设备遥测），用于快速基于键的查找。

→使用 Azure Table Storage。

原因: Table Storage 是一个 NoSQL 键值存储，针对高容量、简单的基于 PartitionKey 和 RowKey 的查找进行了优化。当不需要低延迟 SLA 和全球分发时，它比 Cosmos DB 便宜得多。

需要一个简单、可靠的消息系统来解耦应用程序组件，其中消息是异步处理的。

→使用 Azure Queue Storage。

原因: Queue Storage 为基本异步通信模式提供了一个简单、经济高效且可靠的消息队列。

需要构建、调度和监控复杂的数据集成工作流，以从各种本地和云源移动和转换数据。

→使用 Azure Data Factory (ADF)。

原因: ADF 是一种托管的云编排服务，用于大规模构建和管理 ETL/ELT 管道，具有广泛的连接性和监控功能。

参考↗

Azure Data Factory 管道需要访问位于公司防火墙后面的本地数据源。

→在本地网络中的一台机器上安装自托管集成运行时 (IR)。

原因: 自托管 IR 充当安全网关，使云中的 ADF 能够连接到本地源并从中移动数据，而无需将其暴露给公共互联网。

需要一个单一的集成平台，用于数据仓库 (SQL)、大数据分析 (Spark)、数据探索（无服务器 SQL）和数据集成。

→使用 Azure Synapse Analytics。

原因: Synapse 提供了一个统一的工作区 (Synapse Studio)，将这些不同的分析引擎整合在一起，减少了复杂性和集成开销。

在 Synapse Analytics 中选择 SQL 查询引擎。

→使用无服务器 SQL 池对数据湖中的数据进行即席探索性查询，采用按查询付费模式。使用专用 SQL 池处理具有预置资源的高性能、可预测的数据仓库工作负载。

原因: 无服务器用于不可预测的探索和发现。专用 SQL 池用于具有性能 SLA 的生产 BI 和报告。

需要实时处理和分析来自 IoT Hub 或 Event Hubs 等源的大量流数据，以支持实时仪表板或触发警报。

→使用 Azure Stream Analytics。

原因: Stream Analytics 是一种实时事件处理引擎，它使用简单的类似 SQL 的查询语言以低延迟分析动态数据。

数据科学团队需要一个协作的、基于笔记本的环境，用于使用 Apache Spark 进行大规模数据工程和机器学习。

→使用 Azure Databricks。

原因: Databricks 提供优化的 Spark 运行时、协作笔记本和集成的 ML 功能 (MLflow)，使其成为 Azure 上高级分析和 ML 的首选平台。

需要每秒从移动应用程序、Web 遥测或 IoT 设备等源摄取数百万个事件，用于实时处理。

→使用 Azure Event Hubs。

原因: Event Hubs 是一个专为高吞吐量事件摄取设计的大数据流平台。它充当流数据的“前端”，将生产者与消费者解耦。

组织需要一个单一、统一的 SaaS 分析平台，该平台结合了数据工程、数据科学、数据仓库和 BI，且基础设施管理最少。

→使用 Microsoft Fabric。

原因: Fabric 提供了一个基于单一数据湖 (OneLake) 构建的端到端、基于 SaaS 的分析体验。与使用单独的 PaaS 服务构建相比，它简化了架构并减少了集成开销。

参考↗

在 Microsoft Fabric 中，需要一个单一的工件来以开放的 Delta Lake 格式存储数据，该数据可由 Spark 引擎（用于数据工程）和 SQL 引擎（用于 BI）访问。

→使用 Microsoft Fabric Lakehouse。

原因: Lakehouse 是 Fabric 中的核心架构模式。它将数据湖的可扩展性和灵活性与数据仓库的事务保证和 SQL 查询功能相结合。

Microsoft Fabric 中的 Power BI 报告需要直接从 OneLake 查询大量数据，同时具有导入模式的性能和 DirectQuery 的数据新鲜度。

→在 Power BI 中使用 Direct Lake 模式。

原因: Direct Lake 是 Fabric 的一个独特功能，它按需将 Parquet/Delta 文件直接加载到 Power BI 引擎内存中，避免了数据重复和查询延迟，同时提供了近实时的数据访问。

业务用户需要连接到各种数据源，创建交互式仪表板和报告，并在整个组织中共享洞察。

→使用 Power BI。

原因: Power BI 是微软的商业分析服务，用于构建交互式数据可视化。使用 Power BI Desktop 进行创作，使用 Power BI Service 进行共享和协作。

区分 Power BI 中的多页交互式分析和单页高层概述。

→报告是从单个数据集构建的详细、交互式可视化的多页集合。仪表板是来自一个或多个报告的图块的单个画布，提供一目了然的视图。

原因: 报告用于深入分析。仪表板用于监控关键指标。

一个 Power BI 报告必须与多个用户共享，但每个用户只能看到与他们相关的数据（例如，销售经理只能看到他们区域的数据）。

→实施行级别安全性 (RLS)。

原因: RLS 根据用户角色定义筛选规则，在数据模型级别强制执行数据安全性，以便访问同一报告的用户看到不同的数据子集。

需要生成高度格式化、像素完美的报告（如发票或财务报表），这些报告针对打印或 PDF 导出进行了优化。

→使用 Power BI 分页报告。

原因: 分页报告专为打印就绪的布局设计，对页眉、页脚和分页符具有精确控制，这与用于屏幕探索的标准交互式 Power BI 报告不同。

包含数十亿行的 Power BI 数据集刷新时间过长。只有最近几天的数据会频繁更改。

→在数据集上配置增量刷新。

原因: 增量刷新会对数据进行分区（通常按日期），并且只刷新最新的分区，从而显着减少大型数据集的刷新时间和资源使用。

单个 Power BI 报告需要将预加载的高性能数据（导入模式）与来自操作源的实时数据（DirectQuery 模式）结合起来。

→使用 Power BI 复合模型。

原因: 复合模型允许单个数据集混合具有不同存储模式的表，从而提供了平衡性能和数据新鲜度的灵活性。

组织需要发现、分类和编目其混合数据资产中的所有数据资产，以实现数据治理和发现。

→使用 Microsoft Purview。

原因: Purview 是一种统一的数据治理服务，提供自动化数据扫描、业务词汇表、数据分类和端到端数据沿袭可视化。