数据中台技术的利与弊

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

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

经常使用架构以下：

▪︎  Serverless 架构：

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

▪︎  Event-Driven 架构：

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

▪︎  Microservices 架构：

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

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

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

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

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

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

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

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