我刚才写的这篇文章属于专栏《100个问题搞定大数据理论体系》。 这个专栏是笔者原创的。 引用请注明来源。 不足和错误请在评论区指出。 谢谢你。
本专栏的目录结构和文献引用请参考100个解决问题的大数据理论体系
求解Lambda体系结构作为一种模型，提供了在大型数据集上运行高级可伸缩性和高性能分布式计算的方法，最终为批处理和几乎实时处理提供了一致的数据。 Lambda体系结构定义了水平可扩展体系结构的实现方式和手段，以应对企业中的各种数据负载，延迟预期较低。 Lambda模式模型是通过将整个模式划分为多个功能模块/层(layer )来实现的。 是数据取入层、批处理层、高速处理层、数据存储层、服务层、数据获取层、消息层。 数据湖的功能模块如图所示。
补充数据捕获层是Lambda架构模型中的重要层之一，因为它一个接一个地接收数据以处理和存储高速数据捕获层。 在此级别，必须控制将数据快速传递到Lambda体系结构的工作模型。
重要功能此层必须能够满足各种需求，并具有可根据各种负载情况进行扩展的高可扩展性。 此层需要容错能力、系统可靠性和故障转移功能。 层必须支持多线程和多事件处理。 层必须能够将Lambda体系结构处理层所需的导入数据的结构快速转换为目标数据格式。 该层必须确保在下一步中以最纯的形式处理所有提供的数据。 批量级提取数据批量处理的批量级(batch layer )是在Lambda架构中批量处理提取数据以确保系统资源的最佳使用的级别，同时将长时间执行的操作应用于数据，从而输出数据输出数据也称为“模型数据”。
将原始数据转换为模型数据是批处理层的主要作用，包括Lambda架构的服务层(serving layer )向外部提供数据的数据模型。
重要功能此层必须能够在传入的原始数据上执行数据清理、数据处理和数据建模算法。 此层必须提供重新执行特定操作以进行故障恢复的机制。 为了生成高质量的模型数据，该层必须支持在捕获的原始数据上运行机器学习算法或数据科学处理。 在此级别，可能需要执行一些附加操作，以通过删除重复数据、检测错误数据和提供数据序列视图来提高模型数据的整体质量。 高速处理层1对1的接近实时数据处理高速处理层(speed layer )对从数据取入层接收到的数据执行接近实时处理。 由于处理预期几乎是实时的，因此这些数据的处理必须快速高效，支持高并发场景，设计良好，最终生成满足一致要求的输出结果。
关键功能必须支持在特定数据流上的快速操作。 需要能够生成几乎满足实时处理需要的数据模型。 所有需要长时间执行的处理都必须委托给批处理模式。 需要快速访问和存储层支持，并且处理能力要求避免事件堆栈。 必须与数据摄取层的批处理分离。 必须与批处理生成的数据集集成，以生成能够提供更高级企业数据的输出模型。 数据存储层在一个Lambda体系结构模型中存储所有数据，数据存储层(data storage layer )备受关注。 这是为了定义整个解决方案如何对传入事件/数据流作出反应。
从体系结构常识可以看出，一个系统的速度最多与处理链中最慢的子系统相同，因此如果存储层不够快，在接近实时的处理层上执行的操作就会变慢，从而妨碍获得接近实时的效果
在Lambda的整体架构中，对导入的数据几乎有两种主动操作：批处理和实时处理。 批处理和几乎实时处理的数据需求差别很大。
例如，在许多情况下，批处理模式需要执行串行读取和串行写入。 在这种情况下，使用Hadoop存储层就足够了，但如果考虑进行接近实时的处理，需要快速搜索和快速写入，Hadoop存储层可能就不合适了(见下表)。
为了几乎支持实时处理，数据层必须支持特定类型的索引数据存储。
批处理几乎实时处理串行写入和串行读取操作，高速写入的Hadoop存储层不像Hadoop存储层那么重要，它支持串行读取和随机读取。 根据用户使用情况提供适当的分层解决方案。 支持在批量模式或实时模式下处理大容量数据。 以灵活、可扩展的方式支持多种数据结构的存储。 服务层的每一个数据分发和导出Lambda体系结构也强调了为消费者计划提供数据传输服务的重要性。
众所周知，数据可以通过多种方式在系统之间传递。 其中最重要的方法之一是通过服务(service )传递。 在数据湖背景下，传输数据是主要功能，因此这些服务被称为数据服务(data service )。
另一种数据传输方法是数据提取(export )。 最后，数据可以导出为多种格式，包括消息、文件和数据备份，导出的数据将被其他系统占用。
数据传输/服务侧重于如何将数据转换为预期格式。 该格式可以在数据服务对外提供服务时被强制约定为数据合约。
但是，在执行数据传输操作时，将批量处理和几乎实时处理生成的数据结合起来很重要。 因为这些数据可能包含与组织相关的重要信息。
数据服务层必须确保数据和数据合同(与消费者计划的约定)的一致性。
主要功能有多种支持
机制为消费者程序提供数据服务。每种支持数据服务的机制，必须与消费者程序的数据契约兼容。支持批量处理及近实时处理数据视图的合并。为消费者程序提供可扩展、快速响应的数据服务。因为数据服务层的核心职责是向数据湖以外的消费者提供数据服务，出于增强数据表现的考虑，该层可能会选择性地进行数据合并。
数据获取层一一从源系统获取数据企业中数据格式多种多样，可大致分为结构化数据、半结构化数据和非结构化数据。
结构化数据的常见例子包括关系数据库、XML/JSON、系统间传递的消息等。
企业也非常青睐半结构化数据，尤其是E-Mail、聊天记录、文档等。
非结构化数据的典型例子包括图片、视频、原始文本、音频文件等。
对于这些类型的数据，部分数据可能无法对其定义模式( schema)。需要将数据转换为有意义的信息时，模式是非常重要的。
为结构化数据定义模式的方法非常直接，但是无法为半结构化数据或非结构化数据定义模式。
数据获取层的一个关键作用是将数据转换为在数据湖中可进行后续处理的消息。
因此数据获取层必须非常灵活，能适应多种数据模式。同时，它也必须支持快速的连接机制，无缝地推送所有转换过的数据消息到数据湖中去。
数据获取层在数据获取端由多路连接(multi- connector)组件构成，然后将数据推送到特定的目的地。
在数据湖的例子中，目的地指的是消息层。
很多技术框架可以用于构建能支持多种源系统的低延迟的数据获取层。
对于每种源系统类型，数据获取层的连接都需要根据所依赖的底层框架进行特殊配置。
数据获取层会对已获取的数据做少量转换，其目的是最小化传输延迟。
这里的数据转换指的是将已获取的数据转换为消息或事件，它们可以发送给消息层。
如果消息层无法到达(由于网络中断或消息层处于停机期间)，则数据获取层还必须提供所需的安全性保障和故障恢复机制。
为了确保该层的安全性，它应该能够支持本地持久化的消息缓冲，这样，如果需要， 并且当消息层再次可用时，消息可以从本地缓冲区中恢复。
该模块还应该支持故障转移如果其中一个数据获取进程失败，另一个进程将无缝接管，如图所示。
消息层一一数据传输的保障消息层其实就是数据湖架构里的消息中间件(Message Oriented Middleware，MOM)， 该层的主要作用是让数据湖各层组件之间解耦，同时保证消息传递的安全性。
为了确保消息能被正确传输到目的地，消息将会被持久化到某种存储设备中去。被选用的存储设备需要与消息处理需求匹配(结合消息大小及数量等因素)。
更进一步来看，不论是读操作还是写操作，消息中间件都是按队列(queue)方式来处理的，队列天然适合处理串行存取，机械硬盘足以应付此类I/O操作。
对于那些需要每秒处理百万级的消息的大型应用程序来说，SSD能提供更好的I/O性能。
消息层组件必须能对消息队列进行入队列和出队列操作。对于大多数消息处理框架来说，入队列和出队列操作对应的是消息发布与消息消费。
每个消息处理框架都提供了一系列库函数，用于与消息队列的资源连接(如 topic/queue)。
任意消息中间件都支持两类与队列通信的方式以及topic消息结构:
点对点模型：队列通常用于点对点(point-to-point)通信，每个消息应该只被某个消费者消费一次。发布订阅模型：topic概念经常出现于发布/订阅机制中，在这里，一个消息被发布一次，但是被多个订阅者(消费者)消费。一条消息会被多次消费，但是每个消费者消费一次。在消息系统内部， topic基于队列来构建;消息引擎(message engine)对这些队列进行差异化管理，以实现一个发布/订阅机制。队列与topic都可以根据需要配置为持久化或非持久化。出于保障数据发布安全的目的，强烈建议将队列配置为持久化，这样消息将不会丢失。
从较高的层次来看，消息中间件可以抽象为由消息代理(message broker)、消息存储、topic/queue等组件组成的框架。