灵活、快捷、低运维成本的数据集成方法：数据联邦架构

在传统的企业数据运用中，企业使用多种系统，数据散落在各个存储设备中，数据分析需求往往是跨库的，数据入湖入仓在做分析会有安全问题，或影响业务系统性能。企业需要一种灵活、快捷、低运维成本的数据集成方法，就有了数据联邦架构。本文介绍数据联邦架构。

— 数据联邦概述—

在传统的企业数据运用中，常常会出现这样的困境：企业使用多种系统，数据散落在各个数据存储，数据分析需求往往是跨库的，有两种方式可以解决这类需求。一是先做数据集成（ETL）将数据整合到数据湖或数据仓库后再做分析，这种一般适合需求相对确定、同时存量系统可以迁移到新数据平台的业务场景下。而对另外一些企业，由于其平台建设的阶段性特点，可能存在需求在快速变化、或者存量系统因为各种原因不能直接迁移的情况，基于 ETL 入湖再分析的方案可能会存在业务响应速度慢、灵活度低和过程复杂的弊端，企业需要一种能更灵活、快捷地进行数据集成的方法，这就是数据联邦架构。

数据联邦解决了“数据孤岛”问题，并且避免了传统 ETL 流程长，开发和运维成本较高的问题，可以应用在对数据采集有灵活性、实时性要求，或者存在异构数据源处理的场景。

• 虚拟的操作型数据库（ODS）

通过虚拟操作型数据存储（ODS），构建可操作的数据集成视图，数据变化会很快反映到 ODS，且联邦的数据源数据源可随具体的分析需求灵活增减变化，因此能满足一些轻量、短期的数据分析，或者实时灵活的仪表盘应用。

• 建造数据中转区

利用数据联邦构建数据中转区，可以对大量从生产系统进入数仓的数据进行快照合并，极大减少数据复制对生产系统的干扰。数据中转区对数据变化的实时存储，能记录完整的数据变更信息。

• 数据仓库的扩展

企业部署数据仓库后存在问题：一方面，整个企业不太可能只使用单一数仓；另一方面，企业仍然有大量的数据未存入任何数仓，需要构建统一视角。而数据联邦和联邦计算能在无需转换格式和移动数据的情况下，提供所有企业数仓和零散数据的统一视角，降低了数据移动转换的成本。

• 异构平台迁移

在异构平台迁移过程中使用联邦计算，能使迁移过程更平滑，无需考虑数据的迁移和异构平台语法不兼容等问题，保证应用对数据的使用不受影响，且能在迁移完成后在不影响新应用的前提下更改数据源配置。

• 异构数据分析

企业可以利用数据联邦的能力，实现跨结构化数据、非结构化或者半结构化数据的分析。尽管数据联邦和联邦计算在优化数据采集、平台迁移等方面有很大的价值，但是并不是万能的：一方面，因为数据的集成视图可以被快速实施，许多企业忽略了数据治理，导致联邦过程中产生了不必要的冗余；另一方面，由于数据联邦没有预先针对业务做数据架构设计，因此对于频繁使用的固定形态的数据需求，还是以数据湖、数据仓库等方式提供才有最佳的性能表现。因此，依然不能完全摒弃数据治理、ETL 等方法，需要将它们共同结合应用，才能解决企业内更广泛的数据管理问题。数据联邦更多解决的是仍在频繁演进的数据需求或者 Adhoc 类开发场景等演进中的企业数据开发需求。

— 数据联邦架构简析—

从技术架构的视角来看，数据联邦技术通过在现有的各种数据源上增加一个联邦计算引擎的方式，提供统一的数据视图，并且支持开发者通过联邦计算引擎来统一查询和分析异构数据源里的数据，开发者无需考虑数据物理位置、数据结构、操作接口和储存能力等问题，即可在一个系统上对同构或者异构数据进行访问和分析。数据联邦架构能够为企业的数据管理带来几个关键的架构优势，主要包括：

• 虚拟化的数据集成：与传统 ETL 相比，数据联邦仅进行了虚拟的集成，能更快、更低成本地集成大量数据，提升数据集成速度，可以快速地探索一些创新的数据业务；

• 对一些复杂的存量系统可以在尽量保证系统不动的情况下，提供跨库的数据分析能力，从而保护企业的现有投资；

• 方便开发者灵活的发现和使用数据：用户不需感知数据源的位置和结构，数据源系统不需要做改动，数据处理灵活度得到提升；

