2021搭建数据中台方案.docx

《2021搭建数据中台方案.docx》由会员分享，可在线阅读，更多相关《2021搭建数据中台方案.docx（258页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、数据中台建立第1章 数据中台入门攻略在本章中，笔者通过几个典型的问题让你快速了解数据中台。关于中台，你可能关心以下几个问题。 什么是中台？ 什么是业务中台？ 什么是数据中台？ 为什么要搭建数据中台？本章会针对这些问题进行解答。读完本章你会比别人更加了解数据中台。1.1 什么是中台在2015年年中的时候，马云参观了一家名为Supercell的芬兰游戏公司。这家公司的名字大家可能不熟悉，但是他们开发的游戏却很有名，比如部落冲突。这家公司一年的利润就有15亿美元，而员工数量非常少，不到200人，而且在这家公司里，每一个开发游戏的小团队都只有六七个人而已。这么小规模的公司，怎么做成了这么大的业务呢？其

2、中一个原因是他们在游戏开发过程中，把通用的游戏素材和算法整理出来，作为工具提供给所有的小团队。同一套工具，可以同时支持好几个小团队研发游戏。这就是一个“中台”的模型。中台分为业务中台和数据中台，关于这二者的比较经典的架构如图1-1所示。图1-1 经典中台架构业务中台是中心化的能力复用平台。比如阿里巴巴旗下有很多电商产品，有的产品面向B端（用企业用户），有的产品面向C端（即个人消费者），这些产品基本都会用到账号系统、交易系统、营销系统等，而这些大的模块基本都是通用的，如果每个团队都重新开发一套账号系统、交易系统、营销系统等，就是对资源的严重浪费。因此， 由专门的团队负责开发这些通用系统，再将之提

3、供给各条产品线，这样做，既可以最大化重复利用资源，又可以将每条产品线的数据沉淀在一起。数据中台是什么？几乎每条产品线都需要相关的数据分析工作， 这些工作又会涉及数据分析师、数据开发工程师等角色。如果为每条产品线都配备数据分析师、数据开发工程师，不但数据的标准得不到统一，而且也是对人力资源的一种浪费。数据中台可以承担公司所有产品线的数据分析工作，通过数据化的手段为各条产品线赋能。数据中台主要承担以下四个方面的工作，分别是对数据的“采集”“存储”“打通”“使用”，本书的章节顺序正是按照这个思路安排的。“采集”是指采集各条产品线的数据（如业务数据、日志数据、行为数据等），并将这些数据集中处理，存放在

4、数据中心。“存储”是用更加科学的方式存储数据。业内一般采用分层建模的方式，让采集上来的数据变成公司的数据资产。“打通”分为两方面。一方面要打通用户的行为数据和用户的业务数据，从而构建更加丰富的用户画像；另一方面要打通产品线之间的数据，比如一个用户既用了A产品线的服务，又用了B产品线的服务，需要打通产品线才能挖掘出这些数据信息。“使用”是用打通后的数据赋能业务人员，帮助领导层进行决策，用数据来反哺业务。为什么要搭建数据中台呢？阿里巴巴的军师曾鸣提出过一个概念叫“数据智能”，我们看一下什么是数据智能。以我们生活中常见的美团外卖为例，美团如何调动千万量级的商户和遍布全国的外卖骑手将外卖安全、快速地送

5、到用户的手上呢？如果靠人力进行调度，以美团如此大的业务量，其需要花费的人力是难以想象的。因此美团一定拥有一套不断迭代的智能调度算法，这套算法可以帮助用户找到合适的餐馆，帮助餐馆找到合适的骑手，从而以最高的效率将外卖送到用户手上，所以美团是一家数据智能的公司。数据智能的标志就是由机器代替人工去决策，未来数据智能是一个企业的核心竞争力之一。那么怎么实现企业的数据智能呢？答案就是搭建数据中台。搭建数据中台的最终目标就是帮助企业实现数据智能。1.1.1 . 1 业务中台与数据中台有什么关系业务中台的目的是让一切业务数据化；数据中台的目的是让一切数据业务化。业务中台和数据中台是相辅相成的。如果公司有业务

6、中台，并且由一个专门的团队负责，那么数据中台的搭建会容易很多， 因为业务中台已经整合了公司内所有产品线的业务模块，使通用的业务数据都被统一存储到业务中台，这样就不用再对每条产品线单独进行调研，沟通成本会大大降低。如果公司没有业务中台，也可以搭建数据中台，只不过要多做一些工作，要从各条产品线分别采集数据， 所以公司搭建业务中台，会让数据中台的搭建工作事半功倍。1.1.2 . 2 什么企业适合搭建中台从短期来看，中台的建设成本比较高。业务中台要具备支撑公司所有产品线的核心业务能力，数据中台要支撑公司所有产品线的数据分析相关工作，因此一旦开发相关系统，前期的投入比较大。不过公司在搭建好中台并具备核心

