篇首语：本文由编程笔记#自由互联小编为大家整理，主要介绍了为什么大数据平台要回归SQL相关的知识，希望对你有一定的参考价值。
先说观点因为还没找到更好的。
接下来说原因首先来看看大数据平台都在干什么。
原因
结构化数据计算仍是重中之重
大数据平台主要是为了应对海量数据存储和分析的需求海量数据存储的确不假除了生产经营产生的结构化数据还有大量音视频等非结构化数据这部分数据很大占用的空间也很多有时大数据平台 80% 以上都存储着非结构化数据。不过数据光存储还不行只有利用起来才能产生价值这就要进行分析了。
大数据分析要分结构化和非结构化数据两部分讨论。
结构化数据主要是企业生产经营过程中产生的业务数据可以说是企业的核心以往在没有大数据平台的时候企业主要或全部在使用的就是这部分数据。随着业务的不断积累这部分数据也越来越大传统数据库方案面临很大挑战建设大数据平台自然要解决这部分核心数据分析问题。
有了大数据平台给大家的想象空间也大了起来以往无法利用的日志、图片、音视频等非结构化数据也要产生价值这就涉及到非结构化数据分析了。相对核心业务数据分析非结构化数据分析看起来更像是锦上添花。即使如此非结构化数据分析并不是孤立存在也还会伴随大量结构化数据处理。采集非结构化数据的同时常常会伴随着采集许多相关的结构化数据比如音视频的制作人、制作时间、所属类别、时长、…有些非结构化数据经过处理后也会转变成结构化数据比如网页日志中拆解出访问人 IP、访问时刻、关键搜索词等。所谓的非结构化数据分析经常实际上是针对这些伴生而出的结构化数据。
结构化数据分析仍然是大数据平台的重中之重。而结构化数据处理技术就比较成熟了比如我们常用的基于关系数据模型的关系数据库SQL。
SQL 仍是目前最广泛的结构化数据计算技术
回归 SQL 却是当前大数据计算语法的一个发展倾向。在 Hadoop 体系中早期的 PIG Latin 已经被淘汰而 Hive 却一直坚挺Spark 上也在更多地使用 Spark SQL而 Scala 反而少很多Scala 易学难精作为编译型语言不支持热部署也有很多不方便之处。其它一些新的大数据计算体系一般也将 SQL 作为首选的计算语法经过几年时间的混战现在 SQL 又逐步拿回了主动权。
这个现象大概有这么两个原因
1. 实在没什么别的好用
关系数据库过于普及程序员对 SQL 相当熟悉甚至思维习惯都是 SQL 式的。SQL 用来做一些常规查询也比较简单虽然用于处理复杂的过程计算或有序运算并不方便但其它那些替代技术也好不到哪里去碰到 SQL 难写的运算一样要写和 UDF 相当的复杂代码反正都是麻烦还不如继续用 SQL。
2. 大数据厂商的鼎力支持
大数据的技术本质是高性能而 SQL 是性能比拼的关键阵地。比性能要面对同样的运算才有意义过于专门和复杂的运算涉及的影响因素太多不容易评估出大数据平台本身的能力。而 SQL 有国际标准的 TPC 系列所有用户都看得懂这样就有明确的可比性厂商也会把性能优化的重点放在 SQL 上。
兼容 SQL 更利于移植
大数据平台兼容 SQL 的好处是很明显的SQL 的应用非常广泛会 SQL 的程序员很多如果继续采用 SQL 则可以避免许多学习成本。支持 SQL 的前端软件也很多使用 SQL 的大数据平台很容易融入这个现成的生态圈中。大数据平台打算替代的传统数据库也是 SQL 语法的这样兼容性会很好移植成本相对较低。
好了我们说完大数据平台为什么会回归关系数据模型了。那么继续使用关系数据模型SQL会存在哪些问题呢
问题
性能低
继续使用 SQL 的最大问题就是难以获得大数据计算最需要的高性能。
SQL 中缺乏一些必要的数据类型和运算定义这使得某些高性能算法无法描述只能寄希望于计算引擎在工程上的优化。传统商业数据库经过几十年的发展优化经验已经相当丰富但即使这样仍有许多场景难以被优化理论层面的问题确实很难在工程层面解决。而新兴的大数据平台在优化方面的经验还远远不如传统数据库算法上不占优就只能靠集群更多的机器获得性能提升。另外SQL 描述过程的能力不太好不擅长指定执行路径而想获得高性能常常需要专门优化的执行路径这又需要增加许多特殊的修饰符来人为干预那还不如直接用过程性语法更为直接这也会妨碍用 SQL 写出高性能的代码。
SQL 发明之初的计算机硬件能力还比较差要保证实用性SQL 的设计必须适应当时的硬件条件这就导致了 SQL 很难充分利用当代计算机的硬件能力具体来说就是大内存、并行和集群。SQL 中的 JOIN 是按键值对应的而大内存情况下其实可以直接用地址对应不需要计算 HASH 值和比对性能可以提高很多SQL 的数据表无序单表计算时还容易做到分段并行多表关联运算时一般就只能事先做好固定分段很难做到同步动态分段这就难以根据机器的负载临时决定并行数量对于集群运算也是这样SQL 在理论上不区分维表和事实表JOIN 运算简单地定义为笛卡尔积后过滤要实现大表 JOIN 就会不可避免地产生占用大量网络资源的 HASH Shuffle 动作在集群节点数太多时网络传输造成的延迟会超过节点多带来的好处。
举个具体的例子我们想在 1 亿条数据中取出前 10 名用 SQL 写出来是这样的
select top 10 x,y from T order by x desc
这个语句中有个 order by严格按它执行就会涉及大排序而排序非常慢。其实我们可以想出一个不用大排序的算法但用 SQL 却无法描述只能指望数据库优化器了。对于这句 SQL 描述的简单情况很多商用数据库确实都能优化使用不必大排序的算法性能通常很好。但情况复杂一些比如在每个分组中取前 10 名要用窗口函数和子查询把 SQL 写成这样
select * from (select y,*,row_number() over (partition by y order by x desc) rn from T)where rn<10
这时候数据库优化器就会犯晕了猜不出这句 SQL 的目的只能老老实实地执行排序的逻辑这个语句中还是有 order by 的字样结果性能陡降。
开发效率低
不仅跑的慢开发效率也不高尤其在复杂计算方面SQL 实现很繁琐。比如根据股票记录查询某只股票最长连续上涨天数SQLoracle的写法如下
SELECT MAX(ContinuousDays)-1 FROM ( SELECT code, NoRisingDays, COUNT(*) ContinuousDays FROM ( SELECT code, SUM(RisingFlag) OVER (PARTITION BY code ORDER BY day) NoRisingDays FROM ( SELECT code, day, CASE WHEN price> LAG(price) OVER (PARTITION BY code ORDER BY day) THEN 0 ELSE 1 END RisingFlag FROM stock ) ) GROUP BY NoRisingDays )
用了很绕的方式实现别说写出来看懂都要半天。
此外SQL 也很难实现过程计算。什么是过程性计算呢就是一步写不出来需要多次分步运算特别是与数据次序相关的运算。
我们举几个例子来看
一周内累计登录时长超过一小时的用户占比但要除去登录时长小于 10 秒的误操作情况
信用卡在最近三个月内最长连续消费的天数分布情况考虑实施连续消费 10 天后积分三倍的促销活动
一个月中有多少用户在 24 小时连续操作了查看商品后加入购物车并购买的的动作有多少用户在中间步骤中放弃
……
为了便于理解这些例子已经做了简化实际情况的运算还要复杂很多
这类过程性运算用 SQL 写出来的难度就很大经常还要写 UDF 才能完成。如果 SQL 写都写不出来那么 SQL 的使用效果将大打折扣。
开发效率低导致性能低
复杂 SQL 的执行效率往往也很低这就又回到性能的问题了实际上开发效率和计算性能是密切相关的很多性能问题本质上是开发效率造成。
复杂 SQL 的优化效果很差在嵌套几层之后数据库引擎也会晕掉不知道如何优化。提高这类复杂运算的性能指望计算平台的自动优化就靠不住了根本手段还要靠写出高性能的算法。象过程式运算中还常常需要保存中间结果以复用SQL 需要用临时表多了 IO 操作就会影响性能这都不是引擎优化能解决的事情必须要去改写计算过程。
所以本质上提高性能还是降低开发难度。软件无法提高硬件的性能只能想办法设计复杂度更低的算法而如果能够快速低成本地实现这些算法那就可以达到提高性能的目标。如果语法体系难以甚至没办法描述高性能算法必须迫使程序员采用复杂度较高的算法那也就很难再提高性能了。优化 SQL 运算无助于降低它的开发难度SQL 语法体系就是那样无论怎样优化它的性能开发难度并不会改变很多高性能算法仍然实现不了也就难以实质性地提高运算性能。
编写 UDF 在许多场景时确实能提高性能但一方面开发难度很大另一方面这是程序员硬写的也不能利用到 SQL 引擎的优化能力。而且经常并不能将完整运算都写成 UDF只能使用计算平台提供的接口仍然要在 SQL 框架使用它的数据类型这样还是会限制高性能算法的实现。
根本的解决方法还是要让大数据平台真地有一些更好用的语法。
解法
使用开源集算器 SPL 就可以作为 SQL 很好的替代和延伸作为大数据平台专用的计算语言延续 SQL 优点的同时改善其缺点。
SPL 是一款专业的开源数据计算引擎提供了独立的计算语法整个体系不依赖关系数据模型因此在很多方面都有长足突破尤其在开发效率和计算性能方面。下面来盘点一下 SPL 都有哪些特性适用于当代大数据平台。
强集成性
首先是集成性不管 SPL 多优秀如果与大数据平台无法结合使用也是白费。要在大数据平台中使用 SPL 其实很方便引入 jar 包就可以使用本身也是开源的想怎么用就怎么用。SPL 提供了标准 JDBC 驱动可以直接执行 SPL 脚本也可以调用 SPL 脚本文件。
…Class.forName("com.esproc.jdbc.InternalDriver");Connection conn DriverManager.getConnection("jdbc:esproc:local://");Statement st connection.();//直接执行SPL脚本//ResultSet rs st.executeQuery("100.new(~:baseNum,~*~:square2)");//调用SPL脚本文件CallableStatement st conn.prepareCall("call SplScript(?, ?)");st.setObject(1, 3000);st.setObject(2, 5000);ResultSet resultst.execute();...
高效开发
敏捷语法
在结构化数据计算方面SPL 提供了独立的计算语法和丰富的计算类库同时支持过程计算使得复杂计算实现也很简单。前面举的计算股票最长连涨天数的例子用 SPL 实现是这样的
A1db.query("select * from stock order by day")2A1.groupi(price
按交易日排好序将连涨的记录分到一组然后求最大值 -1 就是最长连续上涨天数了完全按照自然思维实现不用绕来绕去比 SQL 简单不少。
再比如根据用户登录记录列出每个用户最近一次登录间隔
A1ulogin.groups(uid;top(2,-logtime))最后2个登录记录2A1.new(uid,#2(1).logtime-#2(2).logtime:interval)计算间隔支持分步的 SPL 语法完成过程计算很方便。
SPL 提供了丰富的计算类库可以更进一步简化运算。
直观易用开发环境
同时SPL 还提供了简洁易用的开发环境单步执行、设置断点所见即所得的结果预览窗口…开发效率也更高。
多数据源支持
SPL 还提供了多样性数据源支持多种数据源可以直接使用相比大数据平台需要数据先“入库”才能计算SPL 的体系更加开放。
SPL 支持的部分数据源仍在扩展中…
不仅如此SPL 还支持多种数据源混合计算充分发挥各类数据源自身的优势扩展大数据平台的开放性。同时直接使用多种数据源开发实现上也更简单进一步提升开发效率。
热切换
SPL 是解释执行的天然支持热切换这对 Java 体系下的大数据平台是重大利好。基于 SPL 的大数据计算逻辑编写、修改和运维都不需要重启实时生效开发运维更加便捷。
高计算性能
前面我们说过高性能与高开发效率本质上是一回事基于 SPL 的简洁语法更容易写出高性能算法。同时SPL 还提供了众多高性能数据存储和高性能算法机制SQL 中很难实现的高性能算法及存储方案用 SPL 却可以轻松实现而软件提高性能关键就在于算法和存储。
例如前面说过的 TopN 运算在 SPL 中 TopN 被理解为聚合运算这样可以将高复杂度的排序转换成低复杂度的聚合运算而且很还能扩展应用范围。
A1file(“data.ctx”).create().cursor()2A1.groups(;top(10,amount))金额在前 10 名的订单3A1.groups(area;top(10,amount))每个地区金额在前 10 名的订单这里的语句中没有排序字样也不会产生大排序的动作在全集还是分组中计算 TopN 的语法基本一致而且都会有较高的性能。
以下是一些用 SPL 实现的高性能计算案例
开源 SPL 提速保险公司团保明细单查询 2000 倍开源 SPL 提升银行自助分析从 5 并发到 100 并发开源 SPL 提速银行用户画像客群交集计算 200 倍开源 SPL 优化银行预计算固定查询成实时灵活查询开源 SPL 将银行手机账户查询的预先关联变成实时关联开源 SPL 提速银行资金头寸报表 20 倍开源 SPL 提速银行贷款协议跑批 10 倍开源 SPL 优化保险公司跑批优从 2 小时到 17 分钟开源 SPL 提速银行 POS 机交易报表 30 倍开源 SPL 提速银行贷款跑批任务 150 倍开源 SPL 提速资产负债表 60 倍
再多说两句SPL 没有基于关系数据模型而是采用了一种创新的理论体系在理论层面就进行了创新篇幅原因这里不再过多提及 写着简单跑得又快的数据库语言 SPL 这里有更细致一些的介绍感兴趣的小伙伴也可以自行搜索下载。
重磅开源SPL交流群成立了
简单好用的SPL开源啦
为了给感兴趣的小伙伴们提供一个相互交流的平台
特地开通了交流群群完全免费不广告不卖课
需要进群的朋友可长按扫描下方二维码
本文感兴趣的朋友请转到阅读原文去收藏 ^_^