数据处理关键技术类型及其建设思路介绍

以下内容都是根据相关报告总结的，如果有兴趣了解更多相关的内容，请下载原报告阅读。

1. 云数一体化

建设思路

随着大数据使用场景的不断丰富，数据使用强度逐步加深， 数据的重要性也越来越凸显。其中，数据价值的挖掘离不开两个 最基础的能力——存储和计算，也离不开最基本的承载——服务 器。 一般业务系统的建设，大多采用“前端—服务端—数据库” 的经典构筑模式，且每个业务系统相对独立，系统之间的数据或 权限互联互通。业务系统的数据交互，一般采用数据库表同步或 跨系统 API 接口调用这两种方式。而海量数据处理平台的构筑模 式，第一步是建立一个技术平台；第二步，是将来自业务系统或 其他订阅数据源的数据，实时同步或定时同步到海量数据处理平 台；第三步，经过符合业务要求的数据治理和开发等形成各种丰 富的数据资产；第四步，数据资产采用定期报表、实时报表、数 据同步、数据订阅、直接为业务系统服务等各种方式提供最终价 值。

（1）云的价值和意义 软件系统的生命周期与硬件的生命周期并不是完全同步，有 时软件系统的生命周期可能仅有几个月到几年的时间，有时软件 系统的生命周期却可能有 20 年、30 年或更漫长的时间，甚至超过编写它编程语言的主流生命周期。而硬件设施的生命周期一般 是 3 至 5 年，虽然有很多时候也有被使用超过 7 年的硬件，但实 际的物理可靠性早已无法满足商业生产的要求。 同样，随着时间和业务需求的变化，软件系统的设计、开发、 部署、资源调度的周期越来越快，不再是之前以年计算的漫长流 程，而是更加敏捷的 DevOps 开发部署过程。传统的立项、采购、 测试、上线、周期结束等漫长过程无法很好地适应快速的需求发 展变化等挑战。 为了应对上述挑战，采用云的方式管理团队的基础设施变成 了一种好的选择。基于云技术标准化一层虚拟基础设施，既可以 随着资源需要和项目过程的变化灵活调整，也可以屏蔽底层硬件 生命周期的影响，使得上层的业务系统只需要关注业务本身，而 无需再将精力浪费在硬件异常的处理。

（2）早期设计的海量数据处理技术为何不上云 无论哪种海量数据处理技术栈的实现，均具备数据副本冗余 能力，即：任意非关键节点损坏，不影响集群的整体工作情况， 数据具备高可靠性，数据出了问题可以在极短时间内修复，而且 整个过程对上层服务无感知。换句话说，无论是哪种技术栈，均 可原生具备物理硬件损坏或更新后的兼容与冗余能力，无需使用 云技术再进行一次封装。 其次，基于上文提到的数据价值挖掘过程，海量数据处理的 业务均在平台自身内部实现资源调度和故障迁移，计算任务的上线和下线均可在内部完成管理和冗余，不需要使用云技术再进行 一次封装和管理。 再次，早期硬件资源能力不足，采用千兆网络实现节点间互 联，数据交换带宽严重不足，需要存算一体设计，并采用计算本 地化方式节约数据交换带宽，即：利用数据冗余副本，将计算任 务调度到参与计算的数据副本节点，直接从本地获得数据而非网 络，以此节约网络带宽。 随着万兆网络的逐步普及，且数据规模的增长和数据价值的 显现，存储资源和计算资源不再强匹配，采用一体化设计将会出 现资源配置不均衡或浪费等情况。因此，采用不同的服务器，按 照需求分别部署计算角色和存储角色，从而实现初步的存算分离， 成为一种通用做法。

最后，还有一个不能被忽视的问题，早期的云平台一般能提 供给海量数据处理平台的有效关键能力就是服务器，也就是将虚 拟出的节点当作一台服务器交给平台，而平台把它当作一台物理 机使用。但数据平台本身具有数据冗余能力，这就导致了数据的 双重膨胀，即原本一份数据采用三副本策略，在上云之后，云的 冗余机制可能又在该副本的基础上再加三副本，形成了九份数据 副本的情况，一下子资源被冗余出了九倍，最终形成了严重的资 源浪费情况。