7、的业务能力和数据能力之后，再去扩展产品线时，新建产品线所需的成本就没那么高了，新产品线只需接入中台即可，所以从长远来看，中台还是能够降低企业研发成本的。判断一家公司到底是否适合搭建中台，可以看看该公司的产品线数量。如果公司有多条产品线（至少三条产品线以上），各条产品线之间有很多可以复用的功能，那么该公司就适合搭建中台。初创公司是不适合搭建中台的，因为搭建中台需要投入大量的人力、物力成本，大多数初创公司在前期基本只有一条核心产品线，因此等到公司发展出多元的业务再搭建中台也不迟。1.2 双中台实战案例笔者所在公司是一家做服装批发业务的互联网公司，接下来笔者以所在公司搭建的中台项目为实战案例解析一下

8、中台的架构。如图1-2所示，笔者公司主要有三条产品线，分别是打版服务、电商服务、快递/物流服务。图1-2 笔者所在公司的中台架构打版服务主要是给原创设计师提供服装打版、生产的平台。设计师有打版需求则可以在打版平台上选择合适的供应商先进行打版，如果设计师觉得工厂提供的服装样版还可以，就可以把自己设计的服装上架到电商产品线去销售，如果该服装在电商平台上获得市场认可， 就可以集单大批量生产，集单生产可以大大降低生产成本。平台的供应商在大批量生产服装后就可以用快递/物流服务把衣服发货给采购商。电商服务的用户和销售数据能直接引导打版平台的业务；在服装被生产出来后，又可以用快递/物流服务运输给采购商。我们

9、公司的角色就是搭建一个产业互联网的平台，从服装的生产到销售，再到运输都无缝地连接起来，从而打通服装产业的上下游。这三条产品线的无缝连接是靠底层的业务中台和数据中台来支撑的。每条产品线都会用到用户、支付、营销活动等模块，业务中台把这些功能进行模块化封装，使各条产品线都能更快地搭建自己的基础功能，做到一切业务数据化；数据中台对各条产品线的核心数据进行回收，通过销售数据反哺生产和供应链，这样就做到了“一切数据业务化，通过数据赋能业务”。1.2.1 . 1 业务中台架构先来看一下业务中台的架构，如图1-3所示。图1-3 业务中台架构业务中台的底层是数据存储层，可以根据公司业务量的大小，选择合适的数据库

10、存储。再往上一层就是业务中台的核心部分，其包括多个“中心”，是可以扩展的。作为中心化的能力复用平台，业务中台的特点就体现在这里，其把所有的通用模块单独开发和部署好，提供给各条产品线， 各条产品线可以插拔式地使用。下面简单介绍一下业务中台的一些通用模块：用户中心、商品中心、交易中心、支付中心、营销中心。（1） 用户中心。用户中心（或称用户模块）是每个互联网产品都会用到的，只是每个互联网产品的用户类型不一样。比如注册、登录、账号的管理、用户基础信息的管理等这些通用功能的数据会被存储于业务中台中，但是那些偏业务的十分个性化的数据则不会，还是会被分散存储在各个应用中。我们可以想一下，以前每条产品线都需

11、要开发登录、注册这些功能，其实是对资源的严重浪费，现在只要让各条产品线与中台对接起来就能实现同样的功能，这样就大大提高了开发效率。（2） 商品中心。笔者公司的三条产品线（打版服务、电商服务、快递/物流服务）都围绕着商品运转。打版服务会记录商品从设计到生产的全部信息；电商服务会记录商品的上架、销售、售后信息；快递/ 物流服务则会记录商品的运输信息。商品中心汇集了商品生命周期的所有信息。因为商品的数据都汇聚在一起，也就十分有利于数据中台的数据分析工作。（3） 交易中心。交易中心主要与订单的生成和状态管理相关。对于不同的产品线，状态管理是不一样的。在电商服务产品线中，当电商产品用户刚提交订单时，订单

12、状态变为“未支付”；支付完成后， 订单状态就要修改成“已经支付”；当供应商发货完毕时，订单状态就变成“已发货”；当用户确认自己收到的商品没有问题时，订单状态最终变为“已完成”。在打版服务产品线中，最开始设计师会提交需求，接下来就会有多家生产厂家报价，此时商品状态就是“已经报价”；在设计师选择一个生产厂家打版后，商品状态就变成“生产中”；直到生产厂家完成打版并把版样发给了设计师，整个流程才结束。（4） 支付中心。支付中心也是几乎所有互联网产品都需要的模块，因为互联网产品要想盈利就必须要有线上支付环节。支付中心需要处理各个支付渠道的对接（比如支持支付宝、微信、银联等支付方式），还要处理支付后的对账

