58、数据仓库与大数据分析：实时架构与最佳实践-优快云博客

本文链接：https://blog.youkuaiyun.com/pca5navigator/article/details/154569013

数据仓库与大数据分析：实时架构与最佳实践

1. ETL 系统设计与实时分区

1.1 消除数据暂存

部分实时架构，特别是企业信息集成（EII）系统，可直接将数据从生产源系统流式传输到用户屏幕，而无需在 ETL 管道中进行永久存储。若此类系统由数据仓库/商业智能（DW/BI）团队负责，团队需与高级管理层深入探讨备份、恢复、存档和合规性责任的归属问题，明确这些责任是由团队承担，还是仅由生产源系统负责。

1.2 展示服务器中的实时分区

为满足实时需求，数据仓库需无缝扩展其现有的历史时间序列至当前时刻。例如，若客户在过去一小时内下了订单，需在整个客户关系的背景下查看该订单，并跟踪当天订单状态的每小时变化。尽管多数情况下生产事务处理系统与 DW/BI 系统之间的延迟已缩短至 24 小时，但业务用户对实时数据的需求仍促使数据仓库填补这一延迟差距。

设计实时分区是应对这一需求的有效方案，它是传统静态数据仓库的扩展。为实现实时报告，需构建一个与传统数据仓库表在物理和管理上分离的特殊分区。理想情况下，实时分区是一个真正的数据库分区，事实表按活动日期进行分区。

实时分区应满足以下要求：
- 包含自静态数据仓库上次更新以来发生的所有活动。
- 尽可能无缝地与静态数据仓库事实表的粒度和内容相链接，理想情况下作为事实表的真正物理分区。
- 索引应尽可能少，以便持续“少量”地加载传入数据。理想情况下，实时分区完全不使用索引，但在某些关系型数据库管理系统（RDBMS）中，由于已构建的索引与分区方案逻辑不一致，这可能无法实现。
- 通过将实时分区固定在内存中，即使在没有索引的情况下也能支持高响应性查询。

实时分区可有效应用于事务和定期快照事实表，但在累积快照事实表中，这种方法并非必需。

1.2.1 事务实时分区

若静态数据仓库事实表采用事务粒度，它将为源系统中自“记录历史”开始的每个单独事务包含一行。实时分区与底层静态事实表具有相同的维度结构，仅包含自上次加载常规事实表的午夜以来发生的事务。由于需要保持持续的加载窗口，且该表仅保存当天的数据，不存在时间序列，因此实时分区可能完全不使用索引。

在一个每天处理 1000 万笔交易的大型零售环境中，静态事实表会非常庞大。假设每个事务粒度行宽为 40 字节（七个维度加三个事实，全部打包到 4 字节的列中），每天将累积 400MB 数据，一年约为 150GB 原始数据。这样的事实表会有大量索引和聚合支持，但每天 400MB 的实时数据切片应固定在内存中。实时分区可在保证快速加载性能的同时，提供快速查询性能。

1.2.2 定期快照实时分区

若静态数据仓库事实表采用定期粒度（如每月），实时分区可视为当前正在发展的月份。以一家拥有 1500 万个账户的大型零售银行为例，静态事实表按账户和月份进行粒度划分，36 个月的时间序列将产生 5.4 亿行事实表数据。该表会有大量索引和聚合支持，以提供良好的查询性能。而实时分区只是当前正在发展月份的一个映像，随着月份的推进不断更新。半加性余额和全加性事实会根据报告频率进行调整。在零售银行中，涵盖所有账户类型的超类型事实表可能较窄，可能有四个维度和四个事实，实时分区大小为 480MB，同样可固定在内存中。

在每月的最后一天，定期实时分区可幸运地合并到不太易变的事实表中，作为最新月份的数据，然后以一个空的实时分区重新开始该过程。

1.3 ETL 系统设计总结

