大数据架构

大数据架构通常用来解决大量的(Volume)、高速的(Velocity)、多样化 (Variety) 的数据引入、处理和分析等方面的问题

大数据组件

• 数据源

  应用数据存储，如MySQL、PostgreSql、日志文件、Kafka等

• 数据存储

  批处理数据通常存储在分布式文件系统中，这类存储通常称为 Data Lake。如：HDFS、Hive、Azure Data Lake Store、S3等

• 批处理

  由于数据集很大，因此大数据解决方案通常必须使用长时间运行的批处理作业来处理数据文件，以便筛选、聚合和准备用于分析的数据。 这些作业通常涉及读取源文件、对它们进行处理，以及将输出写入到新文件。 选项包括在 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 流式处理技术，例如 Spark Streaming、Flink等

• 机器学习

  通过（从批处理或流式处理）读取准备进行分析的数据，可使用机器学习算法来生成可预测结果或对数据进行分类的模型。 可以在大型数据集上训练这些模型，并且生成的模型可用于分析新数据并做出预测

• 分析数据存储

  许多大数据解决方案会先准备用于分析的数据，然后以结构化格式提供已处理的数据供分析工具查询。 用于支持这些查询的分析数据存储可以是 Kimball 样式的关系数据仓库，如大多数传统商业智能 (BI) 解决方案中可见的那样。 或者，数据也可以通过低延迟 NoSQL 技术（如 HBase）或 Interactive Hive 数据库中呈现，该数据库提供分布式数据存储中数据文件的元数据抽象。 Azure Synapse Analytics 为大规模、基于云的数据仓库提供托管服务。 HDInsight 支持 Interactive Hive、HBase 和 Spark SQL，它们还可以用于提供数据以进行分析

• 分析和报告

  大多数大数据解决方案的目的是通过分析和报告提供对数据的见解。 若要使用户能够对数据进行分析，架构可以包括一个数据建模层，例如 Azure Analysis Services 中的多维 OLAP 多维数据集或表格数据模型。 它还可以使用 Microsoft Power BI 或 Microsoft Excel 中的建模和可视化技术支持自助式 BI。 分析和报告还可以采用适用于数据科学家或数据分析人员的交互式数据浏览形式。 对于这些方案，许多 Azure 服务都支持分析笔记本（例如 Jupyter），这允许这些用户通过 Python 或 R 利用其现有技能。对于大规模数据浏览，可以使用 Microsoft R Server，可以独立使用，也可以将其与 Spark 一起使用

• 业务编排

  大多数大数据解决方案都包括重复的数据处理操作（封装在工作流中），这些操作对源数据进行转换、在多个源和接收器之间移动数据、将已处理的数据加载到分析数据存储中，或者直接将结果推送到报表或仪表板

Lambda 架构

Lambda 架构是一种大数据处理架构，它的核心思想是将不可变的数据以追加的方式并行写到批和流处理系统内，随后将相同的计算逻辑分别在流和批系统中实现，并且在查询阶段合并流和批的计算视图并展示给用户 Lambda 架构通常包含三层，Batch Layer、Speed Layer 和 Serving Layer。架构图如下

• Batch Layer

  批处理层(冷路径):以原始形式存储所有传入数据，对数据进行批处理。 该处理的结果作为批处理视图存储。批处理层可以用 Hadoop、Spark 和 Flink 等框架计算

• Speed Layer

  速度层(热路径):，处理实时的增量数据，这一层重点在于低延迟。加速层的数据不如批处理层那样完整和准确，但是可以填补批处理高延迟导致的数据空白。速度层可以用 Storm、Spark streaming 和 Flink 等框架计算

• Serving Layer

  合并层，计算历史数据和实时数据都有了， 合并层的工作自然就是将两者数据合并，输出到数据库或者其他介质，供下游分析

下面是一个典型的典互联网大数据平台的架构

Kappa 架构

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

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

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

如需重新计算整个数据集（相当于 Lambda 中批处理层执行的操作），只需重播该流即可，通常可使用并行方式及时完成计算