13、每个订单用户应该支付多少钱、平台方应该抽取多少钱、供应商应该分多少钱，需要一套十分严谨的对账逻辑保证各条产品线的账目是平的。（5） 营销中心。比如公司要做一个发放优惠券的营销活动，那么该活动的发券、领券、用券等环节都可以采用通用的模块。另外，应该选择哪些人做活动、以什么方式（如推送、短信、公众号、电话等）触达，这些环节也都可以采用通用的模块。营销中心和数据中台联系得比较紧密，比如“如何选择用户做活动”就可以通过数据中台基于规则推算出来，而且在活动完成后，数据中台可以基于活动产生的数据做自动化的活动效果分析。1.2.2 . 2 数据中台架构接下来我们看一下数据中台的架构，如图1-4所示。图1-4

14、 数据中台架构从下往上看，第一层是数据采集层。企业内每条产品线都会产生一定数量的业务数据，比如电商服务产品线的用户的加购（即将商品加入购物车）数据、收藏数据、下单数据等随着用户量的增大会越来越多，这些数据大部分被存储于业务数据库中；还有用户的浏览行为、点击行为，这些行为会做相应的埋点，产生的数据一般会以日志文件的形式存储。无论是业务数据库的数据还是日志文件的数据，我们都需要把它们抽取到数据中台中做统一的存放。一般数据工程师会用一些比较成熟的数据同步工具，将业务数据库的数据实时同步到数据中台，同时将离线日志数据以“T-1”的形式抽取过来，整合到一起。第二层是数据计算层。数据中台要同步企业内多条产

15、品线的数据，数据量相对来说是比较大的。海量的数据采用传统的存储方式是不合理的。业界一般采用分层建模的方式来存储海量数据。数据的分层主要包括操作数据层（Operational Data Store，ODS）、维度数据层（ Dimension ， DIM ） 、明细数据层（ Data Warehouse Detail ， DWD）、汇总数据层（Data Warehouse Summary，DWS）和应用数据层（Application Data Store，ADS）等，通过分层建模可以令数据获得更高效、更科学的组织和存储。另外，为了保证数据指标的准确性和无歧义性，企业内部的数据指标需要通过一套严格的

16、数据指标规范来管理，包括指标的定义、指标的业务口径、指标的技术口径、指标的计算周期和计算方式等。数据中台的产品人员、开发人员都要参考这套规范来工作，这样就能更大程度地保证数据的准确性和无歧义性。第三层是数据服务层。数据经过整合计算后，如何被调取和使用呢？数据中台一般以接口的形式对外提供服务，开发人员将计算好的数据根据需求封装成一个个的接口，提供给数据产品和各条产品线调用。第四层是数据应用层。数据产品分为几种：针对内部的数据产品、针对用户的数据产品、针对商家的数据产品。针对内部的数据产品一般用于服务公司的产品/运营人员和领导层。产品/运营人员更关注明细数据，比如，如果电商产品的活跃用户持续减少，

17、数据中台如何通过数据帮助他们找出原因；领导层更关注大盘数据，比如根据公司近一年各条产品线的运营情况决定是否开发大屏类产品。针对用户的数据产品可以基于数据中台整合后的数据开发一些创新应用，比如个性化商品推荐，让“货找人”而不是“人找货”，提高了人货匹配的概率，同时也提高了用户的下单概率。针对商家的数据产品可以基于数据中台为商家提供数据服务，比如电商产品基于销售数据制作关于流行趋势、行情、店铺的数据报告等。1.3 数据中台人员构成中台的搭建工作一般来说是“一把手工程”。业务中台承载公司的所有业务，数据中台承载公司的所有数据。业务中台既然要承载所有的业务，就要把所有产品线的业务搬到业务中台，那就涉及

18、大量的跨部门沟通，只有全公司各条产品线都认可中台模式，业务中台的搭建工作才会更加顺利，因此需要公司的一把手直接领导中台的搭建工作。在把各条产品线的业务都接入中台后，数据也就沉淀下来了。在没有数据中台时，数据都是由各个部门汇总给公司的CEO的，等数据到了CEO的层面，信息可能会有一些变化。在拥有了数据中台之后，CEO可以直接通过数据中台拿到公司各条产品线的核心数据，从这个方面来讲，数据中台也扩大了CEO的信息视野。一个典型的中台组织架构如图1-5所示。中台一般会由公司高层直接主管，高层的下面是中台负责人，其充当部门总监的角色，统一管理公司的业务中台和数据中台。图1-5 数据中台的组织架构一般来说

