数据中台技术的利与弊

伴随信息时代的发展，新技术、新框架、新语言层出不穷，解决问题的技术视角其实从来没有改变。所有应用都需要和存储系统相关联，无论存储是 SQL 还是 NOSQL 的。业务系统和数据库遵循不同的开发规范，为了让开发更容易，有一类框架专门帮助解决从应用层到数据库的转换，著名的 ORM 类框架就是其中之一。实际上数据中台技术主要面临的挑战主要也是计算服务和各种数据存储如何便捷的统一起来，并通过服务化 API 和前台业务层对接。

当我们讨论中台应用程序时，先理清包括设计和体系结构在内的一些方法，会更容易认识设计思想的本质。体系结构是处理灵活性，可伸缩性，可用性，安全性以及其他直接与业务视角相关的结构设计。

常用架构如下：

▪︎  Serverless 架构：

Serverless 体系结构是包含第三方“后端即服务”（BaaS）服务的应用程序设计，包括在“功能即服务”（FaaS）平台上以托管、临时容器运行的自定义代码。

▪︎  Event-Driven 架构：

Event-Driven 体系结构模式，是基于事件促成生成、检测、消费和响应。

▪︎  Microservices 架构：

它是面向服务的体系结构（SOA）的一种变体，将应用程序构建为松散耦合的服务的集合。 在微服务架构中，服务是细粒度的，协议是轻量级的。

中台应用程序会涉及与多个系统的多个集成，所以从程序的工程角度，应使用古老的罗马策略：分而治之，将复杂性分解为小块，此外，应可扩展，自由使用实现方式达成目标结果，不拘泥于简单的实现手段。

 

这里的挑战是应用开发和数据开发都有不同各自数据对象和处理方式，应用开发是 OOP、函数式编程，常规集合、key-value 数据，数据开发则需要反复处理动态结构数据和复杂的关联运算。因此，从系统结构的角度来看，需要应用开发和数据开发之间的转换器。

Java8 引入了 Lambda 表达式和流，对许多从事数据开发人员来说非常有吸引力，但硬编码需要很长时间，并且由于人为因素可能产生错误的重复性工作，浪费大量时间。为了使这个过程更加简便并减少错误数量，借助成熟的计算框架和 DSL 语言逐渐成为了主流。

举例说明，以集算器为例，脚本如下：

	A	B
1	[mysql1,mysql2,mysql3,mysql4]
2	fork A1	=connect(A2)
3		=B2.query@x("select   product_no,sum(allDuration) sallDuration,sum(allTimes)   sallTimes,sum(localDuration) slocalDuration ,sum(localTimes) slocalTimes from   userService where I0419=? group by product_no", argType)
4	=A2.conj()
5	=A4.groups(product_no;sum(sallDuration):ad,sum(sallTimes):at,sum(slocalDuration):ld,sum(slocalTimes):lt)

某电信企业用库表 userService 存储用户服务信息，T+0 查询需要呈现各类电信产品的通话时长、通话次数、拨打本地时长、拨打本地次数。实际使用中发现数据量太大，查询效率很低，导致前端显示很慢。

引入中间计算层，将位于多个数据库的 userService 数据合并汇总。多线程并行不仅大幅提升了性能，用 SPL 脚本来实现也更加容易，Java 调用 SPL 也很方便。如果上述计算动作用硬编码实现，多线程、数据合并再二次汇总，工作量将非常巨大。

 

使用中台计算组件是一个很好的策略，它去适配各类 SQL、NOSQL、大数据平台，使用一致的结构化数据模型 / 语法进行开发，对外提供通用接口和标准结果集，应用可以根据自身需要继续封装和对外提供服务。中台计算组件最好具备数据缓存特性，不会在大量访问时，直接对存储系统产生影响。从维护角度，它可以方便地修改计算逻辑而不会影响其他代码，不断优化算法和利用缓存，这对其他开发人员和存储系统维护人员来说都是最愿意看到的方式。但由于向开发方面增加了一层，因此破坏了简单性。