在传统的企业数据使用中，企业应用多种零碎，数据散落在各个存储设备中，数据分析需要往往是跨库的，数据入湖入仓在做剖析会有平安问题，或影响业务零碎性能。企业须要一种灵便、快捷、低运维老本的数据集成办法，就有了数据联邦架构。本文介绍数据联邦架构。
— 数据联邦概述—
在传统的企业数据使用中，经常会呈现这样的窘境：企业应用多种零碎，数据散落在各个数据存储，数据分析需要往往是跨库的，有两种形式能够解决这类需要。一是先做数据集成（ETL）将数据整合到数据湖或数据仓库后再做剖析，这种个别适宜需要绝对确定、同时存量零碎能够迁徙到新数据平台的业务场景下。而对另外一些企业，因为其平台建设的阶段性特点，可能存在需要在疾速变动、或者存量零碎因为各种起因不能间接迁徙的状况，基于 ETL 入湖再剖析的计划可能会存在业务响应速度慢、灵便度低和过程简单的弊病，企业须要一种能更灵便、快捷地进行数据集成的办法，这就是数据联邦架构。
数据联邦解决了“数据孤岛”问题，并且防止了传统 ETL 流程长，开发和运维老本较高的问题，能够利用在对数据采集有灵活性、实时性要求，或者存在异构数据源解决的场景。
- 虚构的操作型数据库（ODS）
通过虚构操作型数据存储（ODS），构建可操作的数据集成视图，数据变动会很快反映到 ODS，且联邦的数据源数据源可随具体的剖析需要灵便增减变动，因而能满足一些轻量、短期的数据分析，或者实时灵便的仪表盘利用。 - 建造数据直达区
利用数据联邦构建数据直达区，能够对大量从生产零碎进入数仓的数据进行快照合并，极大缩小数据复制对生产零碎的烦扰。数据直达区对数据变动的实时存储，能记录残缺的数据变更信息。 - 数据仓库的扩大
企业部署数据仓库后存在问题：一方面，整个企业不太可能只应用繁多数仓；另一方面，企业依然有大量的数据未存入任何数仓，须要构建对立视角。而数据联邦和联邦计算能在无需转换格局和挪动数据的状况下，提供所有企业数仓和零散数据的对立视角，升高了数据挪动转换的老本。 - 异构平台迁徙
在异构平台迁徙过程中应用联邦计算，能使迁徙过程更平滑，无需思考数据的迁徙和异构平台语法不兼容等问题，保障利用对数据的应用不受影响，且能在迁徙实现后在不影响新利用的前提下更改数据源配置。 - 异构数据分析
企业能够利用数据联邦的能力，实现跨结构化数据、非结构化或者半结构化数据的剖析。
只管数据联邦和联邦计算在优化数据采集、平台迁徙等方面有很大的价值，然而并不是万能的：一方面，因为数据的集成视图能够被疾速施行，许多企业疏忽了数据治理，导致联邦过程中产生了不必要的冗余；另一方面，因为数据联邦没有事后针对业务做数据架构设计，因而对于频繁应用的固定状态的数据需要，还是以数据湖、数据仓库等形式提供才有最佳的性能体现。因而，仍然不能齐全摒弃数据治理、ETL 等办法，须要将它们独特联合利用，能力解决企业内更宽泛的数据管理问题。数据联邦更多解决的是仍在频繁演进的数据需要或者 Adhoc 类开发场景等演进中的企业数据开发需要。
— 数据联邦架构简析—
从技术架构的视角来看，数据联邦技术通过在现有的各种数据源上减少一个联邦计算引擎的形式，提供对立的数据视图，并且反对开发者通过联邦计算引擎来对立查问和剖析异构数据源里的数据，开发者无需思考数据物理地位、数据结构、操作接口和贮存能力等问题，即可在一个零碎上对同构或者异构数据进行拜访和剖析。数据联邦架构可能为企业的数据管理带来几个要害的架构劣势，次要包含：
- 虚拟化的数据集成：与传统 ETL 相比，数据联邦仅进行了虚构的集成，能更快、更低成本地集成大量数据，晋升数据集成速度，能够疾速地摸索一些翻新的数据业务；
- 对一些简单的存量零碎能够在尽量保证系统不动的状况下，提供跨库的数据分析能力，从而爱护企业的现有投资；
- 不便开发者灵便的发现和应用数据：用户不需感知数据源的地位和构造，数据源零碎不须要做改变，数据处理灵便度失去晋升；
- 能够实现对立的数据安全管控：因为通过虚构视图而不是复制的形式集成，配套在数据联邦平台上做对立的平安管控，可能做到数据对立进口的平安管控，缩小因为复制数据引入的数据泄露危险，尤其适宜用于剖析一些不适宜将数据导入数据湖的业务零碎，从而保障静态数据和动态数据的平安；
- 打消不必要的数据挪动：对于一些不太罕用的数据，如果应用数据联邦架构后这部分数据就不须要每天整合进入数据湖，而是在有理论剖析需要的时候才去做数据分析，这样缩小了不必要的数据挪动；
- 麻利的数据服务开明和门户性能：有了数据联邦的性能后，企业能够进一步基于其开发一个数据服务门户，提供开发工具和服务工具，让用户更灵便的应用数据。
数据联邦技术架构图如上所示，其关键点即实现基于对立的 SQL 查问引擎，能够联邦多个同构或异构的自治数据源，用户能够随便查问在联邦零碎中任意地位的数据，而不用关怀数据的寄存地位、理论数据源零碎的 SQL 语言品种或存储能力。其上图所示，该架构须要实现了四个方面对立，能力实现以上的外围能力，包含对立的元数据管理、对立的查问加工接口、对立的开发运维工具和对立的平安治理。
* 对立的元数据管理
元数据管理模块须要构建各个同构、异构数据源的形象整体视图，提供对立数据源连贯治理和元信息管理，后续业务开发层只须要通过这个集中的元数据管理模块去获取不同数据库下的元数据信息，而无需去治理各个不同数据库的不同连贯细节。
- 数据源连贯模块
通过数据联邦平台，开发者能够构建跨数据库实例的虚构连贯，从而在以后数据库中实现跨库拜访，个别采纳相似 DBLink 的 SQL 拓展。该层负责管理接入数据源，既反对传统数据源的连贯, 也反对大数据平台的连贯，设计上最好既反对结构性数据，也反对非构造数据接入。DBLink 的语法实例如下，后续开发者就能够间接应用 dblink 上的 table 名来拜访不同数据源上的数据表，甚至能够在一个 SQL 中拜访多个表。
CREATE DATABASE LINK <link_name> CONNECT TO <jdbc_username> IDENTIFIED BY ‘<jdbc_password>’ USING ‘<jdbc_URL>’ with ‘<jdbc_driver>’;CREATE EXTERNAL TABLE <table_name> (col_dummy string) STORED AS DBLINK WITH DBLINK <link_name> TBLPROPERTIES(‘dblink.table.name’=<ref_table_name>);
- 元信息管理模块
因为各个数据库的元数据随着业务的运行而继续变动，数据联邦模块也须要及时的获取数据变动，如表的字段增删或类型变动等，因而元信息管理模块就负责提供这个性能，它须要从各数据源获取元信息并集中管理，通过对数据源的查问来获取和保护最新的元信息，从而保障元数据在各个平台之间的一致性，在构建、运行、保护的整个数据联邦计算的生命周期中起到要害撑持作用。
对立的查问加工接口
这个模块为数据分析人员提供服务入口，次要包含用对立的规范 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 流程长导致的开发和运维老本较高的问题。能够利用在对数据采集有灵活性、实时性要求，或者存在异构数据源解决的场景。