19、，高层不会做一些细节的工作。中台负责人需要负责与其他部门合作，当遇到需要与其他部门沟通的重要工作时，就由中台负责人协调资源来处理。另外，由于业务中台产生数据，而数据中台消费数据，双中台之间也必定会有大量合作和互动，在产生分歧时也需要中台负责人来解决问题。中台负责人的下面是业务中台的负责人和数据中台的负责人。这两个人分别主导业务中台和数据中台的搭建工作，对业务中台、数据中台的搭建工作好坏负有直接的责任。他们的工作主要包括项目的规划、产品团队的管理、项目管理等。接下来我们再具体看一下数据中台的人员构成。一个数据中台的项目需要10种不同角色（包括数据中台负责人在内）共同参与，如图1-6所示。图1-6

20、 数据中台的人员构成（1） 架构师。其是整个数据中台团队的技术负责人。使用业界比较成熟的架构设计来构建大的模块（比如标签平台、推荐平台），能够避免很多无用的工作。一些需要攻关的技术难题（包括技术选型等）也需要架构师来解决。（2） 项目经理。数据中台团队的项目经理主要管理技术团队，要优化内部合作流程，不断提高团队的效率，保证团队按时、高质量、在成本范围内完成项目建设。数据中台团队内部的沟通机制、对外的沟通机制、研发迭代计划的制订等工作都需要项目经理主导。（3） 模型设计师。模型设计是数据中台搭建过程中比较重要的一环。底层模型直接决定数据中台数据指标的质量和可扩展性。一个好的模型设计师需要熟悉公司

21、内部每条产品线的业务流程，熟悉每条产品线的数据存储情况。模型设计师需要和产品经理配合，一起弄清楚每个指标的来龙去脉，并将模型思路、计算方式清晰地告诉数据开发工程师。全面、多维度的建模是数据中台的基础，相对来说，模型设计师是数据中台团队比较核心的职位。模型设计师需要熟悉数据仓库各类模型的建模理论，了解数据仓库数据分层架构，最好有数据仓库架构设计、模型设计、ETL设计1的经验。（4） 数据开发工程师。其主要和模型设计师打交道。模型设计师会把与产品经理沟通的业务口径转化为技术口径，告诉数据开发工程师每个指标应该从哪里提取数据、指标应该怎么计算。数据开发工程师将计算的结果一层一层汇总，最终要和后端工程

22、师定义数据应用的接口。数据开发工程师需要熟悉大数据工程的基本原理，熟悉流式计算等实时计算，熟悉Hadoop、Spark等离线计算，熟悉大数据存储等相关内容。（5） 后端开发工程师。数据中台的后端开发工程师有点与众不同，主要负责与数据指标相关的工作，与数据开发工程师、产品经理、测试工程师打交道。后端开发工程师需要输出对内的数据产品开发接口，还要将一部分数据以接口的形式输出给其他产品线。数据中台的后端开发工程师需要有数据平台系统的开发经验，需要熟悉J2EE 技术平台及主流框架，熟练掌握关系类型数据库，熟悉Linux、大数据处理、NoSQL等相关技术。（6） 前端开发工程师。其主要和后端开发工程师、

23、测试工程师、UI 设计师合作。前端开发工程师需要精通一些前端技术（ 比如JavaScript 、H5 等） ， 熟悉一些可视化的图表组件（ 比如EChart 等）。前端开发工程师需要把数据指标以更通俗易懂的图表形式显示给数据中台的用户。（7） UI设计师。其会根据产品经理提供的原型设计效果图，一旦效果图通过，UI设计师会给出切图（功能的标注），然后由前端开发工程师基于切图完成前端界面的开发。前端开发工程师和UI设计师需要有一定的审美水平，因为视觉设计和交互设计直接决定了产品的用户体验。（8） 测试工程师。和一般项目的测试工程师相比，数据中台的测试工程师有点与众不同。数据中台的测试工程师主要测试

24、数据的准确性。数据中台数据的准确性几乎决定了数据中台80%的价值。测试工程师需要理解指标的计算逻辑。数据开发工程师会对数据进行自测，自测是保证数据准确性的第一道门槛。测试工程师是保证数据准确性的第二道门槛。产品功能上线初期会让运营的同事先试用，这个步骤是保证数据准确性的第三道门槛。在数据中台的功能运营了一段时间（比如两个月或三个月）后，测试工程师会组织进行功能回测，这就是保证数据准确性的第四道门槛。（9） 产品经理。最后笔者再说一下产品经理。数据中台产品经理的工作包括产品的规划、需求的梳理、功能的设计、功能上线后的跟进等。数据中台是服务B端的产品，一般会在公司内部孵化出数据服务的产品，用来服务

