简介：阿里云高级技术专家王烨 (萌豆) 在 Apache Hudi 与 Apache Pulsar 联结 Meetup 杭州站上的演讲整顿稿件，本议题介绍了阿里云如何应用 Hudi 和 OSS 对象存储构建 Lakehouse，为大家分享了什么是 Lakehouse，阿里云数据库 OLAP 团队如何构建 Lakehouse，也介绍了在构建 Lakehouse 时遇到的问题和挑战，以及如何解决这些问题和挑战。

本文 PPT 下载链接：

王烨(萌豆)- 阿里云高级技术专家 -《阿里云基于 Hudi 构建 Lakehouse 实际》.pdf

其余干货：

李少锋(风泽) – 阿里云技术专家 -《基于 Apache Hudi 的 CDC 数据入湖》.pdf

翟佳 -StreamNative 联结创始人、Apache Pulsar PMC 成员 -《Pulsar 2.8.0 性能个性概述及布局》.pdf

盛宇帆 -StreamNative 软件工程师 -《基于 Flink 的全新 Pulsar Connector 的设计、开发和应用》.pdf

一、数据湖与 Lakehouse

2021 年开发者大会上，咱们的一位研究员分享的一个议题，提到了很多数据，次要想论述的是行业倒退到当初这个阶段，数据的收缩十分厉害，数据增速十分可怕。无论是数据规模还是生产解决的实时化，到生产解决的智能化，以及数据减速上云的云化过程。

这些数据来自 Gartner、IDC 的剖析，都是行业最权威的剖析报告里积淀总结进去的。这就意味着咱们在数据畛域尤其是剖析畛域的时机和挑战都很大。

在海量的数据上，咱们要真正做好数据价值的开掘和应用会面临很多挑战，第一是现有的架构缓缓都要往云上架构迁徙；第二个是数据量；第三个是 Serverless 按量付费，缓缓从尝试性的抉择成为默认抉择；第四是还有多样化的利用、异构数据源。置信大家接触过云都晓得，无论是哪个云厂商都有很多种云服务可供，尤其是数据类服务数量繁多。这时候，大量数据源肯定会带来一个问题：剖析难度大，尤其是想做关联剖析的时候，异构数据源怎么连接起来是很大的问题。其次是差异化的数据格式，通常咱们做数据写入会时抉择不便、简略的格局，比方 CSV、Json 格局，但对剖析来讲，这些格局往往是十分低效的，尤其是数据到了 TB、PB 级的时候，基本没法剖析。这时候 Parquet、ORC 等面向剖析的列存格局就衍生进去了。当然还包含链路平安以及差异化群体等等，数据量收缩的过程中又减少了很多的剖析难度。

在实在的客户场景里，很多数据曾经上云了和“入湖”了。湖是什么？咱们对湖的定义和了解更像 AWS 的 S3 或者阿里云 OSS 这种对象存储，是简略易用的 API 模式，能够存各种各样差异化的数据格式，有有限的容量、按量付费等十分多的益处。之前想基于湖做剖析十分麻烦，很多时候要做 T + 1 的建仓和各种云服务投递。有时候数据格式不对就要人肉做 ETL，如果数据曾经在湖里要做元信息发现剖析等等，整个运维链路很简单，问题也很多。这里都是线上客户理论面临的离线数据湖问题，有些优先级偏高，有些低些，总而言之问题十分多。

其实 Databricks 大略 19 年就开始将钻研重点从 Spark 方向，缓缓往 Lakehouse 方向调整了。他们发表了两篇论文，这两篇论文为数据湖怎么被对立拜访、怎么被更好地拜访提供了实践层面的定义。

基于 Lakehouse 的新概念，想做到的是屏蔽格局上的各种差别，为不同的利用提供对立的接口以及更加简化的数据拜访、数据分析能力。架构说实现数据仓、数据湖、Lakehouse 一步步演进。

