机器人|数据中台咋就从“小甜甜”变成了“牛夫人”？( 二 ) 安防|商场|ai|创投圈

选择2：Stream
可能有人会说， Java支持Stream以后这些问题就都能解决了。但是， Stream看着挺好，实际用起来完全不是那么回事。 Stream的中间计算结果和最终结果都要事先定义，而结构的定义和赋值都很麻烦。如果不定义，阅读和使用又不直观。
而且Stream虽然支持Lambda语法，但接口规则比较复杂，代码没短多少但阅读障碍却显著增加。 Stream 的结构化对象如 record\\entiry\\Map都不方便，根本原因还是在于 Java 缺乏专业的结构化数据对象，缺少来自底层的有力支持。
选择3：Kotlin
与 Stream 类似， Kotlin计算能力不足，也是缺乏专业的结构化数据对象，无法支持动态数据结构、难以真正简化 Lambda 语法、无法直接引用字段等。同时Kotlin也缺乏一些重要的基本函数，比如关联计算，开发者仍然要硬编码完成计算，对于多个基本计算组合而成的业务算法，开发过程仍然困难。
但是，有些大厂的中台架构实施得不错，这又怎么解释呢？笔者认为，可能是因为大厂人才多， Java 代码积累丰富吧，实现这些计算就容易一点。但是，互联网大厂虽然规模大，但业务复杂度却远远赶不上传统企业。所以，互联网大厂能跑得通，传统企业未必能跑得通。更何况，互联网大厂已经开始拆中台了？
选择4：SQL
Java、Stream和Kotlin都行，用 SQL 行不？可以，不过得在中台放个数据库，把一堆数据从后台迁移到中台来。迁移多少数据呢？貌似所有的数据都有可能用于计算，那得把整个后台的数据都搬过来。
然而，这还能叫中台吗？不就是把后台挪了个位置而已嘛。在没有不依赖于数据库、可被集成嵌入、支持异构数据源、简单方便且丰富强大的结构化数据计算能力时，数据中台只能说个空想，架构好看但无法落地。
有人说，强行上中台可以吗？除非企业的业务足够简单，否则只会让开发成本上升而效率下降——灵活性一点没增加，麻烦事却一大堆。
【机器人|数据中台咋就从“小甜甜”变成了“牛夫人”？】综合来看，数据中台必须具有上述特征的计算引擎之后，才能让数据中台的合理架构真正发挥作用，才能让数据中台真正的落地、开花、结果。