＋
什么是数据湖？
对于数据湖（Data Lake）Wikipedia、AWS、微软等大厂各有不同定义，其中相对来说AWS给出的定义简洁易懂一些，“数据湖是一个集中式存储库，允许你以任意规模存储所有结构化和非结构化数据。你可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策”。
结合Wikipedia讲到的“数据湖通常是企业中全量数据的单一存储”，以及微软定义中介绍到的“数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析”等描述，让我们能够对数据湖有一个初步理论认知。
再结合一些实际数据湖构建目标和理念，数据湖可以理解为一种不断演进的、可扩展的集大数据存储、处理、分析为一体的基础设施；是以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用的架构。
＋
为什么要数据湖？
在数据湖架构之前大数据存储架构有“以Hadoop为代表的离线数据处理架构”、“Lambda架构”、“Kappa架构”三大代表性架构，并基于此演进出数据仓库的概念。
三种架构从传统T+1离线批处理，到批流分离一致性服务，再到批流一体化解决方案，处理方式的演进逐渐囊括了应用所需的各类数据处理场景与能力，虽然在特定场景中满足需求，但是这些架构仍然存在很多痛点，即使数据仓库的规范和分层也未完全解决。
这些架构的痛点主要表现在：
以Hadoop为代表的离线数据处理架构痛点
海量TB级T+1任务延迟导致下游数据产出时间不稳定
任务遇到故障重试恢复代价昂贵
在处理去重和exactly-once语义能力方面比较吃力
架构复杂，涉及多个系统协调，靠调度系统构建任务依赖关系
Lambda架构痛点
同时维护实时计算平台和离线计算平台两套引擎，开发及维护成本高
数据有两条不同链路，容易造成数据不一致
分区级别的数据更新成本高，需重跑相关链路
Kappa架构痛点
对消息队列存储要求高，消息队列数据回溯能力弱
消息队列数据存储有时效性
全链路依赖消息队列的实时计算可能因数据时序性导致结果不准确
随着业务的不断发展，这些架构为企业解决了许多需求场景，但痛点问题也让他们不足以支撑数据处理的多样化的特定场景需求，为解决这些痛点问题实现特定场景需求，数据湖架构应运而生。
＋
数据湖特征
传统架构的痛点问题，为一个好的数据湖方案提供了功能和特性引导，要做好一个数据湖架构，基础上首先要满足：
可以支撑并较快的更新删除数据
管理好小文件的存储及压缩
可以将一批数据文件封装成一个有业务意义的table
提供ACID、snapshot、schema、partition 等表级别的语义并支持数据多版本存储
在此之上可以通过实现廉价存储、多分析引擎支持、多接口支持、批流读写支持来加快数据湖技术的普及与落地。
数据湖架构最明显的优势是其T+0能力，它解决了Hadoop时代数据分析中传统的数据处理流程从数据入库到数据处理的冗长环节、简化保证数据一致性的处理逻辑，降低流水线延迟，这些都是由它的设计特性决定的，数据湖的基本特征可从数据与计算两方面进行说明。
数据方面
保真性
数据湖强调的是对于业务数据“原汁原味”的保存，对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。
多样性
数据湖能够存储任意类型/格式的数据，如结构化库表数据、非结构化文档数据、半结构化XML数据、二进制音频数据等。
灵活性
数据湖强调的“读取型schema”，在业务的不确定性下将设计延后，支持根据需求对数据进行加工处理。
可管理
数据湖提供完善的数据源、数据连接、数据格式等数据管理能力和权限管理能力，来管理不断的积累、演化的原始数据和处理后的数据。
可追溯
数据湖可以对数据的全生命周期进行管理，能对其间的任意一条数据的接入、存储、处理、消费过程进行追溯，重现数据完整的产生和流动过程。
计算方面
丰富的计算引擎
随着各类机器学习/深度学习算法不断引入，数据湖兼容了从批处理、流式计算、交互式分析到机器学习的各类计算引擎，支持计算引擎的可扩展/可插拔能力。
多模态的存储引擎
为满足与外置存储引擎协同工作及多样化的应用需求的同时实现性价比，数据湖支持如S3/OSS/HDFS/OBS多模态的高性价比存储引擎。
＋
开源数据湖三剑客
结合数据湖的特征实现，Netflix的Iceberg、Uber的Hudi 、Databricks的Delta Lake是目前相对热门的开源数据湖产品，并称为“开源数据湖三剑客”。
其中：
Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。
Apache Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。
Delta Lake在 2017 年立项、2018 年公布、2019 年开源，是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。1.0版本根据自身 spark 创始团队的基因打造的核心竞争力，2.0版本之后优化了一些引擎兼容等，但开源版比商业版有不少差距。
三种数据湖产品虽然都可以满足基础的数据湖场景需求，但由于他们的初衷并不完全相同，所以场景侧重也不尽相同。
其中：
Iceberg高度抽象且定位是高性能读写和可靠的数据管理，更加适合通用的引擎可以多样化的性能分析及数据可靠管理场景。
由于架构设计是基于Uber业务需求，Hudi更加适合于高效 incremental 的 upserts及Deletes场景。
Delta源于Databricks与其Spark代码深度绑定，且定位于批流一体处理，更加适合Spark引擎下的批流一体场景。
当然，随着三剑客的不断迭代完善，各自在发挥特长的基础上也将逐渐融入其他产品的优秀特性，不断提升产品的通用性。
＋
数据湖解决方案
当下数据湖架构目标及特征不断明确，开源组件也不断完善，基于其存储、管理、分析的特性，我们对于数据湖的能力也有了一定的认知。
基于数据湖的架构目标及其存储、管理、分析的特性和能力，数据湖架构解决的问题主要有：
数据分散，存储散乱，形成数据孤岛，无法联合数据发现更多价值
数据湖支持对半结构化、非结构化数据的管理，数据的多样性和保真性可以将数据统一消除孤岛。
存储成本问题
数据湖使用HDFS/对象存储成本较低的技术架构，为企业大大节省成本。
SQL 无法满足的分析需求
传统的 SQL 方式无法满足多样化数据和分析需求的实现，数据湖可支持丰富的计算引擎实现多样化分析需求。
存储/计算扩展性不足
扩展线依赖HDFS/OSS存储，有良好的扩展性和可控性。
业务模型不定，无法预先建模
传统数据库和数据仓库，都是 Schema-on-Write 的模式，需提前定义 Schema ，而在数据湖场景下，可以先保存数据，后续待分析时，再发现 Schema，也就是 Schema-on-Read。
基于数据湖的能力，各大厂商也纷纷推出了自己的数据湖解决方案及相关产品，如：
AWS数据湖解决方案
主要是结合数据湖组件及AWS其它服务互相配合，实现数据流入、数据沉淀、数据计算、数据应用功能的一个高成熟数据湖方案，特别是元数据管理、权限管理上考虑充分，打通了异构数据源与各类计算引擎的上下游关系，让数据能够自由“移动”起来。
华为数据湖解决方案
方案中数据湖探索（Data Lake Insight，DLI）相当于是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。基于其分析引擎的完备性，在数据处理上下游生态上比AWS相对完善，同步结合智能数据湖运营平台（DAYU）使方案完整覆盖了数据处理的生命周期，并且明确支持了数据治理，并提供了基于模型和指标的数据治理流程工具，在华为云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进。
阿里云数据湖解决方案
方案依然采用OSS作为数据湖的集中存储，在具备优秀的数据集成能力的同时，阿里云数据湖构建（Data Lake Formation，简称 DLF）帮助用户构建云上数据湖及Lakehouse的服务，为客户提供了统一的元数据管理、统一的权限与安全管理、便捷的数据入湖能力以及一键式数据探索能力。方案可以帮助用户快速完成云原生数据湖及Lakehouse方案的构建与管理，并可无缝对接多种计算引擎，打破数据孤岛，洞察业务价值。
＋
总结
数据湖技术及方案的不断迭代成熟将为大数据及人工智能时代数据分析处理的灵活多样的需求实现带来更多可能。
数据湖将逐渐融入企业的生命周期实现数据的集中式管理，在数据深入挖掘和多维分析等场景的推动下结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等。这些模型能刺激企业能力的持续增长，深度挖掘数据价值，助力企业数字化转型落地。特定场景下的“仓转湖”、“湖仓一体”也为企业数字化发展注入了新的活力。
文 | 梁洪明 编 | 邢笑睿
文章仅代表作者观点，版权归海颐软件所有，欢迎转发和评论。转发、转载、转帖等须注明“稿件来源：海颐新视野”，如有违者将依法追究相关责任，谢谢！
”
关注公众号
海颐软件
往期推荐
OTHER ARTICLES
