中科技术让白癜风患者早绽笑容 https://m.39.net/disease/a_5972960.html本文我们先以一个例子实战介绍OneData实施流程。接着再讲阿里OneData数据体系中数据指标的管理、数据模型的设计。最后讲一下数据产品中，数据看板的设计。全是实战干货，看完本文你就会知道数据中台最核心的内容。阿里OneData实施过程实战比如当时我们运营提了一个比较有指导意义的数据指标叫爆款率，我们以爆款率为例先说一下OneData每个步骤实施的流程和涉及的角色。第一步要确定指标的业务口径。业务口径应该由数据中台的产品经理主导，找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的，比如运营说爆款率的定义分子是是专场中商品销售件数超过20件的商品数，分母是专场内的总商品数（专场如上图所示，商品会放在运营人员组的一个一个专场里面）。这里面有几个坑：1.这个20件可能是运营拍脑袋定义的数据，这时要协调我们的数据数据分析师看下历史专场销售件数的分布找出最合理的值，然后和运营基于数据再一起定义最终的阈值。如果历史数据专场销售件数大部分都远远超过20件那么这个指标就所有的专场都是爆款专场，就没什么意义了。2.商品的销售件数超过20件，其中有一个十分有争议的字眼那就是销售，怎么定义销售？是下单就算，还是支付才算？考虑不考虑退款？如果考虑退款是发起退款就算还是退款实际发生后再算？其实是有很多问题要考虑的。最终和运营确定为该专场支付后的商品件数除以专场商品的总件数。3.销售的商品件数是按商品销售的件数还是按照商品下SKU的销售件数，这个是要搞清楚的，可能运营不关心这个事，但是影响到模型的设计。处理完这些坑后关于指标的定义还需要问这几个问题。我们统计的维度是什么？比如爆款率的计算维度是专场内商品的维度，一个是要专场内，一个是商品，原子指标就是销售款数。还有就是统计周期，一般统计周期分为按小时、按天（当天）、按业务周（运营自己定义的统计周期）、按自然周周、按自然月月、按年，还有就是截止到昨天也是比较常用。爆款率的统计周期是统计专场开始到结束时间内的销售件数。接下来要问清楚这个指标有什么用，给谁用。不是所有的指标都有开发的意义，因为后面你会发现我们数据中台前期每做一个指标都会花费大量的人力资源，所以一定要考虑这个指标的性价比，我们投入这么多资源，能够给公司带来什么，要么直接和交易额相关，要么就是能节省运营同事大量的工作时间，节省人力成本也是为公司省钱嘛。比如我们的爆款率是给商品负责人看的，专场的商品是由商品运营人员组的，爆款率就决定这个运营人员的组货能力，组货能力强的商品运营一定是能够给公司带来更多的交易额。这样公司就应该多投入资源给那些爆款率比较高的那些运营人员。这样就很清楚了，我们的爆款率是给运营负责人和商品运营看的。另外我们的商品运营会长时间在市场选货，那我们团队决定把这个指标做成移动端可看，并且商品运营人员可以实时查看爆款率这个指标。第二步要确定指标的技术口径。技术口径是由建模工程师主导，此时数据中台产品经理要和模型设计师沟通整个指标的业务逻辑，另外就是要协调业务方的技术开发人员和我们的建模工程师一起梳理数据库层面需要用到表结构和字段。一定要精确到字段级别，比如我们的爆款率涉及到专场表、商品表、订单表、涉及的字段有商品的销售款数（需要关联专场和商品表）、专场的总商品件数等字段。这些字段都确定好后，就能初步定下来这个指标能不能统计，如果不能统计这时产品经理应该主动协调运营告知，并且还要告诉运营同事做了哪些功能才能统计这些指标，接下来就是协调业务方产品经理讨论是不是要做这些功能。第三步是原型设计和评审。此时由数据中台产品经理主导设计原型，对于爆款率来说我们要一方面要展示他们的实时销售件数，另外一方面要实时展示爆款率的变化趋势，加上专场的转化率（支付人数/UV）就可以综合判断这个专场的质量，当运营人员发现转化率和爆款率比较低时再结合商品的数据及时把一些表现比较差劲的商品下架，让销量好的商品得到更多的曝光机会。原型的评审分为内部评审和外部评审。内部评审要拉上我们的架构师、建模工程师、数据开发工程师、后端开发工程师、前端开发工程师、UI，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。接下来就要和我们的运营根据原型最终确定问题。比较重要的功能要发邮件让我们的运营进一步确认，并同步给所有的运营同事保证大家的口径一致。第四步是模型设计。此时主导的是我们的模型设计工程师，按照阿里的OneData建模理论的指导，模型设计工程师会采用三层建模的方式把数据更加科学的组织存储。分为ODS（操作数据层），DWD(明细数据层)、DWS（汇总数据层）、ADS（应用数据层），这是业务对数据分层常用的模型。模型设计工程师要清楚的知道数据来源自那里，要怎么存放。关于数据建模下文会更加详细的介绍再次就不再多说。第五步是数据开发。此时主导的是大数据开发工程师，首先要和数据建模工程师沟通好技术口径明确好我们计算的指标都来自于那些业务系统，他们通过数据同步的工具如DataX、消息中间TimeTunnel将数据同步到模型工程师设计的ODS层，然后就是一层一层的通过SQL计算到DW*层，一层一层的汇总，最后形成可为应用直接服务的数据填充到ADS层。另外大数据开发工程另外一个比较重要的工作就是设置调度任务，简单来讲就是什么时候计算提前写好的计算脚本如T-1每天凌晨处理上一天的数据，随着业务的增长，运营会对实时数据的需求越来越大，还有一些实时计算任务的配置也是由大数据开发工程师完成。第六步是后端开发。此时由后端开发主导，后端开发工程师基于产品经理的功能定义输出相应的接口给前端开发工程师调用，由于ADS层是由数据开发工程师已经将数据注入常规的关系型数据库（如MYSQL等），此时后端开发工程师更多的是和产品经理沟通产品的功能、性能方面的问题，以便给使用者更好的用户体验。第七步是前端开发。此时主导的是前端开发工程师。原型出来后产品经理会让UI设计师基于产品功能的重点设计UI，UI设计师经过反复的设计，UI最终定型后，会给我们的前端开发工程师提供切图。前端开发工程师基于UI的切图做前端页面的开发。第八步是联调。此时数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。此时会要求大数据开发工程师基于历史的数据执行计算任务，数据开发工程师承担数据准确性的校验。前后端解决用户操作的相关BUG保证不出现低级的问题完成自测。第九步是测试。测试工程师在完成原型评审后就要开始写测试用例，那些是开发人员自己要自测通过才能交上来测试的，那些是自己要再次验证的都在测试用例写清楚。此时有经验的产品经理会向运营人员要历史的统计数据来核对数据，不过运营人员的数据不一定准确，只是拿来参考。最终测试没问题产品经理协调运营人员试用，试用中发现的一些问题再回炉重新修改，此时整个研发过程就结束了。第十步是上线。运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器。此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要每过一个周期内部再次验证，从而保证数据的准确性。经历了以上步骤数据中台的一个指标终于开发完成，可以看得出一个小小的指标需要调动8个角色在一起沟通、确认好久才能完成上线。所以产品经理一定要把握好指标的价值，把有限的资源花费到最有价值的指标上去。下面介绍一下完成这些步骤最核心的数据指标的定义与数据模型的建立。基于阿里OneData的数据指标管理体系数据指标的定义我们在梳理公司的数据指标时发现每个部门对同一个指标定义的不一致，就好比交易额这个指标在电商产品中就是一个模糊的指标，是下单金额、还是支付金额（无包含优惠）、或者有效金额（剔除退款），这样没有一个统一的标准，就很难对部门间做横向的对比。甚至部门间对同一个指标的口径也存在不一样的情况，更不用说整个指标的开发要涉及运营同事、产品同事、技术同事等，只要一个环节出问题，指标计算就会不准确。我们也是采用阿里的一套针对指标的规范定义，让大家在一个标准下看数据消除歧义。其中的名词定义我们简单过一下：数据域：面向业务的大模块，不会经常变。比如我们公司有环贸快版打版服务、亿订电商业务、供应链业务等等大的业务模块类似产品线。业务过程：如电商业务中的下单、支付、退款等都属于业务过程。时间周期：就是统计范围，如近30天、自然周、截止到当天等。修饰类型：比较好理解的如电商中支付方式，终端类型等。修饰词：除了维度意外的限定词，如电商支付中的
转载请注明：http://www.aierlanlan.com/rzfs/7938.html
