埋点、数仓到中台：数据体系的从0到1

　　埋点、数仓到中台：数据体系的从0到1

　　前言：有幸深度参与了公司从无数据，到有数据，到开始注重数据，最后才能尊重数据结果，参考数据进行决策的过程。本篇文章是笔者在这个过程中，作为数据产品搭建数据指标体系，如何踩坑、出坑，以及对数据库房建设中的一些总结。

　　如标题所言，如果贵司早已是B轮过后，数据指标和平台化产品应当早已比较完善，属于数据产品应用阶段。如果贵司处于B轮及B轮之前阶段，大机率上会出现笔者下边所描述的情况。

　　本文较长，目录如下：

　　1 混乱期：资源有限，功能为先，忽视数据

　　1.1 资源永远不够用

　　1.2 数据产品的困境

　　2 规范期：他山之石：GrowingIO和神策

　　2.1 GrowingIO平台实践总结

　　2.2 神策平台实践总结

　　2.3 他山之石后的埋点设计及管理

　　3 平台期：建设数据库房

　　3.1 数据维护及*敏*感*词*

　　3.2 数据库房构架设计

　　4 未来：数据中台？

　　4.1 我理解的数据中台

　　4.2 数据中台学习资料推荐

　　------正文分割线------

　　1 混乱期：资源有限，功能为先，忽视数据1.1 资源永远不够用

　　笔者所在的内容服务公司，在搭建指标体系前，已经“裸奔”了3年。对于内容产品来说，最影响用户体验的是内容本身，公司前期借助不错的内容口碑，搭上知识付费的风口，发展迅速，公司资源和业务方向更多是受营运驱动、销售驱动，目标简单而明晰，做哪些心中都有大致预判，轻轻拍拍耳朵，这事儿就定了。后来平台用户数达到第一个1000w，日活步入50w量级后，新人加入，业务线也在拓展，基于主线业务上的优化和探求，不敢再轻易拍脖子了；各业务线也有不同的诉求，如何衡量优先级和协调资源，没有数据，很容易相持不下。

　　也是在哪个时侯，决定要参考数据来决策了。之前APP偏向于做功能，只在特殊功能点，或活动节点时，会在产品需求文档中，附上埋点需求。彼时猛然想看好多数据，会发觉不仅一些大数据（日活、激活率、付费率等）外，缺少好多细部数据，因为压根没有做埋点上报的需求，从日志中也未能解析出相关数据。

　　后来在每位版本中，由功能产品总监附上相关功能的埋点需求，大部分开发资源还在具体功能开发上。在功能上线后许久，才会想起来捞数据瞧瞧疗效。初创公司很容易在业务快速扩张中忽略数据的作用，产品开发团队首要解决的是不断新增的业务需求。资源总是不够用的，所以数据埋点处理、数据剖析、复盘等工作仍然处在被忽略的地方。

　　1.2 数据产品的困境

　　彼时我转岗到数据产品，常调侃自己是一个取数机器。公司有数据需求的部门共有7个，我负责对接各部门的数据需求，梳理清晰后再递交任务给大数据组，由她们做具体的ETL工作。这中间，常会身陷到以下的汪洋大海中：

　　与需求方沟通并最后明晰最后的数据需求（比如：活动组提需求想看某活动页分享数据，经沟通以后，其目的是想看新页面的文案上线后，对分享/浏览比的影响，因此明晰了该需求是该页面的uv、pv，以及分享控件点击的人数、次数）；

　　提交明晰需求后，大数据组发觉之前没有埋点，然后须要跟需求方解释，这个数据为何拿不到，从ta的剖析目标再瞧瞧，是否还有其他数据也才能达成这个剖析目标。