25、一线的产品/运营人员和公司高层，所以数据中台产品经理要了解公司每条产品线的业务流程和未来发展方向，这需要其拥有很强的跨部门沟通能力。数据中台产品经理要为数据中台的总体价值负责。从上文可知，一个指标的开发常常需要多个角色相互配合才能完成，所以数据中台产品经理对指标的价值判断十分重要。数据中台产品经理如何保证数据中台开发的指标都有价值呢？方法是在设定每个指标前，不妨先确定以下两个问题的答案。 这个指标能解决什么业务问题，能帮公司带来多少交易额？ 如果有了这个指标，产品/运营人员能提高多少工作效率，节 省多少时间？无论是帮公司赚钱，还是帮公司省钱，对于公司来说都是有价值的事情。1.4 数据中台开发流

26、程在这一节，笔者讲一下数据中台的开发流程，如图1-7所示。一个指标从口径的确认到上线、迭代都要经历图示的这些过程。图1-7 数据中台开发流程数据中台完成一个指标的开发需要经历11个步骤，分别是业务口径梳理、技术口径梳理、原型设计和评审、模型设计、数据开发、后端开发、前端开发、联调、测试、上线、迭代。接下来我们分别看一下这些步骤都是做什么的。（1） 业务口径梳理。这个步骤应该由数据中台产品经理来主导。产品经理需要与提出该指标的产品/运营负责人沟通，要问清楚这个指标有什么用、给谁用、业务流程是什么，还要确定指标定义、统计周期、计算方式等。不是所有的指标都有开发的意义，因为数据中台每做一个指标都会花

27、费大量的人力资源，所以一定要考虑开发这个指标的性价比投入这么多资源，能够给公司带来什么。（2） 技术口径梳理。这个步骤由模型设计师主导。首先，模型设计师需要理解数据指标涉及的业务逻辑，还需要理解指标定义、统计周期、计算方式等。接着，模型设计师需要与产品线的开发人员一起梳理数据指标涉及的表结构和字段，这个工作比较重要，一定要精确到字段级别，在确定好这些字段后，就能初步判定这个指标在技术层面能不能统计，如果不能统计，模型设计师应该主动告知产品经理：目前这个阶段还没法计算相关指标，做了哪些功能后才能计算这些指标。（3） 原型设计和评审。这个步骤还是由产品经理主导的。基于运营的需求设计原型，在原型设计

28、完后，要经过内部评审和外部评审。在内部评审中，产品经理要召集数据中台的架构师、模型设计师、数据开发工程师、后端开发工程师、前端开发工程师、UI设计师、测试工程师，说明整个功能的价值和详细的业务流程、操作流程，确保大家理解一致。接下来，产品经理和运营人员要针对原型做一次外部评审，把有歧义的地方一并解决。对于比较重要的功能，产品经理需要发邮件让运营人员进一步确认，并同步给所有的产品/运营人员，保证大家的口径一致。（4） 模型设计。这个步骤由数据中台的模型设计师主导。业内一般会采用分层建模的方式对数据进行更加科学的组织与存储。模型一般分为5层，分别为ODS层（操作数据层）、DIM层（维度数据层）、D

29、WD层（ 明细数据层）、DWS层（ 汇总数据层）、ADS层（ 应用数据层），这是业界对于数据分层的常用的模型。模型设计工程师要清楚地知道数据来源于哪里、要怎么存储。（5） 数据开发。这个步骤由数据开发工程师主导。首先，数据开发工程师要和模型设计师确定技术口径，明确计算的指标都来自哪些业务系统。接着，数据开发工程师通过数据同步工具将数据同步到ODS 层，并一层层地汇总，从ODS层到DWD层，再到DWS层，直到最后把可以直接服务应用的数据填充到ADS层。另外，大数据开发工程的一个比较重要的工作就是设置调度任务简单来讲就是配置指标在什么时候计算。数据开发工程师会写好计算脚本（比如按照“T-1”的方式

30、每天凌晨处理前一天的数据等）。随着业务的增长，运营工作对于实时数据的需求越来越大，还有一些实时计算任务的配置也会由数据开发工程师完成。（6） 后端开发。这一步骤由后端开发工程师主导。后端开发工程师基于产品经理对功能的定义，输出相应的接口给数据中台的前端开发工程师或产品线的前端开发工程师。一般来说，最终对外提供服务的数据存储在ADS层，后端开发工程师一般是基于ADS层的数据将数据封装成对外服务的接口，后端开发工程师一方面要和数据开发工程师沟通好ADS层数据的存储结构，另一方面需要和产品经理沟通产品的功能、性能方面的问题，以便为使用者提供更好的用户体验。（7） 前端开发。这个步骤由前端开发工程师主