• 可以实现统一的数据安全管控：因为通过虚拟视图而不是复制的方式集成，配套在数据联邦平台上做统一的安全管控，能够做到数据统一出口的安全管控，减少因为复制数据引入的数据泄露风险，尤其适合用于分析一些不适合将数据导入数据湖的业务系统，从而保证静态数据和动态数据的安全；

• 消除不必要的数据移动：对于一些不太常用的数据，如果使用数据联邦架构后这部分数据就不需要每天整合进入数据湖，而是在有实际分析需求的时候才去做数据分析，这样减少了不必要的数据移动；

• 敏捷的数据服务开通和门户功能：有了数据联邦的功能后，企业可以进一步基于其开发一个数据服务门户，提供开发工具和服务工具，让用户更灵活的使用数据。

数据联邦技术架构图如上所示，其关键点即实现基于统一的 SQL 查询引擎，可以联邦多个同构或异构的自治数据源，用户可以随意查询在联邦系统中任意位置的数据，而不必关心数据的存放位置、实际数据源系统的 SQL 语言种类或存储能力。其上图所示，该架构需要实现了四个方面统一，才能实现以上的核心能力，包括统一的元数据管理、统一的查询加工接口、统一的开发运维工具和统一的安全管理。

• 统一的元数据管理

  
  

元数据管理模块需要构建各个同构、异构数据源的抽象整体视图，提供统一数据源连接管理和元信息管理，后续业务开发层只需要通过这个集中的元数据管理模块去获取不同数据库下的元数据信息，而无需去管理各个不同数据库的不同连接细节。

• 数据源连接模块

通过数据联邦平台，开发者可以构建跨数据库实例的虚拟连接，从而在当前数据库中实现跨库访问，一般采用类似 DBLink 的 SQL 拓展。该层负责管理接入数据源，既支持传统数据源的连接,也支持大数据平台的连接，设计上最好既支持结构性数据，也支持非结构数据接入。DBLink 的语法实例如下，后续开发者就可以直接使用 dblink 上的 table 名来访问不同数据源上的数据表，甚至可以在一个 SQL 中访问多个表。

• 元信息管理模块

由于各个数据库的元数据随着业务的运行而持续变化，数据联邦模块也需要及时的获取数据变化，如表的字段增删或类型变化等，因此元信息管理模块就负责提供这个功能，它需要从各数据源获取元信息并集中管理，通过对数据源的查询来获取和维护最新的元信息，从而保证元数据在各个平台之间的一致性，在构建、运行、维护的整个数据联邦计算的生命周期中起到关键支撑作用。

• 统一的查询加工接口

  
  

这个模块为数据分析人员提供服务入口，主要包括用统一的标准 SQL 语句实现跨平台的数据加工，以及企业可以基于其再提供的一些数据门户管理功能，如 SQL 审查、数据申请等。由于涉及到多种数据库的统一处理，这个模块技术要求比较高，除了要兼容多个数据库的数据类型和 SQL 方言的差异以外，SQL 性能是另外一个非常关键的技术要素。

• 联邦查询 SQL 引擎层

作为统一的语法解析层，解析 SQL 指令。其核心是 SQL 编译器、优化器和事务管理单元，它是保证可以给开发者提供比较好的数据库体验，无需基于底层不同平台且有差异化 API 来做业务开发，同时会经过优化器来生成最佳的执行计划，最终将执行计划推送给计算引擎层。对开发者来说，SQL 引擎层需要支持标准的 JDBC/ODBC/REST 接口。

• 联邦查询计算引擎层

一些 SQL 操作会需要操作多个数据库中的数据并做关联分析，因此计算引擎层需要具备能力加载不同数据库中的数据进入引擎并做各种数据运算，这就要求计算引擎需要基于分布式计算的架构，同时需要有效的解决各个数据库的数据类型的差异性。譬如 varchar 等类型在不同的数据库中，如果字符串在左右侧出现空格时处理会不同，trim 函数的行为也略有差异，另外部分数据库 Decimal/Numeric 的类型定义也不同，这些类型系统的差异会带来非常大的处理复杂度，也是计算引擎的一个核心能力。另外一个重要的特性是性能优化相关，由于涉及多个远端数据库，因此与传统数据库不同，联邦计算引擎需要支持两个典型的 SQL 优化：数据结果缓存和计算下推到远端数据库。

• 数据结果 Cache 层

联邦计算引擎自动统计结果集查询频率，针对热点结果集以及中间缓存数据集，选择缓存或同步底层数据库结果集至联邦计算平台中，并在查询过程中选择最佳查询路径，优化查询性能。

