京东小程序数据中心架构设计与最佳实践( 三 ) _小程序

所谓分层化，就是在同一个流量主题下，进一步按照ODS->DWD->DWS->ADS的层级结构进行数据分层，方便追踪数据血缘，减少重复数据模型的开发。
所谓多元化，就是复用度，加工好的这些数据，可以给下游的团队接入使用，比如商智，黄金眼，数纺这些团队。以小程序广告投放为例，在小程序数仓中我们构建了各个类型的用户群体，在数纺注册了用户群体标签，比如关注用户，粉丝用户或者提单用户等，下游的广告精准通系统会基于我们的这些标签进行人群的圈?。?进而实现小程序广告的投放。
总之，根据业务特点，充分利用好集团BDP的数据工具，帮助我们实现数仓的搭建。
六、基于FLINK实时计算，
落地小程序异常崩溃监控利器
痛点问题
京东小程序在线上运行时，需要实时监测到小程序的业务代码崩溃异常、性能数据波动，网络请求耗时等，在有异常崩溃的情况下，保证可以第一时间通知到商家开发者，帮助业务及时止损。
如何解决

报警规则可配置，基于Zookeeper分布式配置中心存储小程序自定义的告警规则，实时监听规则节点变化，当节点数据变化时，实时聚合到业务流；
自定义滑动窗口，每个小程序的告警窗口大小不一样，拓展实现WindowAssigner，基于用户动态规则确定告警窗口开始时间和截止时间；
广播变量，broadcast机制，将告警配置信息广播到各个Task任务内存，广播变量就是一个公共的共享变量，将一个数据集广播后，不同的Task都可以在节点上获取到，每个节点只存一份，否则，每一个Task都会拷贝一份数据集，会造成内存资源浪费。

文章插图

文章插图
【京东小程序数据中心架构设计与最佳实践】对于小程序的实时监控能力，我们采用flink作为实时计算的框架，小程序在线上运行时，需要实时监测到小程序的业务代码崩溃异常、这种异常很可能会导致小程序白屏或者闪退，需要在探测到有异常崩溃的情况下，保证第一时间通知到商家开发者，帮助业务及时止损。
这里的难点在于告警的规则是支持用户自定义的，比如配置观测多长时间窗口内的异常数据，当达到多少的异常阈值，应该去触发告警，应该判定为异常，这里是需要把告警规则配置的的主动权交给用户的，在这样的背景下：
我们采用的是将告警规则放到分布式的统一配置中心，实时监听节点规则的变化，将业务流和规则流进行co.NET双流合并；
然后根据告警规则，实现windowAssigner生成自定义的动态计算窗口，从而实现窗口动态化；
最后，采用广播变量的broadcast机制，当告警规则变更时，可以高效地将告警配置广播刷新到各个Task任务内存，提高资源利用率，保证计算时效性。
七、探索OLAP领域的黑马，
基于ClickHouse搭建自定义数据分析引擎
痛点问题
小程序内部的数据波动如何自由埋点分析？京东内部业务直接基于子午线埋点上报，业务团队内部自行分析；外部的开发者需要依赖神策,GA等外部的分析系统，无法将数据回流京东，且复用京东现有流量工具进行精细化运营。
如何解决

选择合适的表存储引擎：采用多副本的ReplicatedMergeTree，保证查询性能和数据存储的高可用；
天分区存储数据：PARTITION BY：分区键，PARTITION BY to YYYYMMDD(EventDate)，不同分区下的数据会分开存储，合理建立分区可以加快查询的速度；
统一上报协议：生成全局唯一事件ID，事件ID绑定业务数据；
动态数据解析：基于visitParamExtract函数解析json动态业务数据；
查询脚本下推：Sql引擎生成查询Sql，下沉至ClickHouse完成查询。

文章插图

文章插图
小程序内部的数据波动如何自由埋点分析？京东内部业务是可以直接基于子午线埋点上报，业务团队内部自行分析，但是子午线这种产品本身不对外开放，外部的开发者如果想分析小程序自身的内部数据，需要依赖神策，GA等外部的数据分析系统，这样的话，小程序的数据无法回流京东，那么也就无法复用京东现有流量工具进行小程序的精细化运营。