数据中台

什么是数据中台

核心本质：“数据仓库+数据服务中间件”

数据中台被誉为大数据的下一站，由阿里兴起，核心思想是数据共享。随着业务的快速发展，企业的多条业务线都产生了大量的数据，而且数据都按照不同的形式进行采集、存储、处理等。为了快速满足每个前端业务的需求，公司通常会让前台直接去联系后台，初始可能比较有效，但是随着需求越来越多、越来越频繁，沟通成本大大提高，效率大大降低。

同时，对于一个公司的多个业务来说，哪怕看起来很个性的需求，经过抽象以及合并同类项后，我们发现也可以形成共有的能力。其实，对于后台的很多功能，同样可以抽象出来，成为各业务共有的能力。这样可以让数据更灵活更敏捷地服务于前台的各项业务，这个就是数据中台的初衷。

数据中台包含了面向不同的主题域、分层的数据组织在一起，通过服务化的形式向外提供数据的一个数据共享组织。

解决的问题

其实大多还没有开始数字化转型，或者说正在数字化转型的公司应该都会有这样的问题：

1.效率

1.需求交付速度慢
随着公司发展，运营活动之前可能一周、一个月搞一次，那时候数据交付时间还勉强跟得上，现在可能一天就要搞一次，需要大量的数据来复盘运营活动，这时候研发就会越来越力不从心，最终导致数据没办法支撑业务。

2.找数据难，上万张表，不知道有哪些数据
当数据越来越多的时候，我们有哪些数据，如何找到这些数据对于公司的分析师、运营甚至数据研发来说都相当的困难。对于数据开发来说如何找到这些数据花的时间可能还不如自己重新开发一张表块，对于数据分析和运营来说，找不到这些数据自然也就谈不上分析了。

3.取数难，靠技术人员喂饭
很多公司的运营、产品甚至分析人员需要靠技术人员喂饭，提需求给技术人员，然后技术人员写sql给他们取数，最后技术通过excel的形式交付给数据需求方。。这个过程来来回回加上沟通扯皮调试慢的可能需要一周，这对于需求方来说也难以接受，对于数据研发来说也不爱做这活，大部分的时间都浪费在这种临时取数上。这样就会造成恶性循环，研发越来越累还没法专注于中台本身的建设，需求又觉得给数据慢，导致双方体验极差。

4.报表加载速度慢
很大一部分报表没办法在5秒之内打开，这样就会导致运营或分析人员体验感极差，就不想打开了，久而久之数据也就丧失了它的业务价值

2.质量

绝大多数的问题都是被数据使用方发现，投诉到部门领导。数据出现了问题，作为数据开发人员其实很难发现，基本都是被投诉过后再知道。。甚至有人直接投诉到了数据团队负责人那里，这就非常被动。

1.加工所用到的源数据入仓异常导致应用方结果异常。。。

2.数据开发的代码BUG,这个会耗费大量精力在故障定位和恢复，当数据修复好后业务应用已为时已晚。。。

3.指标口径不一致造成的数据问题

3.成本

很多时候我们大数据上线容易下线难，上线了一张表后，这张表就会不停的加工产出，但是有多少人再用却没多少人关注，这就会造成线上资源的浪费。很大一部分比例的表都超过了一个月没人访问过，白白浪费了计算资源和存储空间。

为什么出现这些问题

1.烟囱式开发

从接到需求开始，数据开发人员直接从原始数据往上怼，直接深度加工产出表，直接就对外提供服务了。。这样最明显的缺陷就是数据没办法被复用，比方说某位开发人员开发了一个任务，但这个任务的数据清洗部分，或者说一些数据加工链路跟另一个任务都是相同的，本来第一个人开发了中间表，第二个任务有相同计算逻辑部分直接复用这张表是最好的，现在要开发两遍。。所以人力成本就直接浪费一倍

2.数据管理能力确失

数据这种粗放的使用，谁访问了哪张表一概不知。比方说要下线一张表，但这张表谁访问都不知道，所以就不敢下线，一旦下线都不知道谁受到影响。。

3.使用门槛高，对非技术人员不友好

我们提供写sql的平台，但运营、产品或业务写sql能力欠缺，写出来的代码参差不齐八层嵌套导致资源浪费。

4.缺少全链路数据质量监控

大数据的数据加工链路其实非常长，一个任务它的上游节点有可能有几十个甚至上百个，当某个节点出了问题，它的下游节点就会全都出问题，逐层往上排查的过程本身就会花费很长时间，尤其是这个节点比较靠上游的时候。所以数据故障定位花费很长时间，数据恢复又花费了更长时间，加起来甚至花费大半天，这对数据使用方就完全没办法接受，本来他们要基于数据工作，结果半天后才数据跑出来。。

5.成本粗放式管理

很多时候我们太过专注挖掘数据价值，往往忽略了数据成本的管理，导致没用的报表、应用数据等每天都在花费大量的钱进行加工生产，然而下游却根本没人用，所以就导致线上资源大量的浪费。

怎样建设

方法论

其实阿里已经提供了一套比较成熟的中台建设方法论，核心是oneDate，下面又细分了OneService,OneModel,OneId.

oneDate

1.主题域管理模式

2.命名规范定义
最差表名也之少包括分层信息、主题域信息及更新模式（全量快照表还是增量表）吧

3.指标一致

4.数据模型复用
讲究数据只加工一次，确保数据模型的高复用性，可以增加一个模型引用系数的指标来计算当前数据模型有多少被下游表直接引用的，系数越高代表模型设计的复用性越高。

5.数据完善
从业务过程的角度来讲，数据的覆盖范围是完整的；从分层的角度来讲，我们其实有很多数据是直接从原始层深度加工到应用层或者数据集市层，这就代表明细层和轻度汇总层的数据是很不完善的，可以引入一个跨层引用率的指标，用来表示数仓分层的完善度，如果跨层引用率比较高，就表示数仓分层完善度比较差。

oneService

1.全链路打通
一般情况数据链路没有打通会存在以下几个问题：
1）数据接入效率比较低，我们在数据交付的时候一般情况是数仓工程师先把数据加工好，然后应用开发再把数据导出到db或者其他hbase等，然后再上面开发服务端的接口来访问，对于不同的查询引擎就需要查询不同的接口，尤其是保存了多套接口的时候，对于应用的接入效率很低。
2）接入以后速度暂且不说，管理的效率也低，数据被谁访问也不知道，这就导致我们不知道数据有问题会影响到谁，当要下线这张表的时候也找不到谁在用。
所以要将数据中台到数据应用的链路打通，做到全链路的故障定位分析及应用数据的回溯。

2.数据网关
3.屏蔽异构数据源

4.逻辑模型
做到接口的复用，需要做类似于数据库视图这样的逻辑表，根据不同应用的需要构建许多逻辑表，保证不同的应用看到的指标不同，但逻辑表下又是同一个物理表。

支撑技术

指标系统：主要管理指标的业务口径、可分析维度、计算逻辑、数据来源等。指标作为数据需求开发的起点，把指标定义规范了就会建设后期数据结果不一致的问题。

数据质量：格式校验、非空非零校验、dt分区内数据量校验、一致性校验等。

数据地图：构建企业数据资产目录，帮助数据使用者快速发现数据并准确理解数据的含义。包含数据字典、数据血缘、数据特征相关信息（如数据量，访问热度，分区信息等）等

数仓建模：秉持先设计后开发，指标口径确定后先进行模型与指标的关联，然后在走离线或者实时完成数据的加工。

成本控制：一个月或者多少时间内没人访问的表下线等。