作者：lixiongxu，腾讯PCG后台开发工程师

| 导语作为一个开发，仅仅有开发监控看板是不够的，还是要有一个秒级数据看板

1. 背景

对于开发来说，当一个新的业务，活动上线的时候，不仅需要关注自己手上的服务监控数据，也需要关注业务数据。 之前对于我们这边一般的实现方案主要有下面两个

1.1 基于007上报实现数据监控

原理 具体实现方案为将一些业务数据，我们这边利用007的属性上报，上报到007的数据库中，然后这边利用007查询接口，将数据拉到本地，再以datatalk或者机器人播报的形式，展示出去

问题

1. 数据实时性 007的属性上报存在3分钟左右的延迟，对于一些场景，可能不够用
2. 007下线，游戏中心全面采用伽利略，新接口存在限频与调研成本
3. 数据不够用，这边只能支持后台主动上报的，如果有些纯前端不涉及后台的，我们这边无法感知。
4. 总感觉开发味道太重

1.2 基于灯塔实现数据监控

原理 对于一些业务数据，产品都是会让开发上报一份流水到dc表中。那这边就可以基于灯塔去清洗这个数据，然后生成看板，不过这条链路一般都是产品选择去做的。

问题

1. 延迟问题，这边数据会有半小时的延迟（主要是计算集群带来的）
2. 感觉更适合做的是天汇聚数据，而不是那种秒级监控看板

1.3 总结

所以之前的两条链路其实都是存在一定的问题，但是作为开发来说，总感觉需要一个数据看板，就是那种像双11一样，数字不断跳动的数据看板。

2. 基于clickhouse实现数据实时看板

2.1 数据源

从1可以看出来，我们的业务数据源主要有两种，一种是开发主动进行属性上报，一种是基于流水上报。 很明显，流水上报的模式更符合我们的要求，数据粒度更细，也符合产品统计的口径。 而且产品的上报已经规范化，但是属性上报是需要侵入业务代码。对于这个数据看板，我们的计划不是只做一个视图而已，而是要定一套规范，后面业务参照这个流程去实现看板就可以。降低接入门槛，提高资源利用。

2.2 clickhouse

我们这边场景是什么呢？

1. 写远远大于读
2. 不要求低延迟
3. 接受大批次更新
4. 不需要事务
5. 大部分场景只是计算uv，pv，不涉及复杂语句

这个时候clickhouse这个数据存储就很突出了。可以说刚好满足了我们的需求。

这边就不大量篇幅介绍clickhouse，有兴趣的可以自己调研一下

2.3 链路方案

确定了数据源以及数据库，那我们这边剩下需要解决的就是将整条链路串起来。

清洗链路

原始的上报数据源太复杂了，基本游戏中心所有的数据都会上报到表中，很多数据其实我们是不关心的，所以这边需要清洗，筛选出我们真正需要的数据。 这边的清洗逻辑我们采用了oceanus中台，这个平台只需要配置相关的sql，就能实现数据清洗。大大降低我们上手成本。也方便我们后面数据管理。

展示链路

这边主要有两种，一种是利用开源的grafana平台，另外一种是基于datatalk平台。综合来看，datatalk相对更友善一点，一些简单逻辑只需要拖拖拽拽就可以，如果没有特别多的要求，那么这边其实已经满足预期了。grafana的话，可能扩展性会更好一点，但是需要写sql，虽然扩展性比较好，但是可能每个图标都要去研究一下具体配置，有点麻烦，而且datatalk是公司内战略产品，在一些权限的管控上可能比云上的要好一点。

3. 流程样例

3.1 数据源出库

上报的表，一般类型都是atta，这边首先需要做的是将表进行出库到cdmq，变成可以实时消费的数据类型。

但是虫洞的数据消费与kafka还是不太一样，kafka这边直接新起一个消费者就可以，但是虫洞是需要你去申请一个消费组才能消费的。

3.2 clickhouse建表

我们clickhouse用的是腾讯云上购买的，这样配套设施比较好，有问题也有人维护。建表语句如下

// 建库
CREATE DATABASE qqmall ON CLUSTER `default_cluster`

// 建表
CREATE TABLE qqmall.pay_bill  ON CLUSTER `default_cluster` (
  `ftime` DateTime COMMENT '上报时间',
  `gc_order` string COMMENT '游戏中心订单号',
  `goods_id` String COMMENT '商品id',
  `uin` Int64 COMMENT '用户uin',
  `order_type` Int32 COMMENT '订单类型   1: 直购，2: 秒杀',
  `order_source` Int32 COMMENT '订单来源',
  `price` Int32 COMMENT '商品原价',
  `quantity` Int32 COMMENT '数量',
  `act_id` String COMMENT '活动 id',
  `act_price` Int32 COMMENT '活动价格',
  `real_price` Int32 COMMENT '真实支付价格',
  `pay_succ_ts` Int32 COMMENT '支付成功时间戳',
  `pay_platform` String COMMENT '支付平台',
  `pay_channel` String COMMENT '支付渠道',
  `goods_type` String COMMENT '商品类型'
) 
ENGINE = ReplicatedMergeTree() 
PARTITION BY toYYYYMMDD(ftime)
order by pay_succ_ts 
TTL ftime + toIntervalMonth(2) 
SETTINGS index_granularity = 8192