在构建和部署 ETL 系统时，将初始历史加载与持续增量加载分开是一个有趣的视角，这两个过程有很大不同。一般建议使用商业 ETL 工具，而非维护脚本库，尽管 ETL 工具价格昂贵且学习曲线较陡，但 ETL 系统作为 DW/BI 架构的一部分，需要长期可维护和可扩展，能够适应人员变动。

实时数据交付的架构与传统批处理不同，随着延迟的降低，数据质量会受到影响，业务用户需在设计权衡中深思熟虑。

2. 大数据分析概述

2.1 大数据定义

大数据不仅仅是数据量大，它包括结构化、半结构化、非结构化和原始数据等多种不同格式，在某些情况下与过去 30 年存储在数据仓库中的干净标量数字和文本完全不同。许多大数据无法使用类似 SQL 的方式进行分析。更重要的是，大数据代表了一种思维范式的转变，涉及如何看待数据资产、从何处收集数据、如何分析数据以及如何将分析见解货币化。

2.2 大数据用例

大数据分析的用例众多，包括搜索排名、广告跟踪、位置和接近度跟踪、因果因素发现、社交客户关系管理（CRM）、文档相似度测试、基因组学分析、群组发现、飞行中飞机状态监测、智能电表、建筑传感器、卫星图像比较、计算机断层扫描（CAT）比较、金融账户欺诈检测和干预、计算机系统黑客攻击检测和干预、在线游戏手势跟踪、大科学数据分析、通用名称 - 值对分析、贷款风险分析和保险政策承保、客户流失分析等。

2.3 大数据系统要求

传统的 RDBMS 和 SQL 无法满足大数据的存储和分析需求。一个能够全面处理大数据的系统应具备以下能力：
1. 轻松扩展以支持 PB 级（数千 TB）数据。
2. 分布在数千个处理器上，可能地理上分散且异构。
3. 以原始捕获格式存储数据，支持查询和分析应用，无需转换或移动数据。
4. 对高度受限的标准 SQL 查询提供亚秒级响应时间。
5. 在处理请求中嵌入任意复杂的用户定义函数（UDF）。
6. 用多种行业标准的过程语言实现 UDF。
7. 组装涵盖大多数或所有用例的可重用 UDF 库。
8. 在几分钟内对 PB 级数据集执行 UDF 关系扫描。
9. 支持各种数据类型，包括图像、波形、任意层次结构的数据结构和名称 - 值对集合。
10. 以非常高的速率（至少每秒 GB 级）加载数据以进行分析。
11. 在加载过程中以高速率（GB/秒）集成来自多个源的数据。
12. 在声明或发现数据结构之前将数据加载到数据库中。
13. 对传入的加载数据实时执行某些流式分析查询。
14. 以全加载速度就地更新数据。
15. 在不预先对维度表和事实表进行聚类的情况下，将十亿行的维度表与万亿行的事实表进行连接。
16. 调度和执行复杂的数百节点工作流。
17. 配置时避免单点故障。
18. 在处理节点发生故障时实现故障转移和进程继续。
19. 支持极端的混合工作负载，包括数千个地理上分散的在线用户和程序执行从临时查询到战略分析的各种请求，同时以批处理和流式方式加载数据。

2.4 大数据架构

为应对这些挑战，出现了两种架构：扩展 RDBMS 和 MapReduce/Hadoop。

2.4.1 扩展 RDBMS 架构

现有 RDBMS 供应商正在扩展经典的关系数据类型，以包含大数据所需的一些新数据类型。RDBMS 需能够加载和处理更广泛的数据类型，包括复杂结构（如向量、矩阵和自定义超结构数据）、非结构化和半结构化文本、图像、视频和名称 - 值对集合（有时称为数据袋）。

为真正掌控大数据，RDBMS 必须允许业务用户分析师编写的特殊 UDF 在数据库管理系统（DBMS）内循环中处理新数据类型。此外，一个有价值的用例是通过 RDBMS 对数据进行两次处理，第一次将 RDBMS 用作原始数据的事实提取器，第二次将结果作为传统的关系行、列和数据类型反馈回 RDBMS 输入。

