大数据架构

大数据架构旨在处理传统数据库系统难以应对的大规模和复杂数据。不同组织进入大数据领域的门槛各异，具体取决于用户权限及工具功能。对于某些组织，大数据可能意味着数百GB的数据，而对于其他组织，则可能意味着数百TB的数据。随着处理大数据集的工具不断进步，大数据的概念也在不断发展。现在，大数据更多是指通过高级分析从数据集中获取价值，尽管这些数据集往往非常庞大。

多年来，数据格局一直在演变。数据的功能和预期用途不断变化，存储成本显著下降，而数据收集手段不断增加。一些数据需要实时收集和监控，而另一些数据则以较大的数据块形式存在，通常是几十年的历史数据。你面临的问题可能是高级分析问题，也可能是需要机器学习的问题。这些都是大数据架构试图解决的挑战。

大数据解决方案通常涉及以下几种类型的工作负载： - 批处理静态大数据源 - 实时处理移动中的大数据 - 交互式大数据读取 - 预测分析和机器学习

当需要处理以下问题时，可以考虑使用大数据架构： - 存储和处理传统数据库系统无法承受的数据量 - 将非结构化数据转换为可用于分析和报告的数据 - 实时或低延迟捕获、处理和分析数据流

大数据架构的组件

大多数大数据架构包含以下组件中的部分或全部：

数据源：所有大数据解决方案都始于一个或多个数据源。例如： - 应用程序数据存储，如关系数据库 - 应用程序生成的静态文件，如Web服务器日志文件 - 实时数据源，如物联网设备

数据存储：用于批处理操作的数据通常存储在分布式文件系统中，可以容纳多种格式的大型文件。这种存储通常被称为“数据湖”。存储选项包括Azure Data Lake Store和Azure Blob存储。

批处理：由于数据集较大，大数据解决方案通常需要长时间运行的批处理作业来处理数据文件，以挑选、聚合和准备用于分析的数据。这些作业通常涉及读取源文件、处理它们，并将输入写入新文件。处理选项包括在Azure Data Lake Analytics中运行U-SQL作业，在HDInsight Hadoop集群中使用Hive、Pig或自定义Map/Reduce作业，或在HDInsight Spark集群中使用Java、Scala或Python程序。

实时数据摄入：如果解决方案包括实时数据源，架构必须包含一种捕获并存储实时数据的方法。这可以是一个简单的数据存储，用于将传入数据放置在一个文件夹中以进行处理。然而，许多解决方案需要一个消息队列来充当消息缓冲区，支持横向扩展处理、可靠传递和其他消息队列功能。流处理架构通常称为流缓冲。选项包括Azure事件中心、Azure IoT中心和Kafka。

流处理：捕获实时数据后，解决方案必须通过选择、聚合和准备用于分析的数据来处理数据。然后，处理后的流数据会被写入输入接收器。Azure流分析提供了基于持续运行的SQL查询的托管流处理服务，这些查询对有限的数据流进行操作。此外，还可以在HDInsight集群中使用开源Apache流处理技术，如Storm和Spark Streaming。

分析数据存储：许多大数据解决方案会先准备好用于分析的数据，然后以结构化格式提供已处理的数据供分析工具查询。分析数据存储可以是Kimball样式的关系数据仓库，或通过低延迟NoSQL技术（如HBase）或Interactive Hive数据库提供。Azure SQL数据仓库为大规模云数据仓库提供托管服务。HDInsight支持交互式Hive、HBase和Spark SQL，也可以使用这些技术提供用于分析的数据。

分析和报告：大多数大数据解决方案的目的是通过分析和报告提供对数据的洞察。架构可以包括一个数据建模层，如Azure Analysis Services中的多维OLAP多维数据集或表格数据模型。它还可以使用Microsoft Power BI或Microsoft Excel中的建模和可视化工具支持自助式BI。对于数据科学家或分析师，可以使用分析笔记本（如Jupyter），允许这些用户通过Python或R应用其现有技能。对于大规模数据读取，可以使用Microsoft R Server，可以独立使用，也可以与Spark一起使用。

业务流程：大多数大数据解决方案都包括反复的数据处理操作（封装在工作流中），这些操作对源数据进行转换，在多个源和接收器之间移动数据，将已处理的数据加载到分析数据存储中，或将结果直接推送到报表或仪表板。自动化这些工作流可以使用Azure数据工厂或Apache Oozie和Sqoop等业务流程技术。

Lambda架构

处理极大型数据集时，客户端所需的查询类型可能需要很长时间。这些查询无法实时执行，通常需要使用MapReduce等算法对整个数据集进行并行操作。然后，结果会与原始数据分开存储，用于查询。

这种方法的一个缺点是存在延迟——如果处理需要数小时，那么查询返回的结果可能是数小时前的数据。更好的做法是获取一些实时结果（可能准确性稍差），然后将这些结果与批处理分析结果结合在一起。

