海量数据下，依靠传统数据库和传统实现方式基本行不通。企业需要一个分布式、高吞吐量、低延迟、高可靠的实时计算框架。下面给大家分享一下字节跳动和阿里巴巴在实时数据湖中的实际应用。01字节跳动实时数据湖实践数据湖是近两年比较热门的技术。从传统的数据仓库到数据湖，架构在过去5年里发展非常迅速。Hudi、Iceberg、DaltaLake被业界称为数据湖三剑客。目前字节对数据湖的解读主要集中在数据湖的六大能力：高效并发更新能力、智能查询加速、批流一体化存储、统一元数据和权限、极致查询性能。以及人工智能+商业智能。字节内部数据湖最初是基于开源数据湖框架Hudi构建的。在尝试大规模落地的过程中，主要遇到了四个挑战：数据管理难、并发更新弱、更新性能差、日志湖接入难。如何应对这些挑战？字节跳动对问题背后的原因做了详细的分析，针对不同的问题采取了不同的应对策略。1.构建统一的元数据层为了解决数据管理难的问题，字节跳动在数据湖和数据仓库之上构建了统一的元数据层。这个元数据层屏蔽了底层系统元数据的异构性，需要一个统一的元数据层来对接BI工具、计算引擎和一系列数据工具，进行数据开发、治理和权限控制。2、使用乐观锁重新实现并发更新能力。多任务并发编写是字节内部实践中非常普遍的需求。因此，在HudiMetastoreServer的Timeline上，Byte使用乐观锁重新实现了这种并发更新的能力。同时，Byte的并发控制模块还可以支持更灵活的行列级并发写入策略，为实时数据相关场景的实现提供了可能。同时，在高QPS入湖的情况下，字节跳动遇到了单个Flink任务的扩展性问题和批流并发的冲突。怎么解决？通过支持在Flink的embeddingtermserver上缓存当前事务元数据，大大提高了单个任务可并发写入的文件级别。提供更灵活的冲突检查和数据合并策略——行级并发、列级并发和冲突合并。3、采用可扩展的数据结构hash在早期的实现过程中，bytes尽可能复用了Hudi原生的一些能力，比如BoomFilterindex。但是，BloomFilter中存在误报。规模达到一定程度后，大部分数据都是更新操作，没办法通过索引来加速。BloomFilter索引出现问题的根本原因是读取历史数据进行定位，导致定位时间越来越长。对此，Byte采用可扩展的数据结构hash，无需读取历史数据即可快速定位数据所在位置。利用这种数据结构，桶可以自然的拆分和合并，让整个桶的索引从人工驱动进化到自动驱动。在写入数据时，也可以根据已有的总数快速推断出最深的有效哈希值的长度，通过不断取余的桶深的2次方来匹配最接近的分数。要写入的桶。4.提供非索引机制日志难以入湖的本质原因在于Hudi的索引系统。这种索引系统要求数据按照组件进行聚合，会造成性能问题和资源浪费。无索引，即绕过Hudi的索引机制，实现数据实时入湖。同时因为没有主键，Upsert的能力也失效了。对此，字节提供了更通用的更新能力，通过shufflehashjoin和broadcastjoin完成实时数据更新。02阿里基于FlinkHudi的增量ETL架构过去六个月，阿里巴巴计算平台事业部SQL引擎团队一直在开发ApacheFlinksql模块，核心工作是Flink和Hudi的集成。为什么选择Hudi而不是Iceberg或DaltaLake？这和Hudi的两个能力有关，一个是事务管理能力，一个是upsert能力。Hudi提供的交易模型是快照级别的，初步实现了海量数据的upsert和交易管理能力。1、Hudi是如何做到近实时访问数据库的？最近出现的debezium、canal等流批一体化架构，通过订阅MySQLbinlogevents，将增量数据近实时导入数据仓库，这就要求下游数据库本身具备upsert语义，Hudi提供了这样的能力，而且目前比较成熟，所以Hudi至少可以在ODS层使用这两种方式进行近实时的数据库数据入湖：先用debezium收集binlog，再用flinkcdcconnector进行直接对接，flinkcdcconnector有snapshot加上增量消费的能力，可以直接用upsert同步到下游数据湖（比如hudi），不需要再连接一层就可以按分钟级入湖卡夫卡。2、阿里如何构建分钟级近实时增量数仓模型？传统方式构建经典数据仓库模型，需要通过调度系统按照一定的时间策略构建定时的流水线任务，并根据流水线之间的依赖关系指定触发机制，整体维护是非常复杂。由于Hudi具备upsert的能力，可以使用debezium等工具通过flinkCDCpluskafka将数据库数据近实时同步到ODS层。如果Hudi可以继续将上游数据的变化数据传递给下游，借助flinkCDC的能力，下游可以继续消费这个增量数据，然后在原有状态的基础上继续做增量计算。因此，阿里通过修改hudi表格式，构建了一个分钟级的近实时增量数仓模型。
