如何实现云上 Lakehouse 高性能

构建云上 Lakehouse 面临的挑战

构建 Lakehouse 的目的是在数据分析时实现更好的性能、更低的成本。这里的成本包含技术成本、运维成本、使用的计算成本和存储成本，同时整个系统要有很好的可用性。接下来介绍在性能、成本和可用性等方面面临的问题。

1. 性能。在云上存储为统一的对象存储，对象存储和 Hadoop 生态的 HDFS 还是存在一定的差异性，如何保证数据入湖和查询效率是一个不小的挑战。同时还需要 StarRocks 高效的读写云存储。提高性能传统的方式是扫描，尽可能的扫描少的数据文件和良好的索引，在 IO 层面有很好的 IO 能力。

2. 成本。包含两部分成本，一是硬件成本。在大多数数据分析系统中，存储和计算并不对等，如何实现存储成本量化计算成本量化也需要对现有架构进行改进才能实现。另一方面数据分析系统非常复杂，如何高效运维是一个很大的挑战。

3. 可用性。对象存储保证了数据良好的可用性，但是如何高效稳定的使用湖格式是一个很大的挑战。尽管 Iceberg 和 Hudi 也提供了一定的管理工具，但是可用性依然很低。因此在云上需要提供标准化的产品能力提升湖的可用性。

#02

如何实现云上 Lakehouse 高性能

1、StarRocks 云上架构优化

在可用性方面，StarRocks 的架构简洁，整个系统核心只有 FE 和 BE 两类进程，不依赖外部任何主线，方便不属于维护。同时 FE 和 BE 模块可以在线水平扩散，元数据和数据都用副本机制，确保整个系统无单点。

FE 是 StarRocks 前端节点，负责管理元数据，管理客户端连接，进行查询规划查询调度。FE 配置根据配置有两种类型的角色， Follow 和观察者。Follow 选出一个 Leader，只有 Leader 会对元数据进行写操作，非 Leader 节点会自动将元数据写入路由到 Leader 节点，每次元数据写入的时候必须有多数的 Follow 写入成功才算成功。那么观察者不参与选组操作，只会异步同步并且回放日志，用于扩展集群的查询并发能力。每个 FE 节点在内存里都会保留一份完整的元数据，每个 FE 节点能提供无差别的服务。FE 为了保证性能，在 SQL 做完语义分析之后，还会进行分区裁剪，已过滤掉不必要的数据，同时还会基于 catalog 里面的统计数据进行 CBO 优化，以此生成的物理执行计划是最优的状态。

BE 是 StarRocks 的后端节点，负责数据存储以及 SQL 执行等工作。BE 为了保证良好的性能和扩展性，在执行层面引入了向量化执行器，使用 SIMD 指令集来获得更高的性能，而同时设备又有着较低的负载。同时 BE 在 IO 接口方面有良好的扩展性设计，使得很可以很方便的去扩展实现云存储，比如对象存储、CHDFS 等存储。

云侧为了降低应用侧的改造成本、同时拥有更高性能，实现了融合存储等技术，使得传统对象存储在调用文件系统 API 时和传统文件系统有着一样的性能表现。同时为了加速云上 StarRocks，引入了两层 Cache 和物化视图技术。

LocalCache 技术：在 BE 级点缓存底层存储数据块实现就近访问，可以通过良好的淘汰算法保证上层有极致的性能。因为云上的 StarRocks 工作在计算存储模式下，BlockCache 主要是缓存对象；存储数据块到计算节点，通过 BlockCache 来降低访问对象存储的延时，以获得良好的性能。物化视图技术：这里的物化视图，是指对经常使用的结果集进行物化，在查询的时候，通过 FE 的 SQL rewrite 直接提取物化结果来提升性能。

​