如何统一数据分析入口

关键词: 多数据源融合计算 跨数据源虚拟视图 统一元数据管理

背景

现代企业面临如下几个问题：

1. 数据依然是分散的，难以进行汇总分析
2. 有大量的分析引擎，难以为终端用户提供统一的出口
3. 因为1,2两个点，难以形成全司视角的统一元数据系统（库表视图）

先看第一点，虽然有数仓，但实际上数据并没有办法在同一个数仓管理。数据物理分散在：

1. 数仓（一个或者多个）
2. 数据湖
3. 各种 OLAP 分析引擎
4. 业务数据库

对于一个大企业，不同部门可能都有一个或者多个上面的物理存在。如何能够完整的关联这些数据进行分析，是迫切的需求。 再看第二点，众多的分析引擎，诸如Kylin, Presto, Spark, Doris, ClickHouse同时存在，从用户视角，用户可能为了解决不同的问题，看不同的数据，需要使用不同的引擎，难以有统一的使用入口，这对于企业而言，也是迫切需要解决的。 最后，企业希望不仅仅能处理散落在各个地方的数据，还能够在一个系统中看到这些数据的完整库表形态，并且能够通过虚拟视图方式构建更多的易于使用的数据集。这种虚拟视图需要能够支持底层是多类型数据源的。

设计

要实现上面的诉求，首先我们需要有多数据源融合计算能力。 如果想在生产可用，多数据源融合计算需要具备如下特性：

1. 支持主流数据源（数据湖，数仓，各种分析引擎）
2. 聚合下推能力，需要能够充分利用底层计算引擎的能力
3. 显示的或者隐式的描述聚合下推，确保用户最终可以获得可用的性能

第二个是跨数据源虚拟视图，这个其实是依托于 多数据源融合计算能力的。 以 Byzer 为例，实现的最终效果如下：

我们将不同的数据源的库表映射成新的视图，其中上面进行了显示的下推（也可以实现隐式下推,具体技术参考： Byzer 聚合下推），从而充分利用底层 OLAP 引擎的计算能力，最后完成了多数据源融合计算。 那如何构建一个 跨数据源虚拟视图 呢？虚拟视图本质上就是一段计算逻辑，这个计算逻辑最终使用文本格式 Byzer 语言的来进行描述。 通过上面的脚本，我们获得了一个虚拟视图叫 final_result, 我们把它放到一个叫做 super_db1 的 database里，最后呈现给用户的大概是这样的：

当用户双击该表的时候，实际上会执行上面的 byzer 代码，从而展示数据。用户也可以直接在 SQL 中去访问这个虚拟视图。 现在，当我们用相同的方式把所有底层引擎，数据湖，业务数据库都已类似上面的脚本暴露出新的虚拟视图，同时根据业务需求，基于已有的虚拟视图不断创建新的虚拟视图，此时我们就有了企业完整的数据视图了。 为此，我们只要开发一个web系统，该系统叫做 统一元数据管理，使用该系统，用户可以管理虚拟视图，诸如创建（其实就是一段Byzer 脚本），删除亦或是搜索，以原有的数仓治理体系逻辑去运作这个 统一元数据管理系统。相比传统数仓，所有的表都是虚拟视图，实际数据分散在各个湖仓和引擎以及引擎的计算逻辑中，每个视图可能是跨数据源的，也可能是单个数据源里的聚合结果。

如果我们不想开发任何系统，我们也可以把这些代码放到git 仓库中，然后通过 Byzer 模块化编程 能力，在需要的地方引入即可，比如：

-- 引入全局虚拟视图
include lib.`gitee.com/allwefantasy/uniform-meta`
where alias="uniform";

-- 引入某个库表
include local.`uniform.super_db1.final_result`;

-- 查询该库表
select * from final_result as output;

几乎可以实现统一元数据相同的效果。 如果想对接外部系统，尤其是不可控的外部系统，我们只要提供一个统一的 JDBC 协议的Proxy(能够从同一元数据管理获取信息)即可，方便用户去使用这些虚拟视图。

落地

第一个其实就是我们的统一元数据管理系统，实现上面提到的管理虚拟库表的能力，构建了和一个虚拟数据层，屏蔽了数据存储技术和部署方式带来的复杂性。 第二个就是JDBC 协议的Proxy,可以面向各种业务场景对虚拟库表进行查询和分析。 目前存在的一些Gap：

1. 统一元数据管理系统（其实就是一个Web系统）
2. 支持JDBC协议。目前 Byzer 只提供了 Http 协议，以及一个不具备生产能力的 JDBC (https://github.com/byzer-org/byzer-jdbc) 库。

实际上JDBC协议我们也能支持 Byzer 的语法，但是如果要对接用户无法控制的BI等第三方工具，则需要完全兼容标准SQL，可能需要在JDBC驱动上适当进行适配。 最后我们来看看架图图：