他的两篇论文论述了很多新概念：第一，怎么设计和实现 MVCC，能让离线数仓也有像数据库一样的 MVCC 能力，从而满足大部分对批事务的需要；第二，提供不同的存储模式，可能适应不同的读和写 Workload；第三，提供一些近实时的写入和合并能力，为数据量提供链路能力。总之，他的思路可能较好解决离线数据分析的难题。

目前业界有三款产品绝对比拟风行，第一个是 Delta Lake，它是 Databricks 本人公布的数据湖治理协定；第二个是 Iceberg，Iceberg 也是 Apache 的一个开源我的项目；第三个是 Hudi，Hudi 最早由 Uber 外部研发，起初开源的我的项目（晚期用得比拟多的是 Hive 的 ACID）。目前这三个产品因为能够对接 HDFS 的 API，能够适配底层的湖存储，而 OSS 又能够适配到 HDFS 存储接口。因为外围原理类似，三个产品各方面的能力都在逐步凑近，同时有了论文做实践撑持，咱们才会有方向去实际。

对咱们来说，过后抉择 Hudi 也是因为其产品成熟度方面的起因，还有它面向数据库方面的数据入湖能力，状态上比拟满足咱们在数据库团队做 CDC 方面的业务需要。

Hudi 晚期的定义是 Hadoop Updates anD Incrementals 的缩写，前面是面向 Hadoop 的 Update、Delete、Insert 的概念，外围逻辑是事务版本化、状态机管制和异步化执行，模仿整个 MVCC 的逻辑，提供对于外部列存文件比方 Parquet、ORC 等对象列表的增量式治理，实现高效的存储读写。它和 Databricks 定义的 Lakehouse 概念很类似，不约而同，Iceberg 也是一样，它的能力也在逐渐往这个方向晋升。

Hudi 官方网站对外提供的架构是这样的状态。之前咱们做技术选型、调研的时候发现很多同行也曾经充沛应用 Hudi 做数据入湖和离线数据管理的计划选型。第一，因为产品比拟成熟；第二，它合乎咱们 CDC 的需要；第三，Delta Lake 有一套开源版本，一套外部优化版本，对外只提供开源版本，咱们认为它不肯定把最好的货色出现。Iceberg 起步比拟晚，晚期相比其余两个产品能力不太齐全，所以没有思考它。因为咱们都是 Java 团队，也有本人的 Spark 产品，Hudi 正好比拟符合咱们用本人的 runtime 反对数据入湖的能力，因而也就抉择了 Hudi。

当然咱们也始终在关注这三个产品的倒退，起初国内的一个开源我的项目 StarLake，也是做相似的事件。每种产品都在提高，长期来看能力根本对齐，我感觉会和论文里定义的能力缓缓吻合。

“以开源 Hudi 为列式、多版本格局为根底，将异构数据源增量、低提早入湖，存储在凋谢、低成本的对象存储上，并且在这个过程中要实现数据布局优化、元信息进化的能力，最终实现离线数据对立治理，无差别反对下面的计算和剖析能力，这是整体的计划。”这是咱们对 Lakehouse 的了解，以及咱们的技术摸索方向。

二、阿里云 Lakehouse 实际

上面介绍一下阿里云 Lakehouse 的技术摸索和具体的实际。首先，大略介绍一下阿里云数据库团队近年来始终提的概念“数据库、仓、湖一体化”策略。

大家都晓得数据库产品分为四个档次：一是 DB；二是 NewSQL/NoSQL 产品；三是数仓产品；四是湖数据产品。越往上数据的价值密度越大，会以元表元仓模式的数据关联到剖析中去，比方 DB 数据格式非常简单、清晰；越往下数据量越来越宏大，数据模式越来越简单，有各种各样的存储格局，数据湖模式有结构化、半结构化、非结构化，要剖析就必须要做肯定的提炼、开掘，能力真正把数据价值用起来。

四个存储方向有各自的畛域，同时又有关联剖析诉求，次要就是要突破数据孤岛，让数据一体化，能力让价值更立体化。如果只是做一些日志剖析，例如关联的地区、客户起源的话，也只是应用了 GroupBy 或者是 Count 等绝对简略的剖析能力。对于底层数据，可能要做屡次荡涤、回流，能力往向在线化、高并发的场景一层层剖析。这里不仅仅间接将数据从湖到库写入，也能够到仓，到 NoSQL/NewSQL 的产品里，到 KV 零碎里去，利用好在线化的查问能力，等等。