（3）海量数据处理平台的新挑战  云数一体化助力构建了数据即服务（Data as a Service） 的理念，海量数据处理平台迎来了更好的整体解决方案。首先， 随着物理硬件的发展，使得万兆网络或更高条件的网络条件变得 普遍且成本不再高昂。随着数据使用的不断深入而导致的存储资 源和计算资源不均衡情况，也可以通过存算分离的方式进行解决， 而不再有物理硬件方面的阻碍。 其次，随着云和大数据技术的共同发展，存储的多重冗余不 再是一个问题。随着海量数据处理引擎的发展，云提供的存储可 以被海量数据处理技术直接使用，而不必先同步到数据平台内部 才可被后续处理。

其次，随着业务需求的不断发展，海量数据处理技术的不断 发展，出现了更加丰富的计算引擎。较早的 MapReduce 引擎被继 任者 TEZ 逐步替代，Spark 引擎的加入丰富了计算引擎的生态， Flink 引擎的加入则进一步拓展了海量数据处理的能力范畴。但 经典的大数据架构产品设计上很难完成版本间兼容，例如 Spark2.X 与 Spark3.X 的同时支持，此外新增一个全新的处理引 擎从产品架构上看也不是容易的。而业务的发展是逐步滚动向前 的，新的业务有需求，老的业务期望能保持成熟版本，这就为经 典大数据一体化设计产品提出了新的挑战。多云多集群环境或是 解决这个问题的有效途径之一。 再次，大数据的资源调度弹性，是在大数据计算集群内部的 弹性，但与其他业务资源之间存在壁垒，从整体业务使用特征看，一般来说业务系统白天繁忙晚上空闲，而海量数据处理系统恰恰 相反，一般来说是晚上繁忙白天空闲。随着整个平台的使用，业 务系统和海量数据处理平台之间的峰谷也会越来越明显，因此需 要一种基于云的全局弹性调度能力。

最终，采用一切皆服务理念完成云数一体化构建，大数据作 为云的一种服务实现深度融合，而非早期的集中部署。最终实现 云原生大数据能力，实现云数的一体化建设，从而获得以下能力： 一是，全局弹性调度能力。消除平台间的资源壁垒，进一步 提高计算资源的利用效率。 二是，大数据引擎的多版本兼容。实现不同历史时期的数据 应用可以同时在一个平台实现调度和运行，不会导致因一次升级 从而全部数据应用推倒重来的窘困局面。 三是，深度融合降低无效存储冗余。从之前各自独立构建部 署，数据在不同平台间必须进行同步，逐步发展为基于数据湖仓 化实现数据价值的最大化的同时，降低无效存储冗余度，提高数 据一致性。 四是，基于云屏蔽基础设施变更带来的挑战。大数据技术栈 虽然具备数据冗余和架构冗余能力，但当物理硬件故障或损坏后， 完成修复的过程仍旧是需要大数据近乎全部的技术知识体系才 能安全地完成操作。通过云技术，实现对基础设施层故障的屏蔽， 大数据的用户可以将最大的精力关注在数据价值挖掘和利用方 面等更有价值的地方，而非纠结于大数据平台运维。

（4）实现云和数的一体化 海量数据处理技术的基础设施通常以复杂著称，利用云原生 技术，提供敏捷易用低成本的云原生大数据服务，是当前海量数 据技术发展趋势。 云原生大数据底座通过构建虚拟集群，容器化中间件、大数 据组件及工具平台，如 Spark、Flink、Presto 等，屏蔽底层各 种资源的细节，为大数据抽象通用接口，对上实现数据应用的无 缝对接，对下实行云化资源的高效调度，大数据产品对接底座即 可在各种云化环境提供服务，灵活便捷、安全高效且具备较低成 本。

云原生大数据底座为了进一步提升资源利用率，专为海量数 据处理场景设计高性能、高扩展、高安全的统一资源调度器，支持在线和离线的全场景安全混部，具备管理千万级资源能力，在 保证在线服务质量的同时，尽可能提升资源利用率。 基于内存的分布式文件系统缓存，可以同时管理多个底层文 件系统，并将不同的文件系统统一在同一个名称空间下，让上层 客户端可以透明地访问统一名称空间内的不同路径对应的存储 系统内的数据。它统一了数据访问并且连接了计算框架和底层的 存储系统，解决了云原生大数据架构网络 IO 以及数据本地化不 足的问题，应用程序只需要连接到这个缓存层就可以访问存储在 任何底层存储系统中的数据，并能够带来显著的性能提升。