2.4.2 MapReduce/Hadoop 架构

MapReduce/Hadoop 是一个开源的顶级 Apache 项目，具有多个组件。MapReduce 是 Google 在 21 世纪初开发的用于跨数千台物理分离的机器进行网页搜索的处理框架，该方法非常通用，完整的 MapReduce 系统可以用多种语言实现，最显著的实现是用 Java。MapReduce 实际上是一个 UDF 执行框架，其中的“F”可以非常复杂。最显著的实现是 Apache Hadoop，它有数千名贡献者和众多不同的应用。Hadoop 原生运行在自己的 Hadoop 分布式文件系统（HDFS）上，也可以读写 Amazon S3 等。传统数据库供应商也在实现接口，允许在其大规模分布式数据库实例上运行 Hadoop 作业。

2.5 大数据架构比较

2.6 大数据最佳实践

尽管大数据市场尚未成熟，但行业已积累了十年的经验，出现了一些针对大数据的最佳实践。以下是一些适用于大数据的通用最佳实践：
- 从业务需求驱动数据仓库数据源的选择。
- 始终关注用户界面的简单性和性能。
- 从维度角度思考：将世界划分为维度和事实。
- 用一致维度集成不同数据源。
- 用缓慢变化维度（SCD）跟踪时间变化。
- 用持久代理键固定所有维度。

此外，大数据最佳实践可分为管理、架构、数据建模和治理四个类别。

2.6.1 大数据管理最佳实践

围绕分析构建大数据环境 ：构建大数据环境应围绕分析，而非临时查询或标准报告。从原始数据源到分析师屏幕的每个数据处理步骤都必须支持以 UDF 形式实现的复杂分析例程，或通过可针对每种分析类型进行编程的元数据驱动开发环境来支持。这包括加载器、清理器、集成器、用户界面和最终的商业智能（BI）工具。
延迟构建遗留环境 ：目前不建议构建遗留大数据环境，因为大数据环境变化迅速，应规划应对来自各方面的颠覆性变化，如新数据类型、竞争挑战、编程方法、硬件、网络技术和众多新大数据供应商提供的服务。在可预见的未来，应在多种实现方法之间保持平衡，包括 Hadoop、传统网格计算、RDBMS 中的下推优化、本地计算、云计算甚至大型机。平台即服务（PaaS）提供商提供了一个有吸引力的选项，可帮助组装兼容的工具集。将 Hadoop 视为一个灵活的通用 ETL 处理环境，目标是为大数据添加足够的结构和上下文，以便将其加载到 RDBMS 中。同一数据在 Hadoop 中可以使用 Hive、Pig、HBase 和用多种语言编写的 MapReduce 代码进行访问和转换。
从沙盒结果构建 ：接受沙盒孤岛并将沙盒结果投入生产。允许数据科学家使用他们首选的语言和编程环境构建数据实验和原型，在概念验证后，由 IT 交接团队系统地重新编程这些实现。例如，自定义分析编程的生产环境可能是 PostgreSQL 中的 MatLab 或 Teradata RDBMS 中的 SAS，但数据科学家可能使用各种他们自己喜欢的语言和架构来构建概念验证。关键在于 IT 必须对数据科学家使用的技术范围保持宽容，并准备在许多情况下将数据科学家的工作重新实现在一套可长期支持的标准技术中。沙盒开发环境可能是直接访问 Hadoop 的自定义 R 代码，但由元数据驱动的 ETL 工具控制。当数据科学家准备移交概念验证时，大部分逻辑可以立即在 ETL 工具下重新部署，以在可扩展、高可用和安全的网格计算环境中运行。
先尝试简单应用 ：可以从简单的大数据应用入手，如备份和存档。在启动大数据项目并寻找有价值的业务用例时，同时积累必要的大数据技能，可考虑使用 Hadoop 作为低成本、灵活的备份和存档技术。Hadoop 可以存储和检索从完全非结构化到高度结构化的各种格式的数据。这种方法还可以帮助解决旧应用程序在未来可能因许可限制而不可用的问题，可将这些应用程序的数据转储到已记录的格式中。

