亚信科技基于Apache Hudi向湖仓一体架构的演进研究
摘要：湖仓一体是一种新型的开放式架构，打通了数据仓库和数据湖，将数据仓库的高性能及管理能力与数据湖的灵活性相融合，存储层支持多种数据类型并存，提供统一封装的访问接口，支持实时查询和分析，为企业进行数据治理带来了更多的便利性。随着万物互联的智能时代的到来，数据已成为关键生产资料。根据国际数据公司IDC的数据显示，预计到2026年全球每年将产生216ZB的数据。这种数据量的增长给数据基础设施平台带来了新的挑战，传统数据仓库已无法满足激增数据的存储和分析需求。现代企业面临着多样化数据类型的挑战，存储并分析这些数据对企业来说变得愈发困难。然而，企业和组织已经认识到这些数据中蕴藏着巨大的价值和潜力，能否充分合理利用这些数据已成为商业竞争优势的关键。许多企业应用场景要求对实时数据进行快速处理和分析，以实现实时决策和反馈。因此，流式数据处理成为满足此类需求的关键核心技术。为了应对这些挑战，大数据架构需要对数据存储和计算分析能力进行升级，同时提高资源利用率。此外，将数据湖的灵活性与数据仓库的高效性融合起来，打通数据湖和数据仓库的能力也变得至关重要。正是在这种背景下，湖仓一体架构应运而生。湖仓一体架构融合了数据湖和数据仓库的优势，不仅能够满足实时数据运算和分析的处理要求，还能提供数据整合和转换功能，企业可以通过此架构存储大规模且多样化的业务数据并进行高效运算处理，助力企业利用数据实现商业价值，获得竞争优势。从《Gartner2022数据管理技术成熟度曲线》趋势预测来看，湖仓一体Lakehouse技术处在期望的高峰期，并且存在持续增高的趋势。
图1：Gartner2022趋势预测图
着眼于大数据架构的演进趋势，当前划分为三个阶段：数据仓库、数据湖及湖仓一体。- 数据仓库Data Warehouse，用于存储和分析的数据系统，良好的范式来规范管理数据，为企业提供决策支持。
- 数据湖 Data Lake，集中式的数据存储系统，虽然可以存储海量的原始业务数据，但整体缺乏数据结构管理和数据治理能力，极易沦为数据沼泽。同时数据按需进行加载使用，导致数据存储多份而造成资源浪费。
- 湖仓一体Lake House，新型开放式架构，是一种结合数据湖和数据仓库优势的新范式，打通两套体系，数据存储一份，让数据和计算在湖、仓之间流动。
图2：大数据架构演进图
当前基于Hadoop体系主要以支撑数据湖及离线数据仓库为主，采用分布式存储实现数据湖的统一数据存储，同时采用Hive来支撑离线的数据仓库。Hadoop体系在从数据湖、离线数据仓库向湖仓一体的演进中，需要从存储、数据处理及数据服务层面，全面对架构进行升级，以满足湖仓一体架构的诉求。
图3：湖仓一体技术架构图
在Hadoop架构体系中，基于Hive的数仓只能满足离线数据的存储，需要新增实时分析能力，如何使用一套技术体系既能支持离线数据的存储，又能支持实时数据的存储，又该如何满足湖仓一体存储架构要求，成为技术探索路径上必须解决的问题。湖仓一体架构在业内内存在3种技术能力：Uber开源的Hudi、Netflix开源的Iceberg和Databricks 开源的Delta Lake，三个组件特性对比如下表所示。
Hudi对比Iceberg、Delta Lake 技术优势主要体现在：- MOR实时性高，它包含列存数据文件(.parquet)和行存增量日志文件(avro格式的.log.*)。当更新写入时，会将更新记录写入日志文件中，然后在进行同步或异步合并compaction来生成最新版本的数据文件，同时采用压缩机制来提高合并效率，这样带来2点好处：减少小文件数量和提升读优化，读取端会直接访问最新版本的数据文件即可。
- Hudi还提供COW引擎，只写列式存储的数据文件(.parquet)，每次写入都要创建新版本数据文件，而新版本文件中包含旧版本文件记录和本次写入的记录，也就是全量最新文件。特点在于写入期间进行合并，这将导致写入时存在延迟，同时也会写放大。所以常被用在写少读多的场景中。
- Hudi提供了自我管理文件大小的技术特性，操作者不需要担心手动维护表数据，通过设定几个简单的参数，便能方便的完成文件大小的自动运维功能。举个例子：当第一个配置值是120MB，第二个配置值是100MB，那么任何小于100MB的文件都被认为是小文件而进行自动合并管理。
- Hudi高效的更新特性，它采用列式存储(Parquet/ORC)方式，将数据按列组织，支持只写增量或发生变化的数据部分，同时配合写入合并技术将小文件合并成较大的文件，降低了元数据管理的复杂性，整体提高更新写入的效率。
- 增量消费特性，可以实时的处理增量变化的数据。Hudi通过监听数据源的变化，及时捕获数据的新增、更新和删除操作，再将变化的数据按增量方式写入Hudi表中。从而做到对增量数据进行实时的计算。避免全量数据的重复传输和处理，提高数据的处理速度。
- 社区活跃度Hudi相比于Iceberg要活跃，而且国内Commiter数量占比相对高，可持续演进方面会很好。Delta lake贡献主要是Databricks公司，商业化公司风险较高。
所以选择Hudi作为湖仓一体的组件，主要因为其功能特性可以同时满足离线及实时数据存储的要求，并且社区活跃度很高，可以持续演进发展，目前在国内使用率也很高。亚信科技湖仓一体技术方案是基于Hadoop作为数据存储，以Hudi为优化文件布局和Hive MetaStore为元数据中心的存储架构。这种架构可以构建一个分布式数据湖平台，实现对数据的实时写入和批量导入，同时进一步支持湖仓数据的增删改查，最终实现业务系统实时在线和离线的数据分析场景。
图4：亚信科技湖仓一体功能架构图
湖仓一体的功能架构基于湖底座和湖治理的整体功能构建，提供以下技术能力：- 湖仓治理：实现全量的元数据采集，全量、统一的数据开发及编排、全量数据资产的治理、全量数据共享和API的数据服务，端到端的全量数据安全管理。
1.具备湖仓一体的架构下多源异构数据源的接入集成能力。2.提供全链路的开发能力，可视化的托拉拽的方式实现基于数据湖的开发。3.提供全流程的、全生命周期的自动化的湖仓数据治理能力。4.统一元数据管理，拉通湖和仓的元数据，实现“物理分散，逻辑统一”的元数据管理能力。1.湖仓一体的架构下支持实时入湖功能，通过对数据源的变化日志进行实时消费入湖，速度快，资源消耗少，能降低30%。2.湖内增量ETL功能，只用计算数据快照之间的增量数据，避免了全量计算而造成的资源浪费。3.基于事务的增删改能力，可以用于构建实时数仓，加速数据分析和指标类应用支撑。在湖仓一体技术实践的过程中，我们发现Hudi开源版本在特定场景下存在局限性。我们研发了新的特性来解决这些问题，并回馈到社区。（一） Spark多端并发写入MOR表特性
该特性解决了多客户端并发写性能大幅下降问题，预计并发写入性能提升大约10%-30%。我们知道MOR表在多客户端写入时，是不会直接写数据基础文件(baseFile)，而是追加(append)写入日志文件(logFile)中，这样就会产生文件锁冲突的情况，导致写入性能大幅下降。多端并写MOR表是基于Bucket Index索引实现的，它允许多个客户端并发写入多个日志文件（logFile）中，然后将具有相同分组（groupId）的日志文件数据压缩合并到数据基础文件（baseFile）中，以实现多端并写的能力。
图5：多端并写技术实现
- 修改社区版本的log文件命名规则：在社区log文件命名ID(groupId)+基准文件提交时间戳(baseFileCommitTimestamp)构成的基础上，增加了客户端写入时间戳属性，以避免文件锁冲突问题。
- 更改marker生成方式：修改了marker的生成方式，增加客户端写入时间戳来标记不同客户端写入数据产生的marker，以保证数据的正确性和一致性。
- 新增冲突检查策略：在多个客户端并发写入数据基础文件时，只允许第一个完成写入的客户端提交事务，其他客户端则等待重试写入。避免多客户端将相同数据写入不同filegroup而导致数据重复问题。
此特性也为多流合并写入场景提供了强大的支持，降低了业务实现的复杂度，同时提升了大数据量写入的并发性和时效性。
（二） Flink架构下Hudi维表关联
目前社区版的Flink还无法做到流里面与Hudi维表关联计算的能力，如果要实现这个场景那就需要将流数据入库存储后，借助第三方如Hive来完成关联，这对存储资源还是计算资源都是不必要的浪费，且时效性很差。我们增强弥补了这一功能，使开发人员可以在 Flink流里面与Hudi维表进行关联计算，不仅解决了资源浪费问题，还能满足实时类业务场景需要。
图6：Flink维表关联技术实现
实现基于Flink的Hudi维表关联能力主要依赖以下两点关键技术：- 基于LookupTableSource接口和方法进行扩展实现，同时自定义了Lookup的自定义函数。简单来讲就是依据传入的左表键值(key)，在Hudi数据中进行精准查找，如找到对应的结果，则返回关联结果。
- Hudi提供的MergeOnReadInputSplit功能可以合并基础文件（base file）和日志文件(log file)。通过定期监测Hudi维表的时间线(timeline)，如果维表有新的数据写入，则需要启动基础文件和日志文件合并任务，以便得到最新的增量数据，从而保证维表数据的时效性。
通过以上技术实现，基于Flink计算引擎的Hudi维表关联功能可以直接在Hudi上完成数据关联操作，无需借助额外的组件，减轻了系统架构的复杂性，同时也避免维表分散存储而带来的数据搬迁操作。以运营商客户多维数据的实时场景化营销为例，底层大数据平台升级演进为湖仓一体架构，这样能够更好的满足个性化和复杂化的实时业务场景。实时统计场景需求：用户轨迹变化规律，用户驻留信息统计如：驻留时长，进出基站时间等，实时统计在某基站（区域内）用户上网详细信息，如：访问app, 访问时长，流量消耗XX等，数据量千万级/分钟。
将上述实时变化的数据进行合并计算，输出为XX场景驻留XX时间，访问XXAPP时长超多XX分钟，或流量消耗超过XX M、G的用户集，整体的延迟要求分钟级，用于实时营销。
图7：基于湖仓一体技术架构
方案从实时数据采集，多流关联处理，基于数据湖事务更新能力，提供准实时的多流合并写入能力，达到了业务要求的性能指标。实现了BO融合业务下的多场景事件营销的实时支撑。本文探索了在大数据Hadoop架构下向湖仓一体演进的技术路线，提出了基于现有能力下的功能特性。未来随着数字化的发展，数据多样性和实时性要求也会越来越高，这对湖仓一体架构也会提出更高的要求，后续的演进方向：
参考资料
[2] 《艾瑞咨询：中国云原生数据湖应用洞察白皮书》[3] 《Gartner2022数据管理技术成熟度曲线》[4] Hudi quick-start-guide：https://hudi.apache.org/cn/docs/quick-start-guide[5] China Database Native Security Capabilities Insights, 2022.
页面更新：2024-04-27
标签：架构 离线 增量 实时 数据仓库 场景 能力 文件 数据 技术 科技
1
2
3
4
5
上滑加载更多 ↓
所有内容加载完毕