反过来也是一样，这些数据库 /NewSQL 产品甚至数仓中的数据也会向下流动，构建低成本、大容量的存储备份、归档，升高下面的存储压力、剖析吞吐压力，且能够造成弱小的联结剖析能力。这也是我本人对数据库、仓、湖一体化的了解。

方才讲了数据库的倒退方向和定位，再看看数据库上面 OLAP 自身的分层数仓体系中 Lakehouse 是怎么的定位。做过数仓产品的同学都比我相熟，（PPT 图示）基本上是这样的分层体系，最开始各种各样的状态非数仓或者非数据湖零碎里面有各种各样的模式存储数据，咱们了解通过 Lakehouse 的能力，做入湖、建仓，通过荡涤、积淀和聚合，造成 ODS 或者是 CDM 层，这里做了初步的数据聚合和汇总能力，造成数据集市的概念。

这些数据在阿里云上咱们会基于 Hudi 的协定，基于 Parquet 文件格式存到整个 OSS 下面，外部通过 ETL 把初始数据集进一步聚合为更清晰、更面向业务的数据集上，而后再构建 ETL，往实时数仓里导入，等等。或者这些数据集间接面向低频的交互式剖析、BI 剖析，或面向 Spark 等引擎做机器学习，最终输入到整个数据利用上，这是整体的分层体系。

整个过程中，咱们会接入对立的元信息体系。因为如果零碎的每个局部都有本人的术语，都要保留一份本人的元信息，对 OLAP 体系来讲是决裂的，因而元信息肯定要对立，调度也是一样。不同数据仓档次的表在不同的中央要串联起来，肯定要有残缺、对立的调度能力。以上是我了解 Lakehouse 在 OLAP 体系中的的定位，次要是贴源层，汇聚离线数据的能力。

后面介绍了 Lakehouse 在数据库和 OLAP 团队里的定位，前面重点介绍一下 Lakehouse 在咱们的畛域设计是怎么的状态。因为之前我本人用过 K8s 做剖析零碎上云，所以对 K8s 的很多理念还是比较清楚。

在咱们本人设计的时候也试图参考、学习一下 K8s 的体系。K8s 有咱们常常提到的 DevOps 概念，这是一种实际范式。在这个范式下会创立很多实例，在实例里会治理很多利用，这些利用最终通过 Pod 形式被原子性调度执行，Pod 里再跑一些业务逻辑，各种各样的 Container。

咱们认为 Lakehouse 也是一种范式，一种解决离线数据的范式。在这里，数据集是咱们的外围概念，比方要构建一套面向某种场景、某个方向的数据集。咱们能要定义 A、B、C 不同数据集，在咱们看来这是一个实例。围绕这个数据集编排各种各样的 Workload 工作负载，比方做 DB 入湖。还有剖析优化类的 Workload，比方索引构建，比方像 z -ordering、Clustering、Compaction 等技术，查问优化能力晋升得更好。还有就是 Management 类型的 Workload，比方定期把历史数据清理了，做冷热存储分层，因为 OSS 提供了很多这样的能力，把这些能力用好。最上面一层是各种 Job，咱们外部是基于 Spark 建设离线计算能力，咱们把 Workload 前后编排成小的 job，原子的 job 全副弹性到 Spark 上执行，以上是咱们对于 Lakehouse 在技术实际中的畛域设计。

这是整体的技术架构。首先，在云上有各种各样的数据源，通过编排定义各种各样的 Workload，跑在咱们本人的 Spark 弹性计算上。外围的存储是基于 Hudi+OSS，咱们也反对别的 HDFS 零碎，比方阿里云的 LindormDFS，外部元信息系统治理库、表、列等元信息。前面基于 K8s 调度所有的管控服务。下层通过原生的 Hudi 接口，对接计算、剖析能力。这是整个弹性架构。