2.6.2 大数据架构最佳实践

规划数据高速公路 ：规划一个具有多个延迟递增缓存的逻辑数据高速公路，并根据实际环境物理实现合适的缓存。数据高速公路最多可包含五个延迟递增的数据缓存，每个缓存都有其独特的分析优势和权衡，具体如下：
- 原始源应用 ：信用卡欺诈检测、即时复杂事件处理（CEP），包括网络稳定性和网络攻击检测。
- 实时应用 ：网页广告选择、个性化价格促销、在线游戏监控。
- 业务活动应用 ：低延迟关键绩效指标（KPI）仪表板推送给用户、故障单跟踪、流程完成跟踪、“融合”CEP 报告、客户服务门户和仪表板以及移动销售应用。
- 顶级应用 ：战术报告、促销跟踪、基于社交媒体热度的中途修正。顶级指高级管理人员查看企业过去 24 小时情况的快速概览。
- 数据仓库和长期时间序列应用 ：各种报告、临时查询、历史分析、主数据管理、大规模时间动态和马尔可夫链分析。

每个缓存都是物理上独立的，数据通过 ETL 过程从原始源沿着高速公路向下流动，可能存在从原始源到中间缓存的多条路径。例如，数据可以进入实时缓存以驱动零延迟的用户界面，同时也可以直接提取到每日顶级缓存中，该缓存类似于经典的运营数据存储（ODS），然后 ODS 中的数据可以流入数据仓库。数据也可以沿着高速公路反向流动。