我们以上面一个 SQL 查询来举例。我们都知道 MySQL 数据库并不擅长做数据统计分析，针对 1000 万行记录的 lineitem 表的聚合运算大约需要 200 秒。而如果采用联邦计算引擎，计算引擎根据多次查询历史记录发现这个表被多次统计分析，它将数据从 MySQL 中持久化到 st_lineitem 中，后续查询到 MySQL 的 tpch1.lineitem 的时候，直接用 st_lineitem。由于分布式计算引擎比较擅长做统计分析，后续的查询都通过联邦计算引擎，性能也得到数量级上的提升，并且原有的 MySQL 数据库的资源消耗也大幅减少。

• 数据下推到远端数据库

在另外一些 Ad-hoc 的统计分析场景下，如果将源端数据库内所有的数据都加载到联邦计算引擎，可能会有大量的数据 IO 和网络 IO，从而导致性能缓慢。如果这类 SQL 查询的部分执行计划能够在远端数据库中直接执行，计算引擎可以在制定执行计划时选择在底层数据库中下推算子，由各个远端数据库来完成基础计算，而最后将执行结果汇总至联邦计算层进行统一计算，从而优化查询性能。

我们举一个简单的例子，假如需要从 MySQL 和 Oracle 数据库中找到员工号小于一个给定值的员工数量，如果没有聚合下推的优化，那么开发者下发统计 SQL 后，联邦计算引擎需要从 MySQL 和 Oracle 中都将全量的千万级数据加载到计算引擎中再计算，这个加载过程可能需要几百秒（主要受限于数据库对联邦计算引擎开放的并发线程数量）。而如果计算引擎支持计算下推到远端数据库，那么涉及到数据搬迁就非常少，性能也从几百秒提升到数十秒。

• 统一的安全管理

由于数据联邦会将各个数据库开放给业务用户，数据开放的同时就暴露了更多的数据风险，因此我们就需要更加细粒度的数据安全防护功能，保护数据认证、审计、授权，以及提供数据加密、脱敏，以及密级分类等功能，保证数据在存储、传输、加工过程的安全。

• 统一权限管理

数据联邦安全层需要提供统一用户模块，用于多个数据库的相关权限管理和授权使用，我们通过元信息映射（外表创建）提供与数据库表级权限管控相同体验的联邦数据源权限管控，以及提供细粒度的用户级别行列级权限管控功能。这种方式，可近似认为在编译期间提供对于原表->视图的查询限制，保障在计算过程中敏感数据不泄露。

• SQL 动态审核

SQL 审核指的是在业务 SQL 提交平台时，平台可以根据提交业务的用户或行为等维度，根据内置或自定义的审核规则，对于敏感查询（如敏感字段等值查询）进行阻断处理或者优化处理建议。为了方便理解，我们列举一些比较典型的 DML 审核规则以及对应的规则描述，如下表：

大型企业随着业务的开放，其对 SQL 审核的需求比较大，很多企业都有自己的 SQL 开放和审核平台，开源社区也有一些针对性的解决方案。总体架构可以参考下图的架构，以 DSL 语言来最规则的定义，由对应的解析器来完成相关的 SQL 审核的操作（如阻断或优化建议等）。

• 敏感数据动态脱敏

与数据库表的行列级权限不同，敏感数据动态脱敏需要保证的是数据的内容安全，是配合权限管控的更加偏向业务级的数据安全保护。需要注意的一点，为了保证结果的正确性，在查询计算阶段使用真实数据计算，仅在输出时做动态脱敏从而保证敏感数据不泄露。为了保障数据脱敏的有效性，数据联邦引擎需要维护全局的表、字段血缘图，这样可以基于数据血缘来完善全局的敏感规则传递功能，这样就能识别更多的敏感数据表，以及针对这些表提供可配置的自动敏感数据识别并脱敏。

• 统一的运维管理

  
  

除了有基础架构作为支撑，联邦计算的落地还需要有上层的数据开发工具的支持，与数据联邦配合实现从数据获取、加工、到价值变现的完整过程，同时跨数据源的数据安全也应该得到保证。开发管理运维工具一般包括数据开发、管理、运维工具平台，使企业可以更有效率的利用联邦计算构建企业内部的数据服务层，以及数据业务价值层。

— Presto 与 Trino —