31、导。在原型设计出来后，产品经理会让UI设计师基于产品功能原型设计UI。在功能界面最终定型后，UI设计师会给前端开发工程师提供切图。前端开发工程师基于UI的切图做前端页面的开发。（8） 联调。数据开发工程师、前端开发工程师、后端开发工程师都要参与这个步骤。一般来说，数据开发工程师要基于历史的数据执行计算任务并承担数据准确性的校验。前端开发工程师和后端开发工程师负责解决用户操作的相关问题，保证不出现低级的错误。（9） 测试。这个步骤由测试工程师主导。在完成原型评审后，测试工程师就要开始写测试用例，哪些是开发人员自测通过后才能交上来测试的内容、哪些是开发人员要再次自测验证的内容，都需要在测试用例文档

32、上写清楚。此时有经验的测试工程师可以向运营人员要一些历史的统计数据来核对数据，不过运营人员的数据不一定准确，只能作为参考。在最终测试没问题后，产品经理可以请运营人员试用， 如果在试用中发现数据准确性的问题则需要再进行一轮测试，以验证数据。如果问题都解决了，整个研发过程就结束了。（10） 上线。运维工程师会配合数据中台的前端开发工程师、后端开发工程师将最新的版本更新到服务器中。此时产品经理要找到该指标的负责人，令其长期跟进指标的准确性。对于重要的指标，每过一个周期还要再次进行内部验证，从而保证数据的准确性。（11） 迭代。数据指标上线后，随着公司业务的变化，指标的口径可能也会有所变动，所以也要定

33、期盘点已有的指标，如果指标有变化，需要不断迭代，保证指标的准确性。1.5 数据中台内外合作机制在搭建中台的过程中，特别是在数据中台与其他部门合作时，数据中台团队经常被各条产品线问到以下两个问题。 为什么要接入业务中台？ 产品线的数据为什么要提供给数据中台？中台是一个中心化的组织结构。中心化就意味着你要和其他部门合作才能完成中台的搭建工作。掌握如何与其他部门合作、如何管理数据中台团队的能力是非常重要的。1.5.1 . 1 数据中台如何与其他部门合作先看下数据中台和其他部门的依赖关系。如图1-8所示，数据中台作为一个独立的部门要支撑起公司内部多条产品线的数据化运营。一般来说，各条产品线的运营人员和

34、产品经理常常会和数据中台打交道。产品线的运营人员经常会有一些关于数据指标的需求。产品线的产品经理需要协助数据中台完成数据指标涉及的业务流程，技术口径的确认也需要业务部门的产品经理协调他们的开发人员一起完成，因为产品的功能都是产品线的产品经理开发的，所以他们是最清楚产品线的业务流程和数据流转的。图1-8 数据中台与其他部门的依赖关系数据中台与其他业务部门的合作主要包括以下几方面。1. 业务口径和原型确认当运营人员有一个新的数据指标要开发时，如何将这些指标清晰地告诉数据中台呢？这就需要有一个规范。一个指标的开发需求列表如图1-9所示。可以用这个表格统一指标的业务口径：是谁需要查看这个指标、这个指标

35、属于哪条产品线、指标的名称是什么、指标的业务口径是什么、统计周期是什么。图1-9 运营人员需求列表这个表格首先要提交给数据中台产品经理，其应该和需求方再次沟通以确定指标的定义和价值。经数据中台产品经理确定后，就可以将表格提交给数据中台的技术负责人，让技术负责人协调模型设计师、数据开发工程师来初步确定指标的技术口径。在技术口径确认后，数据指标开发就会进入产品设计阶段。产品经理在输出原型后，第一件事就是和需求方再次确认，保证功能没有问题。此时最好让运营人员回复邮件确认。之后会进入开发阶段。在完成开发后，产品经理可以向运营人员要一些历史手工统计的数据，这个数据对于数据中台团队来说，有一定的参考意义。

36、在功能上线后，运营人员需要对这个指标负责，可以设定一个试用期（比如一周），他们需要在这个周期内反馈数据的问题。之后就是数据指标的迭代阶段。2. 与各条产品线建立月度沟通机制数据中台团队与其他业务部门的定期沟通十分重要。在企业内部，业务部门是数据中台的主要使用方，在使用数据中台的过程中一定会遇到比较多的问题，业务方的反馈对数据中台团队不断优化自己的产品十分重要。通过月度沟通机制，数据中台团队一方面可以知道业务部门的运营节奏，保证数据中台和运营部门的节奏是一致的，另一方面可以调研运营人员的数据需求，获得问题反馈，帮助他们进行数据化的运营。数据中台的主要用户就是产品/运营人员，基于这些反馈，数据中台