构建大数据事实提取器 ：利用大数据分析作为事实提取器，将数据移动到下一个缓存。例如，对非结构化文本推文的分析可以产生一系列数值、可趋势化的情感指标，如话语权份额、受众参与度、对话覆盖范围、活跃倡导者、倡导者影响力、倡导影响、解决率、解决时间、满意度得分、话题趋势、情感比率和想法影响等。
构建综合生态系统 ：使用大数据集成构建综合生态系统，集成传统结构化 RDBMS 数据、文档、电子邮件和内部面向业务的社交网络。大数据的一个强大之处在于能够集成不同形式的不同数据源。例如，一个大型金融机构处理数百万个账户、数千万份相关纸质文件以及数千名组织内部和外部的专业人员（作为合作伙伴或客户）。可以建立一个安全的社交网络，让所有可信方在业务开展过程中进行沟通，并将这些重要的沟通信息以可查询的方式保存下来。可以将这些信息捕获到 Hadoop 中，进行维度化处理，在业务过程中使用，然后进行备份和存档。
规划数据质量 ：规划数据质量在数据高速公路上逐步提高。这是延迟与质量之间的经典权衡。分析师和业务用户必须接受低延迟（即时）数据不可避免地存在脏数据的现实，因为在极短的时间间隔内，数据清洗和诊断能力有限。对单个字段内容的测试和修正可以在最快的数据传输速率下进行，但对字段之间和跨数据源的结构关系的测试和修正必然较慢。涉及复杂业务规则的测试和修正时间从瞬间（如一组日期按特定顺序排列）到任意长（如等待查看是否超过异常事件阈值）不等。较慢的 ETL 过程（如为每日顶级缓存提供数据的过程）通常基于更完整的数据构建，例如消除了不完整事务集和被拒绝的事务。在这种情况下，即时数据馈送可能没有正确的信息。
尽早为数据增加价值 ：在数据处理的最早阶段应用过滤、清理、修剪、一致化、匹配、连接和诊断等操作。这是上述数据质量最佳实践的推论。数据高速公路上的每个步骤都为数据增加价值提供了更多时间。过滤、清理和修剪数据可以减少传输到下一个缓存的数据量，消除无关或损坏的数据。不过，也有一种观点认为，应仅在分析运行时应用清理逻辑，因为清理可能会删除“有趣的异常值”。一致化是将高度管理的企业属性放置到主要实体（如客户、产品和日期）中的积极步骤，这些一致化属性的存在允许在不同应用领域之间进行高价值的连接，也可称为“集成”。诊断可以为数据添加许多有趣的属性，包括特殊置信标签和代表数据挖掘专业人员识别的行为集群的文本标识符。
实现回流到早期缓存 ：实现数据回流，特别是从数据仓库回流到数据高速公路上的早期缓存。数据仓库中高度管理的维度（如客户、产品和日期）应与早期缓存中的数据建立连接。理想情况下，所有缓存中这些实体只需使用唯一持久键即可。每个 ETL 步骤的首要任务是用唯一持久键替换特殊的专有键，以便每个缓存中的分析可以通过在唯一持久键上进行简单连接来利用上游的丰富内容。在不到一秒的时间内将原始源数据传输到实时缓存时，这个 ETL 步骤是否可行，仍有待探讨。除了维度数据，事实表的派生数据（如历史摘要和复杂数据挖掘结果）也可以打包为简单指标或总计，然后传输到早期缓存。
在选定数据流中实现流式数据分析 ：在选定的数据流中实现流式数据分析。低延迟数据的一个有趣方面是需要在数据流入时就开始进行深入分析，甚至可能在数据传输过程结束之前。流式分析系统备受关注，它允许类似 SQL 的查询在数据流入系统时进行处理。在某些用例中，当流式查询的结果超过阈值时，可以提前终止分析，而无需完成整个作业。一种名为连续查询语言（CQL）的学术努力在定义流式数据处理要求方面取得了显著进展，包括为流式数据上的动态移动时间窗口提供巧妙的语义。可以期待在 RDBMS 和 HDFS 部署数据集的加载程序中看到 CQL 语言扩展和流式数据查询功能。理想的实现方式是在以每秒 GB 级的速度加载数据的同时进行流式数据分析。
避免边界崩溃 ：为避免边界崩溃，应在可扩展性方面设置远限。在早期计算机编程时代，由于硬盘和内存容量极小，边界崩溃很常见，是应用程序开发的难题。当应用程序耗尽磁盘空间或内存时，开发人员不得不采取复杂的措施，这些措施通常需要大量编程，但对应用程序的主要功能并无帮助。虽然普通数据库应用的边界崩溃问题已基本解决，但大数据再次引发了这个问题。Hadoop 架构极大地减少了编程可扩展性方面的担忧，因为在很大程度上可以无限添加通用硬件。当然，即使是通用硬件也需要进行配置、连接并具备高带宽网络连接。因此，应提前规划应对大规模数据量和高吞吐量的扩展。
将原型迁移到私有云 ：考虑在公共云上进行大数据原型开发，然后迁移到私有云。公共云的优势在于可以立即进行配置和扩展。在数据敏感性允许快速进行原型开发的情况下，这种方法非常有效。但要注意，当程序员周末离开时，不要将大量数据集留在公共云提供商处。不过，在某些需要利用数据局部性的 Rack - aware MapReduce 过程中，可能无法使用公共云服务，因为它可能无法提供所需的数据存储控制。
追求性能改进 ：随着时间的推移，应寻找并期待性能提高 10 到 100 倍，认识到高速分析带来的范式转变。大数据市场的开放性催生了许多针对特定分析的专用紧密编码解决方案。这既是福音也是挑战。当不受大型供应商的 RDBMS 优化器和内循环的控制时，聪明的开发人员可以实现比标准技术快 100 倍的局部解决方案。例如，在将十亿行维度表与万亿行事实表连接的“大连接”问题上已经取得了显著进展。但挑战在于这些单个局部解决方案可能不属于统一的单一架构。

