1.数据湖诞生
数据湖概念的诞生，源自企业面临的一些挑战，如数据应该以何种方式处理和存储。最开始的时候，每个应用程序会产生、存储大量数据，而这些数据并不能被其他应用程序使用，这种状况导致数据孤岛的产生。随后数据集市应运而生，应用程序产生的数据存储在一个集中式的数据仓库中，可根据需要导出相关数据传输给企业内需要该数据的部门或个人。然而数据集市只解决了部分问题。剩余问题，包括数据管理、数据所有权与访问控制等都亟须解决，因为企业寻求获得更高的使用有效数据的能力。为了解决前面提及的各种问题，企业有很强烈的诉求搭建自己的数据湖，数据湖不但能存储传统类型数据，也能存储任意其他类型数据，并且能在它们之上做进一步的处理与分析，产生最终输出供各类程序消费。
2.数据湖定义及优势
2.1 数据湖的定义
数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。
数据湖从企业的多个数据源获取原始数据，并且针对不同的目的，同一份原始数据还可能有多种满足特定内部模型格式的数据副本。因此，数据湖中被处理的数据可能是任意类型的信息，从结构化数据到完全非结构化数据。企业对数据湖寄予厚望，希望它能帮助用户快速获取有用信息，并能将这些信息用于数据分析和机器学习算法，以获得与企业运行相关的洞察力。
2.2 数据湖优势
有上可知数据湖负责捕获数据、处理数据、分析数据，以及为消费者系统提供数据服务。
数据湖能从以下方面帮助到企业：
·实现数据治理（data governance）与数据世系。
·通过应用机器学习与人工智能技术实现商业智能。
·预测分析，如领域特定的推荐引擎。
·信息追踪与一致性保障。
·根据对历史的分析生成新的数据维度。
·有一个集中式的能存储所有企业数据的数据中心，有利于实现一个针对数据传输优化的数据服务。
·帮助组织或企业做出更多灵活的关于企业增长的决策。
2.3 数据生命周期
首先，了解一下数据湖中数据的生命周期：
数据生命周期
数据湖中数据的整个生命周期中，可以从元数据管理，数据的可追溯性，数据世系，数据安全等几个方面对数据进行管理。
数据世系被定义为数据的生命周期，包括数据的起源以及数据是如何随时间移动的。它描述了数据在各种处理过程中发生了哪些变化，有助于提供数据分析流水线的可见性，并简化了错误溯源。
可追溯性是通过标识记录来验证数据项的历史、位置或应用的能力。
2.4 数据湖与数据仓库
数据湖与数据仓库的区别，如下图：
数据湖与数据仓库的区别
数据湖与数据仓库的区别
从区别来看，应该视为相互补充。
2.5 数据湖构建方法
不同的组织有不同的偏好，因此它们构建数据湖的方式也不一样。构建方法与业务、处理流程及现存系统等因素有关。
简单的数据湖实现几乎等价于定义一个中心数据源，所有的系统都可以使用这个中心数据源来满足所有的数据需求。虽然这种方法可能很简单，也很划算，但它可能不是一个非常实用的方法，原因如下：
·只有当这些组织重新开始构建其信息系统时，这种方法才可行。
·这种方法解决不了与现存系统相关的问题。
·即使组织决定用这种方法构建数据湖，也缺乏明确的责任和关注点隔离（responsibility and separation of concerns）。
·这样的系统通常尝试一次性完成所有的工作，但是最终会随着数据事务、分析和处理需求的增加而分崩离析。
更好的构建数据湖的策略是将企业及其信息系统作为一个整体来看待，对数据拥有关系进行分类，定义统一的企业模型。这种方法虽然可能存在流程相关的挑战，并且可能需要花费更多的精力来对系统元素进行定义，但是它仍然能够提供所需的灵活性、控制和清晰的数据定义以及企业中不同系统实体之间的关注点隔离。这样的数据湖也可以有独立的机制来捕获、处理、分析数据，并为消费者应用程序提供数据服务。
3. lamda架构构建数据湖
下图给出了一个数据湖的功能模块，我们由此展开叙述：
数据湖中的功能模块
3.1 数据获取层
数据获取层其实就是数据采集层。
企业中数据格式多种多样，可大致分为结构化数据、半结构化数据和非结构化数据。
结构化数据的常见例子包括关系数据库、XML/JSON、系统间传递的消息等。企业也非常青睐半结构化数据，尤其是E-Mail、聊天记录、文档等。非结构化数据的典型例子包括图片、视频、原始文本、音频文件等。
对于这些类型的数据，部分数据可能无法对其定义模式（schema）。需要将数据转换为有意义的信息时，模式是非常重要的。为结构化数据定义模式的方法非常直接，但是无法为半结构化数据或非结构化数据定义模式。
数据获取层的一个关键作用是将数据转换为在数据湖中可进行后续处理的消息。因此数据获取层必须非常灵活，能适应多种数据模式。同时，它也必须支持快速的连接机制，无缝地推送所有转换过的数据消息到数据湖中去。
数据获取层在数据获取端由多路连接（multi-connector）组件构成，然后将数据推送到特定的目的地。在数据湖的例子中，目的地指的是消息层，如下图所示：
数据获取组件
很多技术框架可以用于构建能支持多种源系统的低延迟的数据获取层。对于每种源系统类型，数据获取层的连接都需要根据所依赖的底层框架进行特殊配置。数据获取层会对已获取的数据做少量转换，其目的是最小化传输延迟。这里的数据转换指的是将已获取的数据转换为消息或事件，它们可以发送给消息层。
如果消息层无法到达（由于网络中断或消息层处于停机期间），则数据获取层还必须提供所需的安全性保障和故障恢复机制。
为了确保该层的安全性，它应该能够支持本地持久化的消息缓冲，这样，如果需要，并且当消息层再次可用时，消息可以从本地缓冲区中恢复。该模块还应该支持故障转移，如果其中一个数据获取进程失败，另一个进程将无缝接管，如下图所示。
数据获取层的组件
3.2 消息层
消息层其实就是数据湖架构里的消息中间件，该层的主要作用是让数据湖各层组件之间解耦，同时保证消息传递的安全性。
为了确保消息能被正确传输到目的地，消息将会被持久化到某种存储设备中去。被选用的存储设备需要与消息处理需求匹配（结合消息大小及数量等因素）。更进一步来看，不论是读操作还是写操作，消息中间件都是按队列（queue）方式来处理的，队列天然适合处理串行存取，机械硬盘足以应付此类I/O操作。对于那些需要每秒处理百万级的消息的大型应用程序来说，SSD能提供更好的I/O性能。
消息层组件必须能对消息队列进行入队列和出队列操作，如图2-5所示。对于大多数消息处理框架来说，入队列和出队列操作对应的是消息发布与消息消费。每个消息处理框架都提供了一系列库函数，用于与消息队列的资源连接（如topic/queue）。
消息队列
任意消息中间件都支持两类与队列通信的方式以及topic消息结构，如下所列：
·队列通常用于点对点（point-to-point）通信，每个消息应该只被某个消费者消费一次。
·topic概念经常出现于发布/订阅机制中，在这里，一个消息被发布一次，但是被多个订阅者（消费者）消费。一条消息会被多次消费，但是每个消费者消费一次。在消息系统内部，topic基于队列来构建；消息引擎（message engine）对这些队列进行差异化管理，以实现一个发布/订阅机制。
队列与topic都可以根据需要配置为持久化或非持久化。出于保障数据发布安全的目的，强烈建议将队列配置为持久化，这样消息将不会丢失。
从较高的层次来看，消息中间件可以抽象为由消息代理（message broker）、消息存储、topic/queue等组件组成的框架或引擎。
下图从较高的抽象角度描述了，消息队列的内部模块：
消息队列的内部模块
常见选型是kafka，rmq，pulsar等
3.3 数据摄取层
数据摄取层负责消费消息层中的消息，对消息做适当的转换，从中提取所期望的信息，然后传输给Lambda层供其处理。数据摄取层的输出必须与期望的数据存储或处理格式一致。该层也必须保证消息以一致性的方式消费掉，即没有消息丢失并且每条消息至少被消费一次。
数据摄取层被期望能支持多个消费者/线程来并行消费消息。每个消费者必须是无状态的，并且能快速处理流式数据。从消息层导出的多个数据流中的数据会源源不断地涌入Lambda层。数据摄取层必须确保消息消费速度不低于消息生成速度，这样消息/事件处理就不会有延迟。较慢的处理速度会导致消息层中消息的堆积，会对系统处理消息/事件的近实时特性造成伤害。该层应支持快速消费策略，在必要时恢复因消息堆积而导致的系统故障。
因此，该层有一个隐含的要求，即这一层需要一直保持近实时性，具有最小延迟，这样消息层就不会堆积任何消息。为了保障近实时性，该层必须有能力持续地消费消息/事件，及对故障进行恢复。
消息消费者
消息消费者扮演了向Lambda层递送消息供其处理的关键角色，如上图所示，因此消息消费者的内部组件与数据获取层非常相似，差别在于消息消费者知道从消息层（源）获取的消息及发送至Lambda层（目的地）的消息的格式。消息的消费行为可能是以微批量（micro-batches）方式来处理，这样能实现资源的最优利用，使系统效率更高。
此处，为了解耦，浪尖觉得在数据摄取层和lambda之间应该再加一层消息队列。
3.4 lambda架构
摄取层后就是离线处理和实时处理组成的lambda架构。
lambda架构图-网络
1).离线处理
批处理层（batch layer）是Lambda架构中对已提取数据进行批量处理的层，以确保系统资源的最佳利用，同时也可将长时间运行的操作应用于数据，以确保输出数据的高质量。输出数据也称为模型数据（modeled data）。将原始数据转换为模型数据是批处理层的主要职责，其中，模型数据中蕴含了Lambda架构中服务层（serving layer）向外提供数据的数据模型。该层主要职责如下所列：
·该层必须能在已摄取的原始数据之上执行数据清理、数据处理、数据建模算法。
·该层必须提供重新执行（replay/rerun）某些操作的机制，以实现故障恢复。
·该层必须支持在已摄取的原始数据之上执行机器学习算法或数据科学处理，以产生高质量的模型数据。
·该层可能需要执行一些其他操作，以期通过移除重复数据、检测错误数据和提供数据世系视图来提高模型数据的整体质量。
这层常见的处理架构就是：mapreduce，spark core，spark sql等。
2).实时处理
近实时处理层（speed layer）将对从数据摄取层接收的数据执行近实时处理。由于处理预期接近实时，因此这些数据的处理需要快速、高效，为高并发场景提供支持和相应的精心设计，并且最终产生满足一致性要求的输出结果。很多因素可以影响快速处理层的特性，这些将在本书的后面部分详细讨论。简单来说，该层应包含以下功能：
·必须支持在特定数据流之上的快速操作。
·必须能生成满足近实时处理需求的数据模型。所有需要长时间运行的处理必须被委托给批处理模式。
·必须有快速访问能力和存储层的支持，这样就不会因为处理能力而导致事件的堆积。
·必须与数据摄取层的批处理过程分离。
目前常用的实时处理或者近实时处理方案是：flink，spark streaming。
其实，与之相对的还有一个kappa架构，后面浪尖会继续介绍。
3.5 存储层
在Lambda架构模式中，数据存储层（data storage layer）非常引人注目，因为该层定义了整个解决方案对传入事件/数据流的反应。由架构常识可知，一个系统的速度最多与处理链中最慢的子系统一样快，因此，如果存储层不够快，由近实时处理层执行的操作将会变得很慢，从而阻碍了该架构达到近实时的效果。
在Lambda的总体架构中，针对已摄取的数据有两种主动操作：批处理和近实时处理。批处理和近实时处理的数据需求差别很大。例如，在大多数情况下，批处理模式需要执行串行读和串行写操作，此时使用Hadoop存储层就足够了，但是如果我们考虑近实时处理，需要快速查找和快速写入，那么Hadoop存储层可能是不合适的（见表2-2）。为了支持近实时处理，需要数据层支持某些类型的索引数据存储。
表2-2 Hadoop存储层对批处理和近实时处理模式的适用情况。
存储层
Lambda架构的典型功能如下所列：
·同时支持串行读写及随机读写。
·针对用户的使用情况，提供合适的层次性的解决方案。
·支持以批量模式或近实时模式处理海量数据。
·以灵活、可扩展的方式支持多种数据结构的存储。
3.6 服务层——数据交付与导出
Lambda架构也强调了为消费者程序提供数据传输服务的重要性。众所周知，数据可以以多种方式在系统间传递。其中最重要的一种方式是通过服务（service）传递。在数据湖背景中，这些服务被称为数据服务（data service），因为它们的主要功能是传输数据。
另外一种传输数据的方式是数据导出（export）。数据最终可导出为多种格式，如消息、文件、数据备份等，导出的数据供其他系统消费。
数据传输/服务主要关注的是如何将数据转换为预期的格式。这种格式可以强制约定为数据契约（data contract），数据服务在对外提供服务时遵循该约定。然而，在执行数据传输操作时，合并批量处理及近实时处理产生的数据非常重要，因为这两类数据中都可能包含与组织机构相关的关键信息。数据服务层必须保证数据与数据契约（与消费者程序约定）的一致性。
从较高的层次来看，数据服务层应满足下列特性：
·支持多种机制为消费者程序提供数据服务。
·每种支持数据服务的机制，必须与消费者程序的数据契约兼容。
·支持批量处理及近实时处理数据视图的合并。
·为消费者程序提供可扩展、快速响应的数据服务。
因为数据服务层的核心职责是向数据湖以外的消费者提供数据服务，出于增强数据表现的考虑，该层可能会选择性地进行数据合并。
企业数据湖实现的数据湖架构
存储层常用的存储架构：iceberg，hudi，delta，浪尖后面梳理给出各个架构特点及如何选择。
本文摘自：
