数据中台设计方法论

数据中台建设方针：横向规划，各个击破。

横向规划即在数据中台规划初期，需要打通企业各个业务系，打破数据孤岛现象。其实就是我们建设数据仓库的阶段。比如电信业务，我们要把客户、账务、客服、营销等业务板块打通数据，全盘考虑，融通数据形成数据资产。

数据中台建设过程中涉及到大数据平台建设、数据仓库建设、模型算法、数据治理、数据服务等一系列工程，不可能一蹴而就，我们需要梳理业务场景，看他们需要什么样的服务先找一个业务场景，搭建起数据中台的服务能力，然后依次迭代，各个击破。

一、总体规划

image

数据集成

首先我们需要确认平台接入哪些数据，确认数据接入的方式是实时接入还是离线抽取。离线抽取的话是全量抽取还是增量抽取。抽取频次数每天抽取还是每小时抽取。

实时接入可以使用kafka实时写入数据到HDFS集群上。

image

离线数据可以使用Sqoop抽取关系型数据库到HDFS。

image

模型建设

模型建设是数据中台的重要部分，可以说数据中台的成败在于模型建设的好坏。模型分为我们常指的数据仓库的分析模型和我们的一些通用算法模型。

分析模型

数据接入到数据仓库中，我们需要对数据进行加工，按照我们规划的业务域，对各个业务的数据汇总聚合，形成我们的数据模型。

这其中涉及到数据仓库建设，在这简单说下。

image

这是一个简单的数据分层结构。原始数据ODS，经过清洗成为数仓中的明细数据DWS和维度数据DIM，各个业务的明细数据按照业务域和维度数据关联形成我们的数据模型DW，不同的DW经过聚合形成各个业务指标数据APP层。

image

在数仓的建设中我们声明业务粒度，粒度能够精确的表明业务含义。同时还要确定维度，是用户维度还是商品维度等，最终形成我们的主数据，也就是模型数据的基础。

算法模型

image

我们在业务开发过程中会形成一些通用的算法，可以是封装好的随机森林、回归等通用算法，也可以是我们业务算法，比如用户商品推荐算法等。通过把这些算法总结，形成我们的算法模型，供各个业务直接调用。

ETL平台

在开发数据模型时，我们必须有一个统一的平台，能够像流水线一样，把数据一步步加工成数据模型。这其中涉及到数据萃取、数据聚合、作业调度等。

image

与业务研发不同，数据研发一般很少写详细的需求涉及文档，通常就是和业务人员简单的沟通，但是慢慢的你会发现开发完的任务会一改再改。为了避免此种现象，我们可以根据自己的实际业务整理一份需求模板。其中包括数据来源字段，数据口径，任务调度周期，字段mapping。

数据资产

通俗的来说，我们在数仓中开发的模型就是数据资产，数据资产需要规范的管控和治理。

资产管理最基础的工作是做好元数据的管理，元数据包含了数据的口径，数据模型的释义，模型之间的血缘等等，详细的可以看之前的元数据文章《数据仓库元数据》。将元数据和数据模型统一有序的管理起来形成企业的数据资产。

数据资产治理不是在事后管控的，在我们建设模型的过程中需要形成一套自己的数仓开发规范进行管理。

数据服务

俗话说，酒香也怕巷子深。我们做好数据资产后，要推销我们的资产，为更多部门使用，这也是数据中台建设的初衷。因此提供一套数据服务能力，对外统一对接是一件很重要的工作。

image

数据服务标准：数据结构标准化、在线查询实时化、数据开发可视化。

数据结构标准化

针对数据交互，我们需要提供统一的接口视图，可进行数据的查询、权限管控。

在线查询实时化

针对各业务的调用，我们需要提供指标级数据口径统一的实时数据结果。

数据开发可视化

提供数据接口的可视化统一管理页面，开发人员通过通过可视化管理API，降低接口理解的难度，易于维护。

讨论

关于数据中台的建设，最初是阿里提出来的，但是这之前，很多企业其实已经有了类似的想法，也实施了部分。对于大型集团企业，中台方法论很实用。打破了集团各版块的数据孤岛，形成了统一的数据服务能力。但是慢慢的很多人提出了，对于中小企业，中台方法论是不是太繁琐了，对于他们来说是负担，中小企业需要的也许是更快捷的迭代形式的数据服务。

那么关于中台建设，你怎么看呢？你的企业会选择中台吗？

欢迎关注公众号：数据社

image