数据中台建设方法论-4 实践

讲完基本一些理论内容，下面可以讲一下实践过程的一些经验，下面以实施实现过程中，讲一下实践过程中一些难点

业务调研

数据中台并非一上来就咔咔咔按照理论开始搭建，这样十有八九后面要么返工要么做不下去。数据中台很多技术和架构包括采集、计算、存储等比较成熟，但是建设数据中台最难的是建设一个适应你当下企业的数据中台。其实在业务调研之前肯定有一个立项，公司不可能没有一个立项（就是讨论为什么要建设一个数据中台）的过程。这里面一般都会把目前公司状况以及建设带来的价值都讨论得很清楚，而业务调研是需要细化到更加精确的实施步骤，下面是业务调研需要了解的东西：
1）业务和数据相关

• 业务域：企业目前包括的业务以及之间的关系
• 数据域：就是将业务域转换为实体，这里是要理清楚3个One中的OneID、OnModel
• 关键业务流程
• 关键指标

2）组织架构

• 哪些部门掌握哪些数据（业务）
• 哪些部门需要哪些数据
• 现有部门是否已经有团队建立他们自身使用的数据中心
• 现有业务部门是否存在数据分析团队
• 可操作的人员数量HC

3）目标

• 如何拆分目标
• 需要里程碑是什么（1个月内有什么效果或者半年有什么效果）
• 最终希望的目标是如何

技术选型

我们能知道现在有很多开源软件及付费软件可供参考或者直接使用，那么我们在实践中的技术选型应该注意哪些。在上一步的业务调用中理清楚目标、人员后，我们才能更好的做技术选型。技术选型无外乎3种：
1）直接使用成熟产品；
2）自研
3）成熟或半成熟产品改造
这三种的优缺点就不必累诉了，现在说是数据中台中一些实践的经验，在上一篇中，我们将数据中台分为5个子系统或者5个子平台，其中除了数据流水线平台外，都是比较独立的，而数据流水线更像是将其几个平台串联起来。下面按照这些平台给出一些建议：
1）基础能力平台：这部分包括存储、计算、基础组件等，建议选择开源的平台或者已有的付费云产品，因为该平台如果打造需要耗费很大人力物力。
2）集成开发平台：这个里面包括数据采集、数据计算等模块，还蕴含流程管理，在这里市面上有很多开源的组件，但是他们并没有集成一个很好的可视化可拖拽的平台，比如airflow是工作流开发调度工具、Atlas是数据治理服务、Griffin是数据质量管理等等，可以考虑利用各个组件组装成一个可视化可拖拽的平台，屏蔽底下的组件差异。
3）资产运营平台：这部分主要是数据探查、元数据、主数据、数据服务管理等等，该部分更多是定制化开发，所以建议可以自研，当然有现成的开源或者产品也可以基于该基础改造
4）门户平台：数据应用无外乎提供数据服务API、BI报表、机器学习模型等，大致可分为描述性分析、诊断性分析、预测性分析、个性化分析、决策性分析。在这一方面数据提供的服务或者应用往往定制化。

• 对于特别定制的功能可直接使用数据API开发
• 对于BI报表，可使用开源如superset或者付费如帆软等

5）数据流水线平台：数据流水线更像是将其几个平台串联起来，提供一个高效率的DataOps实现。所以这部分建议自研。

数据汇聚

数据汇聚也是实践过程中很关键也很艰难的过程，有人认为不就是把数据拉过来嘛，有何困难，其实困难不在于拉数据过来，而是拉什么数据，拉的数据全不全？
1）数据收集策略：一定要与业务相结合，实践过程中无论是有固定模型或者从小处着手，一定要理清楚数据与业务的关系，哪些指标使用到哪些数据
2）数据采集策略：全量和增量相互配合，适当时候制定触发型采集，适当的数据冗余。
3）流水线配置：一定要管理好采集的流水线，比如按照源数据划分、按照域划分等等，保证后续溯源等不会出现混乱。
4）数据校验：可适当放宽数据校验规则，但是必要的数据校验还是需要统一。

模型建设

在第二篇的业务难点中讲到一个数据规范，其中有OneModel，就是统一一个模型。任何数据中台建设到最后一定有一个适合于这个行业及这个企业的数据模型，越是成熟的行业如金融、工业、医疗等，都会一些国家或国际标准模型。一般情况我们做模型建设有2种不同方法
1）是一个成熟的行业，有现成模型，可以直接使用并加以改造，因为统一模型肯定无法符合特殊要求
2）如果是一个未知领域，那么可以以小处开始，比如某些关键指标开始建设，之后不断迭代为一个成熟模型

数据质量

我们都知道数据质量关乎到数据中台的信誉，一旦数据质量出现问题，就会导致指标不准确，指标不准确就会导致决策失误，因此在数据中台运营过程中，数据质量是数据治理中一个持久而关键的问题。
一般建设过程中要把握几点
1）制定普遍的质量规则，包括非空、一致、格式等等
2）制定包含业务的质量规则，比如年龄一定是0~120岁，包含行业常识的规则
3）深层次业务规则，比如参照医疗专业比对诊断与用药规则
4）规则需要有一个规则库，在不同层次和不同业务的清洗工程中，可以使用不同的规则
5）可以使用如drools规则引擎定制
6）规则维护和使用需要一套规范，列入到运营制度中，作为长期任务来完成

快速体现价值

数据中台的建设其实需要一个漫长过程，很多时候需要比较久的建设后才能初见成果，但是现实往往就是等不了那么长。老板等不了，业务部门也等不了，就因为这等不了的过程中项目终止了。那么以下是一些可以既给自己留时间也能体现出价值的实践经验。
1）关键指标，关键流程梳理，并优先实现这些价值。在制定里程碑时，切勿由基础开始，而是又实际业务开始。在实现过程中慢慢完成基础建设。比如如果模型一开始无法确定，可以先数据采集，可以优先采集关键指标数据，实现关键指标，再慢慢梳理整体模型后将原先整合到模型中。
2）业务目标中实现基础建设，在某些业务目标中插入基础建设目标才能让业务和领导看到真正效果。比如完成某个核心系统数据采集、指标展现和数字化，这个过程同时建设数据采集、数据存储等基础建设
3）重视业务反馈，但同时也要筛选反馈。业务的某些反馈说明我们建设过程中可能某些地方出错，这样可以让我们少走弯路；但是用户需求永远都是没完没了的，因此需要区分重要性及紧急性。

部门协作

在组织架构中，我们已经说过数据中台并非你一个数据部门就可以完成的，期间需要业务部门、研发部门等多部门协作。虽说最终目标是让数据产生价值，让数据发现问题。但是往往一开始时，能够更快的体现真正价值的重要产出是业务部门给出来的需求或者业务部门对市场的一些洞察、对公司一些管理预见。至于在数据中挖掘更多原先没有发现的价值，都是在平台建设很成熟之后才会慢慢体现，而这个过程中前期更需要业务部门、研发部门来投入参与，因此实施过程中需要重视部门之间协作。
1）业务部门需求和业务数据需要一把手统一口径
2）倾听其它部门的需求，优先解决关键问题
3）多联合多部门沟通，因为原先各个业务之间可能不知道对方的内容，可通过沟通发现原先一些价值数据并未被使用