2024年大数据最新【云原生】开源数据分析 SPL 轻松应对 T+0_开源spl，大数据开发码农是如何进入腾讯的

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

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

T+0问题

T+0查询是指实时数据查询，数据查询统计时将涉及到最新产生的数据。在数据量不大时，T+0很容易完成，直接基于生产数据库查询就可以了。但是，当数据量积累到一定程度时，在生产库中进行大数据量的查询会消耗过多的数据库资源，严重时会影响交易业务，这就不能接受了，毕竟生产交易是更关键的任务。所以，我们常常会把大量用于查询分析的历史数据从生产库中分离出去，使用单独的数据库存储和查询，以保证查询统计不会影响生产业务，这就是常说的冷热数据分离。

数据分离后就会产生T+0问题。数据拆分到两个数据库中，要查询全量数据就涉及跨库查询。而且，我们知道，用于交易的生产库大多使用能够保证事务一致性的RDB，而分离出来的冷数据（量大且不再修改）则会更多使用专门的分析型数据库或数据平台存储，即使是关系数据库也很可能与原来的生产库类型不同，这就不仅涉及跨库，还需要跨异构库（源）查询。遗憾的是，当前实现跨库查询的技术都存在这样那样的问题。

数据库自身的跨库查询功能（如Oracle的DBLink、MSSQL的Linked Server、MySQL的FEDERATED、等）通常是将远程数据库的数据拉到本地，再在本地完成包括过滤在内的大部分计算，整个过程十分低效。不仅如此，这种方式还存在数据传输不稳定、不支持大对象操作、可扩展性低等很多不足。

事实上，要解决分库后的T+0查询问题也并非难事，只要有具备这样一些能力的计算引擎就可以实现：能够对接多种数据源；拥有不依赖数据库的完善计算能力以完成多库数据归集后的数据计算工作；还可以利用数据库（源）的能力充分发挥数据库的效能；提供简单的数据计算接口；性能相对理想等。

除了数据库自身的跨库查询能力，使用高级语言硬编码也可以完成跨库查询，毕竟没有什么问题不是硬编码解决不了的。这种方式虽然灵活，但使用难度却很大，尤其对于当前大部分应用的开发语言Java来说，缺少足够的结构化数据计算类库使得完成跨库查询后的计算很难完成，通常只能做简单的列表式查询，而涉及到统计汇总类的运算就会异常麻烦。

引入SPL

可以借助开源SPL可以实现这些目标。SPL是一款开源数据计算引擎，提供了大量结构化数据计算函数并拥有完备计算能力，支持多数据源混合计算，可以同时连接存储热数据的业务库和存储冷数据的历史库完成全量数据T+0查询。

由于具备独立且完善的计算能力，SPL可以分别从不同的数据库取数计算，因此可以很好适应异构数据库的情况，还可以根据数据库的资源状况决定计算是在数据库还是SPL中实施，非常灵活。在计算实现上，SPL的敏捷语法与过程计算可以大大简化T+0查询中的复杂计算，提升开发效率，SPL解释执行支持热部署。更进一步，依托SPL的强计算能力还可以完成冷热数据分离时的ETL任务。

SPL还提供了自有的高性能二进制文件存储，对性能要求较高时可以将历史冷数据使用文件存储，再借助SPL的高性能算法与并行计算来提升查询效率。此外，SPL封装了标准应用接口（JDBC/ODBC/RESTful）供应用集成调用，也可以将SPL嵌入应用中使用，这样应用就轻松具备了T+0查询与复杂数据处理能力，将计算和存储分离也更符合当代应用架构的需要。

冷热混合计算

对于常见的冷热分库T+0查询场景，SPL实现很简单，这里看一个例子。

	A	B
1	=[[connect@l(“oracle”),“ORACLE”],[connect@l(“mysql”),“MYSQL”]]
2	=SQL=“select month(orderdate) ordermonth,sellerid,sum(amount) samount,count(amount) camount from sales group by month(orderdate),sellerid”
3	fork A1	=SQL.sqltranslate(A3(2))
4		=A3(1).query(B3)
5	=A3.conj().groups(ordermonth,sellerid;sum(samount):totalamount,sum(camount):totalcount)

本例中，Oracle作为生产库存储当期热数据，MySQL存储历史冷数据。前端传入一句标准SQL（A2），再借助SPL的转换功能将标准SQL转换成对应数据库的语法（B3）并发给数据库查询（B4），最后归并结果进行最后的汇总运算（A5）。这里使用了多线程并行方式（A3）同时执行两个SQL，效率更高。

在这里，SPL不仅完成了两个数据库的跨库查询，还提供了SQL转换方法，更利于前端应用使用，同时拥有合并两个数据库计算结果后的继续计算能力，本例是分组汇总。SPL还有更丰富的结构化数据对象及其上的丰富运算，除了分组汇总、循环分支、排序过滤、集合运算等基础计算外，位置计算、排序排名、不规则分组也不在话下。

除了RDB，对于有些场景涉及的NoSQL、Hadoop等数据源也能支持，SPL具备多源混算能力，无论基于何种数据源都可以进行混合查询实现T+0。比如MongoDB与MySQL混合查询：

	A
1	=mongo_open(“mongodb://127.0.0.1:27017/mongo”)
2	=mongo_shell(A1,“Orders.find()”)
3	=A2.new(Orders.OrderID:orderid,Orders.Client:client,Dept:dept,Amount:amount).fetch()
4	=mongo_close(A1)
5	=mysql.query@x(“select ordered,client,dept,amount from orders”)
6	=[A3,A5].conj()
7	…后续计算

SPL的计算能力还能用于ETL，将生产数据转移到历史库中，还经常伴随一些转换计算，这些都可以使用SPL来完成。比如出于某些原因，要将生产数据某些编码字段通过某个对照表转换成另一种编码（遵守一致性的编码规则、整理数据类型获得更好性能等），而对照表通常并不会存在生产库中，而不能直接在生产库中计算好，这就涉及多数据源计算了。

	A
1	>source=connect@l(“oracle”),target=connect@l(“mysql”)
2	=source.cursor(“select * from orders”)
3	=target.query(“select oldCode,newCode from codeComp”).keys@i(oldcode)
4	=A2.run(pid=A3.find(pid).newcode)
5	>target.execute(A2,"insert into orders values(?,?,?,?,?) ",#1,#2,#3,#4,#5)
6	>source.close(),target.close()

高性能

历史冷数据量可能很大，使用RDB存储容易受到资源容量等因素限制，而且数据读取效率很差。相比下文件存储具备很多优势，不仅读取效率更高，还可以有效利用并行、文件压缩等机制提速，同时也不会像数据库容易受到容量的限制。不过开放的文本格式使用效率不高（无压缩、解析数据类型慢等），一般会使用二进制格式文件。另外，文件存储的最大问题是没有计算能力，不像数据库使用SQL可以很方便完成数据处理，通过硬编码处理的难度很大。

这些问题都可以通过SPL来解决，SPL提供了两种高性能二进制数据存储格式集文件和组表，再借助SPL的独立计算能力可以直接基于文件和数据库混合计算实现高效T+0查询。比如前面的例子，可以使用SPL文件存储历史冷数据与生产库热数据混合查询。

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

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

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

dn.net/topics/618545628)**

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