不消 SQL 的数据堆栈

当前绝大部门数据堆栈都会接纳 SQL，SQL 发展了几十年已经成为数据库界的尺度语言，用户量巨大，以是支持 SQL 对于数据堆栈来讲也是很正常的。但是，在今世大数据配景下，业务复杂度节节攀升，在以盘算为紧张任务的数据堆栈场景下，SQL 似乎越来越不敷用了。范例表现是一些数据堆栈开始集成 Python 的本事，将 Python 如许的非 SQL 语言融入到数据堆栈中。且岂论两种风格迥异的开发语言是否能很好融合互补，单看如许的趋势已经富足表现出业界对 SQL 本事的一些质疑。
我们这里要先容一种非 SQL 型数据堆栈 esProc，由于没有使用 SQL 作为查询语言（而是 SPL），可以临时将其当作一种新型数据堆栈。
为什么 esProc 不再使用 SQL 了呢？
要答复这个题目，我们还要继承为什么数据堆栈有了 SQL 还要引入 Python 的话题。引入 Python 要办理哪些题目呢？
我们知道，SQL 对过程盘算的支持很差，纵然有了 CTE 语法在形貌复杂盘算时仍旧非常复杂，经常要嵌套多层且反复关联。同时，SQL 的聚集是无序的，非常不善于有序盘算，涉及序运算经常会写得很繁琐以致很难写出来。SQL 自己的语言特性注定不善于完成某些复杂盘算，而这类盘算在数据堆栈类的数据分析型场景中并不少见。比如在盘算电商漏斗分析（欣赏商品、加购物车、下单、付款等多步的用户流失率）的场景用 SQL 就很难实现。而如许涉及多个前后步调、效果反复使用的场景用 Python 如许支持分步和有序运算的语言实现则要简单得多。
也就是说，SQL 的本事是缺失的。
但是，假如因此引入 Python 品级三方语言来补充本事上的缺失，又会带来技能栈的复杂题目。照旧那句话，Python 能不能补充这些缺失尚且岂论，两者可否很好融合也不管，但是多种技能风格带来的体系复杂度上升，从而导致高开发本钱和运维本钱是跑不掉的了。
除了本事方面的短缺，接纳 SQL 的关系数据库还存在封闭性的题目。
数据库的作用紧张是生意业务（TP），这就必要浩繁束缚包管数据划一等，因此数据入库时只有满意条件才华进来，进来才华使用。这种只有装入内部才华使用的特性我们称之为封闭性。数据堆栈是基于数据库发展而来的，封闭性的特点也继承了下来。
封闭性对于 TP 业务黑白常紧张的。但是，对于以分析盘算为主的 AP 业务，这个封闭性不但毫偶然义，以致另有很大缺点。封闭性要求数据进入内部才华使用，这会导致多个数据库之间的数据无法举行恣意组合和运算，这就极大限定了数据堆栈的应用场景。
不但云云，今世数据应用的数据源非常广泛，除了差别数据库，经常碰面对五花八门的数据泉源和范例。封闭的 SQL 数据库不能针对库外的数据开放其盘算本事，就只能把外部数据先导入才华盘算。这会增长一步 ETL 动作，增大工作量并加大数据库负担的同时，还丧失了数据的及时性。这些外部数据的格式经常不规范，导入进有强束缚的数据库并不是一件很轻易的事。而且，纵然做 ETL 也要先把未整理的数据先入库才华使用数据库的盘算本事，效果把 ETL 做成 ELT，加大数据库负担。
封闭性还不方便用户自由实验空间换时间。我们知道，存储资源相对于盘算资源要自制得多，假如我们针对差别盘算目标把数据以多种方式冗余存储，就大概得到更好的查询体验。但是，SQL 要用表来存储数据，自建表太多又会导致元数据变大，严峻增长运维本钱。表数量太多还会导致数据堆栈出现容量和性能题目，面对扩容压力。很多大型机构的中心数据堆栈中会有成千上万的中心表，积累多年而不敢删除，数据库容量、性能、运维压力都很大。
SQL 在性能方面也不理想。
我们知道，SQL 的实验服从取决于数据库优化引擎的优化水平，好的数据库会根据 SQL 的盘算目标（而非字面意思）选择更高效的实验方式。但这种主动优化机制仅对简单的环境下有用，一旦 SQL 变得稍复杂优化引擎就不起作用了，只能根据 SQL 的字面表达去实验，效果性能陡降。像前面提到的漏斗分析，有人用 SQL 写出 3 步的漏斗盘算到数据库实验，效果性能低到不可用的水平。关于 SQL 性能不佳的环境信托诸位在现实业务中并不少见，很多跑批场景一个 SQL 跑个把小时的环境比比皆是，这些都是 SQL 性能不高引起的。
SQL 本事不敷，加上封闭性又导致使用极重，性能也不高。这是当前 SQL 型数据堆栈面对的紧张题目。
在 SQL 的底子上引入 Python 本事也不能办理题目。除了我们上面提到的技能栈复杂题目会导致使用和运维本钱过高外，Python 还没法得到高性能。
自己 Python 对大数据盘算的支持就比力差，对于超出内存容量的数据盘算并没有提供相应的外存盘算范例（如游标），导致处理处罚大数据非常复杂。同时，Python 并不支持真正的多线程并行，Python 的并行是伪并行，对于 CPU 来说就是串行，以致比串行还慢，难以充实使用今世 CPU 多核的上风。
更紧张的是，由于 Python 要基于 SQL 数据库表举行运算，这些表（存储）为数据库私有外界无法干预。但很多高性能盘算是必要根据盘算目标来构造数据的，如将数据按照关联字段排序就可以使用更高效的有序归并算法，存储无法干预就不能实现这些算法，性能天然也无法得到包管。别的，Python 读取数据库数据还涉及 IO 本钱，这些都会导致盘算性能不高。
看来要办理 SQL 的这些题目就只能扬弃 SQL 了。
着实非 SQL 的盘算技能不停都有，比力范例的代表是 Spark。Spark 诞生之初使用 Scala 作为编程语言，再借助其大规模的分布式盘算本事大有革命 SQL 的态势。不外很遗憾，随着使用的深入我们发现 Spark 并没有代替 SQL 的本事（实现繁琐、性能低），加之 Scala 的使用难度，让 Spark 又不得不回到 SQL 的度量。
接下来我们来看看非 SQL 数据堆栈 esProc 的本事，会有哪些差别。
esProc SPL

