数据中台的产生原因及概述

中台概念来源于阿里(提出"大中台,小前台"的概念)，其产生的核心思想是“共享”和“复用”。

产生原因

随着企业业务的不断发展，公司内部积累了大量的业务数据，而企业缺乏治理这些数据资产的有效手段。

由于企业的业务系统众多，数据存储分散，大量的业务数据都分散在各个部门中，部门间信息不互通，数据不共享，仅仅在有业务需求的场景中才会产生部分的数据共享，难以对全局的数据实现挖掘分析。企业掌握的大量数据难以实现其真正的价值，在如今的大数据时代，各个业务部门的数据应当打通并结合外部数据实现整体的市场分析。

1、传统数仓的开发效率较低

在企业开发传统数仓的初期，由于项目经验匮乏，业务需求不稳定，项目变化较频繁，数据仓库的建设往往缺乏统一的规范要求，良好的主题域和分层的设计，烟囱式的开发较为主流，导致很多企业以往的业务系统是条块化建设的。以前期的淘宝和淘宝商城（天猫前身）为例，他们各自都有货源体系，但因条块化建设，阿里巴巴难以看到自己的数据全貌，也无法将数据打通，导致数据的利用效率极为低下。

在数据规模上升后，业务的复杂度也会上升一个台阶，企业内部各个部门间业务需求会有一定的重叠，由于业务数据的不互通，可能会导致多个部门间利用相同的数据，做相似的指标开发！大量的重复开发不仅浪费成本，还制约了效率的提升。

在传统数仓开发下，企业的数据共享也是一个难题，在以往的烟囱开发模式的制约下，部门间的表命名的规范可能不互通，此外，在部门协调过程中，开发表和使用表的人不一定会是同一人，面对上万张表，上百个字段，理解表含义，疏通表关系也不是一件容易的事情。如果没有一个好的数据管理系统，表开发者很有可能每天被多人打断工作去回答一些重复性的问题。每个表开发人员相当于一个知识库，新人或其他业务系统的人理解这些业务也会付出极大的精力。

2、数据规范不统一

首先是数据的复用性不高，在传统的数据孤岛的模式下，部门A和部门B各自维护一套数据仓库，对于有一定重复性的数据，他们可能会做重复的清洗，如果一张原始表被多个部门以相同的手法清洗，在明细表层面就会产生多个相同的表，抽取压力、维护难度及数据一致性要求都很高。

各个部门对于指标的定义也不一定相同，在数据开发过程中，也许会遇到，两个相同的指标，指标含义一致、数据来源一致，但是结果不一致，很有可能就是对于指标的理解不同导致的。

3、成本较高

大数据平台的业务数据量往往比较大，各个部门间数据不通还会导致存储浪费、数据重复加工、计算资源大量占用。以阿里巴巴为例，阿里巴巴在没使用数据中台之前，预估5年内服务器需求量会达到现有服务器量的100倍，而在发展数据中台后，需求下降了90%。

数据中台概述

有人可能会产生疑问，以上传统数仓的缺点就是因为数据孤岛现象严重，那么只要打通这些数据，做一个统一规范的数据仓库就好了，为什么还要做数据中台呢？

因为数据中台构建了一个完整的数据生态链，提供的也不仅仅只是一个数仓。

数据中台是一种思想，一种概念，连接了前台与后台，为前台提供支持，为后台分担压力。数据中台提供了数据集成、数据存储、数据计算、数据治理、数据服务等一系列功能。数据中台最早由阿里巴巴提出，是为了应对部门内繁多的业务需求以及高时效性而建立的。数据中台要求既要满足日常使用，还要满足双十一之类的高并发场景的业务处理。

在数据中台中，首先要实现数据资产化，以阿里云为例，阿里云三大体系保证了数据资产化顺利进行：

One Model：设计、开发、部署和使用上保障了数据口径的规范和统一，实现数据资产全链路管理，提供标准数据输出。譬如，针对UV这一相同的指标，在统一之前阿里内部竟然有10多种数据定义。据介绍，One Data数据公共层总共对30000多个数据指标进行了口径的规范和统一，梳理后缩减为3000余个。

One ID：打通了用户账号，可以在多终端识别同一用户。

One Service：统一的数据服务中间件，实现对外的数据服务。

统一数据中心中间件

在数据资产化过程中，阿里构建了一个统一数据中心中间件，用于建立一个系统化的数据资产，由以下三个节点构建成集团的公共数据中心。

垂直数据中心：负责从阿里旗下各个业务单元采集数据

公共数据中心：类似数据仓库，将所有数据按不同主题域（电商、文娱、营销、物流、金融等）分类管理

萃取数据中心：按照业务需求，将各主题域数据加工处理，建立起消费者、企业、内容、商品、位置五大数据体系

数据平台的架构

一个经典的数据平台应该是一整套对数据处理的方案，主导数据的采集直到数据的提供。

传统的数仓能做的只有产生每日的报表，作用偏向于为领导提供决策。而数据中台可以提供更多的服务，例如营销推荐、用户画像、风险评估等。

在传统数仓应用时，因为业务变更较快、部门业务不互通，每次出现新业务，都要在底层新建一个业务模型。而使用数据平台后，由于数据是已经分类整理好的，数据分析工作也已经在数据中台中做好了，我们不用重新建模，只要调用数据中台中已有的模型即可，一个模型可以被多个业务部门共享。

一个经典的数据中台的架构应该包含以下几个部分，数据中台对用户屏蔽掉了杂乱的数据来源，用户在使用数据中台时，只需要调用数据服务模块提供的API即可。经典的数据中台的架构分为五大部分：

数据采集：提供统一的数据获取接入方式，数据来源包括内部数据和外部数据，数据类型应支持结构化和非结构化数据采集。

数据存储：可以使用多种数据库混搭存储，当然，HDFS分布式文件系统是最常见的。

数据计算：一般传统的大数据平台已经具备数据计算能力，数据中台直接移植即可，包含离线计算（MapReduce、Spark）、实时流式处理（如Storm、Samza、Spark Streaming、Flink）等。基于大数据对机器学习算法模型的训练工具（如Mahout、Spark MLib、Caffe、Keras、TensorFlow）也可以归为数据计算工具的类别。

数据治理：对于数据资产管理，有以下几个方面

​ 数据标准管理：对公共术语、参考数据、数据编码、指标口径等制定和实施标准化。

​ 数据模型管理：对系统中核心的逻辑模型、物理模型、数据库表、字段、视图等进行统一管控、促进其规范化。

​ 元数据管理：管理所有业务系统元数据。

​ 数据质量管理：包括数据探查、对比、质量监控、SQL扫描和智能报警等。

​ 数据安全管理：设定数据的访问权限。

数据服务：可以使用SAAS方式直接对外提供服务，也可以以更小粒度如API、消息接口、文件接口、服务接口、SDK软件包等方式只提供组件能力或数据服务。