目录
数据湖调研
1、背景
随着数据量的爆炸式增长和数据类型的多样化,数据湖成为支持大规模数据存储、处理和分析的关键架构。本调研旨在深入理解数据湖技术,并评估其在我们业务中的潜在应用价值。
为什么需要数据湖
-
传统架构的局限性:在传统数据架构中,由于规模和成本的限制,高成本的实时分析通常仅限于关键业务报表或业务链路,而大部分数据分析依赖于效率较低的离线处理。数据湖通过提供一种成本较低的近实时分析解决方案,能够满足快速增长的业务需求。
-
数据变更的高效处理:传统系统如Hive在处理数据变更时存在局限,如需覆写整个分区来处理晚到数据或新增列。数据湖通过支持高效的数据追加和列级修改,极大地简化了数据管理过程。
-
流批一体化处理:数据湖支持从Kafka等消息系统中几乎实时地加载数据,满足了除秒级延迟外的大多数实时分析需求,提高了数据处理的灵活性和效率。
应用案例分析
-
准实时标签:实现分钟级数据更新,显著提高决策反应速度。
-
降本增效:与传统实时处理相比,数据湖实现了更高的资源效率和成本节约。
2. 数据湖定义与概念:
数据湖(Data Lake)是一种大数据存储架构,它允许存储大量不同类型和格式的数据,并支持用于数据分析和机器学习的高级查询和处理。数据湖是为了解决大数据场景下的遗留问题而产生的,为打破数据孤岛而诞生。
数据湖的特点如下:
-
灵活性。数据湖可以容纳不同类型和格式的数据,不需要先进行结构化处理,强调原始数据的存储和管理。
-
分布式存储。通常使用分布式文件系统,如Hadoop或Amazon S3作为底层存储引擎,数据可以以原始格式存储,例如JSON、CSV或Parquet等。
-
成本效益。数据湖使用分布式文件系统进行存储,可以实现大规模的数据存储和处理,成本比传统数据仓库更低。
-
智能分析。支持高级分析和机器学习,可以帮助组织从数据中发现模式和趋势,并提供更加精确的洞察。
数据仓库和数据湖对比
数据仓库 | 数据湖 | |
---|---|---|
设计思想 | 数据仓库采用"存储和计算分离"的设计思想,将数据存储在关系型数据库中,计算和分析则在独立的计算层进行。 | 数据湖采用"存储即计算"的设计思想,将数据以原始形式存储在分布式文件系统中,如Hadoop HDFS或云存储服务。 |
处理类型 | 只能处理结构化数据且数据必须与数据仓库事先定义类型吻合。 | 能处理所有类型的数据,如结构化数据(如Hive)、半结构化数据(如Hbase)、非结构化数据(如ES)且数据类型依赖于数据系统的原始数据格式。 |
数据集成 | 数据仓库通常需要进行数据集成和转换,将不同系统和数据源的数据转换为统一的格式和结构,然后加载到仓库中。数据集成的过程在ETL过程中进行。 | 数据湖支持多源数据的集成,可以将不同系统和数据源的数据存储在同一个数据湖中。数据集成的过程可以在存储层进行,支持灵活的数据合并和集成。 |
性能和优化 | 为特定的查询和报表优化,将结构化数据转化为报表、多维数据等。 | 支持广泛的数据探索和大数据处理工作负载。拥有足够强的计算能力用于处理和分析所有类型数据分析后的数据会被存储起来供用户使用。 |
存储访问 | 在设计和维护上可能成本较高,但提供快速、一致和高质量的数据。 | 初期成本较低,存储还是基于hdfs,存储大量数据更经济,可实现降本增效,但管理和维护大规模和多样化的数据集较为复杂。 |
3. 技术架构
1、典型的Lambda架构(目前使用的)
两套架构,两套代码,对开发要求高
2、湖上建仓(市面应用比较广泛的)
分钟级别的数据延迟
数据湖里的数据近实时( 1-5 分钟)可见,比 Hive 离线延时优势明显
数据湖无需单独服务器,机器成本低,运维成本低。存储使用的是 HDFS
3、基于Doris/SR数据湖仓(字节跳动方案)
需要打通Doris和数据湖、HiveMetaStore
架构对比
第一套架构 | 第二套架构 | 第三套架构 | |
---|---|---|---|
数据存储 | 存储特点: 使用HDFS作为主要的数据存储方案,可靠性高,适合存储大量数据。 适用场景: 适合需要处理大规模批量数据与实时数据流处理的场景。 | 存储特点: Hudi提供了在存储层面上对数据变更捕捉的能力,结合Kafka进行数据流入,通过Spark和Flink处理。 适用场景: 适合需要频繁更新数据、并要求数据即时查询的应用场景。 | 存储特点: Doris为MPP数据库,优化了实时分析查询;结合Hudi能够支持数据的实时更新和存储。 适用场景: 特别适用于需要高速查询和实时数据分析的场景,如在线业务分析。 |
数据处理 | 处理特点: 结合批处理和流处理,Spark用于复杂的批处理分析,Flink处理实时数据流。 优势: 可以处理大规模的数据集以及实时数据处理,强大的容错能力。 | 处理特点: Flink与Spark的组合提供了灵活的数据处理能力,Hudi支持近实时的数据更新和查询。 优势: 支持事件驱动型数据处理,对数据更新响应迅速,提高数据处理的灵活性和效率。 | 处理特点: 结合Flink的实时数据处理能力与Doris的即席查询能力,优化了数据分析的响应时间。 优势: 极佳的数据分析性能,适合实时决策支持和快速数据探索。 |
4. 市场分析:
Hudi
Apache Hudi将核心仓库和数据库功能直接引入数据湖。Hudi提供了表、事务、高效的upserts/delete、高级索引、流摄取服务、数据集群/压缩优化和并发,同时保持数据的开源文件格式。
Hudi就是在hive表的基础上又定义了一些规则,让他支持增删改,计算引擎还是flink和spark
-
数据库功能集成: Apache Hudi 将关键的仓库和数据库功能如表管理、事务支持直接集成到数据湖中。
-
操作效率: 支持大规模数据集的近实时插入、更新和删除操作。
-
数据存储优化: 提供摄取合并、增量查询和改变流功能,优化存储并加速数据处理。
-
事务与恢复: 通过多版本并发控制(MVCC)和写前日志(WAL)支持复杂的事务,并能即时回滚以增强数据管理的灵活性。
Iceberg
Iceberg是一个开源的表格式,专为大数据的复杂查询和高效访问设计。支持细粒度的快照管理,使得时间旅行(即访问历史数据)成为可能。
-
高效的复杂查询支持: 专为处理大规模数据的复杂查询而设计的开源表格式。
-
细粒度快照管理: 支持时间旅行功能,允许用户访问历史数据。
-
多计算引擎兼容性: 与Apache Spark、Apache Flink、Presto等多个计算引擎兼容。
-
ACID操作: 提供原子性、一致性、隔离性和持久性的事务支持,确保数据的准确性和完整性。
Paimon
Apache Paimon是一个流数据湖平台,具有高速数据摄取、变更日志跟踪和高效的实时分析的能力。
-
流数据湖平台: 提供高速数据摄取、变更日志跟踪和实时分析能力。
-
表管理: 支持内部表和外部表,类似于Hive,通过 Paimon Catalog 管理。
-
模式演化: 支持在不重新启动同步作业的情况下,实时将数据列变更同步到 Paimon 表中。
-
UPDATE操作: 在 Flink 1.17 及后续版本中支持使用 UPDATE 更新记录,适用于主键表。
Hudi、Iceberg、Paimon对比
Hudi | Iceberg | Paimon | |
---|---|---|---|
规模成本 | PB/低成本 | PB/低成本 | PB/低成本 |
数据治理 | 一般 | 一般 | 强 |
读/写特性 | 支持ACID事务,支持Copy-On-Write,支持Merge-On-Read | 支持ACID事务,支持Copy-On-Write,不支持Merge-On-Read | 支持ACID事务,不支持Copy-On-Write,不支持Merge-On-Read |
平台支持 | spark读写,flink读写,presto读,Kafka读,ClickHouse写 | spark读写,flink读写,presto读写 | spark读写,flink读写,presto读 |
-
Apache Hudi:
-
优势:支持ACID事务,强调实时数据处理能力,优化了数据存储和查询效率。特别适合需要频繁更新数据的应用场景,如实时数据流处理和监控系统。
-
局限性:虽然具备高效的数据处理能力,但在扩展到非常大的数据集时可能面临性能瓶颈。
-
-
Apache Iceberg:
-
优势:提供强大的数据一致性和多引擎支持,特别适合于大规模数据仓库和复杂查询处理,支持细粒度的时间旅行和数据版本控制。
-
局限性:主要针对离线处理,对实时更新的支持不如Hudi灵活。
-
-
Apache Paimon:
-
优势:特别设计于流数据处理和高速数据摄取,适合实时分析和数据密集型应用,支持模式演化和高效的并发写入。
-
局限性:作为一个较新的技术,可能在生态系统支持和成熟度方面不如Hudi和Iceberg广泛。
-
5. 结论与建议:
建议
-
对于需要处理高速数据流和实时分析的业务,Apache Paimon 提供了出色的数据摄取速度和实时处理能力,是一个值得考虑的选择。
-
对于需要稳定支持大规模数据仓库、历史数据分析与复杂查询的环境,Apache Iceberg显示出其优越的数据管理和查询优化能力。
-
对于需要灵活处理大量数据更新、实时数据同步和保证数据一致性的场景,Apache Hudi 提供了强大的实时数据处理能力和ACID事务支持。
6. 附录:
Paimon官网:Apache Paimon™