2.存算分离化

建设思路

如今，以数据对抗“不确定性”的需求进一步增多，技术也 随着需求的变化不断发展，带来了计算能力的提升，也会导致原 先的存算一体化资源配置出现比例失调的现象。以海量数据处理 领域的离线计算来说，从最初的 Hive 发展到 Spark，而 Spark 从 Spark1.x 到当前的 Spark3.x，相比于最初的框架的能力，整体 性能上有数量级的提升。基于数据的业务也逐步丰富，随着技术、 业务、数据的高速发展与需求涌现，海量数据处理平台也面临着 存储资源和计算资源需求的不均衡，不同历史时期建设标准的不 一致，不同业务之间使用的技术栈有所差异的挑战。 为了应对上述三个方面的挑战，海量数据处理的技术架构逐 渐从存储计算一体化的构建方式，演进为“存储标准统一、多计 算引擎统一调度”的存算分离构建方式。存储和计算不再一对一强贴合，而是存储支持 HDFS 标准接口和对象存储标准接口，聚 焦存储引擎本身的任务，以完成来自业务系统和历史平台等各类 不同的数据类型和数据源支持。计算则采用统一的云原生调度引 擎，实现多类型、多版本的计算引擎调度，以满足不同建设周期， 不同业务需求的使用。同时采用一致的数据开发与治理平台，形 成对数据的有效管理，避免出现数据碎片化与数据沼泽。 最终，从业务需求实际出发，以“互相之间的标准兼容”为 衔接，以硬件能力为基础，实现存储能力、计算能力、数据开发 与治理能力的各自最大兼容与系统性总体统一的存算分离架构， 从而满足不同建设周期、不同业务需求对大数据平台的实质要求， 避免重复建设、循环建设，使得数据可以持续地被挖掘与发挥其 价值。

基于云数一体的技术能力基础，海量数据处理的技术逐步支 持云原生部署，由此解决上一代技术在硬件资源与负载要求的错 配、资源浪费、系统难升级、难扩容、增删节点需要成倍的资源 处理和数据重分布等挑战，并获得存算分离架构演进所带来的敏 捷、池化、弹性、低成本等优势能力。 存储层构筑多集群融合能力，即：同一平台中，既可以部署 以 Hadoop 为主的存算一体集群，也可以部署以对象存储为主的 存储计算分离集群，亦或是二者同时部署在同一个集群中被使用。 算力层与云原生底座深度融合，通过构建虚拟集群，容器化 中间件、计算引擎及工具平台，如 Spark、Flink、Presto、Iceberg 等，屏蔽底层各种资源的细节，为大数据抽象通用接口，对上实 现上层应用的无缝对接，对下实现云化资源的高效调度。 存储加速层，是基于内存的分布式文件系统缓存作为以内存 为中心的虚拟分布式存储，可以统一数据访问方式，为计算与存 储构建了桥梁，可以大幅提升数据计算的性能。

3.数据湖仓化

建设思路

数据湖通常被认为是一个成本较为低廉的存储库，也被理解 为一种数据组织形态，承载各种各样来源的结构化或非结构化的 原始数据或原始数据的镜像，它可以存储任何类型的数据，包括 像图片、文档这样的非结构化数据。这样的数据存储结构，存储 其中的数据不需要满足特定的 schema，数据湖也不会将特定的 schema 施加其上。相反的是，数据的拥有者通常会在读取数据的时候解析 schema，当处理相应的数据时，将转换施加其上。相 比传统的分治式数据组织方式，数据湖强调的是统一的数据组织 方式，也就是所有的数据都在湖中进行加工、处理、分析和流动。 数据仓库，则是将原始数据源或数据湖中完成数据初步加工 的结果进行进一步的处理。数据仓库主要存储的是基于关系型数 据库组织起来的结构化数据。数据通过转换、整合以及清理，并 导入到目标表中。在数据仓库中，数据存储的结构与其定义的 schema 是强匹配的。

