TiDB 整体概况

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

TiDB 数据主要来源：

通过 DM 从 MySQL 同步过来的数据，可以进行实时的数据监控，和一些即席的数据查询。
Kafka 队列里的用户事件数据，总体大概是3 亿条/天，不过我们会做定时清理，确保数据量在2天范围内。
我们自己放到 RocketMQ 里面的一些数据。这个数据是我们有一个 RocketMQ 的MySQL 插件，也是把 MySQL 的一些 binlog 实时进行处理，经转化为 json 放到 RocketMQ 里面，然后我们再去消费这个数据。

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

承载业务：

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

渠道实时转化业务

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

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

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

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

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

作者介绍：

黄龙，360 金融数据小组负责人，TiDB User Group (TUG) 大使。

本文转载自 AskTUG。

原文链接：