为什么大数据平台回归SQL？

Source: Dev.to

背景

结构化数据是大数据分析的主食

大数据平台的核心目标是满足大数据存储和分析的需求。在需要存储的海量数据中，除了业务活动产生的结构化数据外，还有大量的非结构化数据——音频、视频等——这些数据往往占据平台上全部数据的 80 % 以上。存储数据只是大数据平台目标的一部分，更重要的是分析和利用数据以产生业务价值。

大数据分析涵盖两类数据：结构化和非结构化。

• 结构化数据 在日常业务运营中产生，是企业的核心部分。在大数据平台出现之前，结构化数据几乎占据了企业信息库的全部或大多数。随着业务的扩展，数据不断累积，给传统基于关系型数据库（RDB）的处理系统带来压力。大数据平台应运而生，提供了解决结构化数据分析问题的方案。
• 非结构化数据（日志、图片、音频、视频）通常会被处理以提取相关的结构化属性——例如视频的制作者、日期、类别、时长，或日志的用户 IP、访问时间、关键字等。因此，非结构化数据分析主要关注其产生的结构化数据副产品。

由此可见，结构化数据分析仍然是大数据平台上业务分析的主导。用于处理结构化数据的成熟技术——主要是基于 SQL 的关系模型 RDBMS——被广泛使用。

SQL 主导结构化数据处理领域

回归 SQL 语法已成为大数据分析的明显趋势。在 Hadoop 中，早期的 PIG Latin 被抛弃，而 Hive 仍然存活；在 Spark 上，SparkSQL 的使用远远超过基于 Scala 的 API。新的大数据计算系统也倾向于使用 SQL 进行计算。这门古老的语言在与各种挑战者多年竞争后再次确认了自己的地位。

推动这种回归的两大原因：

1. 更好的选择尚未出现
   关系型数据库已经流行了很长时间，SQL 成为程序员的“老朋友”。虽然 SQL 对于常规查询非常简洁，但在处理复杂的过程式或顺序计算时不够方便。替代技术往往同样繁琐，需要编写复杂的 UDF 或自定义代码。面对这两种麻烦，许多人宁愿选择熟悉的 SQL。

2. SQL 获得了大数据厂商的背书
   厂商追求更高的性能，而 SQL 提供了一个众所周知且易于理解和评估的基准（例如 TPC‑H）。这促使厂商将优化工作重点放在 SQL 上。

与 SQL 兼容的平台更易迁移

SQL 兼容平台的优势显而易见：

• SQL 被广泛熟知，降低培训成本。
• 众多前端工具已经支持 SQL，集成变得直接。
• 与现有的基于 SQL 的数据库兼容，迁移更顺畅，成本更低。

然而，这些好处也意味着必须接受 SQL 的一些缺陷。

问题

性能低下

使用 SQL 的最大问题在于，它并不是实现大数据计算所需高性能的最有效手段。

• SQL 缺乏针对某些高性能计算的专用数据类型和定义，严重依赖执行引擎的工程化优化。
• 虽然数十年的经验为商业数据库积累了丰富的优化技术，但许多大数据场景仍然难以优化。
• SQL 并不擅长表达过程式计算或指定最优执行路径，而这些对于高性能算法至关重要。实现最优路径往往需要大量特殊修饰符；过程式语法则可能更直接。

历史上，SQL 是为硬件受限的环境设计的。其设计约束使得充分利用现代硬件特性（如大内存、海量并行、集群机制）变得困难。以下是一些与性能相关的限制示例：

• JOIN 操作 —— 传统的 SQL JOIN 通过键值匹配，通常使用哈希计算。在大内存环境下，基于地址的匹配速度可能快得多。
• 无序表 —— 虽然单表计算可以通过分区实现并行，但跨多表的动态划分（例如多表 JOIN）较为困难，需要静态分段，从而限制了灵活的线程分配。
• 集群计算 —— SQL 并不区分维度表和事实表，并将 JOIN 定义为过滤后的笛卡尔积。大表 JOIN 会触发代价高昂的哈希洗牌，消耗网络带宽，削弱了集群扩展的收益。

示例

从一个拥有十亿记录的表中获取前 10 行：

SELECT TOP 10 x, y
FROM T
ORDER BY x DESC;

ORDER BY 子句会强制对整个表进行排序，在如此规模下极其缓慢。可以设计算法避免全表排序，但 SQL 无法直接表达，只能依赖数据库优化器去寻找高效的执行计划。