37、可以更有针对性地优化现有的功能。3. 建立日常沟通微信群需要与每条产品线的运营同事、产品同事建立微信群。日常的数据难免会有一些问题，当有问题时运营人员需要十分便捷的反馈渠道。针对微信群里的反馈，数据中台团队要在第一时间内处理，因为正是这些反馈，能令数据中台的功能变得更加有价值。4. 建立规范的取数流程一般来说，数据中台研发的相关指标不可能满足产品/运营人员的全部需求。数据中台可能会遇到其他部门的很多特殊的取数需求。针对这些取数需求，数据中台需要制定一套规范的取数流程，制作取数申请表格，如图1-10所示，业务人员要对自己要提取的数据进行详细描述，包括指标的定义、业务口径、统计周期和计算方式，写清

38、楚自己取数的用途。这个表格首先需要经过业务人员所在部门负责人的审核，然后还要经过数据中台产品经理的审核。数据中台产品经理审核该表格主要是为了确定这个数据的意义和目前的系统是否拥有这样的数据。如果确定帮助业务人员取数，则要进一步确认业务口径，尽量让开发人员一看到业务口径就知道该怎么计算相关指标，避免浪费开发人员的时间。图1-10 业务人员取数申请表格1.5.2 . 2 数据中台内部项目管理流程数据中台的指标开发流程涉及多个角色，花费的时间比较长，因此，如何让运营人员、产品人员、开发人员、测试人员高效地配合来完成数据中台的目标，是一件非常重要的事情。在这里，笔者推荐一个名为“双周迭代计划”的数据中

39、台内部项目管理流程，如图1-11所示。图1-11 双周迭代计划数据中台项目在立项时是需要对各条产品线进行大量调研的。这时候，数据中台需要和运营部门一起确定一个总的目标，比如以一年为一个周期，数据中台要将这一年里要做的功能，按照需求的优先级、性价比，把关键任务拆解到各个阶段，从而分阶段完成。我们可以按季度分阶段，每个季度完成一个小目标，当小目标都一一实现时，大目标的实现也不会出现大的纰漏。接下来，这个季度小目标还可以拆解到每个月的计划中，每个月完成相应内容。如果以一个月作为一个迭代周期，那么迭代周期会显得有些长， 因为等到数据中台一个月后把指标开发完成，运营人员的关注点可能就已经改变了，开发的功

40、能可能已经脱离了当前的运营目标。所以笔者所在的公司采用“月度目标、双周计划”的机制也就是说，每个月都会基于目标设定阶段性任务，再将阶段性任务分为两个迭代周期来完成。接下来我们具体看看“月度目标、双周计划”怎么运转。（1）每月制订月度计划，设定月度目标。每个月数据中台都会组织每条产品线的产品/运营人员做一次常规沟通，一般安排在第三周，主要讨论他们目前使用数据中台所遇到的一些问题，另外弄清楚产品线下个月的计划是什么。基于运营人员的反馈，数据中台可以制订下个月的迭代计划，包括下个月工作的优先级、在什么时间节点完成什么内容，这样就能保证数据中台和产品线的节奏一致、目标一致。（2）每两周迭代一次，完成月

41、度目标。数据中台可以将一个月的任务分为两个迭代周期完成。一般来说，第一个迭代周期是上半个月，第二个迭代周期是下半个月。在第一个迭代周期里主要做一些优化的功能和一些需求已经十分明确的功能。在第一个迭代周期里，产品经理需要完成第二个迭代周期的需求调研，在需求都明确下来后，会在第一个迭代周期的第二周进行需求评审，在需求评审完成后，技术人员就可以准时在第三周进行第二个迭代周期的开发工作。到了第三周，需要和运营人员开一次月度会议，从而确定下个月的需求也就是步骤（1），产品经理就可以继续完成下个月第一个迭代周期的需求调研，并在第四周进行需求评审。这样，产品经理的需求调研工作会比技术同事的开发工作提前两周完

42、成，这就形成了一个良性的迭代循环。 1 注：E T L 即E x t r a c t - T r a n s f o r m - L o a d ，指数据从来源端经过抽取（e x t r a c t ）、转换（t r a n s f o r m ）、加载（l o a d ）等步骤至目的端的过程。第2章 数据采集数据是数据中台的燃料。搭建数据中台的一项比较重要的工作就是采集企业内所有产品线的数据。在本章中，笔者将介绍数据中台需要采集哪些数据、如何采集数据，以及数据采集涉及的相关技术。2.1 数据采集的分类数据中台要采集的数据分为两种类型，一种是用户行为数据，一种是业务数据。我们先看一下什么是用户