　　那段时间十分繁忙，但总觉得自己是个二传手，最大的收获，就是在对接了N个需求以后，发现我司的数据基础建设情况惨不忍睹：平台埋点不规范、数据指标定义不统一、业务数据库和数据库房标准不统一、数据需求处理周期长…… 我的精力好多耗在沟通需求、管理需求上。后来与公司的数据剖析部门一齐讨论制订了一套新的数据递交流程：每个部门的需求汇总到部门中的一个数据对接人，由ta先行递交到数据剖析组，简单需求，会由数据剖析组通过DBeaver等工具，连接数据库导入，复杂类、工具类需求，则递交给我：

　　

　　图1：数据需求递交流程

　　另外，针对每位部门的数据对接人进行了指标定义的说明，以及递交数据需求的规范标准的培训：

　　

　　图2：培训资料一页：什么是好的数据需求

　　此时的工作还逗留在偏临时需求的处理上，作为数据产品，却没有作出多少数据产品下来。

　　2 规范期：他山之石：GrowingIO和神策

　　在决定搭建数据体系后，我司商讨了几家背部的数据平台，如GIO、ThinkingData、神策等，来补充我司埋点功力薄弱的问题，最后选择了GIO，在使用了一年多以后，因为要做私有化布署，而GIO的私有化布署功能还刚处在开发阶段（写这篇文章的时侯，他们的私有化布署早已做下来了），于是我司又决定换神策平台，重新来一遍POC和SDK接入工作（对，就是如此折腾，o(╥﹏╥)o）。在完整地对接了这两家平台以后，我司数据体系逐渐迈向规范，我也总结了一下两家平台关于指标管理、数据体系搭建的工具特性，以及思路进行了一些总结，如下。

　　2.1 GrowingIO平台实践总结

　　在接触了几家平台后，我们最终选择了GIO，该平台的特性特别显著：

　　拥有无埋点技术，能够实现做功能时，不需要专门针对埋点耗费工时，接入GIO的SDK，在功能上线后，SDK才能采集基础使用信息，同时，针对页面浏览数据，和页面控件点击数据，可以通过“圈选”的形式实现（对于彼时苦于埋点效率低下的现况，这种方案极具诱惑）；

　　公有云布署，接入成本低；

　　后台操作界面简约，属于营运思路的一款产品，上手较容易；

　　因为是SaaS服务，线上问题反馈速率比较快。

　　但后来发觉一些问题：接入SDK后，我们只简单对接了会员状态数据，做了少量的埋点指标，除据悉自动圈选了大量页面指标和控件数据，因为GIO的圈选功能实在很好用了，所见即所得，不必再发版等埋点上线，经过简单操作后就可以自己取数、看数，结合GIO提供的基础剖析工具，如风波剖析、漏斗剖析、留存剖析等功能，人人都能成为一名分析师了。

　　

　　图3：GIO圈选功能

　　但到后期，圈选数据的问题日渐曝露，也成为平台要更换GIO平台的*敏*感*词*。圈选数据的逻辑：是按照页面xpath路径，*敏*感*词*页面浏览风波，和页面上的控件的浏览、点击风波，保留7天，因此圈选完成后，能向前溯源7天的数据。圈选功能的问题主要在于：

　　耗流量，看下逻辑你应当能理解；

　　一旦版本迭代，对页面的路径做更改，或者控件位置、文案有更改，原来的圈选数据可能还会出错，需要重新圈选，之前借助圈选指标设定的剖析模型都要替换；

　　圈选指标难以分辨细部参数，比如：书籍详情页，无法通过圈选数据来分辨是哪一本书；

　　对web的页面数据处理仍然不好，尤其是涉及到APP的内嵌H5页时，非常苦闷。

　　

　　图4：版本升级后，某圈选指标数据突降

　　这似乎也是GIO的业务朋友比较推崇无埋点技术，而我司彼时经验尚不充足踩下的坑，到后半阶段开始补习，开始做客户端和服务端埋点了，埋点开发周期似乎长了点，但是起码才能用得上去。但是由于之前对GIO工具使用上形成的各类不爽，导致前面有了更准确的埋点后，大家用上去也经常怀疑，这数据准不准，能不能用？一旦对数据源形成不信任感，产研团队的解释成本高，数据发挥价值的周期变长，团队屡受指责又看不到成绩，大数据团队本身在数据体系建设的初期存在感就低，如此一来，工作积极性显得更低。

