共计 4777 个字符，预计需要花费 12 分钟才能阅读完成。
在近日举办的 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.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 提供的框架，输出表名、行数、散布、排序等优化所需的元数据信息。
接下来，咱们调研了目前支流的实时计算引擎，想看其是否能够提供比拟齐备的 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 引擎，咱们分享了所采纳的技术计划以及实现的性能，心愿能给大家有所启发。
