共计 3503 个字符，预计需要花费 9 分钟才能阅读完成。
简介：疾速理解汇量科技在云原生数据湖畛域的摸索和实际，详解 StarLake 的架构及业务利用案例。
作者：陈绪（汇量科技资深算法架构师，EnginePlus 2.0 产品负责人）
内容框架：
• 互联网业务视角看湖仓一体
• StarLake 架构实际
• StarLake 业务利用案例
• 将来方向
一、互联网业务视角看湖仓一体
1、数据仓库
• 结构化数据
• 范式建模
• 预设 Schema
• 流批架构简单
• 计算存储弹性个别
2、数据湖
• 非结构化
• 读取型 Schema
• 流批一体化
• 云原生，人造弹性
• 元数据和对象存储能力继续演进
3、湖仓一体
• 以湖为底座
• 加强元数据扩展性
• 晋升云对象存储性能
• 优化宽表实时数据摄入吞吐
• 剖析、迷信一体化
二、StarLake 架构实际
在咱们本人去实际湖仓一体的利用的时候也找了一些业务场景，比如说咱们的举荐零碎，咱们的设施治理、DMP。一些开源的数据湖组件咱们也遇到了局部问题，也是这些问题驱动咱们从新去设计了一套新的 StarLake 数据湖。
具体来讲解决了这样几类问题，第一个就是 Upsert 的性能，Upsert 要去做实时匡表的插入，每一列每一行有不同的施行流，可能是并发在写。跟个别的 ETL 流程会有比拟大的区别，传统的框架可能它这块的性能优化水平是个别的，StarLake 有做专门的设计。
第二块就是元数据的扩展性，他们往往会在肯定的量级比如说小文件到亿级别十亿级别，个别会有一些性能的扩展性的问题，针对这块 StarLake 也专门用分布式 DB 的形式做元数据扩大。
第三，对象存储的吞吐性，一般来讲数据湖框架，包含 Hive 这些框架根本不太波及这块，没有专门为云上对象存储这种场景去思考。然而咱们在设计 StarLake 的时候就晓得是要专门为对象存储这种存储介质进行优化，所以咱们做了专门的设计去晋升对象存储吞吐。
第四，高并发写入，实时匡表多流并发去更新一个表，这就须要反对高频发写入，须要反对 Copy on Write、Merge on Read 这些不同的模式，每种模式下还会有进一步不同的数据分步优化去晋升实时摄入的性能。
最初就是咱们的一些分区模式，会和查问引擎去进行算子的优化联动。
咱们要实现下面提到的咱们想去做的优化指标，实际上和现有的数据湖框架架构是有肯定的区别的。
以前的数据湖在元数据管理这就是要多版本控制，并发管制。再往下其实还是交给每个计算引擎，他们本身的实现，去读数据写数据。比如说咱们要去读一个 Parquet 这样的开发文件格式，一个劣势存储，往下就是走到 Hadoop File Format 这一层形象。再往下读写 OSS，这是他们的设计。咱们在做 StarLake 设计的时候就发现仅仅元数据这一层是不够的。咱们的元数据、查问引擎、查问打算，文件的解析和对象存储这几层须要联动，咱们从元数据能够下推一些信息到查问打算，查问打算进一步下推一些货色到文件的读写，最初文件的 IO 这一层间接思考和对象存储进行预取。这四层，在 StarLake 外面全副做在一起。
首先是根本的数据存储的模型，这一块其实咱们做的一个比拟有特色的中央就是它反对两种分区模式，这个有点像 Hbase，咱们能够同时反对 Hash 分区和 Range 分区。这两个分区能够在一个表里同时存在。不同的分区模式下数据的散布是不一样的。比如说 Hash 分区的时候每一个分片内它都是曾经按分片分好了，且在文件内是有序的。这样其实它能够取得十分多的性能晋升点。第二个就是咱们在增量写的时候，它也是和其余数据湖比拟相似，首先第一个版本就是成为基准文件 Base File，接下来增量的咱们就是 Delta File，而后去写入，通过元数据管理造成文件组的模式把它们组织在一起。这样的益处就是我在去增量写入的时候能够有一个比拟高的吞吐和并发。
然而数据湖有两种模式，Copy on Write 和 Merge on Read，Copy on Write 它次要是低频更新，Merge on Read 相当于写快然而可能把一些数据合并的开销就推延到读的时候做。
咱们在这一块解决的形式是这样，咱们重写了 Merge Scan 的读数据的物理打算层，它会主动去做 Base 文件和 Delta 文件这两个文件的合并，这个可能和其余的数据湖框架不太一样，他们是让计算引擎本人去做。咱们其实是在文件的读取层间接做这个事件。比方分区信息，在 Hash 分片内做文件合并的时候，咱们做了一个设计叫做 Merge Operator，一般来讲 Upsert 场景有可能是它须要对这个数据进行更新不仅仅是笼罩。比方一个累加池可能始终加，并不仅仅是把老数据间接笼罩掉。这样的一个场景下有个 Merge Operator 容许用户自定义，默认笼罩，也可自定义。自定义的时候就能够实现数值求和或者是字符串拼接等自定义的逻辑，可能节俭十分大量的计算资源。所以 Merge Operator 它参考了数据库的实现形式。咱们其实是借鉴了传统数据库剖析引擎他们做的一些事件。但咱们把它做在一个数据湖的框架外面。
有了多级分区之后，Hash 分区在这种场景下咱们去做 Upsert 性能会十分快，因为咱们去写入的时候，其实开销非常低，只有把 Hash 分片分好，再部分排个序间接写入就能够。它跟历史的数据是没有任何交互的，是纯增量，没有任何历史数据取出写入这样的开销，所以它会十分快。
咱们本人测试跟 Iceberg 比，像这种行级别的更新有十倍的晋升。因为十分大的性能晋升，所以咱们非常容易做到反对多流的并发更新。
第二局部是文件格式这一层去和对象存储 OSS 的拜访去做联结的优化。OSS 和自建 HDFS 比拟大的区别是拜访提早会绝对高一点，所以它在原来的像 Hadoop FileSystem 这样的模式上来拜访，通常会有比拟显著的提早。所以读数据的时候 CPU 利用率很低。咱们想做的事件就是把读数据和计算重叠起来，不过预取做在文件系统层是不太行的，因为 Parquet 这种格局是劣势的存储，最初在剖析的场景可能只读两头某几列，某一个业务查问可能就读一两列。在文件系统这一层不晓得如何去 prefetch 这个信息。所以咱们是做在 Parquet DataSource 外面。Parquet DataSource 里咱们其实曾经拿到了所有的下推条件，拿到这些信息之后去做一个并行化的 prefetch 解决。这样晋升了性能而且它不会对带宽对 OSS 的拜访带来额定的开销，所以在做了这样的优化之后其实在匡表读的场景是有肯定晋升的，这其实是 E2E 的测试，独自看两头读的局部是有两到三倍的晋升。
接下来开展解说咱们怎么去扩大元数据。以前像 Delta Lake、Iceberg 可能就是更多的是往文件系统外面写一个文件，相当于去记录一个多版本的 Mata，遇到了抵触就去回退和重试，效率绝对比拟低。大家用数据湖的时候往往有一个问题，小文件多的时候性能可能会急剧下降，因为它要在 OSS 外面要把一堆的小文件用 Mata 扫出来合并，效率特地低。所以为了晋升扩展性咱们就罗唆用一个分布式的数据库做这个事件，咱们抉择了 Cassandra，它自身是分布式扩大能力十分强的数据库，数据库外面自身有一个 LWT 轻量级事务的性能，就能够用来实现高并发所须要的 ACID 事务，保证数据的一致性。Cassandra 它的保护治理还是比拟容易的，因为它是去中心化数据库的设计。在云上的这种扩容其实会比拟不便。
元数据扩大这块其实咱们还要进一步去做查问打算联结优化，咱们拿到分区信息，比如说有些 Range 的分区、Hash 的分区，这一类的分区其实曾经对数据分布进行了提前的组织，组织的信息会下推给查问引擎这一层。比如说在 Spark 执行一个 SQL 查问的时候，会通知它这个是同一个 Hash 分片的查问，它们人造就能够打消掉 Sort 和 Shuffle 阶段，对 Join、Intersect 这样一类场景会有非常明显的性能晋升。
三、StarLake 业务利用案例
接下来论述 StarLake 实在的一些利用场景。首先咱们本人搭建了一个叫做云原生数据分析智能一体化的平台，咱们给它起的名字叫做 EnginePlus。它构建在齐全云原生的架构，计算的局部齐全采纳容器化的形式去部署，包含所有的计算节点、计算引擎。在存储这一块是齐全计算存储拆散，齐全通过 OSS，在下面用 StarLake 去搭建数据湖加上湖仓一体的能力。咱们还集成了一些 AI 的组件，MindAlpha 这样的云原生的部署，整体的湖仓一体剖析和 AI 一体的平台 EnginePlus 2.0，它能够十分疾速的去做部署，也可能实现十分好的弹性。
四、将来方向
- Flink Sink
- 更多联结查问优化
- Auto Compaction
- 物化视图、Cache
原文链接
本文为阿里云原创内容，未经容许不得转载。
