我拿什么拯救你，我的数据

一、架构和应用并重，不可偏废

谈到数据业务，过去肯定首先想到数据应用，不管是BI还是联机交易，亦或是大数据维度的应用，都是在考虑在应用层面实现数据的利用。但是，在当今这样一个趋势和大背景下，我们肯定要同时考虑数据业务的架构，中台架构无疑是非常重要的考虑。当然中台只是一个概念，归根结底还是要关注数据能力体系的构建，把关注点从应用层落实到能力层，不是说非得要求每个客户都实现数据能力原子化，至少应该按照大的流程把划分开。

二、控制数据平台的边界

以前我们所说的数据体系里面主要是包括传统数仓等内容，一般来说不包括交易系统和流程系统本身。随着技术的发展，又逐渐融入了大数据手段和AI等智能化的元素，但无论怎么演进，还是应该坚持以提供数据能力为核心，进一步可以作为业务流程的依据和元素，但肯定不能改变业务本身的状态。同时我们需要根据实际需求把架构进行分成和分解。一般来说，业务属性是首先应该被考虑的，业务无关的组件应该沉淀成数据架构的技术中台，主要包括数据存储、加工、可视化等业务无关的部分。其余部分应该根据业务相关性，分解成数据业务系统，再细化的话，需要在分解成数据前台和数据中台，前台重视灵活性，中台重视稳定性。也就是说数据前台是业务相关的，为业务系统提供数据应用，下面应该是大的数据中台，具体说里面应该包括两部分，一部分是业务无关的技术中台，另外一部分业务和能力相关的小数据中台。其实应该画个图，我比较懒，下次再说吧。

三、对外接口很重要

重视内部架构的同时，更需要的是要重视整个数据平台的对外接口的管控。所谓接口，主要是指的是刚才描述的前台和中台的接口。以前接口的做法多以批量的文件导入为主，现在有一个很重要的观点就是，建议更多的采用API服务的方式。那么为什么呢？总结来说大致有以下原因：

1）批量文件导入不容易被治理，约束性差；

2）批量文件导入容易导致前台系统产生数据堆积，久而久之会破坏前台的灵活性，破坏”小前台大中台“的架构体系。

四、面向主题还是面向应用

现在我们一般都说数据仓库不等于数据中台，数据集市又不能完全属于中台。其实，数仓是面向主题的，是对数据的高度汇总和抽象，基本不会体现业务属性和业务流程，仔细一想这好像跟数据中台向一线赋能的大原则相违背，所以中台肯定是还是得体现业务属性，所以把原来的数据集市拆分成两部分还是有必要。一方面把业务相关的内容拆出来形成业务域，融合进中台里面；另一方面，有数据需求的业务单元也会更加碎片化，会向前台不断靠拢。这样看来，数据中台既有面向主题的数仓，也会有面向应用的业务域。

五、始终是一个整体

中台的出现毕竟还是为了解决原来数据层面各自为战的情况，终究还是需要一个整合的统一服务输出。从这一点来说，肯定得需要一个服务管理模块，电信喜欢叫“能力开放”，外面有人喜欢就服务管理、服务调度或者服务网关。其实叫什么都好，关键是要通过他完成服务拼装和管控。

其实数据层面自成体系，最终会形成一个完整的架构体系，同时跟业务流程又有千丝万缕的联系。复杂，太复杂！