【深度干货】异构数据的SQL一站式解决方案

在近日举办的GDG开发者大会广州站上，个推高级技术总监董霖以“异构数据的SQL一站式解决方案”为主题，深入分享了个推在SQL领域多年的实战经验。本文将从三方面阐述统一SQL：

一、为什么要统一SQL

二、如何统一SQL

三、个推统一SQL实践

（以下根据演讲内容整理）

公司内部围绕数据开展的工作，需要数据分析师、数据研发工程师、运维工程师、甚至产品运营人员共同完成，沟通和协作的效率成为关键性因素。

数据存储引擎眼花缭乱

随着大数据行业的发展，数据存储引擎目前处于百花齐放的阶段，新兴技术层出不穷：如关系型数据库，包括MySQL、Oracle、SQL Server以及蚂蚁推出的OceanBase等；NoSQL方案，包括Redis、Aerospike、MongoDB等；基于Hadoop体系的方案，包括Hive、HBase等；以及目前比较火热的NewSQL方向，包括Greenplum、TiDB、Doris、ClickHouse等。

各式各样的存储引擎让不少参与数据作业的人感到茫然，不知道该选择什么样的方式。开发者要花非常多的成本不停地尝试各种方案，以应对市场需求。开发者需要准确了解数据存在哪里、字段格式怎样、数据表间的关系怎样、数据如何操作等信息，技术人员和业务人员还需要花很多时间掌握各种存储引擎的性能和特性。

多样的数据存储方案

引擎选择类型多、学习成本高

除了存储引擎，计算引擎的选择也给大家带来困扰。Spark和Flink各有千秋，也各自在快速发展和相互学习融合。另外机器学习引擎也有很多方案，比如Tensorflow、PyTorch以及计算引擎中携带的机器学习算法库，但这些方案的学习成本比较高，常常令开发者感到纠结，难以抉择。

存储引擎和计算引擎具有繁多的方案，会给协同工作带来较大的语言障碍。对于分析师来说，日常大量使用的主要是SQL，但是有些时候也会使用Python、Shell脚本等方式完成数据处理。数据建模人员主要依赖Python，而数据研发人员则主要使用Java和Scala来开发实时任务。产品运营人员甚至会使用Excel来完成一些简单的分析任务。当然，大多数时候他们还是将需求表达给数据分析师，由分析师来协助完成。

语言障碍也在一定程度上限制了协作的效率，在资源调配上也缺乏灵活性。比如基于Spark或Flink的实时任务目前只能由数据研发同学完成，这很容易造成工作积压。

如果我们仔细思考，其实会发现数据处理本质上是数仓的加工处理，而各类数据作业都可抽象为数仓的ETL过程，即数据的提取（extract）、转换（transform）和加载（load）。目前来看，SQL是描述数据处理流程最优的DSL（Domain Specific Language），是事实标准。

在目前大环境下推行统一SQL的解决方案是大势所趋，具备天时地利人和的基本条件：

•    天时：数据体量增长，计算、人力、沟通成本增加，为企业不能承受之重；

•    地利：主流关系型数据库、MPP数据库、计算引擎、ES、甚至NoSQL方案已经或者计划支持SQL语法；

•    人和：SQL语言易于上手，核心功能只有9个动词；分析师、建模师、数据研发甚至产品运营等非技术人员都可以快速掌握SQL这门语言。

我们认为可以通过统一SQL的方式去完成二八原则的转换，即从目前把80%的时间花在20%的常规数据作业上 ，转变成用20%的时间就可以完成80%的常规数据作业。这样我们就可以有更多的时间去解决更复杂的工作，去思考数据的价值。

02 如何统一SQL

要想实现SQL的统一，我们认为需满足四大核心需求：元数据打通、跨数据源、支持离线和实时计算、支持机器学习。

先以一个典型的离线计算场景为例，我们希望通过简单的SQL即可达成目标，即用Hive数据与MySQL数据相融合，然后回写到HBase。

update hbase.biz.user_balances as a

set a.balance = ret.balance

from

    (

    select b.uid, c.balance

    from hive.warehouse.users as b

    inner join mysql.biz.balances as c

    on b.uid = c.uid

    ) as ret

where a.uid = ret.uid

类似的，如果是一个典型的实时计算场景，我们也希望能通过一个简单的SQL来完成Kafka数据流与MySQL的融合再回写到Redis这样的需求，例如：

update redis.dashboard.brands as a

set a.cnt = ret.cnt

from

    (

    select c.brand, count(distinct b.uid) as cnt

    from kafka.app.visit_logs as b

    inner join mysql.warehouse.users as c

    on b.uid = c.uid

    group by c.brand

    ) as ret

where a.brand = ret.brand

为寻找到合适的解决方案，我们首先调研了独立的开源方案。我们关注到奇虎360开源的Quicksql，这个方案大体上是先将SQL解析成AST（抽象语法树），然后将执行计划下推到具体的执行引擎。QuickSQL支持比较多的数据源，包括Hive、MySQL、ES、MongoDB等，遗憾的是这一方案不支持实时任务，是针对离线场景的解决方案。

该方案的Apache Calcite极具借鉴意义。Apache Calcite是一个基于SQL的动态数据管理框架，首先它把SQL的语法解析成AST，进行语法校验，接着基于RBO和CBO的查询进行优化，最后通过JDBC等引擎连接外部数据源。此外，Calcite支持元数据对接，开发者可以通过Calcite提供的框架，输入表名、行数、分布、排序等优化所需的元数据信息。