前言：
突然想开一篇新专栏学大数据，感觉也不是那么难，起码比深度学习简单多了——我这样想到
为什么大数据平台会回归SQL
总结来说就是：因为还没找到更好的。
结构化数据计算仍是重中之重
大数据平台主要是为了应对海量数据存储和分析的需求，海量数据存储的确不假，除了生产经营产生的结构化数据，还有大量音视频等非结构化数据，这部分数据很大，占用的空间也很多，有时大数据平台 80% 以上都存储着非结构化数据。不过，数据光存储还不行，只有利用起来才能产生价值，这就要进行分析了。
大数据分析要分结构化和非结构化数据两部分讨论。
结构化数据主要是企业生产经营过程中产生的业务数据，可以说是企业的核心，以往在没有大数据平台的时候企业主要或全部在使用的就是这部分数据。随着业务的不断积累，这部分数据也越来越大，传统数据库方案面临很大挑战，建设大数据平台自然要解决这部分核心数据分析问题。
有了大数据平台，给大家的想象空间也大了起来，以往无法利用的日志、图片、音视频等非结构化数据也要产生价值，这就涉及到非结构化数据分析了。相对核心业务数据分析，非结构化数据分析看起来更像是锦上添花。即使如此，非结构化数据分析并不是孤立存在，也还会伴随大量结构化数据处理。采集非结构化数据的同时，常常会伴随着采集许多相关的结构化数据，比如音视频的制作人、制作时间、所属类别、时长、…；有些非结构化数据经过处理后也会转变成结构化数据，比如网页日志中拆解出访问人 IP、访问时刻、关键搜索词等。所谓的非结构化数据分析，经常实际上是针对这些伴生而出的结构化数据。
结构化数据分析仍然是大数据平台的重中之重。而结构化数据处理技术就比较成熟了，比如我们常用的基于关系数据模型的关系数据库（SQL）。
SQL 仍是目前最广泛的结构化数据计算技术
回归 SQL 却是当前大数据计算语法的一个发展倾向。在 Hadoop 体系中，早期的 PIG Latin 已经被淘汰，而 Hive 却一直坚挺；Spark 上也在更多地使用 Spark SQL，而 Scala 反而少很多（Scala 易学难精，作为编译型语言不支持热部署也有很多不方便之处）。其它一些新的大数据计算体系一般也将 SQL 作为首选的计算语法，经过几年时间的混战，现在 SQL 又逐步拿回了主动权。
大数据体系
大数据体系和SQL
大数据体系-OneSQLrules bigdata all
-
消息队列——解耦存储和计算
-
重点——分析引擎（SQL）
- SQL极为重视的原因：
- SQL简单便捷进行数据处理
- SQL有多种设备支持接口
- SQL用来处理大数据
准确来说，包括Spack一类的引擎，最初并不包含sql的操作，只是后续逐渐加入了。
SQL的处理流程
简单一句话就是：
-
Parser
将SQL输入转化成AST输出
-
Analyzer
转化为Logical Plan，逻辑计划
-
Optimizer
输出物理计划
-
Executer
转发给客户
具体来说：
Parser
String->AST（abstractsyntaxtree）
词法分析：拆分字符串，得到关键词、数值常量、字符串常量、运算符号等token
语法分析：将token组成ASTnode，最终得到一个AST
实现：递归下降(ClickHouse)，Flex和Bison(PostgreSQL)，JavaCC(Flink)，Antlr(Presto,Spark)
Analyzer和LogicalPlan
Analyzer
检查并绑定Database,Table,Column等元信息
SQL的合法性检查，比如min/max/avg的输入是数值
AST->LogicalPlan
LogicalPlan
逻辑地描述SQL对应的分步骤计算操作
计算操作：算子（operator）
比如：
变为：
对于上图的流程来说：从下往上看，三个SCAN算子（读取作用）读取最下层的三张表——由JOIN算子（连接作用）根据某个条件去连接——AGGREGATE算子（聚合作用）起到求和的效果。——Top-N算子。
这类的树（left-deep-tree）都有一个共性：即JOIN的右子树都是一个SCAN算子，即都是一个表
作者：LuciferPluto
链接：https://juejin.cn/post/7124195152108716063
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
查询优化
SQL是一种声明式语言，用户只描述做什么，没有告诉数据库怎么做
目标：找到一个正确且执行代价最小的物理执行计划
查询优化器是数据库的大脑，最复杂的模块，很多相关问题都是NP的
一般SQL越复杂，Join的表越多，数据量越大，查询优化的意义就越大，因为不同执行方式的性能差别可能有成百上千倍
按照遍历树的顺序划分：
Top-down Optimizer：
- 从目标输出开始，由上往下遍历计划树，找到完整的最优执行计划
- 例子：Volcano/Cascade,SQLServer
Bottom-up Optimizer：
- 从零开始，由下往上遍历计划树，找到完整的最优执行计划
- 例子：System R,PostgreSQL,IBM DB2
根据优化方法划分：
Rule-based Optimizer(RBO)
- 根据关系代数等价语义，重写查询
- 基于启发式规则
- 会访问表的元信息（catalog），不会涉及具体的表数据（data）
- Cost-base Optimizer(CBO)
- 使用一个模型估算执行计划的代价，选择代价最小的执行计划。
PhysicalPlan和Executor
PlanFragment：执行计划子树
目标：最小化网络数据传输
利用上数据的物理分布（数据亲和性）
增加Shuffle算子
Executor
单机并行：cache，pipeline，SIMD
多机并行：一个fragment对应多个实例
小结：
OneSQL rules big data all
SQL需要依次经过Parser，Analyzer，Optimizer和Executor的处理
查询优化器是数据库的大脑，在大数据场景下对查询性能至关重要
查询优化器需要感知数据分布，充分利用数据的亲和性
查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段
