从 Hadoop 到湖仓一体

众所周知，大数据平台的架构选型一般有两种，一种是我们基于传统的 Hadoop 去构建大数据平台，另一种是根据新的湖仓一体的架构去构建大数据平台。但是在跟数仓、云数仓的竞争当中，发现前者相比于传统数仓在易用性上有很大的劣势。现如今，大数据平台的总体趋势已经开始从单一的 Hadoop 组件逐渐向多样化、生态化的湖仓一体的数据平台进行发展。

湖仓一体产品内核剖析

LAS核心优势

高昂的维护成本 -> Serverless：首先我们这个产品是开箱即用的，不需要任何的平台的管理和调优，只要会 SQL 就能轻松地去上手使用产品。其次一个非常强的弹性，一个超大规模的存算、分离以及单独扩展的能力，并且可以支持这种灵活的计费方式。既有预付费，也有这种按量付费，从而可以去降低平台的使用成本。最后我们是全托管的 Spark，可以去针对用户自身的负载进行调优，并且性能相比开源还有很大的优势，是开源的 2.7+ 倍。
数据孤岛 -> 统一元数据：我们通过一个统一的元数据和系统解决数据孤岛的问题。实现多引擎元数据、权限统一管理，有效降低管理成本。除此之外，我们还支持了这种元数据发现的功能，可以从已有的元数据缺失的数据当中自动的去抽取、分析，构建出它的元数据，极大缩短数据从产生到应用的整体链路。
数据时效慢 -> 智能实时湖仓：LAS 提供一个全托管的智能浮仓，底下有基于 Hudi 深度去优化的一个批流一体存储引擎，支持事务及数据实时更新。同时实现了让一份数据在多种多个引擎、多种查询模式下去进行同时分析，在这种场景下，Presto 的引擎也做了极致的优化，性能是在开源的 3 倍以上。
开发成本高 -> 统一 SQL：LAS 使用多引擎共用 ANSI 标准语法，从而降低使用成本。再进一步，通过 LAS 上层的另一个产品 DataLeap，提供统一管理的开发及调度工具。除此之外通过 JDBC，支持对接各类 BI 工具及数据应用。

内部组件

Table Format

支持 EB 级批流一体，支持实时更新，基于 Hudi 深度优化，100% 产品化内嵌，通过行列混合存储、索引、湖仓统一元数据等技术打造的批流一体的湖仓一体存储方案。

全托管数据湖存储

一个全托管的数据湖存储核心，就是要把数据湖整体服务化。设计目标是针对云原生多租户和高可用性去设计的。其次就是全托管 Hudi Meta Server，它是一个强一致的、高性能的一个数据湖元数据存储系统，最后是全托管的 Hudi Table Optimizer，这是一个专门针对 Hudi 表的一个优化服务。

Spark

LAS 团队在字节内部负责 Hive 数仓和 Spark SQL 应用，基于海量的实践经验，对 Spark 做了产品化输出。在内部 LAS 支撑了 10 万加的节点数，每天会处理 EB 级别的数据，DAU 也达到了万级别。同时我们在产品能力上面，支持了多个版本和多种编程范式。我们支持了 Spark SQL 和 Spark Jar，也同时支持 Spark 2. 3 和 Spark 3，方便客户，可以做一键迁移；同时性能为开源的270%，这是基于 TPC-DS Benchmark 测试。

Presto

Presto 在字节内部有一个 10 万核的超大规模的实践，我们也依托于这个超大规模的实践，针对很多场景做了深度优化，LAS 的 Presto 有日均百万级的查询，提供一个秒级的响应能力。我们单个的数据集最大可能要接近 EB 级，每天扫描可能就要扫描实际 10 PB 的数据。我们的 Presto 的性能也基于 TPC-DS 测试，是开源版的3倍。

Flink

Flink 在字节内部有一个 1000W+ 核以上的内部实践，消息处理的峰值达到了 90 亿 QPS。这个 QPS 在 LAS 之上，也支持了 Flink SQL 和 Flink Jar 这两种作业类型。并且版本层面我们支持了一个开源最新的 1. 16 的版本，以及经过深度优化打磨过后的1. 11 的版本，基本上能做到百分之百的兼容开源。在其他层面我们也做了不少增强，比如 SQL 增加、CEP 增强以及 Runtime 增强。