由于业务场景和需求的复杂性，数据湖和数据仓库虽各有优 势，但又有各自的局限性，为了满足业务实际需要，我们常常将 二者联合使用，即：数据湖、数据仓库和其他专门的系统，采用 数据持续集成的办法将架构拼接混合使用，而这将带来三个常见 问题： 一是缺乏开放性。数据仓库将数据转换为专有格式，这增加 了将数据或工作负载迁移到其他系统的成本。由于数据仓库主要 提供 SQL 的访问模式，因此很难运行其他分析引擎，如机器学 习系统。此外，使用 SQL 直接访问数据仓库中的数据非常昂贵 和缓慢，这使得与其他技术的集成变得非常困难。 二是对机器学习或其他新生的技术栈的支持有限。尽管有很 多关于 ML 和数据管理融合的研究，但没有一个领先的机器学习 系统，如 TensorFlow、PyTorch 和 XGBoost，能够很好地在仓库 之上工作。与提取少量数据的 BI 系统不同，ML 系统使用复杂的非 SQL 代码处理大型数据集。对于这些用例，有些数据仓库供应 商建议将数据导出到文件中，这进一步增加了系统的复杂性。

三是数据湖和数据仓库之间的强制权衡。超过 90%的数据存 储在数据湖中，这是因为数据湖使用廉价存储，从开放直接访问 文件到低成本的灵活性。为了克服数据湖缺乏性能和质量的问题， 企业将数据湖中的一小部分数据 ETL 到下游数据仓库，用于最重 要的决策支持和 BI 应用。这种双系统架构需要对数据湖和数据 仓库之间的 ETL 数据进行持续的工程处理。每个 ETL 步骤都有 可能导致失败或引入 bug，从而降低数据质量。同时保持数据湖 和数据仓库的数据一致性是非常困难和昂贵的。除了需要为持续 的 ETL 支付费用外，用户还要为复制到仓库的数据支付两倍的 存储成本。

4.计算融合化

建设思路

计算融合化的目的，是整合不同的海量数据计算组件，形成 统一的计算、查询与分析入口，旨在解决传统大数据架构下诸如 计算引擎的语言门槛高、处理引擎多而杂、海量数据计算链路长 而复杂、资源利用率低、存储异构、数据孤岛等痛点和问题。其 建设思路具体如下：

（1）语法自适应 支持对接不同类型的外部计算（执行）引擎，包括 Presto、 Livy、Hive、Flink，以及丰富多样的数据源，如MySQL、PostgreSQL、 Hive、SparkSQL/Livy、Oracle、Phoenix (HBase)、ElasticSearch、 Kylin、ClickHouse、Druid、Presto 等。引擎之间、数据源之间 所使用的 SQL 语法存在一定的差异，作为计算分析的入口需要能 够有效屏蔽语法差异做到语法自适应，从而为整合不同的海量数 据处理组件提供基石。提供一套通用 SQL 语法，并通过 SQL 兼容 转换功能来实现不同 SQL 语法之间的转换；做到在用户无需更改 SQL 语法的前提下实现底层执行引擎的切换，通过一套 SQL 语法， 自动适配不同计算引擎和数据源语法。 顾名思义，SQL 兼容转 换功能整体可以划分为两个模块，即 SQL 兼容与 SQL 转换。 SQL 兼容：在进行 SQL 兼容时，为解决部分大数据平台语法 与业务强耦合、定制化严重，以及不同语法强行融合易导致歧义 的问题，遵循干净、可扩展、可替换、多场景兼容的兼容准则，提供插件式的解析模块，将 SQL 语法模板化，分类管理，形成可 扩展、多样的 SQL 生态。将 SQL 语法分为两大类即通用型（如 SQL 标准语法，以及常见的 Spark、Hive、Flink 等大数据查询语 法）、独特型（自定义语法，不具有普适性），基于分类语法模 板、语义扩展定义、配置文件生成多样的 SQL 解析器，并且支持 动态切换解析器，灵活性强。任意解析器得到的语法树均将转换 为统一的逻辑计划，可基于此逻辑计划生成符合不同引擎或数据 源方言语法的执行语句（这一过程即 SQL 转换）。默认使用通用 Parser，其基于 SQL 标准语法，支持大部分通用大数据语法（如 Spark、Hive 语法），适用于大部分的大数据系统组件。而对于 一些与业务逻辑强耦合的自定义语法，支持自定义 SQL 模板，生 成自定义解析器，通过这种做法，结合上文提及的生成统一执行 计划以及下文提及的 SQL 转换，可以灵活地将业务任务切换到指 定引擎。

