数据中台为什么不好搞？

数据中台为什么不好搞？

从 2015 年阿里提出“大中台”的数据中台战略，到 2019 年大厂及中台服务商“大兴”数据中台，再到 2021 年大厂又开始拆中台。数据中台从小甜甜变成牛夫人仅仅用了 2 年时间，为什么这么快数据中台就不香了？（说明：数据中台的概念比较模糊，有些人说是业务概念，有些人说是技术概念，这里我们仅从技术的角度讨论，即认为数据中台是技术概念）

数据中台为什么难搞？

从技术上讲，中台的架构挺合理的。在前台和后台之间夹一个中台，屏蔽后台的数据存储，应对前面没完没了的变化需求。前台跟着界面走，天生就稳定不了，总是有五花八门的数据请求，这是必然的事情。后台应该主要负责数据存储，把不同形式和规模的数据以合适的方式整理好，大数据倒腾起来动静太大，要求有一定的稳定性。如果前台的请求都要求后台直接做，那后台管的事就太多了。应对灵活请求和规整数据存储在一定程度上是两个优化目标不同的需求，同一个团队在同一套硬件上同时对付这两件事，容易发生精神分裂。而且，后台是被许多前台共享的，如果直接向前台提供灵活数据服务，还可能导致各个前台之间的耦合程度太高，维护成本立即陡增。同样的，把这些数据处理放在前台也不合适，一方面不太安全，另一方面，前台团队也是忙着让界面如何更好看使用更流畅，没太多工夫琢磨数据的事情。有了中台就好很多了，后台专心管存储，前面专心管界面，前后台之间的差距由中台负责抹平。分工明确，各司其职，效率自然提高。

既然架构合理，那为啥搞不下去？

原因呢，说啥的都有，不过大都没说到点子上。因为说这些话的大都不写代码，写代码的又大都轮不到来说话。技术上的根本原因在于，业界就没有准备好能让数据中台落地的技术！

中台向前台提供数据服务。啥是数据服务呢？就是收到请求后返回一些合适的数据回去，那咋弄出返回的数据呢？计算！就是把以前在后台让数据库做的事搬到中台完成。

那么，你打算让我用什么技术来写这些计算代码呢？

Java？开玩笑呢？写个稍复杂些的分组汇总就可能好几百行，你让我怎么提高效率？还想迅速应对前台变化？这代码我连写带调得好几天，下礼拜再见吧。

中台要干的这些任务，也是之前数据库干的事，绝大多数都是结构化数据相关的计算。而 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 代码示例：

热切换能力

SPL 采用解释执行机制，天然支持热切换。这样对于稳定性差、经常需要新增修改的中台数据处理需求非常友好。SPL 服务脚本与 Java 程序独立，外置在 Java 之外，修改和维护都可以独立进行，脚本修改上传后就能实时生效，保证中台可以不中断地提供服务。

使用 SPL 实现中台中的数据处理逻辑，可以有效地降低数据服务和框架之间的耦合性。整个中台架构也更为合理。

敏捷语法

作为专业的数据计算引擎，SPL 为结构化数据处理设计了专门的敏捷计算语法，通过 SPL 语法可以快速实现数据处理任务，及时响应前台多变的数据请求。在敏捷语法与过程计算的支持下，即使原来使用 SQL 难以完成的复杂计算（更不用说 Java 了），用 SPL 也可以轻松实现。比如要根据股票记录查询某只股票最长连续上涨天数，SQL（***）的写法如下：

select max(continuousDays)-1from (select count(*) continuousDaysfrom (select sum(changeSign) over(order by tradeDate) unRiseDaysfrom (select tradeDate,case when price>lag(price) over(order by tradeDate) then 0 else 1 end changeSign from AAPL) )group by unRiseDays)

可以尝试一下读懂这句 SQL，是不是很绕？这是由 SQL 的特性（缺乏离散性、集合化不彻底等）决定的。同样的思路，SPL 写起来就简单多了，不用绕来绕去了：

数据从数据库中取出（数据源是什么都可以，下面会说到 SPL 的开放性），计算在计算引擎 SPL 中完成，符合数据中台的目标。

SPL 还提供了简洁易用的 IDE 环境，在 IDE 中不仅可以很方便编码调试，过程计算的每步计算结果都可以实时查看，网格式编码代码天然整齐，通过格子名称引用中间计算结果无需定义变量，十分方便。

强计算

数据中台的计算引擎需要独立的计算能力。SPL 作为独立的计算引擎，计算能力不依赖数据库，提供了十分丰富的结构化计算类库，拥有完备的计算能力。分组汇总、循环、过滤、集合运算、有序计算等应有尽有。

SPL 还提供了很多高性能算法来保证计算效率，内外存计算、索引机制、遍历复用等很多在业界内首次使用的算法，同时支持并行计算进一步提升计算性能。

开放性

SPL 还具备非常开放的计算能力，可以对接多种数据源，RDB、NoSQL、CSV、Excel、JSON/XML、Hadoop、RESTful、Webservice 都可以直接对接并进行混合计算，不需要借助数据库，数据实时性和计算实时性都可以很好保障。

我们知道，不同数据源有各自的优势，RDB 计算能力较强，但 IO 吞吐能力弱；NoSQL 的 IO 效率高，但计算能力很弱；而文本等文件数据完全没有计算能力，但使用非常灵活。SPL 不仅可以基于这些数据源混合计算，在实施计算时还可以充分保留原有数据源的优势。除了原生计算语法，SPL 也提供 SQL 支持（相当 SQL92 标准），可以使用 SQL 查询文本、Excel、NoSQL 等非 RDB 数据源，这样就极大方便了熟悉 SQL 的应用开发人员。

总结一下，数据中台落地的关键在于计算引擎，而计算引擎需要具备独立且完备的计算能力、应对多样性数据源的开放性、开发的高效性以应对不停变化的前台需求，还能支持热切换以确保中台持续提供服务。从这些方面来看，SPL 的确是数据中台计算引擎的不二之选。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。