LAS Unified SQL

刚刚介绍了几个引擎，在引擎之上 LAS 提供一个增值的能力，用统一的一套标准 SQL，再加上多引擎的一个智能选择，去直接去用一种语法去使用这多个引擎，各业务场景它其实需要的引擎也不一样。

LAS 弹性队列

可以帮助助力到企业的降本增效。构建大数据平台，LAS 的 Spark/Flink 为作业级申请及释放资源，最大程度节约资源，响应客户的需求。

湖仓一体实践案例

抖音电商的湖仓一体架构

此业务场景主要包含营销大促、流量诊断和物流监控业务。在早期没有湖仓一体架构之前，它是一个 Lambda 架构。构建一套实时数仓和离线数仓，不仅数据量大，计算逻辑复杂、数据源多，而且宽表构建成本高、计算周期长且增量计算成本高。我们这边给到的解决方案是增加高性能入湖和湖内计算，从而轻松应对数据量增长；基于数据湖存储的多流拼接，简单易用，时效性可达分钟级；基于批流一体存储，使用微批代替长周期增量计算，和离线数据合并，开发运维成本低。

湖仓一体架构下的用户画像平台

用户画像的平台也是有一个特别大的特点，就是数据源是比较多的。业务痛点主要是大宽表存储，自适应更新列难；高频标签更新，单个标签增量 & 批量消费，指定 Snapshot 查询，全量批计算成本高。我们这边的解决方案是基于 Schema Evolution，满足动态更新列的诉求；列级并发更新和消费，满足标签更新诉求；小时级数据归档，满足按照事件时间高效查询诉求；极致优化的 Spark 引擎，从而大幅降低计算成本。

基于湖仓一体架构的金融行业大数据平台

客户对我们的诉求，是我们要给他提供一个满足业务快速发展，并且能支撑数据指数据增长的一个大数据平台。另外一个重点就是我们能快速的去响应实时业务诉求。LAS 它本身去具备了一个企业级大数据平台的能力，它的能力其实覆盖了离线计算、实时计算、交互式分析、用户场景。我们基于 LAS 构建的企业级大数据平台，大幅缩短离线数据加工时长，同时灵活满足实时数据的加工迭代，简单易用的统一 SQL，从而减少开发维护成本。

消费行业传统数仓架构升级

最后一个 Case 是一个消费行业的传统数仓的一个架构升级。最早这个行业其实是使用传统数仓，但由于扩展性的问题，它难以去支撑业务版图扩张带来的一个数据量的爆炸性增长，并且使用这套数仓架构的时候，它会经常会出现这种计算能力不足，扩展性弱导致的一系列的业务问题。我们的解决方案就是提供一套湖仓一体架构，具备海量存储数据存储计算能力的这样的一个服务。同时全托管容器化计算，能够快速扩展算力响应业务诉求；优化原有数据链路，助力企业降低运营成本；最后实时入湖，敏捷分析。

湖仓一体产品规划

第一个重要的方向就是实时湖仓。当前的湖仓能力，更多的其实覆盖的还是这种分钟级的数仓的能力，还没有办法去完整的覆盖实时数仓的诉求，我们接下来会去提供一个秒级可见的流批一体存储。同时在统一 SQL 基础上去加统一的 SQL 引擎，并且针对 SQL 引擎会去做一些解决方案，针对用户的数据回溯、数据质量探查、数据校验等场景做一些针对性的解决方案。

第二个就是智能湖仓，智能湖仓围绕着智能化视图、智能索引构建，基于 HBO 的降本增效，让用户在使用我们的产品的时候可以越查越快，越查越省。

第三个我们在引擎能力会去做持续增强，在 Spark、Presto 的当中不断地去尝试引入一些基于 C + + 实现的段子去进行加速。同时针对这种 Adaptive Query Execution，我们会去不断的持续增强，让 Spark 基本上能做到一个完全免调优的状态。同时也会去做一个自适应的 File Split 的调度，利用到一些缓存的亲和性，进一步的去加速进行查询。

以上就是火山引擎湖仓一体的新发展以及实践规划新理念的全部内容，欢迎对这方面有需求、感兴趣的用户都可以积极地来体验一下我们的 LAS 湖仓一体分析服务。

本文来自公众号：字节跳动数据平台