字节跳动杨诗旻：浅谈数据存储与计算「终于解决」

欢迎大家来到IT世界,在知识的湖畔探索吧!

引言

存储与计算支撑、推动着数据的生产、留存与应用，是数据智能的基础模块。

那么，存储和计算在大数据架构的实践应用中的现状如何？会遇到哪些挑战？为此，DataFun与火山引擎 LAS 产品化技术负责人杨诗旻进行了对谈，探讨了上述问题。

杨诗旻老师于 2019 年加入字节跳动，目前是数据湖团队技术负责人。团队负责基于 Hudi 的 EB 级数据湖解决方案，在字节内部的实时数仓、离线数仓和推荐系统等多个场景落地，还负责火山引擎产品 LakeHouse Analytics Service 的相关技术。目前聚焦于湖仓一体和批流一体的架构演进，在大数据计算、存储、数仓优化等领域有丰富的经验。

DataFun社区｜出品

数据智能专家访谈 第13期｜来源

▼

01.

数据存储

1. 分布式存储

从大数据的应用视角看，分布式存储主要有几种主流的类型，分别是分布式文件系统、对象存储和分布式块存储。

其中分布式文件系统最被大家所熟知的是 GFS 和 HDFS，可以说是大数据时代的 1.0。现在企业自建的大数据集群，持久化的数据大部分都是存储在分布式文件系统 HDFS 之上。HDFS 与 Hadoop 生态的其他组件高度集成，也经过了大量的打磨，在大数据的领域成熟度可以说是最高的。但是在可扩展性上，相比于对象存储还是有劣势的。

而对象存储，则是随着云计算的普及，以及非结构化数据的快速增长而被广泛应用。对象存储最具代表性的产品就是 AWS 的S3 了，后续也逐渐成了每个云厂商必备的存储产品。对象存储最初主要被用于数据的备份和归档，以及一些多媒体类的非结构化数据存储。后来随着越来越多的企业上云，并尝试将对象存储作为大数据平台的存储引擎，并与 Hadoop 生态做了集成，例如通过 HDFS 来访问 S3 的数据、通过 Hive、Spark 处理 S3 上的数据。

分布式块存储，最典型的应用就是在虚拟化和容器化的场景下，分布式块存储在具备高性能的同时，也能提供极高的可用性和容错能力，以及数据的可靠性。当然，分布式块存储相比对象存储和分布式文件系统，在性能上是有优势的，但是相比于本地存储，在成本和延迟上，还是存在一定劣势。

除此之外，业界也有尝试去将这三种存储类型做一个大一统，最典型的就是 Ceph。Ceph 的底层存储本质是对象存储，并在对象存储之上实现了分布式文件存储和块存储。各个存储引擎在垂直领域都有自己的优势，

而在分布式存储之上，另一个重要的话题就是存储格式，选用一个适合的存储格式，能大大提升数据处理的效率。在大数据的领域，列式存储逐渐成为了主流，开源的 Parquet、ORC 被各个大数据的计算引擎所接纳，用于加速数据处理，降低存储成本。

同时，数据湖表格式也正在快速发展，并逐渐成为企业在数据湖之上构建数仓的首选之一，最典型的就是 Hudi、Iceberg、Delta，在分布式文件存储和对象存储之上，提供了 ACID 和索引的支持。

2. 数据库

数据库从大类上面来分，主要分为关系型数据库、NoSQL 数据库。传统的关系型数据库相信不需要展开介绍了，还有一些 NewSQL 数据库，基于存算分离的架构，解决了传统数据库的存储扩展性问题，但是技术成熟度相对于老牌的 Oracle、MySQL 还是有不小的差距。

NoSQL 数据库有很多细分，例如 KV 数据库、文档数据库、列存数据库、图数据库等等。

其中 KV 数据库适用于高性能和低延迟的场景，最典型的就比如 Redis。文档数据库和图数据库顾名思义，适用于文档和图计算场景。

列存数据库相对来说在大数据领域应用的比较广泛，可以展开讲讲。

从早期的 MonetDB 和 Vertica，列存储数据库的出现和向量化计算就脱不开关系，我本人对于列存、向量化计算的研究也是从它们的论文开始的。