然后这边ReplicatedMergeTree后面是不用加东西的，集群会默认帮忙加，可以通过控制台看到具体执行的命令,其中order by决定了每个分区中数据的排序规则

3.3 清洗任务

清洗任务首先需要建立两张表，一张来源表，一张是入库表。对于我们这个场景，来源表就是远端cdmq，也就是kafka，入库表就是对应clickhouse.

3.3.1 oceans上kafka表的建立

我这边采用的方式是sql建表，上面填的都是一些kafka的信息

3.3.2 oceans上clickhouse表的建立

因为clickhouse是一个qps不高的数据库，所以这边都是推荐批量写，这边设置的就是2s或者1000条数据的时候，就把数据落盘。

3.3.3 新建一个应用

这边新建应用主要就涉及两个点

1. 清洗sql
2. 计算资源配置

其中清洗sql要关注的点为，如果入库源是kafka，那么这边是需要在代码里面指定消费组是什么

ALTER TABLE
  qqmall_pay_bill_08700068630
SET('client.id' = 'cg_oceanus_qqmall_pay_bill_v1');
ALTER TABLE
  qqmall_pay_bill_08700068630
SET('group.id' = 'cg_oceanus_qqmall_pay_bill_v1');

insert into
  clickhouse_qqmall_pay_bill(
    select
      SPLIT_INDEX(ftime, '.', 0) as ftime,
      gc_order,
      goods_id,
      uin,
      order_type,
      order_source,
      price,
      quantity,
      act_id,
      act_price,
      real_price,
      pay_succ_ts,
      pay_platform,
      pay_channel,
      goods_type
    from
      qqmall_pay_bill_08700068630
  )

oceanus还是挺好用的，这边如果说存在语法错误，这边都是会提示的，不过要关注一下，如果你在外面升级了表的版本，你应用里面默认是不会更新的，要自己指定一下

启动后，这边就可以通过应用运维看到对应的信息了,虽然存在一点延迟，不过也可以接受

3.4 数据展示

经过上面的应用，我们这边数据已经落库了，那我们就能基于这个数据库区实现我们要的看板了。上面也说了，我们这边选择的展示层是datatalk，这个应用我们之前也一直在使用，确实很方便，一些简单的图只要妥妥拽拽就行，复杂的我们也能自己去写sql。

3.4.1 数据源接入

这边只需要在创作台上面新建一个数据源连接就行，相关参数配置一下，配置完后，添加一下数据表就可以了。这个连接时后台事件，平台会在连接成功后发消息邮件进行通知。

3.4.2 做看板！

做了那么多前面的事，终于到了核心，做看板！datatalk的优势就出来了，一些简单的逻辑，拖拖拽拽一下就行

如果数据不能满足你得要求，这边也可以自己去写sql

3.4.3 看板样例展示

看板一做，一些活动上线的时候，前期不用再去给产品捞数据，解放开发，产品也反馈好用，谁能拒绝一个秒级生效的数据看板。

因为涉及敏感数据，所以这边对于一些数据进行了脱敏处理，只展示了一下我们看板整体设计

4. 踩坑记录

4.1 clickhouse 建表一直失败

我之前在腾讯云上建表，死活建不成功，后面发现，对于一些建表语句，这边必须要加一下 ON CLUSTER default_cluster

4.2 应用跑起来了，但是数据一直没有写入

这个之前也是查了好久，看监控是存在消费的，但是看clickhouse就一直为空。看监控一切正常，然后这边看集群节点运行日志，发现这边是存在参数解析错误。atta上面指定的是int，但是上报的是string，导致解析失败。。。建议后面对于一些参数都用string

4.3 云上kafka监控显示无消费

因为我们这边存在一个应用，是消费远端kafka写入clickhouse中，但是当我在远端监控观察的时候，发现这边消费速度一直为0，但是看clickhouse一直有数据写入。就很奇怪

后来问helper，这边底层的实现是一直消费，但是消费的时候并不会accept，这就导致从监控上来看像一直没有消费的样子，这边accept只有当应用在停止做savepoint或者定时做checkpoint的时候才会，然后如果这边停止后没有从上次的savepoint重启的话，这边默认从最新起点开始消费，这就会导致停止那段时间的数据丢失