其实 Serverless Spark 是咱们的计算根底，提供作业级弹性，因为 Spark 自身也反对 Spark Streaming，通过短时间弹出一个 Spark 作业实现流计算。抉择 OSS 和 LindormDFS 做存储根底，次要利用低成本、有限容量的益处。

在这个架构上，怎么连通用户的数据实现数据入湖到存储、到剖析的能力呢？以上是咱们基于 VPC 构建的平安计划。首先咱们是共享集群模式，用户侧能够通过 SDK 和 VPDN 网络连接过去，再由阿里云外部网关买通计算集群，实现治理和调度；再通过阿里云弹性网卡技术，联通用户的 VPC 实现数据通路，同时实现路由能力和网络隔离能力，不同用户还可能有子网网段抵触问题，通过弹性网卡技术能够实现雷同网段同时连贯同一个计算集群的能力。

用过阿里云 OSS 的同学都晓得，OSS 自身是阿里云 VPC 网络里的公网，它是共享区，不须要简单的网络。而 RDS 和 Kafka 是部署在用户的 VPC 里，通过一套网络架构就能够实现多种网络买通。比照 VPC 网段抵触，共享区域没有这样的问题。其次，数据之间隔离，ENI 有端到端的限度，比方 VPC 有 ID 标记、有不同的受权要求，非法用户尝试连贯 VPC，如果不是这个网卡则网络包无奈联通，就能够实现平安的隔离和数据的通路。

网络架构曾经确定了，怎么运行执行呢？在整个设计里，咱们会以 K8s 的 DSL 设计为楷模，后面提到会定义很多入湖工作，一个 Workload 可能有很多小工作，这时候须要相似定义 DSL 的编排能力，job1、job2、再到 job3，定义一套编排脚本；这些编排脚本，通过 SDK、控制台等入口提交过去，再通过 API Server 接管并由 Scheduler 调度起来。这个 Scheduler 会和 Spark 的网关之间买通，实现工作治理、状态治理、工作散发等，最终调度外部的 K8s 拉起作业来执行。有些全量作业跑一次，比方 DB 拉一次就行了，还有常驻的流式作业、有触发式的异步作业、定时异步作业等等，不同的状态雷同的调度能力，从而能够扩大。过程中有作业状态继续反馈状态、间隙性统计等等。在 K8s 里，K8s Master 承当了这样的角色，同样有 API Server 和 Scheduler 的角色。在咱们这里也是相似，也是通过一主多从架构实现调度能力 HA 机制等等。

在这里，为什么咱们要把一个 Workload 面向用户侧的工作拆成 N 个不同的 job？因为这些工作齐全放在一个过程里跑，整个 Workload 的水位变动十分大，做弹性调度十分难。全量工作跑一次就能够了，然而配多少资源适合呢？很多时候 Spark 没有那么灵便，尤其是异步工作和定时工作拉起来耗费很大，然而用完之后又不晓得下一次什么时候来，很难预测。就像很多信号系统解决里，须要做傅里叶变换一样，把简单的波型拆成多个简略的波型，信号处理就简略起来。咱们也是有这样理性的了解。用不同的 Job 来执行 Workload 中不同角色的工作，就很容易实现弹性能力。像定时或临时性的触发 Job，长期拉一个 job，资源耗费与常驻的流式工作齐全无关，就能够齐全不影响流式工作的稳定性、入湖提早等等。这是设计背地的思考，就是让简单的问题简单化。因为基于弹性的角度来讲，拆得波形越简略，弹性就会更好做，预测也会简略一点。

入湖里会波及很多用户的账密信息，因为不是所有云产品都以 AWS 的 IAM 或阿里云的 RAM 等零碎来构建齐全云化的资源权限管制。很多产品还是以账密形式做认证和受权治理，包含用户自建的零碎，数据库系统等等。这样，用户要把所有的连贯账密都交给咱们，怎么更平安的治理它们？咱们是基于阿里云的两套体系：一套是 KMS，以硬件级数据加密体系来加密用户数据；第二套是 STS，齐全云化的三方鉴权能力，实现用户数据的平安拜访，尤其是敏感数据的隔离或者爱护的机制，这就是咱们当初的整个体系。

