TiDB 在实时渠道转化分析的应用

作者： 张鱼小丸子 -PingCAP 原文来源：https://tidb.net/blog/a1326684

本文整理自 TUG 大使、360 金融数据小组负责人黄龙在 8 月 25 日 TUG 华南区首次线下活动的分享。

TiDB 整体概况

TiDB 在 360 金融主要用来存一些实时数据。历史数据或者数据量很大的数据是存在 Hive 里面。

TiDB 数据主要来源：

• 通过 DM 从 MySQL 同步过来的数据，可以进行实时的数据监控，和一些即席的数据查询。

• Kafka 队列里的用户事件数据，总体大概是 3 亿条 / 天，不过我们会做定时清理，确保数据量在 2 天范围内。

• 我们自己放到 RocketMQ 里面的一些数据。这个数据是我们有一个 RocketMQ 的 MySQL 插件，也是把 MySQL 的一些 binlog 实时进行处理，经转化为 json 放到 RocketMQ 里面，然后我们再去消费这个数据。

整体数据量：6T，接近 90w region

承载业务：

• 报表：渠道报表，产品报表，电商业务报表。

• 实时监控：之前使用 MySQL 做监控，现在通过 DM 同步过来 MySQL 的数据，放在 TiDB 上做实时监控。

目前部署了 5 个 TiDB 节点，10 个 TiKV 节点，运行了大概半年。

渠道实时转化业务

在渠道实时转化业务的设计中主要有四个方面的考虑：

• 转化漏斗实时查询：之前把渠道转化数据拉出来通过邮件发给大家，比较慢。现在可以做指标对比，同比分析，选择相关查询条件查询不同转化漏斗的数据。

• 节点流失用户查询：节点间跳转时候流失的用户，查看这些用户的信息，并据此做用户召回。

• 转化率同比环比分析：将查询的漏斗转化数据与昨日、上周当日做对比，分析问题。

• 用户事件分析：针对转化一场的流失用户，取这批用户的唯一标识 ID 查询其用户事件，推断异常原因。

数据处理

数据结构设计

当时的设计原则必须要让查询简单，我当时想法是必须要做单表查询。如果把事件分散到不同的表里，然后去查转化率，做表的 Join，性能肯定是非常低的。我们当时设计关键的三个转化率：H5 渠道注册转化，APP 渠道注册转化，渠道完件转化。

• 渠道完件转化从登录开始算，同一用户每一个环节节点都会写入对应用户记录的节点时间字段，以确保查询过程中不出现表 Join 操作，提高查询效率。

• 表字段有两种类型：维度字段，包括 H5 指纹，请求 IP 等设备信息；事件发生时间字段，包括看广告的时间，发送短信验证码的时间等。

• 查询逻辑：依据选择转化业务、渠道和时间范围条件，查询这些条件下的相应事件以用户标示去重的数量即可。

数据处理逻辑

• 实时消费指定埋点数据写入 / 更新至 TiDB：根据转化事件基础配置，消费 Kafka 中指定的用户事件，并写入 TiDB 的指定转化表，对于满足时间窗口范围要求的后续事件，一般是更新相应表数据的事件时间字段。

• 实时消费指定 binlog 数据写入 / 更新至 TiDB：根据转化事件基础配置，消费 RocketMQ 的 binlog 事件，将其依照配置的规范转化为相应事件，并根据转化事件的时间窗口配置更新相应表数据的事件字段。

如何阐述我们转化率表现的一些数据：

• H5 渠道注册转化：insert 250w+/ 天，update 100w+/ 天

• APP 渠道注册转化：insert 50w+/ 天，update 10w+/ 天

• 渠道完件转化：insert 20w+/ 天，update 40w+/ 天

查询界面展示如下，查询条件略掉：