2015年阿里提出“大中台”数据中台战略，到2019年，大厂和中台服务商“大兴”数据中台，再到2021年，大厂开始拆除中间平台。数据中心从小就变成牛太太，只用了2年时间。为什么数据中心如此迅速地流行起来？（解说：数据中心这个概念比较模糊，有人说是业务概念，有人说是技术概念，这里我们只从技术角度讨论，即我们认为数据中心是一个技术概念。）为什么数据中心这么难？从技术上讲，中泰的结构还是比较合理的。在前台和后台之间夹着一个中间平台，屏蔽后台的数据存储，应对前台不断变化的需求。前台跟界面走，天生不稳定。总是有各种各样的数据请求，这是不可避免的。后台主要负责数据的存储，对不同形式和规模的数据进行适当的组织。大数据过于动态，需要一定程度的稳定性。如果前台的所有请求都需要后台直接来做，那后台管理的东西就太多了。从某种程度上说，响应灵活的请求和定期存储数据是两个有着不同优化目标的需求。如果同一个团队在同一套硬件上同时处理这两件事，很容易出现精神分裂症。此外，后端由许多前台共享。如果直接向前台提供灵活的数据服务，各前台之间的耦合度可能会过高，维护成本会立即急剧增加。同样，把这些数据处理放在前台也不合适。一方面，它不安全。另一方面，前端团队忙于让界面看起来更好用更流畅，没有太多时间考虑数据。有一个中间平台会好很多。后台可以专心管理存储，前台可以专心管理接口。中台负责拉平前台和后台之间的差距。分工明确，各司其职，效率自然会提高。既然结构合理，为什么不能继续下去呢？至于原因，说的五花八门，但大多都没有切入正题。因为说这些话的人大多不写代码，而写代码的人大多轮不到说话的机会。根本的技术原因是业界对于让数据中心落地的技术还没有准备好！中台为前台提供数据服务。什么是数据服务？就是接收到请求后返回一些合适的数据，那么如何获取返回的数据呢？计算！就是把数据库在后台做的事情，搬到中台去完成。那么，你想让我用什么技术来写这些计算代码？爪哇？只是在开玩笑？写一个稍微复杂一点的小组总结可能需要几百行。你问我如何提高效率？还想快速响应前台的变化？这几天我一直在编写和调整这段代码，下周见。中台要做的工作也是之前数据库做的，而且大部分都是结构化数据相关的计算。但是Java等高级语言基本没有有用的结构化数据计算库。SQL几句、几十句就能搞定的，现在Java就需要几百甚至几千行代码。代码长，不仅难写，而且容易出错。而且，Java程序员的成本也相当高。效率没有提高，钱都花光了，何苦呢？你可能会说，Java支持Stream后，这些问题就迎刃而解了。Stream看起来不错，但实际上完全不是这样。Stream的中间计算结果和最终结果必须提前定义好，结构体的定义和赋值非常麻烦。如果没有定义，阅读和使用起来不直观。而且，Stream虽然支持lambda语法，但是接口规则更加复杂，代码也短不了多少，但是阅读障碍明显增加了。Stream的结构化对象如record\entiry\Map不方便。根本原因是Java缺乏专业的结构化数据对象和底层的强大支持。与Stream类似，Kotlin的计算能力不足也是由于缺乏专门的结构化数据对象造成的。不能支持动态数据结构，不能真正简化Lambda语法，不能直接引用字段等等。同时，Kotlin也缺少一些重要的基础功能，比如关联计算。开发人员仍然必须硬编码才能完成计算。对于由多个基础计算组成的业务算法，开发过程还是比较困难的。不过，目前看来，一些大厂的中台架构执行得很好。这怎么解释呢？可能是大厂人才多，Java代码积累丰富，做这些计算比较容易。而且，事实是，这些互联网大公司虽然规模大，但业务复杂度远不及传统行业。大公司能做的，你不一定能做。更何况大厂又开始拆中台了不是吗？如果不用Java，那还要继续用SQL吗？嗯，那我们就得在中台放一个数据库，从后台搬一堆数据到中台。要移动多少数据？好像所有的数据都可能用来计算，所以整个后台的数据都要搬过来。但这东西还能叫中台吗？不就是把后台挪到一个位置吗，就是吃的满满当当的。当没有独立于数据库、集成嵌入式、简单方便、丰富强大的支持多数据源的结构化数据计算能力时，数据中心只是一个结构美好的幻想，却无法实现。强行上中台，除非你的业务足够简单，否则只会增加开发成本，降低效率。灵活性一点也没有增加，反而麻烦很多。数据中心受限于计算能力。必须要有具备以上特点的计算引擎，数据中心平台合理的架构才能真正发挥作用，数据中心平台才能落地、开花、结果。开源SPL：数据中心计算引擎开源计算引擎SPL具备数据中心所需的所有特性。它不仅提供了不依赖于数据库的完整计算能力，开放的计算系统还可以直接基于各种数据源进行计算。类库和敏捷的语法可以轻松完成复杂的结构化数据计算。SPL出色的集成性保证了它可以方便地分布到数据中心的各个环节来处理数据，帮助数据中心发挥应有的作用。从逻辑上讲，SPL实现了应用与数据源之间的数据处理，为上层提供计算服务，为下层屏蔽不同数据源的差异性，非常适合数据中心的结构。SPL提供了标准的JDBC/ODBC/RESTful接口，可以像调用存储过程一样请求SPL计算结果。JDBC调用SPL代码示例：Class.forName("com.esproc.jdbc.InternalDriver");Connectionconn=DriverManager.getConnection("jdbc:esproc:local://");CallableStatementst=conn.prepareCall("{callsplscript(?,?)}");st.setObject(1,3000);st.setObject(2,5000);ResultSetresult=st.execute();热切换能力SPL采用解释执行机制，天然支持热切换切换。这对于稳定性较差，经常需要增删改查的中台数据处理需求非常友好。SPL服务脚本独立于Java程序，在Java之外。可独立进行改装和维修。脚本修改上传后实时生效，保证中台不间断提供服务。使用SPL实现中台的数据处理逻辑，可以有效降低数据服务与框架之间的耦合度。整个中台结构也更加合理。敏捷语法是一个专业的数据计算引擎。SPL为结构化数据处理设计了专门的敏捷计算语法。通过SPL语法，可以快速实现数据处理任务，及时响应前台不断变化的数据请求。在敏捷语法和过程式计算的支持下，即使是使用SQL（更不用说Java）难以完成的复杂计算，也可以通过SPL轻松实现。例如，根据股票记录查询某只股票的最长连续上涨天数，SQL（oracle）的写法如下：(orderbytradeDate)unRiseDaysfrom(selecttradeDate,casewhenprice>lag(price)over(orderbytradeDate)then0else1endchangeSignfromAAPL))groupbyunRiseDays)您可以尝试理解此SQL，不是吗令人困惑？这是由SQL的特性决定的（缺乏离散性、集合不全等）。同理，SPL写起来就简单多了，不用绕来绕去：从数据库中取数据（任何数据源都可以，下面会说到SPL的开放性），计算完成在计算引擎SPL中。符合数据中心的目标。SPL还提供了一个简单易用的IDE环境。在IDE中，不仅编码和调试非常方便，而且可以实时查看流程计算每一步的计算结果。网格格式编码代码自然整洁，中间计算结果通过网格名称引用，无需定义变量，很方便。强计算数据中心的计算引擎需要独立的计算能力。SPL作为一个独立的计算引擎，不依赖于数据库的计算能力，提供了非常丰富的结构化计算类库，具有完整的计算能力。分组汇总、循环、过滤、集合运算、有序计算等一应俱全。SPL还提供了很多高性能算法来保证计算效率，如内外存计算、索引机制、遍历复用等很多算法都是业界首次使用，并支持并行计算，进一步提升计算性能.SPL的开放性还具有非常开放的计算能力，可以对接多种数据源。RDB、NoSQL、CSV、Excel、JSON/XML、Hadoop、RESTful、Webservice都可以直连，不需要数据库就可以进行混合计算。实时性和计算实时性都能得到很好的保证。我们知道不同的数据源各有优势。RDB计算能力强，但IO吞吐量弱；NoSQLIO效率高，但计算能力弱；而文本等文件数据根本没有计算能力，但是使用起来非常灵活。SPL不仅可以基于这些数据源进行混合计算，还可以在实现计算时充分保留原有数据源的优势。除了原生的计算语法，SPL还提供了SQL支持（相当于SQL92标准），可以使用SQL查询文本、Excel、NoSQL等非RDB数据源，极大方便了熟悉SQL的应用开发者.综上所述，数据平台落地的关键在于计算引擎，而计算引擎需要具备独立完整的计算能力，开放性应对多样化的数据源，高效开发以满足不断变化的战线-端需求，也可以支持热切换，保证中台可以持续提供服务。从这些方面来看，SPL确实是数据中心计算引擎的最佳选择。
