达达埋点迁移京东子午线实践 | 京东云技术团队
一、概述
1.项目价值及成果
使用集团的统一埋点采集能力和埋点平台,完成达达7条业务线共43个站点应用的埋点迁移,降低自研采集工具和平台的研发投入和机器成本,打通数据链路,创造更多的数据分析价值。具体降本增效价值如下:
1.1 数据分析价值:与京东流量数据打通,拉齐数据口径,流量串联
1)信息孤岛:快送与京东流量数据分离,库表访问成本高,也无法进行结合分析
2)数据口径:埋点规范对齐:比如广告位曝光、页面浏览等埋点上报规则,与京东的逻辑对齐,拉齐数据口径,提高准确度
3)用户信息串联:可以通过用户基础信息的串联,比如device_id,用户pin/supplier_id等,分析用户从京东入口进入的流量链路、以及进入京东流量的访问深度等等
1.2 减少迭代/维护人力成本:0.5人/年
1)天河平台迭代成本
2)流量传输链路运维成本
1.3 节省机器/中间件费用:2w+每年
1)减少2台云主机+估计2万左右/年中间件费用
2.项目节奏
二、方案调研选型
1.方案衡量
在初期,我们拟定了迁移方案一,但是考虑到迁移成本巨大,我们综合评估后,制定了方案二,基于迁移成本最小化等综合考虑,我们选取了方案一
方案详情 | 工作量 | |
---|---|---|
方案一 | APP、小程序、PC&H5各业务线分别进行改造和迁移 | 需做43个站点应用的SDK层适配 |
方案二 | 1)APP进行SDK封装,其他业务线只需接入即可 2)PC&H5在SDK层适配,其他35个应用方只需接入即可 | 需做3个SDK层适配,其他业务线接入即可 |
三、项目实现
1.上下游迁移流程
2.迁移技术架构
在接入项目之前,我们需要考虑两点
稳定:一方面项目需要整体平稳运行,另一方面也迁移前后数据差异保持在合理的误差范围内
高效:本次迁移涉及客户端、小程序、h5等数十个项目,节约开发成本也是关键
(1)方案选择
1、直接替换:由于项目众多,再加上每个项目中点位也很多,显然我们不能直接替换业务中的埋点,工作量太大,出问题的风险也会更高
2、切面替换:在埋点上报的某个环节中统一替换,这样好处是只需要修改一次,代码侵入性小,风险也可控,最重要的是工作量大大降低了
(2)方案设计
以客户端为例,旧的埋点框架包含埋点采集、存储、上报三个过程,并且是彼此独立的,我们很容易的就可以在埋点采集到存储过程之间进行切面拦截,将原本的埋点数据进行转换,如下图
旧框架架构图
(3)方案实施
在确定具体方案后,我们开始规划具体代码实现,考虑到需要替换的项目众多(以客户端为例,有达达骑士、 达达快送、洪流、孔明等项目),每个项目都去实现一遍无疑是有资源的浪费,我们把项目按端分成Android、ios、小程序、h5, 这样原本数十个项目,简化成一套方案,四端代码,各项目只需要简单的集成即可,这样节约了大量的人力资源
3.技术亮点
1、采用切面拦截迁移方案节约人力成本
2、统一封装与多端复用将埋点规范统一
3、数仓层:从京东实时topic直接消费落库,在库表层做京东和达达的数据结构兼容,达到下游报表层“无感知迁移”,将业务报表的影响和下游迁移成本最小化
4.踩过的坑
1、ios不支持后台上报埋点
问题:骑士和商家存在app退出前台,处于后台模式状态时候上报埋点的情况,但是子午线最开始不支持长时间后台上报埋点。
解决:子午线添加配置,支持不限时支持后台上报埋点功能。
2、ios网络问题
问题:首次安装app,在用户没有同意网络权限的情况下,子午线sdk会上报dau埋点,上报失败后重试3次再次失败触发2分钟限制,2分钟内不会在上报埋点。
解决:子午线单独提供无2分钟限制的包。
3、APP上报策略问题
问题:子午线默认上报策略为15s10条,导致部分用户没有触发上报条件退出app后无法上报已有埋点情况。
解决:子午线更新配置为2s2条。
4、uid为空导致埋点不落表
问题:新用户在未同意隐私协议前,不会获取用户的设备信息,导致appUniqueID传空,不会落入子午线离线表。
解决:在新用户在未同意隐私协议前,随机生成一段字符串并加密,作为设备id传给子午线,保证所有埋点都能落表。
5、小程序上报机制问题
问题:小程序达达sdk批量上报,子午线sdk是单条上报,会产生数据差异
解决:子午线sdk已支持批量上报
6、H5埋点量级过大时被丢弃
问题:洪流应用中,session_id大于10000次后数据会被子午线离线表丢弃
解决:同城数仓直接从实时topic消费数据,落离线表,不加session_id数量限制
作者:京东零售 周慧娴
来源:京东云开发者社区 转载请注明来源

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
00后如何组织双十一大促看这一篇就够了! | 京东云技术团队
引言 大家好,我是王蒙恩,一名“整顿职场”的00后。作为一名去年刚刚加入京东的校招生,我有幸成为本次CDP平台的11.11备战负责人。虽然早在实习的时候就经历过大促,但是真正组织整个部门的备战还是很难忘的。于是提起笔,给自己做一个大促总结,记录下11.11大促期间的经历、感受、收获。 11.11认知变化 记得我还在上大学的时候对11.11的印象就是和室友熬夜在整点的时候疯狂下单,本人有幸成为过哈尔滨南岗区剁手榜前500名。 一年前,我正式入职京东,告别了校园生活。那时候在11.11这一天,大家都很忙碌,加班到很晚。对我来说,11.11意味着免费的晚餐,还有非常多的美食(真香警告⚠️)。 在今年的618大促期间,我(打酱油的)参与了我们部门的备战工作。我负责其中一个接口的压测,以及一些配置报警和统计数据的工作。 得知本次大促由我来负责这个消息后,我充满了兴奋和动力,同时也意识到会面临巨大的技术压力和挑战。但这也是一次非常宝贵的技术锻炼和成长机会。 CDP平台是什么 平台能力 我本次所备战的系统人群画像(CDP)是一个以“用户为中心”,围绕数据融合、标签生产、群体数据服务(人群命中、标签取...
- 下一篇
高效开发与设计:提效Spring应用的运行效率和生产力 | 京东云技术团队
引言 现状和背景 Spring框架是广泛使用的Java开发框架之一,它提供了强大的功能和灵活性,但在大型应用中,由于Spring框架的复杂性和依赖关系,应用的启动时间和性能可能会受到影响。这可能导致开发过程中的迟缓和开发效率低下。优化Spring应用程序的启动速度和性能是一个重要的任务,通过分析和优化应用的初始化过程、减少不必要的依赖和组件加载、并利用异步初始化、懒加载等技术,可以显著改善应用的启动性能。这将帮助开发者提高开发效率、减少调试时间,并提供更好的用户体验。 线上的业务 jar 包基本上普遍比较庞大,动不动一个 jar 包几百 M,启动时间在10分钟级,拖慢了我们在故障时快速扩容的响应、以及本地开发调试效率。于是做了一些分析,看看 Spring 程序启动慢到底慢在哪里,如何去优化,目前的效果是大部分大型应用启动时间可以缩短 70%~80%。 主要有下面这些内容 SpringBean 加载耗时 timeline 可视化分析(✅) SpringBean 的可视化依赖分析(✅) 应用未加载的jar包(Jar瘦身)(✅) 应用启动过程线程wall clock火焰图(✅) 重要性和影响...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用
- Linux系统CentOS6、CentOS7手动修改IP地址
- 2048小游戏-低调大师作品
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器