Presto（或 PrestoDB）是一种开源的分布式 SQL 查询引擎，从头开始设计用于针对任何规模的数据进行快速分析查询。它既可支持非关系数据源，例如 Hadoop 分布式文件系统 (HDFS)、Amazon S3、Cassandra、MongoDB 和 HBase，又可支持关系数据源，例如 MySQL、PostgreSQL、Amazon Redshift、Microsoft SQL Server 和 Teradata。Presto 可在数据的存储位置查询数据，无需将数据移动到独立的分析系统。查询执行可在纯粹基于内存的架构上平行运行，大多数结果在秒级返回。Presto 最初作为 Facebook 的数据仓库上运行交互式分析查询的项目，底层数据存储基于 HDFS 的集群。在构建 Presto 之前，Facebook 使用的是 2008 年创建并推出的 Apache Hive，但是对着业务负载的增加以及交互式分析的需求增加，Hive 不能满足交互式查询所需的高性能。在 2012 年，Facebook 数据基础设施组构建了 Presto，这种交互式查询系统能够以 PB 级规模快速运行。今天，Presto 已成为在 Hadoop 上进行交互式查询的流行选择，获得了来自 Facebook 和其他组织的大量贡献。Facebook 版本的 Presto 更多的是以解决企业内部需求功能为主，也叫 Presto DB。后来，Presto 其中的几个人出来创建了更通用的 Presto 分支，取名 Presto SQL，版本号以 xxx 来划分，例如 345 版本，这个开源版本也是更为被大家通用的版本。前一段时间，为了更好的与 Facebook 的 Presto 进行区分，Presto SQL 将名字改为 Trino，这就是 Trino 项目的历史由来。

Presto 和 Trino 都只是一个分布式计算引擎，本身并没有数据存储的能力，加上社区里做了大量数据库的连接器适配，因此是开源方案中比较适合用于做数据联邦查询的引擎。在 Trino 中，存储和计算分离的核心是基于 connector 的体系结构。connector 为 Trino 提供了访问任意数据源的接口。如图二所示，每个 connector 都提供了对底层数据源的基于表的抽象。只要可以使用 Trino 可用的数据类型以表、列和行来表示数据，就可以创建 connector，查询引擎就可以使用数据进行查询处理。目前支持的 connector 包括：Hive, Iceberg, MySQL, PostgreSQL, Oracle, SQL Server, ClickHouse, MongoDB 等。

如上个章节中介绍，统一的计算引擎是数据联邦系统的关键核心，如何能够提供灵活的 Adhoc 查询并且有很好的性能表现也是 Presto 的重要设计目标。在物理架构上，Presto 主要分为 Coordinator 和 Worker，其中 Coordinator 主要做 SQL 任务的编译和计算任务下发给 Worker，而 Worker 主要负责从远端数据存储中拉取数据并做相应的数据计算。由于 Presto 是基于 Java 语言开发的，JVM 的执行效率不如底层语言，为了解决这个导致的性能问题，Presto 还使用了代码生成技术（Code generation）来生成底层引擎直接执行的 Bytecode 来提升分析性能。

Presto 在计算上采用了基于内存而非磁盘来做数据计算，即数据计算过程中的数据主要缓存在内存中。由于计算过程中不可避免的出现内存膨胀问题，可能会导致 Worker 进程崩溃，因此内存管理是 Presto 中非常重要的技术。Presto 把整个内存划分成三个内存池，分别是 System Pool ,Reserved Pool, General Pool。System Pool 是用来保留给系统使用的，例如机器之间传递数据，在内存中会维护 buffer，这部分内存挂载 system 名下,默认为 40%的内存空间留给系统使用。Reserved Pool 和 General Pool 是用来分配 query 运行时内存的。其中大部分的 query 使用 General Pool。Reserved Pool 的空间等同于一个 query 在一个机器上运行使用的最大空间大小，默认是 10%的空间。分布式执行计划联邦分析的另外一个核心支撑能力，Presto 在计算模型上采用了 pipeline 的计算模式，一个执行计划会被编译为多个 stage，每个 Stage 是不需要数据 Shuffle 的计算任务的集合，每个 Stage 的任务被并行化拆分为多个 Task 后并行执行，没有互相依赖的 Stage 之间也可以并行执行，因此可以充分利用分布式计算引擎的并发执行能力来提升性能。

总体上说，在统一的元数据管理和查询接口层面，Presto 和 Trino 都有非常好的架构和清晰的代码结构，是比较适合基于其做二次开发的项目。不过由于开源社区对企业级管理类需求的关注不足，在统一的数据安全管控和运维管理工具的支撑上，这两个社区都还缺少比较好的功能模块来支撑。因此，如果要实现一个完整的数据联邦分析的体系，还需要二次开发或者引入商业化软件来补充和完善必要的功能。— 小结—本文介绍了数据联邦的架构与案例，数据联邦解决了“数据孤岛”问题，并且避免了传统 ETL 流程长导致的开发和运维成本较高的问题。可以应用在对数据采集有灵活性、实时性要求，或者存在异构数据源处理的场景。