投递工作面临的问题主要有以下几个点:
-
缺乏整体的规划,投递数据使用难度大。就是大家可能在使用的过程中说,在不同业务当中同样的字段不一样,或者不一样的还以同样的字段,或者在同一个业务因为时间的前后性,在一年前做的字段还有用但一年之后它就代表了另外一种含义,又或者产生了一个相同含义的另一个字段,这就造成了后续使用数据的难度特别大;
-
管理力度不足,后期维护成本极高。这其实也是一个双刃剑,如果管理力度过高的话,业务在使用起来就会觉得约束性比较强,效率就会有所降低。但如果管理力度不够的话,就会造成一种随用随投的过程,最终导致了历史延续性很差,维护成本极高。同时,如果没有工具和平台去统一维护和管理的话,大家会以各种形式来传递这些信息,导致沟通成本也相当高;
-
缺少共用的约束和校验环节,投递质量难以保证。由于没有一个统一的规范,导致后续对投递质量校验和监测的过程中,也就没有统一的标准,最终导致投递质量难以保障;
-
字段等定义不一致,跨业务数据打通很难。作为一个公司,不同业务线的数据在各自业务线发挥的价值要远远小于数据能跨业务向打通的这种价值。所以,当字段的这种跨业务线定义产生很大的差异,或者完全不一致的情况下,这种跨业务数据难打通造成的数据的价值流失特别严重。
3、数仓体系
下图右侧是一个简化流程,依据Pingback规范建设Pingback管理平台,同时开发了一整套的Pingback SDK。业务在使用SDK的时候,把这些用户行为投递出来并进行收集,通过ETL输出到测试统计和灰度监测这两个平台上,通过两个环节对数据质量进行校验,尽可能地把投递问题堵截在全量发布之前。
我们主要是从五个角度去输出中台能力,分别是服务、数据、平台、投递、标准/规范。在爱奇艺数据中台的实施过程中,我们划分出了三个大方向:
-
生产,也就是我们所说的投递体系;
-
数据,也就是统一数仓的体系,是数据的核心;
-
大数据平台能力:包括开发、治理、服务。
日志投递:
-
这部分我们输出了投递规范,进一步针对投递规范,我们需要对公司的相关员工进行培训,让大家深刻地理解投递是为了做什么,并且怎样才能达到我们对于用户的行为足够深入的分析要求。
在平台和工具这个角度,我们封装了Pingback SDK来满足不同端的投递工作,比如安卓、iPhone等;通过Pingback SDK去帮助业务实现通用化的工作。同时我们帮助投递管理的同学提供了一个管理平台,并且在数据的使用当中提供统计测试平台和灰度监测平台。
大数据平台:
-
我们有一线开发、对应的运维管理、实时开发对应的运维管理,以及数据治理、数据图谱、数据服务和即席查询。即席查询是我们数据服务里的一个子项,但是因为应用面比较广,就单独拎出来了。
统一数仓:
-
最后一块是统一数仓的能力,也就是为下游提供离线和实时的两种数仓能力。为了方便大家实现跨离线和实时混合使用的场景,需要进行标准化的工作,也就是离线输出的字段、定义、口径、格式和实时数据要尽可能一致,即实时数据向离线数据看齐。
同时,数仓在提供数据本身的能力之外,我们还要维护整个公司级别的指标体系和统一维度,让所有的数据系统平台和都会对接到统一的维度指标体系。而且,为了帮助数仓建设过程中的数据建模和统计指标的管理,我们建设了一个对应的数据平台,也是按照数据规范的标准建设,以此来支持使用方使用平台依照规范去建设数仓的流程化工作。
2、Pingback体系
Pingback的体系就是投递体系,那么具体为什么要做这个事情呢?

(编辑:鹰潭站长网)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|