【数据中台】学习摘录-纵观数据中台

这段时间将极客时间上的网易的《数据中台实践》与《阿里的大数据之路》粗略的看了一遍（两本书写的内容涉及面非常之多，也有很多细节没有展开，但都是非常好的数据中台指南，两本内容侧重点不同，网易的更偏实践，阿里更偏理论，都适合放在案台用作工具书翻看），也将整个数据架构梳理了一遍，对数据中台有了更深层次的理解，也看清了数据中台在整个公司中的战略位置。下面我将梳理一些我所学到，理解的数据中台及实现方案。

首先，先说明结论，数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。对于庞大且繁多的业务线，构建数据中台的成本是持续的，并且构建初期效果也是甚微的，但长期来看，对公司的业务发展是有好处的。但对于业务的需求变化缓慢，且数据非海量的情况下，照搬大厂的数据中台建设体系，构建数据中台的效率提升与优化成本的优势是发挥不出来的，反而会增加企业的资源成本。

由于涉及的东西非常之多，本系列笔记摘录将挑选关键的内容，围绕着这些关键的内容进行展开，并后期应该是会不断地调整，丰富内容。

1. 做数据中台的前提

如果准备要建数据中台，首先要考虑这样几点：

1. 问问自己为什么要建中台，与业务达成一致的目标；
2. 把数据中台作为一个公司级别的顶级项目来推进，而不是一个数据部门自己的 KPI；
3. 数据中台必须要有清晰的、可量化的价值来衡量（从主观上也要得到业务部门的认可）

建立数据中台的最终目的是更好的服务于业务，让业务更好的去服务于客户。
可见立项是建数据中台最关键的一步，因为它的核心就是挖掘业务的痛点，跟业务达成一致的建设目标。如果能达成一个一致的、可量化的目标，数据中台的项目就成功了一半。

1.1 那如何挖掘业务的痛点呢？

首先通过调研业务方，这里需要重点关注两点：

1. 当前数据使用过程中存在哪些痛点；
2. 当前业务部门最关注的业绩目标。

对于一些传统企业来说，业务部门的数据思维能力比较薄弱，数据使用水平还比较初级，根本讲不出什么痛点。如果遇到这种情况，可以多关注一下业绩目标（比如，如何让数据帮助企业达成KPI）。

一般来说，公司内一般都普遍存在以下几类痛点：

1. 指标业务口径不一致
2. 需求响应速度慢
3. 取数效率低
4. 数据经常违反常识
5. 数据成本指数级增长

除了找准痛点，还需要调研各个部门的业务目标，目的就是让数据帮助解决更多的业务问题。

有了这两方面的调研之后，还需要进一步制定目标，网易该项目是从效率、质量和成本三个方面和业务部门制定共同的KPI，然后选择与之最相关的部门进行合作，共背业绩KPI。

• 模型复用比：一个模型被读取，直接产出下游模型的平均数量。
  比如一张 DWD 层表被 5 张 DWS 层表引用，这张 DWD 层表的引用系数就是 5，如果把所有 DWD 层表（有下游表的）引用系数取平均值，则为 DWD 层表平均模型引用系数，一般低于 2 比较差，3 以上相对比较好（经验值）。

这个表里包含中台建设和业务支撑两部分，前者对应的是业务痛点，后者对应的是业务目标。更为关键的是，我们都是从业务出发制订的这两部分内容，我认为这是业务愿意和中台团队达成共建 KPI 的基础。后来，在 CTO 的推动下，供应链、仓配以及市场部门把指标梳理、自助取数、数据模型迁移中台纳入了 KPI 考核。当然，对数据中台的支撑工作，这部分在业务部门的 KPI 中比例不会很高，一般最多 20%，但是却很重要，因为只有这样，业务部门才有压力去做这个事情。

1.2 推进数据中台项目落地

1. 调整团队组织架构，明确各个团队的职责。
   因为每个业务团队都有自己的数据开发，数据分析，数据产品，分析师，为了避免不必要的纠纷，数据中台数据开发的职责调整成，基于数据中台数据，加工私有的集市层和应用层。主要负责DW层公共数据，以及跨部门共享的集市层和应用层的数据建设。

2. 数据整合
   首先面对的是混乱的指标业务口径，所以要通过业务深层调研来梳理指标，建立全局的指标管理规范，去除了冗余指标，对齐口径不一致的指标。这里需要强调的是，中台团队必须要完全接管ODS层数据，这可以强迫业务部门必须要基于中台数据进行再加工。

3. 研发工具产品
   在数据中台构建过程中，积累了很多规范和经验，但数据中台如果要形成落地、长久的运行机制，就必须把这些规范和经验沉淀到产品中，通过产品化的方式实现。以下为网易的数据中台支撑技术产品的清单。
   

4. 数据产品构建
   就是业务支撑，通过构建数据产品，帮助业务达成业绩目标。

5. 螺旋式开发
   建设数据中台不是一口气就能吃成一个胖子，它的建设往往是滚雪球的方式，随着一个个应用的迁移，中台的数据也越来越丰满，发挥的价值也越来越大。