目前，大数据集的可视化是一个热门主题，“浏览”PB 级数据需要出色的性能。大数据可视化是一个令人兴奋的新开发领域，它既有助于分析，也有助于发现意外特征和进行数据探查。另一个对性能要求极高的应用是“无预聚合的语义缩放”，分析师可以从高度聚合的级别逐步深入到非结构化或半结构化数据的更详细级别，类似于在地图上进行缩放。这一最佳实践的重要启示是，性能提高 10 到 100 倍可以带来在消费和分析大数据能力上的革命性进步，因此必须准备将这些发展纳入工具套件。

监控计算资源 ：将大数据分析工作负载与传统数据仓库分离，以维护服务级别协议。如果大数据托管在 Hadoop 中，它可能不会与基于传统 RDBMS 的数据仓库竞争资源。但如果大数据分析在数据仓库机器上运行，则需谨慎，因为大数据需求变化迅速，必然会朝着需要更多计算资源的方向发展。
利用数据库内分析 ：充分利用数据库内分析的独特功能。主要的 RDBMS 厂商都在数据库内分析方面进行了大量投资。在将数据加载到关系表后，可以将 SQL 与分析功能相结合，以实现更高效的数据分析。

2.6.3 大数据数据建模最佳实践

维度建模 ：采用维度建模方法，将数据划分为维度表和事实表。维度表包含描述性信息，如时间、地点、产品等，事实表则包含具体的业务度量，如销售额、数量等。这种建模方式有助于提高查询性能和数据分析的灵活性。
一致维度 ：确保不同数据源之间的维度一致，使用一致的维度定义和编码，以便进行跨数据源的分析和整合。例如，在不同的业务系统中，客户维度的定义和编码应该保持一致。
缓慢变化维度处理 ：处理缓慢变化维度（SCD），即维度属性随时间发生变化的情况。常见的处理方法包括类型 1（覆盖旧值）、类型 2（保留历史记录）和类型 3（记录变化的属性）。根据业务需求选择合适的处理方法，以准确跟踪维度的变化。
灵活的数据结构 ：设计灵活的数据结构，以适应大数据的多样性和变化性。可以采用嵌套结构、数组、JSON 等数据类型，存储复杂的数据结构和关系。

2.6.4 大数据治理最佳实践

数据标准制定 ：制定统一的数据标准，包括数据定义、数据格式、数据质量规则等。确保数据在整个组织内的一致性和准确性，提高数据的可用性和可理解性。
数据安全管理 ：加强数据安全管理，保护大数据的隐私和机密性。采用访问控制、加密、审计等技术手段，防止数据泄露和滥用。
元数据管理 ：建立完善的元数据管理体系，记录数据的来源、含义、使用方式等信息。元数据管理有助于数据的发现、理解和使用，提高数据治理的效率。
数据质量管理 ：实施全面的数据质量管理，包括数据清洗、验证、监控等环节。及时发现和纠正数据中的错误和异常，确保数据的质量符合业务需求。

3. 总结

大数据分析为企业带来了新的机遇和挑战。在构建数据仓库和实施大数据分析时，需要综合考虑实时架构、系统设计、最佳实践等多个方面。通过采用合适的架构和最佳实践，可以提高数据处理和分析的效率，为企业提供更有价值的决策支持。

同时，为了更清晰地展示数据在数据高速公路上的流动和处理过程，下面给出 mermaid 格式流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(原始源应用):::process --> B(实时缓存):::process
    A --> C(业务活动缓存):::process
    A --> D(顶级缓存):::process
    A --> E(数据仓库和长期时间序列):::process
    B --> C
    C --> D
    D --> E
    E --> D(回流)
    D --> C(回流)
    C --> B(回流)
    B --> A(回流)

在未来的发展中，随着技术的不断进步和大数据应用的不断拓展，企业需要持续关注大数据领域的最新动态，不断优化和改进数据处理和分析的方法，以适应市场的变化和竞争的需求。同时，要注重培养和吸引大数据领域的专业人才，提高企业的大数据分析能力和创新能力。通过合理利用大数据，企业可以更好地了解市场和客户需求，优化业务流程，提高运营效率，实现可持续发展。