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

一、为什么要对立SQL

二、如何对立SQL

三、个推对立SQL实际

（以下依据演讲内容整顿）

01
为什么要对立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的实时工作目前只能由数据研发同学实现，这很容易造成工作积压。

“对立SQL”天时地利人和

如果咱们认真思考，其实会发现数据处理实质上是数仓的加工解决，而各类数据作业都可形象为数仓的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.uidgroup 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提供的框架，输出表名、行数、散布、排序等优化所需的元数据信息。

接下来，咱们调研了目前支流的实时计算引擎，想看其是否能够提供比拟齐备的SQL反对。首先评估的是Spark SQL。它通过antlr解析器把SQL语法解析成AST，接着进行查问优化，最初把指令拆解成RDD工作。

这个计划能够反对离线和实时，然而在公司外部应用会遇到几个问题：一个是如果要扩大反对更多的数据，须要批改Spark SQL的Connector局部，这须要批改Spark环境，对于一个大规模的Spark集群来说，更新降级底层环境会带来比拟大的危险；另外底层环境的更新对于私有化部署的场景也是比拟难以承受的。

此外须要通过USING这样的个性化DDL语法去连贯内部数据源，这肯定水平毁坏了SQL的规范性。但综合而言，Spark SQL的确为咱们提供了十分好的解决方案和思路。

而后，咱们评估的是Flink SQL。它是阿里为Flink提供的十分有价值的组件，整体流程跟Spark的计划非常相似，通过Calcite解析SQL语法，进行查问优化后下推执行打算，同时也反对十分多的数据源。相对来说Flink SQL比Spark SQL支持性更好，然而也依然存在和Spark SQL相似的问题，包含元数据买通、底层引擎迁徙老本、采纳自定义的WITH关键字来申明数据源的拜访等。

因为这些DDL语法不是规范的SQL语法，一方面会带来一些学习的老本，另外一方面会带来兼容性问题，导致同样的SQL无奈同时运行于Spark和Flink平台。

最初，咱们还调研了机器学习的SQL反对形式。咱们寻找到一个叫MLSQL的开源计划，它通过相似于train、predict这样的关键词就能够疾速实现模型训练和预测的工作，也反对跨数据源查问。但MLSQL更侧重于从前到后残缺的流程整合，在大规模数据体量下临时还不足成熟的利用案例，对于咱们的应用场景还须要进行不少的定制化开发。不过总体而言，它的语法扩大形式对咱们有极强的借鉴意义。

`
load json./tmp/train as trainData;

train trainData as RandomForest./tmp/rf where keepVersion="true" and fitParam.0.featuresCol="content" and fitParam.0.labelCol="label" and fitParam.0.maxDepth="4" and fitParam.0.checkpointInterval="100" and fitParam.0.numTrees="4" ;

predict testData as RandomForest./tmp/rf;`

*起源：MLSQL官网文档

根据上述调研咱们进行了总结整顿，心愿对立SQL的技术架构是这样的：

1、兼容两种计算引擎（Spark/Flink），不对计算引擎进行批改；

2、可灵便扩大数据源；

3、对SQL优化过程自主可控，逻辑上与引擎解耦，物理上能够与引擎绑定；

4、扩大反对机器学习语法。

03
个推对立SQL实际
为了不便不同的角色、不同岗位的人员参加到数据治理工作中，个推开发了一套数据中台零碎，在公司外部叫作每日治数平台。每日治数平台由数据仓库、模型平台、数据资产治理平台、数据集成平台、数据开发平台五个模块组成，帮忙企业解决数据治理痛点、升高数据应用门槛、晋升数据使用价值。

通过数据资产治理平台，咱们能够录入数据资产、治理数据间的血缘关系以及对数据品质进行监控。通过数据集成平台，咱们能够与数据源进行对接，实现数据的结构化工作。通过数据开发平台，咱们能够实现数仓的建设和保护工作。其中对立SQL引擎——GQL便是个推数据开发平台的根底。

GQL的构造跟前文提及的Spark SQL、Flink SQL十分像，都是通过解析层把SQL拆解成语法树结构，而后联合数据的元信息实现查问优化的工作，最初再把这些执行工作派发给相应的计算引擎或者存储引擎。

在元数据方面，咱们将数据治理平台的信息与SQL解析层对接，打消DDL的差别，无需再通过WITH、USING这样的关键字定义长期表的模式申明要拜访的数据，进步了SQL的规范性。

在开发环境方面，咱们基于Database Navigator插件拓展了GQL的反对。开发者能够在IntelliJ IDEA上编写和调试GQL，并间接查看查问后果。

在数据源方面，咱们目前反对五大类的数据源，包含JDBC/ODBC接口、文件系统、Hadoop体系、KV型数据以及kafka。将来，咱们心愿 API的数据接口也能够通过GQL的形式进行接入。

在机器学习方面，GQL次要做了两块性能反对。在特色工程方面，包含异样值、缺失值的解决，特色组合、特色自动化筛选等绝对机械的工作，都能够通过GQL来实现。在模型方面，GQL反对罕用的有监督学习模型（如逻辑回归、随机森林、XGBoost等）以及无监督聚类模型。

SQL作为一种DSL，语法尽管简略，但并不通用。有些工作不适宜用SQL来形容和实现，如迭代和加解密算法等，这就须要通过UDF（User Define Function）扩大，让SQL代码具备更丰盛的能力。GQL对UDF也做了扩大反对，能够通过Java、Python等形式减少UDF。

04
总结
咱们认为SQL是目前最适宜人与数据打交道的语言，没有之一。元数据买通、跨数据源、离线和实时反对、机器学习反对是对立SQL所需的四大外围性能。Flink SQL根本能满足咱们的需要，如果底层计算引擎就是Flink，毫无疑问，应用它能够解决绝大部分的问题。然而如果心愿放弃更大的灵活性以及扩展性，那么有必要思考将SQL作为独立的一层技术栈进行倒退。联合个推本身实际，以GQL作为每日治数平台的对立SQL引擎，咱们分享了所采纳的技术计划以及实现的性能，心愿能给大家有所启发。