　　后来受资方等多诱因影响，我们须要做私有化布署，对数据的准确度、智能营运也有更进一步的需求，而彼时GIO还没有成熟的私有化布署功能，因此我们两家后来好聚好散，转而选择了神策。（此处抱着GIO的朋友哭一会儿）

　　但总体来说，GIO平台还是可圈可点，它的优势在于：

　　数据响应速度快，圈选功能比较成熟，对于快速迭代活动的场景，圈选功能最为方便；

　　用户操作界面友好，几大核心剖析功能逻辑结构清晰，学习成本低，能够实现在公司大范围推广使用（你千万别认为这类数据工具是可以轻易上手的，根据我在公司推广GIO和神策的经验，工具使用门槛并不低）；

　　售后团队比较专业，能够从剖析视角，发现我司业务上的问题；并且对平常提及的问题，反馈及时，问题解决程度也比较高。

　　2.2 神策平台实践总结

　　后来由于私有化布署的诉求，选择了神策平台的产品。这里解释下，为啥没有选择自己研制数据产品。这显然是一个太经济学的审视。在接入GIO前，我司有自己一套ubt的埋点系统，但是只是基础的数据采集，以及raw data进数据库，从raw data 到数仓，再到提取，把统计类数据以excel方式，或者教会剖析人员使用SSMS或PowerBI来进行取数剖析，中间流程很长，无法做到快速响应及反馈。而找一个团队自研，时间成本和人力成本都很高。

　　神策、GIO这样的平台，取数功能完整度比较高，而且有一个比较完整的可视化剖析平台，收录了风波剖析、漏斗剖析、留存剖析等基础的剖析功能，也有归因剖析模型、用户画像等功能，这些功能找一个大数据团队和几个算法工程师，一年的成本高了去了。对于B轮左右的公司，建议别折腾，花点钱，除了防止自研成本，还能从这种SaaS平台的服务中，了解到比较成熟的方法论。

　　神策的剖析全家桶有以下几款产品：

　　

　　图5：神策产品矩阵

　　其中，左边【数据基础能力】是基础服务，可以选Pass，也可以选私有化布署，但是节点费、流量费是按照自己的流量来核算。（市政单位，或者对业务数据安全敏感度高的，建议私有化。不是说Pass不安全，像神策、GIO这样专门做数据服务的平台，不至于去窃取顾客数据，一个顾客数据泄漏风波就可以使这类企业直接死掉，这个帐她们拎得清，而且有数据隐私合同）。右边的【数据应用产品】则是可选项了，【神策剖析】收录了风波剖析、漏斗剖析等基础的剖析功能，一般必不可少；【神策用户画像】和【智能营运】是偏向于营运侧的工具，如果自己没有精准营销的产研能力，这两项服务业比较好用。至于【智能推荐】和【神策客景】则依照公司情况，对于内容繁杂，品类繁杂的内容平台、电商平台，还是比较有必要。但我个人觉得，前三项服务玩得转了，再去考虑采购后两项服务不迟。

　　神策平台的特性是一开始推的是埋点方案，而非无埋点方案；而且最早支持私有化布署的数据服务平台。这一点是使她们才能获得一些金融行业、政企行业的单子的缘由。这也是我们最后评估后，选择她们的缘由。

　　2.3 我司平台的埋点设计及指标管理

　　在经过了UBT、GIO和神策三套埋点方案的使用和比较后，对于我司自己的埋点系统也有了比较清晰的方向，最后决定采用常规数据使用后端埋点、关键数据使用服务端埋点、临时活动搭配使用全埋点的方案。

　　全埋点、前端埋点和服务端埋点的区别

　　埋点方案

　　实施方案

　　优点

　　缺点

　　全埋点

　　部署对应sdk，页面及控件数据全采集，使用时解析