还有一个问题，不同用户之间通过各种机制齐全隔离开了，然而同一个用户有很多的工作。在 Lakehouse 概念中有四层构造，一个数据集上面有多个库，库上面有多个表，表上面有不同的分区，分区上面是不同的数据文件。用户有子账号体系、有各种不同的作业，因而操作数据时可能会呈现相互影响。

比方不同的入湖工作都想要写同一张表，线上 A 工作曾经失常运行了，后果另外的用户配置了 B 工作，也要写入同一个空间，这就有可能把曾经上线的 A 工作数据全副冲掉，这是很危险的事件。还有其余用户删除作业的行为，可能会删掉线上正在运行工作的数据，有可能其余工作还在拜访，但又不能感知它；还比方通过别的云服务、或是 VPC 内别的程序、本人部署的服务等等，都可能操作这个表，导致数据出问题。因而咱们设计了一整套机制，一方面是在表级别实现锁的机制，如果有工作最早就占有一张数据写入权限时，前面的工作在这个工作生命周期完结之前，都不容许再写入，不能够写脏了。

另一方面基于 OSS 的 Bucket Policy 能力，构建不同程序的权限校验能力。只容许 Lakehouse 的的工作有权限写数据，而其余程序不容许写，但其余程序能够读。同一个账号的这些数据原本就是为了共享、为了剖析，为了各种利用场景的接入，就是能够读，但相对不能够净化它。咱们在这些方面做了可靠性工作。

咱们更多讲的架构体系，回到整体看一下怎么了解数据模型，咱们认为整个过程是以行为核心（因为数仓还是一行行的数据，存储在表的范畴内），以行数据构建对立入湖、存储、剖析，元信息模型等。首先有各种各样的数据源（有文本或二进制，binlog 就是二进制的数据；或者相似 Kafka 中能够存储各种二进制），这些数据最终通过各种各样 Connector、Reader（不同的零碎有不同的叫法），把数据读过来，映射成行数据。在这些行数据中，有要害的形容信息，比方起源信息、变更类型等等，还有可变的列汇合。再通过一系列的规定转化，比方滤掉某些数据，要为数据生成主键，要段定义版本、类型转换等等；最初再通过 Hudi Payload 封装、转换、元信息信息保护、文件生成等等形式，最终写到湖存储里。

在存储里通过元信息、分区等数据保护，并对接后续计算和剖析，就无缝看到湖、仓里所有存的数据的元信息，无缝对接不同状态的利用场景。

上面介绍一下咱们对常见数据源接入模式的反对。DB 入湖是最常见的场景，在阿里云上，有 RDS 和 PolarDB 等产品。以 MySQL 引擎举例，个别都是有主库、从库、离线库等架构，可能还有主从接入点，然而万变不离其宗。DB 入湖要先做一次全量同步，再做增量同步。对用户来讲，DB 入湖是明确的 Workload，但对系统来讲要先做好全量同步这件事件，再主动对接增量同步这件事件，数据还要通过肯定的机制把位点连接住，确保数据的正确性。整个调度过程通过对立的管控服务获取 DB 信息，主动抉择从库或线上压力最小的实例，进行全量同步写到库里，并保护好相应的 Watermark，记录全量从什么工夫点开始的、从库和主库之间有多少提早等。全量做完之后，开始做增量工作，利用 DTS 等同步 binlog 服务，基于后面的 Watermark 做数据回溯，开始做增量。利用 Hudi 里的 Upsert 能力，以用户定义的 PK 和版本依照肯定逻辑把数据合并，确保数据最终统一，剖析侧的正确性。

在整个 Watremark 保护上须要思考很多，如果全量挂了，再重试一下，位点应该从哪里开始，如果增量挂了，不仅要思考增量之前曾经进行到哪里，还要渐进式的保护增量位点，不能每次增量一挂就回退到最开始全量前的位点，那前面数据提早太重大了。在 Lakehouse 表级别保护这些信息，在 Workload 运行时、重启、重试等过程能够主动连接，对用户通明。