esProc 数据堆栈的情势化语言是 SPL，并没有使用业界广泛接纳的 SQL。缘故起因就在于 SQL 本事缺失、体系封闭、性能不高，而 SPL 能很好办理这些题目。
本事完备

起首，SPL 天然支持过程盘算。
过程盘算可以有用低落复杂业务的实现难度，同样的 100 行代码，分成 100 个语句照旧只有 1 个语句，其复杂度完全不是一个层面的。SQL 固然在 CTE 语法和存储过程的支持下具备了肯定水平的过程化，但仍远远不敷。SPL 在这方面提供了天然支持，将复杂盘算分解成多步从而低落实现难度。
其次，SPL 提供了更丰富的数据范例和运算支持。
相比 SQL 没有明显的记录数据范例（单条记录会被 SQL 作为只有一条记录的临时表处理处罚，也就是个单成员的聚集），SPL 提供了专业的结构化数据对象序表，并在序表的底子上提供了丰富的盘算类库，从而使得 SPL 具备了美满且简单的结构化数据处理处罚本事。
比如部门通例盘算：

1. Orders.sort(Amount) // 排序
2. Orders.select(Amount*Quantity>3000 && like(Client,"*S*")) // 过滤
3. Orders.groups(Client; sum(Amount)) // 分组
4. Orders.id(Client) // 去重
5. join(Orders:o,SellerId ; Employees:e,EId) // 连接

复制代码

有了过程化和序表的支持，SPL 就可以完成更加丰富的运算。比如对有序运算的支持 SPL 就更为直接和彻底。另有分组运算，SPL 可以保存分组子集，即聚集的聚集，如允许以很方便完成我们分组后对分组效果的进一步利用。相比之下，SQL 没有显式的聚集数据范例，无法返回聚集的聚集这类数据，不能实现独立的分组，就只能逼迫分组和聚互助为一个团体来盘算了。
别的，SPL 对聚合运算也有新的明确，聚合效果除了常见的单值 SUM、COUNT、MAX、MIN 等之外，也可以是个聚集。比如经常出现的 TOPN 盘算，SPL 也看作和 SUM、COUNT 一样的聚合盘算，既可以针对全集也可以针对分组子集。
着实 SPL 另有很多特性不但比 SQL 更加美满，相对 Python 也更加丰富。像离散性可以让构成数据表的记录游离于数据表外独立反复使用；广泛聚集支持任何数据构成的聚集并加入运算；毗连运算区分了三种差别毗连范例可以因地制宜；……。
有了这些完备的盘算本事，不但代码编写简单，更不必要借助其他盘算本事，技能栈简单，在一个体系内就可以搞定全部题目。
体系开放