　　不需要做埋点开发；

　　需要用的时侯再去圈选使用；

　　所见即所得，圈选时就可以看见数据；

　　不需要测试介入，取数周期极短

　　新圈选时，只能向前溯源7天；

　　数据不够确切；

　　发版后会影响之前圈选数据的稳定性。

　　前端埋点

　　前端定义的风波触发时，上传对应数据

　　较为确切；

　　基本不会受页面改版影响。

　　有一定开发工作量；

　　设计新功能时须要考虑对原有埋点的影响，维护指标文档；

　　会受网路环境等诱因影响，出现数据难以上报或延时上报。

　　服务端埋点

　　服务端定义的风波触发时，上传对应数据

　　最为确切；

　　不受前台功能改版影响。

　　开发和测试的工作都较大；

　　不容易发觉问题。

　　而我司基本是后端埋点和服务端埋点的组合，其中关于数据指标的设计和管理，采用了右图所展示的数组名，对事实表进行管理和维护。

　　

　　图6：我司数据指标维护表头

　　关于数据指标管理，最使我头大的就是怎样保证可读性的前提下，梳理不断新增的数据埋点需求。我的设计思路是：以使用者视角设计，尽可能合并同类型指标，用维度保证扩展性，用备注内容保证可读性。

　　上面的指标维护表，是要同时给开发人员，和营运人员看的，这里指的使用者，是指营运人员。因为最后埋点设计做完了，也正常上报了，但是营运人员看不懂，用不上去，培训成本高企，是难以充分发挥数据价值的。所以在这里就须要数据产品总监平衡简洁和可用性。

　　举两个反例：

　　例子1：平台资源位埋点设计

　　对于通常互联网产品平台来说，资源位无外乎两种类型，弹出型和轮播型；而具体指标无外乎浏览和点击，因此，将这两种类型的资源位具象成下边4个指标，由维度（资源位位置、轮播位置）来进行分拆。

　　

　　图7：平台资源位埋点设计

　　例子2：内容详情页埋点设计

　　对于内容类、电商类平台来说，内容详情页和商品详情页是最为关键的页面，因此这个页面的浏览数据极为重要。因为详情页是一个通用页面，而且对于一篇文章，或者一个商品来说，可能会在APP出现多个入口，如果对N个入口进行分别埋点，会使指标建设冗余，并且由于网路环境等影响，点击数≠页面加载≠页面加载成功，可能会采到脏数据上来。因此我在这里的设计思路是：以页面加载成功为触发，区分页面本身的数据信息，以及上一个页面的维度信息。

　　

　　图8：内容详情页埋点设计

　　这里的挑战来自于去梳理上一个页面的类型和具体参数值，需要与营运组、数据组同学沟通清楚，他们关心的维度，以及下钻的颗粒度。

　　3 平台期：建设数据库房

　　建设数据库房是一个必然的选择，在业务体量不大，数据需求不多的情况下，从业务数据库捞数据，甚至解析日志，都是才能满足的。但后期必然会有更多维度、更复杂的分析型、报表型数据需求，全部借助业务数据库其实不现实。现在计算机储存成本不高，数据库房可以看做是一个【用空间换时间】的方案，数据库房是面向剖析、应用的数据库，在构建好标准的ETL流程和更新机制后，分析型、报表型数据需求从数据库房中获取，从而提升效率，也解放业务数据库，让业务库专心处理业务。

　　特点

　　面向对象

　　数据库

　　处理业务需求，实时性要求高

　　具体业务

　　数据库房

　　ETL后有比较明晰分辨的主题表

　　可并多个表、多个维度，支持复杂查询

　　分析型数据

　　目前有关数据库房的文章非常多，对数据库房应当分几层，也有好多说法。这里须要明晰一点，数据库房的分层是一个理念，其核心是将不同应用层级的数据进行界定。一般来说起码有五级，我司采用的也是五级数仓。

　　数仓分层

　　数据来源

　　特点

　　ODS