Lambda架构由Nathan Marz提出，通过创建两个数据流路径解决了这个问题。所有进入系统的数据都会经过这两个路径： - 批处理层（冷路径）：以原始方式存储所有传入数据，并进行批处理。处理结果作为批处理视图存储。 - 速度层（热路径）：实时分析数据。设计此层是为了降低延迟，但牺牲了一定的准确性。

批处理层将结果反馈到服务层中，后者编制批处理视图的索引以提高查询效率。速度层根据最新数据使用增量更新来更新服务层。

流入热路径的数据受到速度层的延迟要求约束，因此可以尽快处理。通常情况下，这需要牺牲一定的准确性，以便数据尽快就绪。例如，在使用某个物联网方案时，可以通过大量温度传感器发送遥测数据。可以使用速度层来处理传入数据的滑动时间窗口。

另一方面，流入冷路径的数据不受这些相同的低延迟要求约束。这使得可以在大型数据集上进行高精度计算，而这些计算可能需要较长时间。

热路径和冷路径最终在分析客户端应用程序处汇合。如果需要实时显示时间敏感但准确性要求不高的数据，客户端将从热路径获取结果。否则，客户端将从冷路径选择结果以显示时间敏感但准确性要求高的数据。换句话说，一开始可以使用时限较短的热路径数据作为结果，稍后再使用冷路径的更准确数据更新结果。

存储在批处理层的原始数据是不可变的。传入数据始终追加到现有数据上，不会覆盖以前的数据。对特定基准值的更改将作为带有时间戳的新事件记录存储。这样可以选择历史记录中任意时间点的已收集数据重新进行计算。根据最后的原始数据重新计算批处理视图这一功能非常重要，因为它可以随着系统的不断发展创建新的视图。

Kappa架构

Lambda架构的一个缺点是复杂性。处理逻辑显示在冷路径和热路径两个不同的位置，并使用不同的框架。这导致计算逻辑重复，并且两个路径的架构管理起来也很复杂。

Kappa架构由Jay Kreps提出，用于替代Lambda架构。它具有与Lambda架构相同的基本目标，但有一个重要的区别：所有数据都通过一个路径流动，并使用一个流处理系统。

某些方面与Lambda架构的批处理层有些相似，即事件数据是不可变的，并且可以收集所有数据，而不是只收集一部分。数据作为事件流引入到一个容错的分布式一致日志中。这些事件按顺序排列。一个事件的当前状态只有在追加新事件的情况下才会改变。与Lambda架构的速度层相似，所有事件处理都在输入流的基础上进行，并作为实时视图保存。

如果需要重新计算整个数据集（类似于Lambda架构中的批处理层操作），只需重播该流即可，通常可以使用并行方式及时完成计算。

物联网（IoT）

从应用角度来看，物联网（IoT）涵盖了连接到互联网的所有设备，包括计算机、移动电话、智能表、智能恒温器、智能冰箱、联网汽车、植入式心脏监护仪，以及任何可以连接到互联网并发送或接收数据的设备。连接的设备数量不断增加，从它们收集的数据量也在增加。通常情况下，这些数据是在受到严格限制且有时延迟严重的环境中收集的。然而，在另一些情况下，数据是在低延迟环境中通过成千上万甚至数百万台设备发送的，这就要求能够快速引入数据并进行相应的处理。因此，为了应对这些约束和特殊要求，需要正确地进行规划。

事件驱动的架构是IoT解决方案的核心。下图显示了IoT可能出现的逻辑架构。这张图强调了事件流式传输组件。

云网关：使用可靠的低延迟消息传递系统在云边界引入设备事件。

设备可以直接将事件发送到云网关，也可以通过现场网关发送。现场网关是一种公用设备或软件，通常与接收事件并将事件转接到云网关的设备位于同一位置。现场网关还可以预处理原始设备事件，执行过滤、聚合或协议转换等功能。

引入后，事件将通过一个或多个流处理器，这些处理器可以将数据路由到存储或其他位置，也可以执行分析和其他处理。

常见处理类型： - 将事件数据写入冷存储，用于归档或批处理分析 - 热路径分析，实时或近乎实时地分析事件流，以检测异常、识别滚动时间范围内的模式，或在流中出现特殊情况时触发警报 - 处理设备中的特殊类型非遥测事件，如通知和警报 - 机器学习

灰色阴影框：表示IoT系统的组件，虽然这些组件与事件流式传输没有直接关系，但为了完整性，仍在此处提出。 - 设备注册表：预配设备的数据库，包括设备ID和常见的设备元数据，如位置信息。 - 预配API：一种常见的外部接口，用于预配和注册新设备。 - 某些IoT解决方案允许命令和控制消息发送到设备。

希望这些内容对你有所帮助！