第二个是像类音讯产品的入湖，咱们也做了一些技术摸索和业务尝试，它的数据不像 DB 一样 Schema 都很明确。像阿里云现有的 Kafka 服务里，它的 Schema 只有两个字段，Key 和 Value，Key 形容音讯 Id，value 自定义，大部分时候是一个 Json，或者是二进制串。首先要解决怎么映射成行，会有很多逻辑解决，比方先做一些 Schema 推断，失去原始的构造。Json 原来的嵌套格局比拟容易存储，然而剖析起来比拟吃力，只有打平成一个宽表剖析才不便，所以还要做一些嵌套打平、格局开展等等逻辑，再配合后面提到的外围逻辑，最终实现文件写入、元信息合并等等。这个元信息合并就是指，源头的列的个数不确定，对于不同的行有时候有这个列，有时候没有。而对于 Hudi 来讲，须要在应用层把元信息保护好。Lakehouse 里的 Schema Evolution，就是 Schema 的合并、列的兼容解决、新增列的主动保护等等。

咱们外部有基于 Lindorm 的计划。Lindorm 是咱们自研兼容 HBase、Cassandra 等大宽表接口的 KV 行存。它有很多的历史文件和很多 Log 数据，通过外部的 LTS 服务调，把全量和增量数据通过 Lakehouse 形式存在转换成列存文件，反对剖析。

对 Kafka、SLS 零碎中都有分片（Partition、Shard）概念，流量变化很大时须要主动扩缩容，因而生产侧要被动感知变动，不影响数据正确性的继续生产。并且这种数据都是偏 Append-Only，正好能够利用好 Hudi 小文件合并能力，让上游剖析更简略、更快、更高效。

三、客户最佳实际

以上是技术摸索的分享，接下来会介绍一下在客户的利用。之前一个跨境电商的客户，他们问题就是 DB 数据不容易剖析，目前有 PolarDB 和 MongoDB 零碎，心愿把所有数据近实时入湖到 OSS 上做剖析。当初业界联邦剖析 FederatedAnalytics，问题在于直连查问数据时原库的压力很大，最好的形式就是入湖到离线湖中里做剖析。通过 Lakehouse 形式构建离线湖仓，再对接计算和剖析，或者对接 ETL 清晰，躲避对线上数据的影响，同一架构把整体数据平台构建起来，利用、剖析百花齐放，不影响任何货色。

这个客户的难点是他们有很多库、表以及各种各样的利用 case，咱们在 Hudi 上做了很多优化，也实现了 20 多个 patch 奉献到社区里欠缺 Hudi，包含元信息买通、局部 Schema Evolution 能力，在客户侧也利用起来。

另一个客户数是 Kafka 日志近实时剖析。原来他们的计划须要人肉做很多步骤，包含入湖、数据管理、小文件合并等。通过 Lakehouse 计划，对接客户数据，主动合并入湖，保护元信息，客户间接利用就能够了，外部间接买通了。

还有一个问题小文件，在他们的场景里与 Hudi 社区一起参加 Clustering 技术的建设。Clustering 就是主动将小文件合并成大文件，因为大文件利于剖析。其次，在合并过程中，能够依照某些特定列把数据排序，后续拜访这些数据列时，性能会好很多。

四、将来瞻望

最初，我再分享一下咱们团队对将来的思考，Lakehouse 能够怎么利用起来。

第一，更丰盛的入湖数据源。Lakehous 重要的价值在于屏蔽各种数据差别，突破数据孤岛。在云上很多零碎中有各种各样的数据，有很大的剖析价值，将来要对立更多的数据源，只反对一个 DB 或 Kafka，客户价值不是最大化的。只有把足量的数据汇总到一起，造成大的离线湖仓，并且屏蔽复杂度，对用户的价值才愈发显著。除了云产品，还有其余模式的入湖，像专有云、自建零碎、自主上传场景等。次要还是强化贴源层的能力。

