湖仓一体架构在火山引擎 LAS 的探索与实践

动手点关注

干货不迷路

火山引擎湖仓一体分析服务 LAS（Lakehouse Analytics Service），是面向湖仓一体架构的 Serverless 数据处理分析服务，提供字节跳动最佳实践的一站式 EB 级海量数据存储计算和交互分析能力，兼容 Spark、Presto 生态，帮助企业轻松构建智能实时湖仓。

LAS 服务是什么？LAS 有哪些优化特性？本文将从基础概念、数据库内核特性优化、数据服务化、业务实践等角度全方位介绍湖仓一体架构在LAS的探索与实践。

LAS服务是什么？

在了解 Las 服务是什么之前，先来了解一下数据平台整体行业的发展趋势，大概分为三个阶段。

第一阶段，一般被称为传统数仓，一种从 1980 年开始的基于传统数据库技术来做的 BI 分析场景。在这种架构下，通常计算和存储是高度一体的。整体系统能支撑的计算能力，依赖于服务提供商的硬件配置，整体成本高，存在物理上限，扩展起来比较麻烦。

第二阶段，随着技术的演进， 2010 年开始出现了以 Hadoop 技术体系为主流的传统数据湖。在以 Hadoop 技术为主的数据平台架构下，通常可以支持服务在普通硬件上面去部署，整体的计算和存储的扩展性都得到了解决。基于开源技术生态，多个大型公司也参与到数据湖技术发展中来，整体生态繁荣度也在逐步提升。

但在这一阶段凸显出了一个问题，随着生态技术的发展，越来越多的开源组件开始累积。对于一个企业来说，为了解决不同领域的问题，需要运维多个开源的组件，来满足不同领域的数据需求，就导致整个企业的技术运维成本逐步提升。

基于这个问题，随着技术的进一步发展，在 2020 年，湖仓一体的架构开始被提出。

相比起传统数据湖，湖仓一体架构支持原生的 ACID 能力，支持像 BI 分析、报表分析，机器学习和流式分析多种类型的计算范式，以及云上的对象存储和弹性计算能力。以上能力，让湖仓一体架构能够有效地去解决企业的对数据规模，以及对计算能力的弹性伸缩需求。同时，湖仓一体可以在很大程度上规避传统 Lambda 架构存在的多个计算组件，或者多种架构范式导致的架构负担，让企业能够更专注地去解决他们的业务价值。

LAS 就是基于湖仓一体的架构进行设计的。从上图来看，LAS 架构整体上分为三个部分。最上层是开发工具层，开发工具层会通过计算层提供的统一 SQL 访问服务去访问计算层，根据用户的 SQL 类型自动做 SQL 解析。所有引擎计算能力统一由弹性容器服务来提供，可以支持弹性伸缩，按需使用。

再往下就是湖仓一体的存储层。首先，湖仓一体存储会通过统一的元数据服务，向计算层提供统一的元数据视图，屏蔽底层的具体元数据实现细节，可以使多个引擎无缝对接到统一的元数据服务。

接下来是湖仓存储引擎，它主要提供了事务管理能力，也就是 ACID 的能力，以及对数据批流一体的读写能力。

再往下就是 LAS 基于火山引擎对象存储服务 TOS 和 CloudFS ，来提供 EB 级的数据存储能力和数据访问的缓存加速能力。

以上就是 LAS 整体的技术架构。

LAS 数据湖内核剖析

这一版块将向大家呈现 LAS 数据湖内核的特性及优化。

LAS 的数据湖内核—— ByteLake 它是什么？

首先，ByteLake 是基于开源 Apache Hudi 进行内部增强的湖仓一体存储引擎，提供湖仓一体的存储能力。

它的第一个主要能力是提供了湖仓统一的元数据服务，完全兼容开源的 Hive Metastore，可以无缝对接多种计算引擎。第二个主要能力是可以支持对海量数据的 Insert，完全兼容 Hive SQL，可以平迁传统数仓场景下的 Hi