SQL 转换：SQL 转换发生在两个阶段，一阶段是通过解析器 得到抽象语法树后，进行语法树重写以确保该语法树能转换为统 一逻辑计划；另一阶段是基于统一逻辑计划与不同引擎或者数据 源语法之间的等价映射关系，能够将逻辑计划转换为不同的引擎 或数据源语法，做到执行引擎的无感切换，也为下文的智能引擎 选择功能奠定基石。 这种执行引擎的无感切换，不光能让平滑进行智能引擎选择， 充分发挥引擎的优势特点，增加 SQL 执行效率；还能支持业务无感迁移，做到在用户无需更改 SQL 语法的前提下实现底层执行引 擎的切换，并且尽量最小程度地更改用户的使用习惯。 通过 SQL 兼容和 SQL 转换，能够统一计算入口，整合大数据 平台组件，降低大数据系统使用的门槛和繁琐程度。

（2）引擎选择自适应 智能引擎选择是计算融合化的进阶功能之一，表现融合的自 适应性。通过组合算法，自动为每条用户 SQL，挑选合适的不同 类型的计算引擎（如 Presto、Spark 等）来执行，以提升用户体 验（如响应时间快、可靠性高等）和资源利用率（CPU、内存等）。 传统基于 RBO/CBO 的 SQL 优化框架，存在规则人工定制、统计信 息缺失、历史流水闲置、失效资源浪费等几个主要问题。针对这 些问题，可以设计一套基于历史负载的查询优化（History-Based Optimization，HBO）和基于机器学习的引擎选择。HBO 目标是分 析处理历史用户 SQL 流水，以通用、抽象化的 HBO 策略，增强补 充（非取代）已有的具体化 RBO/CBO 策略。机器学习算法可以自 动学习 SQL 特征，更好地弥补人为规则的黑角。把 HBO 和机器学 习结合起来，可以更好地降低日均提效失败（即错误选择引擎后 执行失败）的 SQL 数，提升用户 SQL 的平均执行时间，减少引擎 集群无效负载的同时节省宝贵的计算资源。 HBO 框架的设计实现包括四个子模块；它们也代表了一条用 户 SQL HBO 优化的四个串行阶段。基于引擎选择（SQL 优化）的 实时性要求，整个 HBO 耗时必须控制在毫秒级。

查询签名：执行的所有计算类 SQL 语句（DQL/DML），无论 执行结束后状态是成功还是失败，流水入库时都新增生成查询签 名（Query Signature，QS）字段。 查询签名是自研设计的 SQL 文本的 “浓缩” 表示，包含 SQL访问的库表名和关键子句（Filter/Join/GroupBy/Orderby） 中包含的列名。通过 QS 来匹配判断当前用户 SQL 与哪些历史 SQL “HBO 等价”，然后通过分析汇总这些历史等价 SQL 的执行特征， 来决定当前 SQL 是否应选某类引擎执行。 索引宽表：HBO 要求为每个最新提交的用户 SQL，从历史流 水库中查找其最近一段时间内等价的历史 SQL 集。依赖外部的统 一元数据服务，固化缓存 HBO 索引宽表来解决检索的实时性能问 题。宽表的每一条记录对应一条历史查询，包括查询签名、执行 时间、引擎类型、结果状态、数据量、引擎 shuffle 数据等信息。 历史检索：基于查询签名的完全匹配（exact match），调 用统一元数据服务的 REST API，返回最近历史区间（如一周）内 的索引宽表记录集。通过不同的 API 入参，指定返回记录集的最 大行数、起止日期、超时时间等属性，确保检索的实时性能（平 均 < 100ms）。 提效判定：分析统计获取的历史记录集，综合执行时间、失 败率、引擎分布等数据，对比系统阈值参数，决定是否对当前 SQL 选择使用的某类计算引擎来执行。