到后续出现的 HBASE，Cassandra 这些非典型的列式数据库，虽然提供了表格存储的抽象，以及非常灵活的存储模型，但是实际是使用列簇而非列存。以 HBase 为例，实际上每一个 Cell 都是以 KV 的形式存储。这使得 HBase 能一定程度上兼顾点查的能力，但是过滤下推的能力比较有限，需要用户根据实际场景设计 Row Key。

再之后就是 ClickHouse、Doris 这些开源的列式数据库，以及 Parquet、Orc 等开源的列存格式。前者更聚焦于极致的 OLAP 查询性能，提供更低的查询延迟，后者更聚焦于开放的存储格式，具备非常好的 Hadoop 生态兼容性，与各个大数据组件的深度集成，以及深度的压缩能力。

3. 场景

从元数据存储，到临时数据存储，以及持久化存储，可以说数据存储涉及到了整个大数据系统的方方面面。

元数据的存储，最典型的就比如基于 Hadoop 构建数仓使用到的 Hive Metastore，底层的元数据就存储在传统的关系型数据库中，当然也有过一些 NewSQL 的尝试，在存在大量冷数据的情况下，会比传统的 MySQL 有优势，但是从成熟度上来讲，还是会首选 MySQL。此外，还有当下比较流行的数据湖 Table Format 的元数据存储，由于保存了大量的元数据信息，使得元数据本身也变成了大数据，这些元数据除了保存在分布式文件系统或者对象存储上之外，还有专门为数据湖定制的元数据管理系统，来兼顾海量元数据的存储与查询性能。例如火山引擎 LAS 团队向 Hudi 贡献的 Hudi Meta Server，除了直接在分布式系统上管理元数据外，还支持通过 MySQL 或者 NewSQL 托管元数据，未来还会将多级的元数据存储能力贡献到社区。

临时数据存储，有计算引擎在计算过程中的 Shuffle 和 Spill 数据，也有日志数据。这些数据有些被存储在本地磁盘，有些会被存储在弹性块存储之上，还有一些会存储在分布式文件系统上。

持久化数据，主要存储在分布式文件系统和对象存储之上。往往会包含大量的日志数据，业务系统的业务数据也会通过数据集成来汇聚到大数据的存储当中，来做备份和分析。

4. 存储能力与行业需求

对于构建企业级的大数据平台来说，在存储的选择上，首先要考虑的就是数据量，不同的数据规模对存储组件以及背后的开发运维团队的要求是截然不同的。当要构建一个 PB 甚至是 EB 级的大数据平台，如果没有一些合规上的强约束，首选还是使用云厂商提供的存储产品矩阵。云厂商可以提供多个存储产品，使客户可以根据需求选择合适的产品。

很多时候，对于企业来说，需要的不是一个单独的存储产品，而是一整套离线数据加工和存储的解决方案。这种场景下，往往可以直接全托管的数仓产品。如果又想存大量音视频数据，则可以使用对象存储。

对于云厂商来说，稳定性、高可用是最基本的要求，而如何在提供相同等级的服务的情况下降低客户的成本，是一个关键任务。

另一方面，对数据存储的需求往往有行业属性，在这里简单略微展开介绍一下。

例如金融行业，对数据的安全和隐私保护，以及数据的完整性和可用性有着非常高的要求。往往建设多地多数据中心，并实时或定期做数据的备份和同步来实现数据冗余，保障数据的一致性。并且真正当灾难发生时，具备快速恢复数据的能力。

对于制造业来说，随着物联网和产业智能化升级，数据量也有大幅度的增长，往往会采集大量由设备产生的时序数据、物料数据、供应链数据等等，一般会被存放在时序数据库或者 NoSQL 数据库中，同时业界也有为物联网垂这个直领域专门打造的数据库。

其他的诸如互联网行业、媒体行业、电信行业、能源行业等等对数据存储的需求，就不一一展开介绍了。

▼

02.

数据计算

在大数据的领域，除了存算一体的组件和模块外，数据计算主要类型是离线计算和实时计算。

在数据计算的基础设施角度来看，主要有几大挑战：

