2024年大数据最新开源 SPL 消灭数以万计的数据库中间表_开源spl(1)，2024年最新Glide的缓存机制

2401_84615996

于 2024-05-14 01:39:35 发布

阅读量367

点赞数 4

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.csdn.net/2401_84615996/article/details/138827416

版权

程序员专栏收录该内容

50 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

$select * from d:/Orders.csv where Client in (‘TAS’,‘KBRO’,‘PNS’)


复杂些的with都支持：

$select t.Client, t.s, ct.Name, ct.address from
(select Client ,sum(amount) s from d:/Orders.csv group by Client) t
left join ClientTable ct on t.Client=ct.Client


SPL在处理JSON/XML等多层数据（文件）方面也很有优势，如：根据员工订单信息（json）完成计算。




|  |  |  |
| --- | --- | --- |
|  | A  |  |
| 1  | =json(file("/data/EO.json").read())  |  |
| 2  | =A1.conj(Orders)  |  |
| 3  | =A2.select(Amount>1000 && Amount<=3000 && like@c(Client,"\*s\*"))  | 条件过滤  |
| 4  | =A2.groups(year(OrderDate);sum(Amount))  | 分组汇总  |
| 5  | =A1.new(Name,Gender,Dept,Orders.OrderID,Orders.Client,Orders.Client,Orders.SellerId,Orders.Amount,Orders.OrderDate)  | 关联计算  |


可以看到，相对其他JSON库（如JsonPath）SPL的实现更简洁。


同样，使用SQL也可以查询JSON数据：

$select * from {json(file(“/data/EO.json”).read())}
where Amount>=100 and Client like ‘bro’ or OrderDate is null


SPL的敏捷语法和过程计算还非常适合完成复杂计算，比如基于股票记录（txt）计算某只股票最长连涨天数 可以这样写：




|  |  |
| --- | --- |
|  | A  |
| 1  | =T("/data/stock.txt")  |
| 2  | =A1.group@i(price<price[-1]).max(~.len())-1  |


再比如，根据用户登录记录（csv）列出每个用户最近一次登录间隔：




|  |  |  |
| --- | --- | --- |
|  | A  |  |
| 1  | =T(“/data/ulogin.csv”)  |  |
| 2  | =A1.groups(uid;top(2,-logtime))  | 最后2个登录记录  |
| 3  | =A2.new(uid,#2(1).logtime-#2(2).logtime:interval)  | 计算间隔  |


这类计算即使基于数据库使用SQL也很难写，SPL实现却很方便。


有了SPL的库外计算支持，原本数据库中间表带来的各种问题就能得到有效解决。文件存储不再占用数据库存储空间，数据库扩容压力降低，数据库更方便管理；库外计算不再占用数据库计算资源，数据库减负可以更好服务其他业务。


### 高性能文件格式


虽然文本是很常见的数据存储形式，具备通用性易读性等优点，但是，文本的性能却非常差！基于文本做计算很难获得高性能。


文本字符不能直接运算，需要转换成整数、实数、日期、字符串等内存数据类型才可以进一步处理，而文本的解析是个非常复杂的任务，CPU 耗时很严重。一般来讲，外存数据访问的主要时间是在硬盘本身的读取上，而文本文件的性能瓶颈却经常发生在 CPU 环节。因为解析的复杂性，CPU 耗时很可能超过硬盘耗时（特别是采用高性能固态硬盘时）。需要高性能处理较大数据量时通常不会使用文本。


SPL提供了两种高性能数据存储格式，集文件和组表。集文件是SPL提供的二进制数据格式，采用了压缩技术（占用空间更小读取更快），存储了数据类型（无需解析数据类型读取更快），还支持可追加数据的倍增分段机制，利用分段策略很容易实现并行计算，进一步提升计算性能。


组表是SPL提供列存、索引机制的文件存储格式，在参与计算的列数（字段）较少时列存会有巨大优势。组表除了支持列存，实现了minmax索引外，还支持倍增分段机制，这样不仅能享受到列存的优势，也更容易并行提升计算性能。


SPL存储的使用很方便，与文本使用基本一致，比如读取集文件并计算：




|  |  |  |
| --- | --- | --- |
|  | A  | B  |
| 1  | =T("/data/scores.btx")  | 读入集文件  |
| 2  | =A1.select(CLASS==10)  | 过滤  |
| 3  | =A1.groups(CLASS;min(English),max(Chinese),sum(Math))  | 分组汇总  |


如果数据量较大，还支持游标分批读取以及多CPU并行计算：

=file(“/data/scores.btx”).cursor@bm()


在使用文件作为数据存储方式时，无论原始数据是何种格式，最后都至少要转存成二进制（如集文件）格式，这样无论在空间占用还是计算性能上都会更有优势。


### 易管理性


中间表转移到库外通过文件存储以后，除了可以帮数据库减负，库外中间表自身还具备极强的易管理性。文件可以通过系统的树状目录进行存储，使用和管理都很方便。将不同系统、不同模块使用的中间表存放在不同的目录中非常清晰，不会出现交叉引用的情况，这样就不会出现以往数据库中间表使用混乱造成各个系统或各个模块之前的紧耦合问题。如果对应功能模块下线也可以放心删除对应的中间表数据不用担心对其他程序产生影响。


### 多数据源支持


除了文件数据源，SPL还支持其他几十种数据源，不仅可以连接取数，还可以完成混合计算。


![..](http://img.raqsoft.com.cn/docx/1648625900540100.png)
中间表改用文件存储后要与数据库中的实时数据进行全量查询就涉及跨源计算，使用SPL完成这类T+0查询就很方便。




|  |  |  |
| --- | --- | --- |
|  | A  |  |
| 1  | =cold=file(“/data/orders.ctx”).open().cursor(area,customer,amount)  | /冷数据从文件系统（SPL高性能存储）中取，昨天及以前的数据  |
| 2  | =hot=db.cursor(“select area,customer,amount from orders where odate>=?”,date(now()))  | /热数据从生产库中取，今天的数据  |
| 3  | =[cold,hot].conjx()  |  |
| 4  | =A3.groups(area,customer;sum(amout):amout)  | /混合计算实现T+0  |


### 集成性


SPL提供了标准JDBC和ODBC接口供应用调用。特别地，对于Java应用可以将SPL作为嵌入引擎集成到应用中，使得应用本身就具备中间（数据）表的处理能力。


JDBC调用SPL 代码示例：

…
Class.forName(“com.esproc.jdbc.InternalDriver”);
Connection conn =DriverManager.getConnection(“jdbc:esproc:local://”);
Statement st = connection.();
CallableStatement st = conn.prepareCall(“{call splscript(?, ?)}”);