建设中台：难点是技术问题？不！其实是认知问题
前言
随着企业的快速发展，在规模不断扩大的同时业务逐渐变的多元化，有更多的业务数据产生，为企业进一步实现业务数据化和数据业务化提供了更多的可能性。但是，由于各种历史原因，导致企业数据烟囱林立，数据理解、认知以及分析断层，缺数据、缺标准、缺治理，知数据难、懂数据难、要数据难，需要如何规避系统的重复建设，让系统复用的同时快速支持多元化前台业务的迭代更新、灵活创新是企业数字化转型过程当中必然会面临的问题与困境。
为了，进一步和大家一起认识到中台的本质，统一认知偏差，本篇按照顺序介绍如下：
中台建设之前需要知道的事情中台建设的方法论中台建设的内容
01
中台建设之前需要知道的事情
最近外面已经各种关于中台的文章，真可谓是百家争鸣，有的人说了建设中台的各种概念，有的人说了建设中台的坑与雷，有的人说了建设中台的方法，但是却对于建设中台问题的本质总是避而不谈。
遇到从没有真正落地实践过的人，已经要跳出来做行业的布道者、先行者，真的是打字不用负责任的年代，这种行为是撸羊毛还是收智商税，亦或是其他一些什么东西，想必稍微有点辨别事物真伪的人，都知道在干什么。
中台的本质其实很简单，总结成一句话就是：通过资源集中化的方式汇聚整个企业的运营数据能力，产品技术能力，快速的支撑各前台业务迭代更新。
那么，如果企业想建设中台，需要通过什么样的方式来判断和评估，适不适合建设中台呢？
个人经验，可以从以下几个方面来进行判断与评估
1.1.明确建设中台的目标与意义是什么
中台是以场景化业务驱动为中心，具有可服用能力的有机组合。目标是为了能够快速的赋能业务，进行落地实施、改造、试错、转型；意义是为了快速提升组织之间的效率，最终，达到降本增效。
为什么说要明确建设中台的目标与意义呢？
毕竟，认知这个东西真的很可怕，很多人认为企业建设中台就是蛋糕的重新分配，其实不然。毕竟，任何事物的存在必然有它存在的道理和原因，己所不欲，勿施于人道理，想必大家都懂。
企业在建设中台之前如果不统一人员认知的话，必然在中台的建设过程中就会四面碰壁，各种扯皮、推诿，面临多方面的阻碍，陷入一个被动的局面。
个人经验，需要做好两个方面，一方面，是职责边界的划分问题，需要明确知道那些东西该中台来做，那些不该中台来做，需要业务部门自己去做；另一方面，更多的是涉及到沟通的艺术和做事情的方式方法。
1.2.是否具备建设中台的条件与时机
1、战略分析
企业需要从公司整体的战略布局、核心竞争力、战术方法、业务方向等维度来，明确的知道自己的优劣势综合判断，现阶段做与不做中台对于企业未来发展的利弊都有哪些，对于未来业务影响到底有多大，从而进一步明确企业建立中台的目标是真的想赋能业务，做到真正的降本增效，还只是单纯的想对外秀肌肉
2、业务调研
只有深入业务，明确业务单元后，梳理出业务价值链条后，拆解各个业务系统的情况，才能评估出业务是否有值得中台化的场景，同时也能明白就算通过组件化、模块化、标准化、解耦等方式来拆分系统和业务，再基于数据服务化的方式就真的能快速支撑前台业务的迭代更新，从而不断的沉淀能力，做到服务和体验都统一升级吗？
3、数据调研
基于业务统计出数据来源，确定数据资源分类，做好数据评估，确定当前数据容量，结合业务运行频度，数据产生效率，预测数据成长规模。
因为，建设中台是在全域级数据汇集之后，做数据清洗、数据治理、数据资产管理等工作之前，所以，需要对数据使用情况进行盘点，为后续中台建设过程中数据流动和使用机制提供有力依据。
4、技术调研
通过技术现状调研，可以提前了解技术落地情况、人员技术情况，做好建设中台的技术人员准备，提前规避风险
5、组织分析
通过高层访谈、组织架构分析，明确企业中台的目标与意义，同时调研分析各个事业部对建设中台的看法，为后续中台的沟通落地、推广做好前期准备
1.3.中台的用户和客户是谁
中台的用户和客户其实主要就是企业所有事业部、业务线的人，只有先把对内的赋能做好了，或许才有机会对外赋能。与此同时，企业需要把握好短期利益与长期利益的博弈和厮杀，中台需要与各个事业部、业务线定义好职责边界。
为什么说要定义好职责边界？
就目前而言，任何企业确定要启动中台战略，一定会涉及组织、业务、技术等多方面的架构调整，也一定会出现短期的矛盾与冲突。企业的组织架构调整，是一个相对敏感的话题，毕竟，只要组织架构调整后，一定会牵扯到利益关系。这种矛盾和对立关系，需要如何平衡好，稍有不慎，就带来很多不必要的麻烦。
所以说，企业建设中台需要有自己的主赛道，做到兼听则明，偏信则暗，才能真正意义上建设好中台。
1.4.中台每个阶段的效果如何来验证
中台每个阶段的效果如何来验证呢？需要如何评价企业中台建设的效果，验证每个阶段是否达到企业建设中台的预期目标呢？
任何一个产品都存在生命周期，中台的建设也是一样，在不同的阶段产品侧、研发侧、运营侧所运用的策略，评估的方法也不尽相同。
对于数据中台来讲，更多的是如何助力提升运营、研发效率，快速的将数据的价值挖掘出来，并缩短周期；对业务中台来讲，更多的是基于数据的表现力来判断，如基于现在建设的中台是否真的能快速的减轻前台的负担，提高前台响应速度。
小结
个人建议，千万不要盲目的跟风去启动中台战略，看到别人家做了中台就也要做，一定要三思而后行，从多个角度去衡量去思考，毕竟各家企业在很多方面都存在较大的差异化，盲目去做，到最后会变成事与愿违、弄巧成拙，那就尴尬了。
企业是否建设中台跟公司大小、数据量大小、业务线多少其实没有多大关系，关键取决于公司业务是否需要快速扩张以及数据使用的方式；其次，希望大家明白，中台不是一个产品，是一个战略和体系，是以数据驱动业务发展为主，让『一切业务数据化，一切数据业务化』。
02
中台建设的方法论
在搞清楚企业到底要不要建设中台之后，大家一定会问，对于中台的建设到底应该如何落地呢？有没有一些行业落地的经验和方法，可以参考呢？
答应一定是有的。任何事物的发展变化都是有规律可循的，中台的建设也是一样。虽然，各家企业存在一些差异化，但是建设中台的思想和方法都是相通的。
下面就和大家一起来探讨下，建设中台的一些方法和步骤。
2.1.业务中台方法论
在前面的文章中，提到过业务中台是为了沉淀业务通用服务能力，以服务化形式提供公共业务组件，为企业快速变化的场景化业务应用提供专业、稳定、高效、安全的共享服务，提升前端应用开发效率，快速响应实现创新需求，实现业务创新、数据共享和业务能力协同。
说的简单通俗一点，业务中台更多是建设通用的公共基础业务和通用服务。例如，用户中心、账户中心、会员中心、服务中心、交易中心等。
那么，我们需要通过什么样的方法和步骤去评估出业务中哪些功能点适合做中台化呢？
1、业务抽象
明确中台建设目标及与意义之后，可以从以下几个方面对业务进行抽象处理
【需求分析】由于企业建设中台的需求多数来源于公司高层领导的一句话，需求很难明确具体，只能从企业建设中台的目标与愿景出发，进行拆解和分析
这样做的目的，一方面，是为了知道参与企业建设中台工作当中的个体和组织有哪些人，他们的关注点和担心点是什么；另外一方面，是为了明确在企业建设中台过程中，量化好建设中台的价值，知道企业高层领导的期望是什么，知道每个阶段中台能给业务解决什么问题，带来什么价值，实现什么目标。
【竞品分析】通过竞品分析，取其精华去其糟粕，加深行业对于中台的理解和认知。目前各家企业主要都是看阿里巴巴建设中台的落地经验，然后，进行合理借鉴和参考
只有通过竞品不断的学习，加深自己对于中台的理解和认知，才能真正找到可借鉴的地方，从而节约试错成本
【功能分析】体验各个业务线的产品，从产品的交互流程、业务规模、服务方式、性能要求等维度来了解各个业务线的产品现状，才能找到各个业务存在的问题，从而，提取出各个产品的共性需求
【业务分析】从业务流程、业务对象、业务规则、业务价值四个维度出发逐个拆解各个业务模块
【用户分析】贴近产品的用户，做用户分析和调研，明确各个产品业务线的用户是谁、用户的使用场景是什么以及用户需要是什么
只有基于需求分析、竞品分析、功能分析、业务分析、用户分析五大维度进行分析，才能找到真正的找到适合做中台化的场景需求。
2、方案设计
通过基于企业建设中台的目标与意义，通过需求调研和业务分析，找到适合做中台化的场景需求之后，需求才能正式开始进行业务设计和架构设计。
业务设计目的，一方面是明确产品的模式，与多个业务方达成一致，从业务流程、产品原型、业务规则三个方面做好功能规划，知道做这个需求的目的是什么，能为前台业务提供什么能力，解决什么问题；另外一方面，需要做好风险评估，预估上线后的切换成本有多高，制定出应对措施与机制
架构设计目的，一方面是梳理业务落地，解决业务功能系统的复杂度带来的问题；另外一方面是确定与上下游系统的依赖关系，为建立统一的标准化做准备
个人经验，只有做好详尽的需求调研与分析，定义好职责边界，了解各个业务合作团队的工作环境和系统业务逻辑之后，进行多轮的需要评审，才有可能做好业务设计和架构设计。在必要的时候，需要进行制定人员轮岗的方案和机制，只有这样才能知道各个业务线目前的痛点是什么、诉求是什么。
3、方案落地
对于大多数企业建设中台都是一个样，瞎子过河，不知深浅。在摸索的过程当中都会遇到各种坑与雷，真可谓如人饮水，冷暖自知。
在中台项目推进的过程当中，由于业务的错综复杂，人员的认知不统一，需要如何进行有效的沟通与推进，真的是极度考验智商和情商的一个过程。
如果，稍有不慎，没有处理好各个业务方人员之间的利益和关系，真的会一着不慎，满盘皆输。
那么，在方案落地过程中，需要如何做好项目管理和项目推进呢？
在方案落地开始之前，需要做好项目启动会和产品启动会，必要时候需要和各个业务方建立合伙机制共同推进，这样做的目的一方面是为了统一认知，达成目标一致，确保项目能够顺利的进行；另外一方面，是确定上下游部门的排期、制定协同机制；
在方案落地过程当中，需要随时沟通项目的进度，可以通过日报、周报、月报等方式，让各个业务方及时的知道和明确目前项目的进展情况和风险，及时发现问题，处理问题；
在方案落地执行之后，及时进行项目复盘，分析原因，及时调整优化迭代方案，提前规避风险。
4、上线运营
企业建设中台是一个长期的过程，在不同阶段所使用的运营策略不尽相同，中台部门需要自己把握好中台产品的发展节奏，才能真正意义上做好中台相关的运营工作
2.2.数据中台方法论
数据中台概念最早于2015年年底被阿里巴巴首次提出，是一个承接技术，引领业务，构建规范定义的、全域级可连接萃取的、智慧的数据处理平台，建设目标是为了高效满足前台数据分析和应用的需求。
数据中台，主要涵盖了数据资产、数据治理、数据模型、垂直数据中心、全域数据中心、萃取数据中心、数据服务等多个层次的体系化建设方法。
数据中台具有数据获取与存储、数据计算与处理、数据共享与协作、数据应用与价值探索以及数据服务与服务运用等全链路一站式数据服务的能力，紧密贴合业务，探索业务场景中的价值，助力企业数字化、智能化转型。
额，看到这么一大堆专业术语的名词解释，想必大家和我一样，真想反问一句“sorry，I don't understand what you're saying”。
那么，数据中台到底是什么？
说的简单通俗一点，数据中台是全域级、可复用的数据资产中心与数据能力中心，可以提供干净、透明、智慧的数据资产与高效、易用的数据能力，使得业务能够数字化运营。
数据中台主要负责大数据统计分析相关的DaaS和PaaS相关基础能力的服务建设。
就目前而言，市面上数据中台的方法论也是集百家之长，最典型的代表莫过于阿里巴巴数据中台建设的方法论。
无论是阿里数据中台的建设方法论还是其他企业建设数据中台的方法论，其最核心的思想都来自于数据仓库领域关于数据仓库规划实施和指标体系建设的方法。
稍微知道，数据仓库发展史的人都应该清楚，在数据仓库领域中一直存在两套截然不同的方法和体系在相互暗自较劲。一个是数据仓库之父Bill Inmon所倡导的至上而下的方法，另一个是Ralph Kimball大师所倡导的至下而上的方法。
对于数据仓库体系结构的最佳问题，其实始终存在很多不同的看法，甚至有人把Ralph Kimball和Bill Inmon之争称之为数据仓库界的“宗教战争”，至于谁好谁坏，只能说一千个人眼中就有一千个哈姆雷特，在这里就不做过多的深究，只能说适合的是相对较好的。
阿里数据中台的建设主要遵循三个One的概念：One Data, One ID, One Service，从中可以看出数据中台不仅仅是汇聚企业各种数据，而且让这些数据遵循相同的标准和口径，对事物的标识能统一或者相互关联，并且提供统一的数据服务接口；其中One Data，核心CDM层采用的是多维模型，主要选择了以Kimball维度建模为核心理念的模型方法论，同时在指标设计的方法论基于Kimball方法中的粒度建模的方法，进行了一定的升级和扩展，构建了阿里集团的数据架构体系。
那么，我们需要通过什么样的方法和步骤去建设好数据中台，才能融合汇集整个企业的数据，打通数据之间的隔阂，消除数据之间的不一致性呢？
在规划做数据中台架构设计之前，要明确需求是什么，知道要接入什么数据到数据中台中来，再根据数据接入的实际情况，进行技术选型，合理评估计算和存储资源的配置。
数据中台的愿景是接入全域级的数据。但是，笔者经常会反问自己，数据中台真的需要全域级的数据吗？
想必大家脱口而出的答案一定会是，需要。
刚开始，和大家的想法也是一样的，但是在真正落地开始建设数据中台之后，才翻然醒悟。其实在没有找到场景化的需求之前，给中台再多数据其实都是徒劳。静态的数据价值永远没有流动数据的价值大，没有基于业务真正的使用起来的数据，价值为零。
所以，建设数据中台需要以场景化需求为中心，做好业务调研和需求调研，然后以数据多样性的全域思想为指导，采集与引入全业务、多终端、多形态的数据才是相对合理的。
个人经验，数据中台的建设主要包括数据资产、数据治理、数据模型、数据服务四个部分。
1、数据资产
数据即资源的概念，伴随着大数据时代的发展逐渐深入人心。企业都希望通过数据交换共享和数据服务应用的方式，不断积淀的数据后发挥它的价值。
但是事实上，若没有通过恰当有效的管理方法和手段，数据可能会变成企业的负资产。因为，企业只有对数据怀有敬畏之心的认知，才可能发挥出数据背后所隐藏的价值，要不然反而会被数据所害。
基于数据资产管理白皮书看来，主要从数据标准管理、数据模型管理、元数据管理、主数据管理、数据质量管理、数据安全管理、数据价值管理以及数据共享管理等方面来做好数据资产管理。
但是，在实际企业做数据资产管理落地的情况之下，不会完全按照这个所谓的行业标准的，这个行业标准太理想化。现实情况是各家公司的情况和历史原因都不一样，所以不会完全按照这个标准来，更多的会是各种差异化的做法。
因为，任何的数据资产管理做到最后都会变成数据治理。
2、数据治理
说到数据治理，想必身边很多数据仓库的研发小伙伴天天自嘲说自己就是个提数工程师，每天的工作就是帮业务提取数据、核对各种指标。时间长了，小伙伴们对自己的工作设定，开始怀疑人生，就更不用说业务人员对于系统数据的准确性、一致性极度不信任了，导致这些问题的根本是数据质量问题与指标口径的原因。
数据治理是王婆娘的裹脚布，也是政治斗争的绞肉机。治理与管理永远是两个矛盾的对立面，数据质量归根结底主要是受到人的影响，仅仅试图依赖技术手段解决管理问题的效果往往甚微。
因为，任何的数据治理方案最后还是需要人去落地、去实施。它是一个漫长而持续的过程，没有立竿见影的捷径可以走，要想保障数据资产的完整性、准确性、一致性、及时性，只能共同保证正确的信息，用正确的形式，在正确的时候，交付给正确的人，才能根据指定的规范开发模型、校验模型、管理模型，为业务提供统一、准确的数据。
3、数据模型
数据模型，其实就是数据仓库领域中的模型范畴，通过标准规范数据架构与研发方式，统一基础层、公共中间层、应用层的数据分层架构模式，通过数据指标结构化规范化的方式实现指标口径统一，实现数据的标准化。
4、数据服务
数据中台需要对外提供统一主题式服务。主要是通过构建服务元数据中心和数据服务查询引擎，面向业务统一数据出口与数据查询逻辑，屏蔽多数据源与多物理表，降低使用成本和复杂度。从原则上来说，数据中台只提供通过数据服务能力，更多个性化需求需要各系统在业务层面自己去实现，用协同的方式简化系统上层业务的使用，提升对前台业务需求的响应效率，以此达到降本增效的目的。
通常提供采用以下三种服务方式：依赖接口的服务、依赖工具的服务和依赖数据的服务
依赖接口的服务：通过数据接口标准化的方式，提供统一的数据服务在线查询视图，让开发者能够快速、简单的访问数据服务；
依赖工具的服务：通过数据开发可视化的方式，提供服务接口的可视化配置，开发者通过配置SQL的方式产生Api，降低接口开发的要求和成本，也便于后续的管理和维护；
依赖数据的服务：通过数据封装的服务方式，主要有Data Api 、SDK 、引擎等多种方式数据服务方式。
小结
中台的建设主要围绕着规划、治理、整合、共享四个方向来进行演进。首先，做好企业的全域级数据接入，做好数据资产盘点、整合、分析、确保全域级数据一致性、准确性、可复用性，为前台提供数据资产、数据创新、数据监测与数据分析等服务，最终实现数据资产的价值最大化。
在具体建设中台的策略方面，需要结合公司的发展战略和业务特点，选择明确数据资产对象，以大数据小场景的方式去验证场景化需求。
03
中台建设的内容
基于前面中台建设需要知道的事情和中台建设的方法论，希望大家能有所收获。笔者在这也尽量多说些细节方面的东西，统一大家的认知，避免大家知其然，不知其所以然，如果是这样的话，与其一知半解不如全然不知，权当罪过，良心难安。
中台建设的内容主要分为三大块：One ID（一个用户账号）、One Data（一个数据平台）、One Service（一个业务平台）服务体系。
3.1.OneID体系
One ID的前身其实是ID - Mapping。说的简单通俗一点，ID-Mapping是用来关联识别同一个用户ID的。ID-Mapping通过把多份来源于不同业务系统的数据源，通过一系列技术手段、方法识别为同一个主体或对象。通过直接或者间接的方式，识别同一台设备，同一个用户，同一家企业等等，业内形象地理解为用户画像的“拼图”过程。
因为，一个用户的行为数据、属性数据通过业务过程数据化的方式，记录存储到不同的业务系统，从各个业务系统的数据来看信息都不一定是完整的，看到的只是用户在某个系统或者某个业务一个片面的画像，而ID-Mapping技术能够将碎片化的数据全部串联起来，消除数据孤岛，形成一个完整的用户信息视图，让数据在不同的领域发挥出相应的价值。
那么，企业需要如何做好ID-Mapping呢？
1、基于物理设备做Mapping
通过唯一标识符作为一个用户ID号。常用的标识用户的唯一标识符的有：MAC位址、IMEI（手机序列号）、IMSI、Android ID、UDID 、UUID、OpenUDID、IDFA、Telephone、身份证等。
这种方式是最直接的，可以通过精准地记录和标识识别出一个用户。通过利用硬件设备码生成一个统一的设备码，利用一些强账号来关联标识用户。这个层面上主要的技术难度在于ID的稳定性、唯一性、准确性和持久性。
2、基于用户行为做Mapping
在前面的文章中，笔者就说到过，大数据中的大就是少，越是真实的业务数据，数据量就越大，可用的信息比例就越少，更多的是噪音数据。如果你拟合了噪音数据，那就被数据绑架了，所以不要只看数据，更多地从业务层面上多思考问题。
在做ID-Mapping识别也是一样，同一个用户的数据存在在不同的业务系统，在多份数据、多种ID之间存在着一对多、多对多的关系，需要如何统一这些ID。
哪些ID是可以相信的？置信度如何去评估？
业内通常采用的方式是人工规则和机器学习两种方式相互结合，从多个纬度来帮助确定身份的ID的准确度，做到收敛、分配、分裂、聚合。
基于业务分析梳理出人工标注（正样本和负样本），然后基于人工规则做正向、反向的反馈，这里的业务规则更多来源从业者的经验与智慧。梳理规则目的是确定在不同的业务场景下，是不是为同一个用户，同时也为后续机器学习的结果做AB测试的校验和输入。
常用的机器学习方式和策略，有单模型和多模型两种方式。模型是机器学习的结果，而这个学习的过程称为训练（Train）。
一个训练好的模型可以被理解成一个函数：y = f(x)，这个 y 可能是一个数值（回归），也可能是一个标签（分类）。模型是基于大量的数据，然后基于对数据训练得到结果，当然数据越多，训练的结果相对就越准确。
单模型的意思就是通过一种方式的训练过程得出结果；多模型就是两种以上的训练方式得出结果。相对来说，多模型训练的准确度会比单模型训练准确度要好。多模型在训练时更多需要考虑融合问题以及融合后的判断机制。
3、基于相似用户做Mapping
通过把行为相似的用户给合并起来，物以类聚，人以群分的道理想必大家都懂。先根据用户历史消费行为帮你找到一群和你口味很相似的用户；然后根据这些和你很相似的用户再消费了什么新的、你没有见过的物品，然后做内容物品推荐。
说的简单一点，就是一个给用户聚类的过程，把用户按照兴趣口味聚类成不同的群体，给用户产生的推荐就来自这个群体的平均值。
本质其实就是，用户与物品之间的关系矩阵。大致的思路是，先准备用户向量，理论上来说可以给每一个用户得到一个向量；其次用每一个用户的向量，两两计算用户之间的相似度，设定一个相似度阈值或者设定一个最大数量，为每个用户保留与其最相似的用户，为每一个用户产生推荐结果，从而做到基于用户兴趣做相似用户Mapping。
小结
ID-Mapping绝对不是一个简单的按照key和value匹配的过程，在实际的落地过程中会遇到各种困难。
数据中往往带噪音数据，如果你拟合了噪音数据，那就被数据绑架了，识别结果就不准确，需要考虑如何提升数据质量问题
对于僵尸用户或者长期不用的用户，保存数据是没有意义，浪费资源而且数据长期不更新后也会导致数据不准确，需要考虑到ID-Mapping后数据的更新频率机制
打通后的数据是HDFS的离线数据，需要如何保证ID之间的Mapping关系，选择何种分布式数据库、表如何设计、如何做到数据更新时才不会影响线上服务呢？
3.2.OneData体系
在中台建设的过程当中，最核心的是OneData体系建议。
数据体系建设目的是建立企业统一的数据公共层，从设计、开发、部署和使用上保障数据口径的规范和统一，实现数据资产全链路管理，提供一套完整、规范、准确、标准的数据体系，可以方便快速的撑前台的数据应用。该体系主要包含：全局数据仓库规划、数据规范定义体系、数据模型规范设计、数据连接萃取、数据运维监控、ETL规范研发等以及支撑整个体系从方法到实施的工具体系。
那么，企业需要如何做好数据中台设计呢？
1、数据模型层次设计
基于Kimball维度建模的方式，将数据分为操作数据层（ODS）、公共维度模型层（CDM）、应用数据层（ADS）。
ODS层：把来源于其他系统的业务流程数据，同步到数据仓库当中来，中间仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。
CDM层：存放明细事实数据、维表数据及公共指标汇总数据。CDM层又细分为DWD层和DWS层，分别是明细宽表层和公共汇总数据层，采取维度模型方法基础，更多采用一些维度退化手法，减少事实表和维度表的关联，容易维度到事实表强化明细事实表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多宽表化的手段构建公共指标数据层，提升公共指标的复用性，减少重复的加工。
DIM层：建立一致的数据分析维表，降低数据计算口径不统一的风险
DWD层：标准化、维度补齐、异常处理
DWS层：基于业务场景做行为数据组织、提升公共指标的复用性
DWM层：宽表集市、跨过业务场景、行为数据组装
ADS层：存放数据产品个性化的统计指标数据，根据CDM层和ODS层加工生成。面向应用，个性化指标加工、基于应用的数据组装。
需要遵循图中的调用方式，但是，并非绝对，有时候在特殊的业务诉求下会违法建模规范的。
2、数据规范定义设计
中间层（CDM）构建过程以维度建模为理论基础，构建总线矩阵，划分业务板块、定义数据域、业务过程、维度、度量、修饰类型、修饰词、时间周期、派生指标，进而确定维表、明细事实表、汇总事实表模型设计。
数据域是指面向业务或数据本质分析，归纳总结出来的数据集合。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。
一致性指标定义即描述原子指标、修饰词、时间周期和派生指标的含义、类型、命名、算法，被用于模型设计，是数据建模的基础；
原子指标：在某业务过程下具有明确的业务含义最小度量单元，原子指标不可再拆分，在设计时以动作+度量构成。比如：支付金额(pay_amt)、停留时长(stay_time)；
时间修饰词：数据统计的时间范围或者时间点，如最近1天、最近7天、最近1小时；
其他修饰词：是对指标业务场景的限定，如用户等级高、终端（App、PC、小程序）；修饰词归属到某个抽象的修饰类型，比如：用等级、终端类型等；
派生指标：由原子指标、时间周期修饰词以及其他修饰词组合而成。其中原子指标为单一选择，时间修饰词为单一选择，而其他修饰词可以多选。派生指标继承了原子指标所在的数据域、数据类型、算法，保障指标的一致性。原子指标、时间修饰词、其他修饰词的命名确定后，派生指标的命名也被确认下来。
在数据建模的过程中需要遵守开发规范。比如，表、字段、分区、任务的命名、类型都需要做一致性定义，公共代码的一致性规范定义，确保整个模型的规范、易理解、易查找；同时，每个表责任到人，可以找到对应的技术责任人，技术责任人对表的处理逻辑、数据质量、产出时间、以及规范性等负责。
在必要的情况下表的责任人与HR系统打通，当责任人离职必须把负责的所有表转移给接手人，否则不予办理离职手续，避免表无责任人情况。
ODS层、CDM层的表一般有技术责任人即可；ADS层表除了要有技术责任人和业务责任人，业务责任人主要是为了避免业务已经停止使用，技术也不敢下线数据加工任务的情况。
3、数据模型设计
维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法，维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。主要包括维度表设计、事实表设计、汇总表设计。
维度表是表示对分析主题所属类型的描述。通常来说维度表信息比较固定，且数据量小。
事实表是表示对分析主题的度量。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。通过合理设计事实表使其有效地组织和保存业务数据，沉淀为企业核心数据资产。
事实表是数据仓库维度建模的核心，一切数据应用和分析都是围绕来它展开的，稳定的数据模型能大幅提高数据复用性；根据平台和业务特性，适当冗余的事实表能提高数据易用性并降低平台计算成本。
维度建模常见的由星型模型、雪花模型和星座模型三种，数据中台设计一般采用星型模型。
小结
数据体系建设的大致流程如上图所示，在实际落地过程中还涉及到一些其他的外部系统依赖，比如调度系统、元/主数据质量管理系统、离线/实时的计算平台、数据质量监控系统等等，总的来说数据体系建设成败的关键在于是否具备全方位的掌控能力。
在建设的过程中，需要能做好以下几个方面：
1、企业人员需要统一对数据的认知，特别是高层领导更加需要具备数据驱动的战略思维。高层领导的自上而下是企业数据战略后续人、财、物持续投入的保障，只有自上而下和自下而上都具备统一的数据认知，才能推动数据应用场景落地，发挥出数据的价值；
2、基于数据和业务调研，制定一套符合企业业务现状、数据现状、技术现状以及符合企业未来发展的数据建模规范。数据建模方法本身是大同小异的，关键点是需要一套标准的规范，才能保障其正常的流转运行，包括需求对接规范、数据分层规范、命名规范、开发规范、数据权限隔离规范、数据安全隐私规范等；
3、在数据中台数据体系建设的过程当中涉及到多个业务团队的共同协作，人员的变化以及业务的发展变化很难靠人保证规范的持续执行，只有依靠数据相关的工具来保障规范的正常执行，如果能把数据建模规范、数据质量监控、数据地图等工具规范融入到工具使用当中就更好；
4、无论是战略的执行、方法规范的制定、数据工具的落地都需要有组织人员保障。基于数据治理的方针，建立数据委员会运用自上而下顶层设计方法，制定符合企业现状短期和长期的建设目标、规范、制度并且推动执行，同时将数据团队的考核与业务发展进行双向绑定，共同推动业务数据化和数据业务化的发展。
3.3.One Service体系
在做数据服务平台建设之前，先和大家来聊一聊“一切业务数据化，一切数据业务化”这句话背后隐藏的本质，统一认知后，方能透过现象看到本质，不会被事物的假象所迷惑。
1、业务数据化
业务数据化可以理解为就是把我们现实世界中业务的对象、业务的生产过程，通过连接的方式虚拟到我们的数据世界，每一次的连接都有一个数据交互的产生，形成数据记录，最终能够和业务产生一一映射和对应。
业务数据化可以细分为：业务对象数据化、业务过程数据化以及业务规则数据化三种。
业务对象数据化：所有企业的业务基本上都是基于人、物、场景三个维度来构建业务生态的，因此有人、物、管理等是重要信息对象 。比如，一个产品的产品属性、产品的编码、产品价格等，这些其实都是需要通过数据化的方式来进行数据建模
业务过程数据化：能够自动记录数据的流动过程。比如，购买商品的下单过程、日志记录、数据埋点，以及结合各种应用场景产生的数据
业务规则数据化：其实比较难的事情，所有企业都在做，但是效果确都不是很好，需要不停地优化迭代。在业务过程中给业务行为提供业务流程上面的指引，可以落地的指引的逻辑规则和业务规则 。比如游戏规则、购买规则、业务规则等，这些规则都是行业人群总结出来的经验与智慧，只有做到数字化才能变成数据，从而做到业务规则上和应用上真正意义上的解耦。
所以说，业务数据化是企业每个部门都要去做的事情，并不是数据中台的事情，是整个企业的事情。只有先从源头保证数据的质量，才能发挥出数据的真正价值，无论是做业务数据化或者数据业务化都离不开数据，数据质量是很重要，不做好做数据中台就没有数据，真的会沦为巧妇难为无米之炊的窘境。
2、数据业务化
数据业务化是业务数据化的一种延伸，即将收集的数据用于业务或产品本身，将数据转变为带有建议性的信息帮助客户实现商业目的与价值。数据服务化主要包含数据智能和数据创新两个方面。
比如，现在有把用户数据打包卖给其他人，其实还称不上真正意义的数据业务化。因为，数据并未转变为面向客户实现商业目的的内容，可以定义为数据交换的一种方式。
比如，当一个电商平台，根据用户之前的购买、流量记录，通过算法判断用户的购买偏好，推送商品给用户，这个阶段才真正意义上算的上是数据业务化的开始。
所以说，只有先用过业务数据化的方式，打破业务之间的数据壁垒，让数据在各个业务之间像水一样来回流通，才能满足灵活多变的数据需求，让全域流通和按需自助实现。
那么，需要建设那些数据服务呢？
数据来源于业务，服务来源于场景。只有先基于业务梳理出场景化需求，才能更好的使用数据、利用数据与应用数据。
常见的数据服务有基础画像服务、标签画像（用户画像、物品画像）服务、用户圈群服务、算法模型服务以及各种搜索/广告/推荐SDK引擎服务等。
比如，接口的服务是通过数据接口标准化的方式，提供统一的数据服务在线查询视图，让开发者能够快速、简单的访问数据服务；用户圈群服务是基于用户标签筛选人群，在推荐/精准营销场景中，可以通过接入这个服务，来实现商品推荐和精准广告投放等；
所以说，首先基于业务来源的数据做基础数据的服务，提供数据指标跨域自助获取；其次需要做好标签画像服务，为用户和内容物品向量化处理；最后基于场景，提供数据服务和能力。
只有当数据在业务层面上做到全域级的流通，才能做好业务数据化，做好数据的能力延伸。
小结
任何企业的数据主要来源于业务，只有先打破业务之间的数据壁垒，实现业务数据化，才能真正的对应前台灵活多变的数据需求。
基于业务面向的对象，把跨业务板块、跨数据域的特定对象数据进行整合，形成对象的全域标签体系（人的标签体系、物的标签体系、场景的标签体系），才能方便后续数据的深度的分析、挖掘、应用。
中台在构建服务时需要考虑到可复用性的，大家也都希望每个服务就像一块积木，可以随意组合，非常灵活，只需轻量级的组装模块服务就可以为前端快速的实现，从而达到降本增效的目的。
但是，是否业务中台有车身和底盘，数据中台发动机和电气设备，就真的能做好一个汽车呢？
总结
“道”是宇宙万物的根源，世间的万事万物都是由“道”产生的。万事万物都是深刻相连的事实，意味着“好与坏”、“错与对”只是人内心的幻相，换个角度来思考都会变成相对的和短暂的真实。
万事万物每天都在不断的变化，那么我们要如何认识事物的本质呢？
笔者认为，其实万事万物的本质是生命，生命的延续是时间，时间没有了，生命也就结束了。企业建设中台道理也是一样的， 先通过连接的方式记录着虚拟数字世界中的“精彩”，然后做数据在另一场景领域的能力延伸。
数据始终基于业务，如果业务死了，对于这个业务产生的数据来说，它的使命就暂时结束了，至于之后会用什么其他的方式延续“生命”，在数据的世界里真的无从知晓吗？
企业建设中台一定是一个持久而漫长的过程，绝非一蹴而就，能力和服务都需要不断的业务滋养，才能逐渐走向成熟；这个过程一定是吃苦的过程，同时也请各家企业在建设中台或者打算建设中台的人，请一定不要短期高估，长期低估中台的能力。
数据是企业真正能发挥价值的武器，能使用数据的场景有很多，希望大家一直对数据怀有敬畏之心，结合场景化需求去落地，将数据逐渐沉淀成企业的资产；其次更多的从数据的角度去发现问题、解决问题、改进问题。
毕竟，在大数据时代的我们，一切皆可量化。
【参考文献】
[1] (美) 金博尔 (Kimball,R.) , (美) 罗斯 (Ross,M.) , 著《数据仓库工具箱:维度建模权威指南(第3版)》[M].清华大学出版社,2015
[2] 阿里巴巴数据技术及产品部.《大数据之路：阿里巴巴大数据实践》[M].电子工业出版社,2017
[3] 钟华.《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》[M].机械工业出版社,2017
如果觉得文章对你有所帮助，欢迎留言并且推荐给你的好友。
本文由橙子解忧杂货店（ID:gh_3eefe43b811e）发布，授权互联网早读课转载。内容仅代表作者独立观点，不代表早读课立场。如需转载，请联系原作者。
排版：放开那芒果
热点阅读：
延伸阅读：
