当前位置：主页 > 查看内容

StarLake：汇量科技云原生数据湖的探索和实践

发布时间：2021-06-09 00:00| 有位朋友查看

简介：作者陈绪汇量科技资深算法架构师 EnginePlus 2.0 产品负责人内容框架互联网业务视角看湖仓一体StarLake 架构实践StarLake 业务应用案例未来方向一、互联网业务视角看湖仓一体 1、数据仓库结构化数据范式建模预设 Schema流批架构复杂计算存储弹性一般 2……

作者陈绪汇量科技资深算法架构师 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 它可以非常快速的去做部署也能够实现非常好的弹性。