差别于 SQL 数据库必要数据先入库再盘算（封闭性），SPL 面对多样性数据源时可以直接盘算，具备精良的开放性。
SPL 没有传统数据堆栈中“库“的概念，也没有元数据概念，更没有束缚。任何可访问到的数据源都可以看作 SPL 的数据，并可被直接盘算。盘算前不必要先“入库”，盘算后也可以用接口写出目标数据源中，不必要刻意“出库”。
SPL 对常见的数据源都封装了访问接口，如各种关系数据库（JDBC 数据源）、MongoDB、HBase、HDFS、HTTP/Restful、…，以及 SalesForces、SAP BW、…。这些数据源在逻辑上职位根本雷同，访问后都可以单独或肴杂盘算，差别之处仅仅在于访问接口以及差别接口表现出来的性能。
文件存储

在数据存储方面，SPL 与传统数据堆栈也有很大差别。
SPL没有元数据，直接接纳文件存储，可以使用恣意开放文件范例，SPL 为了包管盘算性能还操持了专门的二进制文件格式。
现在 SPL 提供了两种文件范例：集文件和组表。集文件接纳了压缩技能（占用空间更小读取更快），存储了数据范例（无需剖析数据范例读取更快），支持可追加数据的倍增分段机制，使用分段计谋很轻易实现并行盘算，包管盘算性能。组表支持列式存储，在加入盘算的列数（字段）较少时会有巨大上风。组表上还实现了索引，同时支持倍增分段，如许不但能享受到列存的上风，也更轻易并行提升盘算性能。
存储和盘算不再绑定还很方便实现存算分离，进而实验弹性盘算，也更易于云化。
文件存储的本钱更低，在 AP 类盘算场景下用户可以随意操持空间换时间的方案，无非就是多存几个文件，纵然冗余数据文件多到上万（今世文件体系处理处罚这个规模的文件数据很轻松）也完全没有负担。而且使用文件体系的树状结构很轻易分门别类管理这些数据文件，运维本钱更低。
延伸阅读： 跑在文件体系上的数据堆栈
高性能

基于机动的文件存储，我们就可以根据盘算目标机动操持数据构造（存储）情势以实现高性能。除了高性能存储支持外，SPL 还提供了诸多大数据与高性能盘算机制和算法支持。
SPL 起首在运算本事上提供了游标盘算来应对超出内存容量的大数据盘算。

1. =file("orders.txt").cursor@t(area,amount).groups(area;sum(amount):amount)

复制代码

同时还为表里存盘算都提供了并行盘算支持。简单增长一个 @m 选项就可以实现并行充实使用 CPU 多核的本事，非常方便：

1. =file("orders.txt").cursor@tm(area,amount;4).groups(area;sum(amount):amount)

复制代码

除了游标和并行盘算外，SPL 还内置了很多高性能算法。像 TOPN 运算，SPL 把这种运算平静凡的聚合运算同样对待后，写出来的取前 N 名的语句中就不会有排序动作，实验服从因此更高。
雷同的，SPL 还提供了很多如许的高性能算法。包罗：

• 内存盘算类的二分法、序号定位、位置索引、哈希索引、多层序号定位、……
  
• 外存查找类的二分法、哈希索引、排序索引、带值索引、全文检索、……
  
• 遍历盘算类的耽误游标、遍历复用、多路并行游标、有序分组汇总、序号分组、……
  
• 外键关联类的外键地点化、外键序号化、索引复用、对位序列、单边分堆、……
  
• 归并与毗连类的有序归并、分段归并、关联定位、附表、……
  
• 多维分析类的部门预汇总、时间段预汇总、冗余排序、布尔维序列、标签位维度、……
  
• 集群盘算类的集群复组表、复写维表、分段维表、冗余与备胎容错、负载均衡、……
  

有了高性能文件存储和高性能算法的支持，esProc 在现实应用中经常得到比传统 SQL 数据堆栈几倍到几十倍，有的以致到达上千倍的性能提升。
看起来，相对于 SQL，SPL 就没有劣势？
这固然不大概，这天下上没有全面都好的东西。
SQL 颠末几十年的积累发展，很多数据库都拥有很强的优化引擎。对于得当用 SQL 完成的简单场景运算，可以将寻常步调员写出来的慢语句优化出较好的性能，从这个意义上讲，对步调员的要求相对较低。某些场景（比如多维分析）已经被优化多年，某些 SQL 引擎也可以跑出相称好的极致性能。
相比之下，SPL 没有做多少主动优化的功能，要跑出高性能，险些端赖步调员写出低复杂度的代码。步调员必要颠末肯定的培训和训练来认识 SPL 的理念和库函数，多一个上手的门槛。而且 SPL 现在是用 Java 实现的，固然得到了兼容性好、移植性强以及易于云化的利益，但也受限于 JVM 而无法充实使用 CPU 和内存。某些简单运算场景下的性能照旧赶不上被充实优化的 SQL 引擎。
数据堆栈不肯定非要 SQL，另有 SPL。
开源SPL源码地点
免费下载试用

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金