第二，更低成本、更牢靠的存储能力，围绕数据生命周期治理。因为阿里云 OSS 有十分丰盛的计费形式，反对多种存储（规范存储、低频存储、冷存储以及更冷的存储）等等，计费逻辑里几十项，个别人不齐全分明。但对用户来讲，老本永远是设计核心心，尤其是构建海量的离线湖仓，因为数据量越来越大、老本就越来越多。

之前接触过一个客户，他须要存储三十年的数据，他们的业务是股票剖析，要把交易所、券商的所有数据全副爬下来，传到大的湖仓里。因为要做三十年的剖析，老本优化是十分要害的。原来抉择在线零碎，存几个月就扛不住了，因为数据量太大了。剖析数据是有从冷到热、从绝对低频到高频拜访的特点，Lakehouse 利用这些特点，通过定义规定和逻辑，主动屏蔽用户对哪些目录须要冷存储、哪些目录须要热存储的简单保护，帮用户走得更进一步。

第三，更强的剖析能力。在 Hudi 减速剖析的能力里，除了后面提到的 Clustering，还有 Compaction。Clustering 就是小文件合并，比方日志场景，每写入一批就产生一个文件，这些文件个别都不是很大，但文件越小越碎剖析时的拜访代价很大。拜访一个文件就要做鉴权、建连贯、元信息拜访。拜访一个大文件这些过程只做一次，而拜访小文件则成倍放大，开销十分大。在 Append 场景，通过 Clustering 疾速合并小文件成大文件，躲避因为写入而导致的剖析性能线性进化问题，确保剖析高效。

在 Hudi 中如果是 Merge On Read 类型的表，比方 Delete、Update 都会疾速写到 log 文件，在后续读的时候 Merge 数据，造成残缺的逻辑的数据视图。这里问题也很显著，如果有 1000 个 log 文件，每次读须要合并 1000 次，剖析能力进化必定十分重大。这时 Hudi 的 Compaction 能力就会定期把 log 文件合并起来。后面提到，如果齐全要在同一个入湖作业里实现，尤其是文件合并，计算开销很大，在做这些重负载的时候，对入湖链路的提早影响很大，肯定要通过异步化调度的形式，实现写提早保障。并且这些过程都是可弹性的，不论是 100 个文件要合还是 1 万个文件要合，都是能够疾速弹性而不影响提早，十分有劣势。

第四，更丰盛的场景化利用。集体感觉 Lakehouse 还是面向贴源层的能力，配合做肯定水平的聚合。因为更高层次的聚合性和实时性，有更多实时数仓抉择，当初业界比拟火的 DorisDB、ClickHouse 对实时的高频剖析有很大劣势。基于 Hudi、Lakehouse、OSS 做实时剖析没有太多劣势，所以还是以构建贴源层的能力为主。

原来都是近实时入湖场景，然而可能有些用户没有这么多实时性要求，周期性的 T + 1 逻辑建仓能够满足，能够利用 Hudi+Lakehouse 能力，每天查问一部分逻辑增量数据并写入 Hudi，并保护分区，和实现 Schema Evolution 能力。

晚期数据量越来越大，客户通过分库分表实现逻辑拆分。剖析的时候发现库、表太多了，剖析、关联难度大，这时候能够通过构建多库多表合并建仓能力，汇总到一张表后做剖析。

而后是跨区域交融剖析，有很多客户提这样的需要，尤其是海内。有些客户要服务海内用户，必须有局部业务在海内，特地在跨境电商的场景，而它的洽购体系、仓储体系、物流体系、分销体系等又都在国内建设，很多数据想要交融剖析怎么办？首先 OSS 提供了跨域复制，但也只是到数据层面，没有任何逻辑，在这里能够通过 Lakehouse 做逻辑层建设，把不同 region 数据混合在一起，汇总到同一个区域之后，提供对立的 SQL join、union 等能力。

最初 Hudi 有 TimeTravel、Incremental query 的能力，这时候构建 incremental ETL 荡涤不同的表，在肯定水平上通用化，让用户用得更简略。将来内置更多场景化能力，让用户构建和利用湖仓更加简略！

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。