（3）计算运行时自适应 传统的大数据架构下，整个计算链路通常是单向的，上层计 算缺少底层状态（比如资源状态）的反馈。单向链路虽然简单， 但会造成计算资源不均衡、资源利用不充分等问题。算力感知是 计算融合化的又一个进阶功能，是自适应计算架构里底层反馈的 桥梁，让上层计算具备感知资源状态的能力，进而自适应地调整 资源使用。通过算力感知，可以获取计算资源整体的资源状态以 及单节点详细的算力指标，上层计算借此自适应地动态调整计算 决策、资源使用、任务调度等。 以 Presto 为例，作为一款典型 的 MPP 架构、纯内存计算的交互式查询引擎，为了追求性能的最 大化，Presto 会尽可能地利用节点上可用的资源，包括 CPU/内 存/网络带宽等，节点间的物理资源规格也需要尽可能保持一致。 然而在实际的使用场景中，节点的 CPU/内存等负载（算力）是随 时波动的，而 Presto 的原生任务调度策略并未将节点的算力考 虑在内，导致在节点算力明显下降的情况下，计算任务会受到严 重的影响，从而产生长尾问题。为此，Presto做了针对性的优化， 在动态的计算环境中，通过感知节点算力的变化，自适应地调整 计算任务的调度，避免低算力节点的影响。 Presto 自适应任务 调度主要分为：Task 自适应调度与 Split 自适应调度，方案实 现的核心思想是：根据节点的算力情况动态分配 Split 和 Task。

Presto Coordiantor 在运行过程中，会实时感知 Worker 节 点的算力变化情况，同时计算出对应的节点可用算力权重，在 Task 和 Split 的调度过程中，针对不同的算力权重，根据模型计算出相应的 Worker 上还可分配的 Task 或 Split 数目，对于算 力严重下降的节点，少分配或不分配 Task 或 Split，尽量避免 长尾问题，从而做到自适应的调度。 自适应调度效果：当计算 Task 在 CPU 波动比较大的节点上，会造成明显的计算长尾的问 题，拖慢整个任务的运行，在没有开始自适应调度 的情况下，Task 的执行时间波动很大。

在开启自适应调度后，Task 会避免调度到 CPU 算力差的节 点，有效地消除长尾问题。如图 6 所示，Task 的执行时间更加均 衡，避免长尾问题影响整个计算任务的性能。

（4）资源自适应 面向大规模集群部署，多集群是运维管理的常规手段。但从 资源管理的角度，多集群会带来诸多问题： 一是资源对业务不透明，业务在使用计算资源时，需要人为 指定特定集群。人为选择集群的方式不仅麻烦，也会带来集群负 载不均衡的问题； 二是由于资源不能统筹管理，资源整体利用率不高。资源自 适应的目标是能够把所有资源统一管理起来，对计算提供统一的 资源池，对资源统一调度，打破集群间的隔离问题，实现对资源 的公平共享，充分利用空闲资源，提高资源利用率，同时对业务 透明化。 资源自适应主要包括集群间弹性伸缩和集群内资源调度。每 个租户对应一个虚拟 K8S 集群，每个租户都有最低的资源保障， 租户之间能借用资源，也可以借用集群空闲资源。通过自适应调 配资源，打破集群间的隔离，充分利用不同业务的潮汐效应，错 峰使用资源，提升整体的资源利用率。

（5）数据编排自适应 在公有云、私有云、内网不同场景中，大数据底层存储是异 构的，主要涉及 COS、HDFS、Ceph、Ozone 等。面向异构化的存 储，自适应计算平台构建了一层统一的数据编排层，位于计算和 存储之间，透明化存储差异。通过适配不同的权限和认证体系的 统一的存储 Client，解耦计算和存储，避免不同计算引擎和不同 存储间的相互适配工作，让计算和存储更加专注。在大数据场景中，每天产生海量的数据，而数据治理往往赶 不上数据积累的速度，海量元数据以及小文件会给存储 Master 节点（例如 HDFS NameNode）极大压力，造成性能抖动。数据编 排层会自适应缓存存储元数据，以及自动小文件合并，减轻 Master 节点压力，同时在跨 DC 数据访问时，加速元数据访问， 提升数据访问速度。