第一，离线计算引擎的选型上，Spark基本上已经成为业界标准。但是对于许多企业而言，还有大量的 MR 和 Hive 作业。如何在不影响业务的情况下，完成数据计算引擎的迁移是一个巨大的挑战。这里还往往会涉及短期投入和长期价值之间的权衡，以及大量的长尾迁移工作。实时计算引擎的选型上，Flink 也成为了当下的业界标准。而由于实时作业往往有极高的时效性要求，迁移的过程也同样有极大的挑战。

第二，如何拥抱云原生和 Serverless 架构，也同样是一个巨大的挑战。虽然在任务调度和资源管理上，Yarn 依旧是大数据平台的主流选项。但随着越来越多的企业选择上云，尝试使用 K8S 做在离线资源一体化调度。但是各个数据计算引擎，在 K8S 上的成熟度，还远不如在 Yarn 之上。当切换为容器化部署之后，除了资源调度上的改变，对本地磁盘的使用也会发生改变。

也许通过几个例子，能更好的描述这一方面所面临的挑战。比如说离线计算领域，云原生改造后的 Spark，由于缺乏在 Yarn 上的 External Shuffle Service，在计算过程中的 Shuffle 数据量比较大的场景下，需要引入 Remote Shuffle Service 来替代。前几年有一些海外的 RSS 开源框架，比如。而近些年国内的各个云厂商也陆续将一些 RSS 的框架开源，来帮助企业完成离线计算的云原生话改造。

又比如实时计算，云原生改造之后的 Flink，由于有状态计算对于磁盘有极高的延迟和吞吐的诉求，使用云盘往往会有较高的成本，相比本地盘也有一定性能上的差距。未来会出现一些存算分离架构下的状态存储，来平衡性能与成本的诉求。

第三，从架构上来看，湖仓一体的架构逐渐趋于成熟。通过结合数据湖存储格式，在分布式文件系统和对象存储之上，提供了数据更新、增量读写、Schema 演变等等能力。而在接下来，如何通过索引和缓存层的优化，解决存算分离架构下的性能问题，提供接近数仓的查询体验，也是数据计算层面需要解决的最大的挑战之一。

第四，从数据计算的引擎内核上来看，离线计算相比于实时计算更成熟一些。离线计算接下来的一个重点方向就是 Native 化，使用 C++和 Rust 这样的语言，对一些 Java 实现的计算引擎进行 Runtime 的改写，能够让引擎能够与底层硬件、操作系统、网络和存储进行更紧密的集成，从而带来性能上的大幅提升，以及成本上的缩减。典型的就比如 DataBricks 的 Photon 引擎，替换了 Spark 原本的 SQL Runtime。又比如开源的 Velox 和 Gluten，尝试做通用的 C++ Runtime 来提升 Spark、Presto 等开源计算引擎的性能。

而实时计算，一个最大的挑战就是对长周期、复杂计算的支持力度。当用户想要实时计算一些周级、月级等长周期指标的时候，其开发成本、运维成本、资源成本都远高于离线计算。相信未来应该会有支持存算分离、冷热分层的状态存储，来解决这些问题带来的挑战。

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

– End –

访谈人：杨诗旻 字节跳动

与谈人：刘晓坤 DataFun

撰文：刘晓坤 DataFun

▌2023数据智能创新与实践大会

• 4大体系，专业解构数据智能
• 16个主题论坛，覆盖当下热点与趋势
• 40+演讲，兼具创新与最佳实践
• 1000+专业观众，内行人的技术盛会

第四届DataFunCon数据智能创新与实践大会将于⏰ 7月21-22日在北京召开，会议主题为新基建·新征程，聚焦数据智能四大体系：数据架构、数据效能、算法创新、智能应用。在这里，你将领略到数据智能技术实践最前沿的景观。

欢迎大家点击下方链接获取大会门票～

DataFunCon2023（北京站）：数据智能创新与实践大会 �-�百格活动

▌数据智能专家访谈

“数据智能专家访谈”是 DataFun 新推出的内容系列，本系列旨在访谈不同公司的核心技术人员，得到专家在不同领域的洞察，包括但不限于行业重点、热点、难点，增加读者对行业技术的了解。

▌大话数智

大话数智，是DataFun策划的智库类公众号，包括但不限于知识地图、深度访谈、直播、课程等学习资料，旨在为广大数据智能从业者、数据智能团队提供一个日常学习成长的平台，促进先进的数据智能技术的传播与广泛落地。