　　操作型数据、实时数据、日志数据等

　　近似 = raw data

　　EDW

　　ODS层

　　按明晰主题和维度进行ETL的数据表

　　DM

　　ODS层、EDW层

　　面向明晰应用，ETL获取的数据表

　　3.1 数据维护及*敏*感*词*

　　基于Hadoop的成熟体系，搭建完成数仓系框架后，接下来要做的是往数仓中填充数据“血肉”，以及持续进行数据*敏*感*词*的工作了。在用数据赋能业务的链条中：产生数据（埋点）-> 获取数据(ETL) -> 分析数据 -> 发现问题 ->业务决策，似乎并没有数据*敏*感*词*的事情。链条上的四点是可见的过程，而数据本身形成污染后，可能会到获取时、分析时，甚至是决策阶段，才会意识到数据本身可能出现了问题。数据从触发上报-> 发送-> ETL-> 进数仓，中间有任何一个过程出问题，都可能会影响数据的稳定、准确和及时。另外，不断扩充的业务需求，业务数据数组会发生变更，这时错传、漏传了数据进数仓，也会影响数据质量。

　　总结出来，基于下边三个点，需要持续进行数据维护和*敏*感*词*：

　　数据进仓链路长，存在出现脏数据的风险；

　　新业务需求增删改数组，没有及时同步进数仓；

　　数仓表结构数组设计扩展性不足，新数据须要单独建表，导致冗余。

　　针对第1点，我司对于数据指标本身的异常波动做了监控的设计。在接入了神策平台以后，该平台提供了一个指标异常波动提醒的功能，还很好用。

　　

　　图9：神策数据异常监控

　　针对第2点谈谈我司实践。我司通过搭建【异构数据平台】来解决业务数据同步到数据库房的问题。业务数据在进数据仓的同时，会根据约定的规范，同步传送一份到数据库房；如果有修业务数据的情况，也须要异步地通过该平台，发消息给数据库房，由数仓消费后，更新数仓的数据。

　　针对第3点，没有哪些好办法，需要数据产品和大数据组、业务产品总监多沟通，对于数仓目前有什么表，哪些数组，功能规划上，未来会新增什么产品线，与当前业务线的关系，有一个大致预判，最大程度降低重复建表的工作。

　　3.2 数据库房构架设计

　　基于以上，我司数据库房是基于Hadoop框架，Hive处理离线数据，Flink处理实时数据，实现用户行为数据和业务数据准实时入数仓（有一些延时），并且后端数据产品应用，从数据库房中调插口取数。（目前还没有完全实现所有业务数据都从数据库房走，还在建设中）

　　

　　图10：数据库房构架设计

　　4 未来：数据中台？

　　数据中台概念在19年实在很火了，颇有些12年，到处都在说O2O的情形。对于数据产品来说，将产出的数据产品抽象化、共用化，成为象中台一样的基础服务能力是心之所向。但是否应当盲目上中台项目，谈谈我的理解。

　　4.1 我所理解的数据中台

　　我很喜欢【中台】这个词：处于中间，承上启下；成为平台，隔绝上下流动，但自身提供服务上下的能力。对于数据中台，其核心是提炼各业务线的共性需求，将这种需求解决方案封装为标准化、组件化的解决能力，然后以插口的方式提供给前前台业务数据。从而实现尽量少地重复造轮子，尽量多地提升研制的敏捷性。

　　不是所有公司都须要立即做中台，但按照熵增定律，一家能持续发展的企业，其业务形态一定会不断发展和膨胀，而当新业务线和老业务线有共性诉求，能够通过中台化来提升效率，并且具有能串联多业务线的项目能力，这些问题想清楚，就可以开始做中台项目了。

　　4.2 资料推荐

　　在学习数据中台的过程中，整理了一些资料，如下：

　　数据中台到底是什么？

　　换个视角看中台的对与错

　　有赞零售中台建设方式的探求与实践

　　原文链接：/article/gaBwDw5Jkj