43、行为数据。用户无论在哪个客户端（iOS 端、安卓端、小程序端、H5端）操作，用户产生的行为数据都分为两种：一种是浏览数据，一种是点击数据。这些隐性的行为数据，一般不会存储在产品线的数据库中，而是通过异步传输的方式传输并存储到数据采集服务器中。为什么要花那么多的资源采集这些行为数据呢？因为这些数据对后期数据的挖掘应用是十分有用的。举个例子， 对于电商产品，如果没有行为数据的采集，我们无法判断用户对某个商品的感兴趣程度，但是如果有了这些数据，我们就可以定义用户对商品的感兴趣程度，比如用户对某商品的1次点击，代表用户对该商品的兴趣度增加10分，而用户的3次点击代表他对这件商品非常有兴趣。接下来介绍一

44、下什么是业务数据。业务数据一般存储在业务数据库或者业务中台中，业务数据库一般存放产品线的个性化的业务数据，业务中台一般存放通用的业务逻辑数据。比如对于电商产品来说，对坑位的管理、对活动页的管理属于个性化业务，其他产品线通常不会用到，这种业务的数据会存放在业务数据库中，而用户模块的登录数据、交易模块的订单数据等则会存放在业务中台中。2.2 用户行为数据采集本节以电商产品为例，讲一下如何采集用户的行为数据。用户行为数据的采集有如下三种方式。（1）与第三方移动应用统计公司合作完成数据采集。（2）采用前后端埋点结合的方式完成数据采集。（3）采用可视化埋点与后端埋点结合的方式完成数据采集。接下来笔者分别

45、介绍这三种用户行为数据的采集方式以及它们各自的优、缺点。2.2.1 . 1 与第三方移动应用统计公司合作的数据采集方式第一种方式是与第三方移动应用统计公司合作完成数据埋点。前端开发工程师需要按照第三方移动应用统计公司的对接要求， 集成第三方移动应用统计公司提供的数据采集SDK （ Software Development Kit，即软件开发工具包）。一般来说，第三方移动应用统计公司会提供H5端、安卓端、iOS端、小程序端的SDK。前端开发工程师完成了SDK的集成，就能在他们的后台查看自己的应用的数据。市场上比较主流的第三方移动应用统计产品包括百度移动分析、Google Analytics、腾讯

46、移动分析等，接入这些公司的SDK就能完成基础数据的采集。这种方式的优点是开发工作量少，一般每个客户端花费12天的开发时间就可以完成集成，而且数据分析相关功能都不需要开发，这些第三方移动应用统计公司会直接提供相关功能。采集到的数据相对来说比较准确，因为这些产品都是比较成熟的，有很多公司都在使用，一般不会出现数据质量的问题。不过，这种数据采集方式也有几个缺点。（1） 产品线的流量相关数据比较丰富，但是因为只做了最基础的页面和按钮埋点，很难采集到产品线的业务数据，比如对于电商产品来说，我们不但要看坑位的流量，更要看坑位的转化率，而转化率这个指标就涉及交易额，但是第三方移动应用统计产品是无法获取我们产

47、品的交易额的。如图2-1所示，这是百度移动统计大致的演示页面， 我们只能看到流量相关数据，不能看到业务数据。图2-1 百度移动统计（2） 能看到的数据有限。第三方移动应用统计产品都是标准化的产品，提供的都是标准化的数据，其数据的范围不一定能覆盖公司所有数据方面的需求。（3） 第三方移动应用统计产品提供的数据很难同步到数据中台的数据中心。第三方移动应用统计公司一般不会提供这样的数据同步接口，只有产品用户活跃度很高的大客户才能获得这些分析数据，小型公司则很难获得。2.2.2 . 2 前后端埋点结合的数据采集方式第一种方式采集到的用户行为数据无法结合用户的业务数据，而通过前后端埋点结合的数据采集方式

48、就可以解决这个问题。所有数据埋点相关的工作都是为了解决实际项目中的问题，接下来笔者以电商产品为例介绍一下如何通过前后端埋点的方式完成产品线的用户行为数据的采集，同时会进一步介绍如何使用采集到的行为数据解决电商产品的实际问题。（1）如何分析电商产品主路径每天的访问情况用户访问电商产品的主路径一般为：访问首页访问商品列表页访问商品详情页加购下单支付。有了埋点数据就可以知道访问主路径每个步骤的用户数，从而可以分析出哪两个步骤之间的转化率比较低，接着可以进一步分析转化率低的原因，从而根据原因进一步优化产品。如图2-2所示，这是一个典型的用户访问电商产品主路径示意图。图2-2 用户访问电商产品主路径示意图（2）如何解决坑位的转化率问题电商产品都由一个个坑位组成，每个坑位分布在不同的位置，不同的商品在不同的坑位中售卖。采用与第三方移动应用统计公司合作完成数据采集的方式只能获得坑位的流量数据，比如P