2023年7月17日发(作者：)

数据仓库——数据采集与同步【系统埋点设计】系统埋点设计1、数据分类在⼯⼚环境中，我们将数据仓库获取的数据划分为业务数据和⽤户⾏为数据。1. 业务数据：业务流程中产⽣的交易、状态流转、⽤户等相关的数据，通常存储在 DB 中， 包括 rdbms、nosql等，这部分数据是业务相关的，具体哪些数据需要保留⼀般由业务侧设计，不需要过度关注，按实际需要采集即可。2. ⽤户⾏为数据：⽤户在使⽤产品过程中，与 C 端产品 (⾯向个⼈消费者的产品，⽐如：微信、头条、抖⾳、美团等等) 交互过程中产⽣的数据，⽐如页⾯浏览、点击、停留等，这部分数据由于不影响业务流程本⾝，所以通常不受关注，但对运营、产品优化⾄关重要，所以通常也是数据建设的⼀部分，需要单独设计数据埋点、采集策略。2、⽤户⾏为数据埋点设计⽤户⾏为数据埋点的设计有三个关键点：1. ⽤户标识体系建⽴2. 多屏⽤户标识打通（多屏：⼿机、PC、Pad）3. 埋点⽅案设计2.1 ⽤户标识体系建⽴在电商场景中经常会遇到⽤户在不登录/注册的情况下访问⽹站的情况，对于电商平台来说，希望能够收集到⽤户所有的访问⾏为数据，包括⽤户在未登录/注册之前的⾏为数据， 这就涉及到了⽤户标识的问题，如何在⽤户不登录/注册的情况下对⽤户进⾏标识，并且将不登录/注册情况下的⽤户⾏为数据追加到⽤户完整的⽤户⾏为数据中，这是⽤户标识体系需要完成的⼯作。同样的，对于运营、产品和研发部门，需要根据⽤户在注册前后的⾏为，明确是什么吸引了⽤户最终完成注册。因此需要将⽤户注册之前的⾏为与注册之后的⾏为关联起来，也就是将注册前后的信息打通。2.2 ⽤户标识建⽴⽅案考虑到移动端和 PC 端的区别，我们在建⽴⽤户标识时划分两个场景，分别是 PC 端和APP 端：1)PC 端PC 端的电商平台在浏览器中进⾏展⽰，也就是以 H5 的形式进⾏展⽰，采⽤ cid 和 uid 相结合的⽅式对⽤户进⾏标识。cid：类似于 cookie id，但不是 cookie id，cid 随着不同的⽤户切换在改变，我们的⽬的是⽤ cid 来标识⽤户，同⼀个⽤户在不同的屏幕上是不同的 cid。uid：是⽤户注册后分配给⽤户的，可以唯⼀标识⼀个⽤户的序号。2)APP端APP 端同样采⽤ cid 和 uid 相结合的⽅式对⽤户进⾏标识。uid：是⽤户注册后分配给⽤户的，可以唯⼀标识⼀个⽤户的序号。以上的两种⽅案都引⼊了 cid 和 uid 的概念，只不过不同的平台 cid 的定义不同。在⽤户注册/登录前，使⽤ cid 作为设备标识，跟踪⽤户⾏为数据；⽤户注册/登录后， 使⽤ uid 标识⽤户，跟踪⽤户⾏为数据。① ⼀个新设备，从来没有访问过电商平台，第⼀次⽆登录访问时，电商平台给他分配⼀个 cid，然后，⽤户登录了，由于不是切换⽤户，那么 cid 不变，登录后的数据有⼀个 uid， 根据登录后的 cid 和登录前的 cid 进⾏数据的匹配。② ⼀个新设备，从来没有访问过电商平台，第⼀次⽆登录访问时，电商平台给他分配⼀个 cid，然后，⽤户注册了，由于是新注册，cid 不变，⽤户登录后电商平台分配给他⼀个新的 uid，根据登录后的 cid 和登录前的 cid 进⾏数据的匹配。③ ⼀个⽼设备，⼀个⼈登录后，cid=xyz，uid=123，退出登录后，cid 不变，uid 不变， 之后所有的未登录访问⾏为的 cid 和 uid都是上⼀次登录的⼈的 cid 和 uid，因此全部会被划分到上⼀个登录的⼈的⾏为⾥。④ ⼀个⽼设备，⼀个⼈登录后，cid=xyz，uid=123，退出登录后，cid 不变，uid 不变， 之后有⼈再次登录，如果 cookie 中的 uid和之前的不⼀致，那么判定为⽤户登录切换，是不同⽤户，cid 改变，uid 改变，如果 cookie 中的 uid 和之前的⼀致，那么 cid 和uid 都不变化。根据③可知，如果⼀个⼈登录后再推出登录，在下次登录之前，即使是多个不同的⼈访问了电商平台，也会被记为上次登录的⼈的访问⾏为。虽然 cid 并不是⾮常精确，但是他能够让数据找到归属。2.3 多屏⽤户打通⼀个⽤户可能同时拥有⼿机、平板、电脑等设备，我们将多种不同的电⼦设备称为多屏。我们希望能够将同⼀个⽤户在多屏上的数据进⾏打通。同⼀⽤户在不同屏幕上的 cid 是不同的，但是 uid 是相同的，但是如果只使⽤ uid，那么注册/登录之前的数据就会丢失，因此必须将 cid和 uid 结合使⽤。综上所述，通过 cid 和 uid 相互结合，实现未注册/登录数据与注册/登录数据的整合，然后通过 uid 实现多屏数据的打通。2.4 埋点设计2.4.1 埋点对象分类在⽣产环境下，我们主要的埋点对象有两类：Native APP、Web H5。PC 端的⽤户主要访问的是 H5 页⾯，移动端⽤户主要是使⽤ APP 进⾏访问，当前我们所接触到的APP 有多种类型，如 Native APP、Web APP、Hybird APP，在详细讨论埋点设计之前，我们先了解⼀下⼏种不同的 APP：1)Native AppNative App 是⼀种基于智能⼿机本地操作系统如 iOS、Android、WP并使⽤原⽣程式编写运⾏的第三⽅应⽤程序，也叫本地 app。⼀般使⽤的开发语⾔为 JAVA、C++、Objective-C。Native App 因为位于平台层上⽅，向下访问和兼容的能⼒会⽐较好⼀些，可以⽀持在线或离线，消息推送或本地资源访问，摄像拨号功能的调取。但是由于设备碎⽚化，App 的开发成本要⾼很多，维持多个版本的更新升级⽐较⿇烦，⽤户的安装门槛也⽐较⾼。2)Web APPWeb App 就是运⾏于⽹络和标准浏览器上，基于⽹页技术开发实现特定功能的应⽤。WebApp 是指基于 Web 的系统和应⽤，其作⽤是向⼴⼤的最终⽤户发布⼀组复杂的内容和功能。当⽤户登录⼀个⽹站（如百度、淘宝），⼤家很容易理解这是在访问⼀个 Web App。但是对那些仅仅提供基础服务（如电话查询或是信息查询）的⽹站，区分⽤户是否在访问 WebApp 就变得相当困难了。其实这些服务⼤多都是 Web App。常常这样问⾃⼰“这个程序是否完成了某个任务？”。即便它只完成了某个⾮常⼩的任务，那么它也是⼀个 Web App。Google 的搜索引擎就是⼀个 Web App，它本质上和电话查询服务没有什么区别。3)Hybrid APPHybrid App（混合模式移动应⽤）是指介于 web-app、native-app 这两者之间的 app，兼具“Native App 良好⽤户交互体验的优势”和“Web App 跨平台开发的优势”。Hybrid App 虽然看上去是⼀个 Native App，但只有⼀个 UI WebView，⾥⾯访问的是⼀个 Web App，⽐如街旁⽹最开始的应⽤就是包了个客户端的壳，其实⾥⾯是 HTML5 的⽹页，后来才推出真正的原⽣应⽤。再彻底⼀点的，如掌上百度和淘宝客户端 Android 版，⾛的也是 Hybrid App 的路线，不过掌上百度⾥⾯封装的不是 WebView，⽽是⾃⼰的浏览内核，所以体验上更像客户端，更⾼效。Native APP ⽆法获取 URL 相关信息，Web APP ⽆法获取设备相关的信息，因此，市⾯上现有的 APP ⼤部分是 Hybird APP，它兼具Native APP 和 Web APP 的特点，能够同时获得设备信息和 URL 信息。通常设计埋点时针对 Native App、Web H5 采⽤不同的规范，但不利于数据整合和使⽤， 推荐采⽤事件模型进⾏埋点设计，即把⽤户的⼀切⾏为动作都看作事件，包括页⾯浏览、按钮悬停、点击等，这样 Native 和 H5 统⼀数据标准，实际数据仅参数上的区别。2.4.2 埋点分类根据埋点位置，可分为客户端埋点、服务端埋点。两种埋点⽅式各有利弊，⽐如服务端埋点对⽆后台请求的⽤户⾏为⽆法捕获（⽐如⽤户在页⾯上的悬停，这种事件是有意义的，⽐如⽤户会悬停在感兴趣的品类、商品或者⼴告上），⽽客户端埋点可能会由于⽤户的环境问题存在数据包丢失，客户端可能⽆法获取全部的数据（有些数据存储在服务端，因为页⾯不会存储过多不会经常使⽤的信息，客户端需要⼀些调⽤才能够获取到，对性能会有影响）等，所以⽆特殊情况下，建议采⽤服务端埋点⽅案。APP 的更新时是周期性的，你没有办法强制⽤户去更新 APP，如果在客户端埋点的话就会由于版本更新的问题没有办法改变埋点，但是如果在服务器埋点的话就没有这个问题， 可以在服务器端按照需求设置埋点，不关⼼ APP 的版本。如果有⼀些类似于悬停这种事件，服务端⽆法捕获到，⽽这些事件⼜是⾮常重要的，那么可以在页⾯上加⼊⼀些代码，当发⽣这些事件的时候执⾏⼀个请求服务器的动作，让服务端进⾏埋点，负责这部分数据的落地。3、业务数据埋点设计业务数据⼀般存储于 rdbms 中，由业务 RD（研发⼯程师） 根据业务流程设计，具体记录信息⽆需过度关注，但在可能的情况下，尽可能提出相应的规范。① 每张业务表必须有⾃增 id 能够唯⼀标识⼀⾏记录。② 必须包含该记录的写⼊时间(created_time)、数据更新时间(updated_time)，部分表最好能够在updated_time 列构建索引（⽅便后续的数据采集，根据时间进⾏数据的获取）。独⽴的业务数据埋点：由业务服务端根据具体场景的需要，独⽴记录和业务强相关数据⽇志（不是⽤户⾏为数据），通常落地于相应业务应⽤的服务器磁盘，需要单独采集， ⽅案可以参考⽤户⾏为数据的采集。4、数据埋点案例分析4.1 背景某电商平台，产品覆盖 app、pc 端，其中 app 为 hybrid 架构，业务数存储 mysql 库中。4.2 需求需要分析⽤户访问路径、各步转化、流失等，进⾏页⾯优化、运营效果评估、商品推荐。4.3 设计埋点规范①⼀切⽤户操作⾏为都看作事件②应覆盖事件的核⼼要素4.4 数据格式为确保灵活、可扩展性，上报数据采⽤ json 格式，不要太深的嵌套（99%的埋点都是⼀层），将数据分为两部分：公有参数、⾃定义私有参数。① 公有参数公有参数需要覆盖事件核⼼要素，实际上报数据时不可缺失。埋点数据公有参数：② 私有参数私有参数即根据事件发⽣时的场景、需求，定义需要抓取的数据内容。某种意义上该部分数据也分公共参数与私有参数，⽐如事件发⽣在 app 中，⼀般都会伴随当时的设备信息；事件发⽣在 h5 中，⼀般会伴随 url。对于⼀般的推⼴ H5，需要抓取基本数据：currurl（当前页⾯的 URL）、refferurl（上⼀级页⾯的独⽴ URL）、refferpage（上⼀级页⾯的独 ⽴名称）（适配 App 页⾯）、sourceid（跟踪访问的源头，是微信、微博还是其他的推⼴平台，⽤以判断哪边的推⼴效果更好）、⾃定义参数(⽐如商品 ID、活动ID、商家 ID、posid 等)。对于 App，⼀般需要附加设备信息：refferpage（上⼀级页⾯的独⽴名称）、⾃定义参数( 商品 id、商家 id 等等)、设备信息(imei、idfa、os、gps、wifi 等信息)。对于 hybrid APP：其中包括 native 和 h5，虽然是 h5，但由于在 app 中，依然能够拿到相关设备信息，因此按照 app 的参数设计进⾏埋点，同时也要包括 h5 ⾃⾝的特有数据，⽐如 url、refferurl 等。4.5 埋点数据内容设计4.5.1 APP 启动埋点本着抓取⾼价值、符合需求、不影响⽤户体验和性能的原则，仅在⽤户启动 app 时触发，在⽤户授权的情况下抓取⽤户⼿机中安装的 app信息、通讯录信息，频率可以⾃定义。4.5.2 列表页1) 普通版本：2)计费版本⼀:页⾯采⽤翻页模式，⼀页只有⼀个事件，进⼊列表页后，将这⼀页的所有商品进⾏上报。3)计费版本⼆对于精确的曝光计费，特别是滚动刷新的⽅式（⾮翻页），⽤户不真正看到商品是不是计⼊ goodlist 的，之后⽤户真正滚动到了商品的位置，才会计⼊ goodlist，上报服务器。在计费⽅式⼆的情况下，会随着每次页⾯的翻转发送⼀条列表页⽇志数据。4.5.3 详情页1) click2) previewpreview 事件的 PV（page view⾯浏览量）往往低于 click 事件，因为有的访问会加载失败。如果 preview 和 click 相差太多（同⼀个页⾯），那么就要审视是否是产品出了问题，为什么这么多次没有加载出来，是后台性能太差还是⽹络⼀直有问题。4.5.4 ⾸页我们关注⽤户是通过什么途径进⼊主页的，这就涉及到渠道推⼴，因为很多电商在其他平台进⾏推⼴，⽽推⼴是需要交纳⼀定费⽤的，⽽其他平台向你提出的收费额度，你怎么确定是否准确，就要通过⾸页的埋点进⾏采集。4.5.5 banner(横幅)页⾯上的不同⼴告位的定价不同，同⼀⼴告位会有多个⼴告（滚动屏，⾃动切换），这些⼴告由于前后位置的不同收费不同，除了⾸页占据⼤⾯积的滚动屏，还有固定位置的⼴告。埋点参数等设计完毕后，提交相关开发组开发。若存在客户端埋点，需考虑⽤户⽹络环境下的数据丢失、数据上报性能：对于 h5，实时、异步上报。对于 App 客户端缓存，⼩批量压缩上报，尤其是数据⽐较⼤时；⽐如缓存 3s 或者数据⼤于 1M 主动上报。4.6 埋点数据采集系统搭建埋点数据的采集⽅案有多种选择，下图为企业常⽤的埋点数据采集⽅案之⼀：如上图所⽰，APP 以及 H5 端的埋点数据⾸先被发送到 Nginx 中，由 Nginx 负载均衡到Tomcat 服务器，Tomcat 服务器中部署的Servlet 接受埋点数据，处理后调⽤ Kafka API 发送到 Kafka 集群，离线数据处理和实时处理分别通过 Kafka 消费者消费 Kafka 集群中的数据， 然后进⾏后续的处理⼯作。根据 Kafka 消息队列的特性，消息队列实现了⽣产者与消费者的隔离，在上述的采集⽅案中，控制层的 Servlet 为⽣产者，数据处理层的离线业务或者实时业务为消费者，通过 Kafka 的特性，实现了控制层与数据处理层的隔离。离线业务消费埋点数据后，会将⽤户⾏为数据写⼊ ODS 层的表格中，之后在数据仓库中进⾏数据的分析处理。实时业务消费埋点数据后，会对数据进⾏实时的分析和处理，之后存⼊数据库。4.7 数据同步策略4.7.1 增量型1）.⽆状态变更数据假设数据源是流⽔数据，此类数据没有状态变更，写⼊数据库后基本不再改变，数据中⼀般包含 Created_time 信息，可以根据Created_time 的值获取增量数据，或者记录上次的获取到的 ID，然后从下⼀个 ID 开始获取，这是⼀种纯增量采集。2）.有状态变更数据假设表⽐较⼤，⽐如说⼀些订单表，这些表的状态变化周期⼀般偏长，状态变化⼀直会更新，⽽且状态变化会跨零点。此时要求所有的源系统数据库的设计需要加⼊ Created_time、updated_time，在 Source层把昨天发⽣变化的数据抽取过来（updated_time >= T-1 0:0:0），没有设置 updated_time < T 0:0:0，因为你昨天对数据进⾏了修改，可能在今天采集数据之前⼜进⾏了修改，因此，只要昨天修改过就符合抽取条件，如果想更更精准地获取数据，或者说让抽取的数据量⼩⼀点， 那么可以加⼊Created_time 的限制条件（updated_time >= T-1 0:0:0 and Created_time < T 0:0:0），通过这种抽取条件就可以获得昨天更新的数据和昨天新增的数据。获取到更新数据后进⾏合并，两张表进⾏⽐对（根据主键进⾏⽐对）：（A 表为 T-2 全量数据，B 表为增量数据）1. 如果 A 表中包含的数据（根据⾃增主键判断）在 B 表中也包含，那么就代表数据在昨天发⽣了变化，那么就⽤ B 中的数据替换 A 中的数据。2. 如果 A 表中没有的数据在 B 表中包含，那么就代表数据时昨天新插⼊的，那么就将 B 中数据插⼊ A。3. 如果 A 表中包含的数据在 B 表中没有，那么就代表数据在昨天没有被更新；经过上述逻辑后，将更新后的全量数据放到 A 表的 T - 1 分区中，成为了 T - 1 的全量数据，按照这⼀规则，每⼀天的全量数据都会被保存⼀份。完成数据更新后 B 表就可以被丢弃了。4.7.2 全量型假设表不是很⼤，⽽且数据状态会发⽣变化，可以进⾏全量采集，采集所有数据。此表格每天⼀个快照，累计时间长了之后，数据量也会很⼤。数据仓库中的表格 Dw_a 按照⽇期进⾏分区：每个分区中保存的是全量数据（全量快照）。不论是全量抽取还是增量抽取，每个分区Dt 中保存的都是截⽌到当⽇最后⼀刻，这张表的快照。05-09 是 5 ⽉ 9 号的全量快照，5 ⽉ 10 号时，采集当天的增量数据 A_incr-20180510， 然后⽤增量数据 A_incr-20180510 和Dt=2018-05-09 中的数据进⾏合并，写⼊ Dt=2018-05-10 分区中，这样就能保证 0510 是全量数据。如果没有发⽣变化，那么 5 ⽉10 号的快照和 5⽉ 9 号的快照是⼀样的。所有的表都可以采⽤这种⽅式，但是我们考虑，如果表的数据不是很⼤，那么使⽤全量采集也没有问题，但是随着数据量的不断增加，每天进⾏全量采集的代价越来越⾼，此时可以考虑使⽤增量采集。例如订单表，本⾝数据量很⼤，变化周期长，那么可以直接采⽤增量采集。