“ 作为一个后台开发，当服务上线的时候你是否只能看着黒呼呼的日志，单调的服务主被调曲线? 不如换一个思维，让我们通过业务数据实现一个秒级延迟的数据看板？去做一个从用户角度出发的业务数据觉察与监控系统？从另外一个角度来察觉业务可能存在的问题？”
1. 项目背景
1.1 当前痛点
1.2 计划做的事
综合上面的痛点，其实我们需要做的是一套数据觉察体系，从输出来看，需要有以下的一些能力
2. 整体规划
2.1 数据落库与可视化
首先要做的是实现数据可视化，但是这边的计划其实不仅仅是为某个业务服务，而是说计划制定一套可复用的标准流程，包括如下
1 | 数据源怎么选 |
2 | 数据清洗方案 |
3 | 数据库的选型 |
4 | 数据可视化方案 |
因为这边其实不仅仅是某个业务所需要的，应该是所有业务都需要的，只是对于一些场景来说，优先级没有那么高而已。但是谁又能拒绝一个秒级生效的数据看板？
2.2 数据分析与监控
实现了数据看板，仅仅只是开始，我们通过看板可以对整体业务节奏与体量有个把控，但是如果只是单单看这个看板，如果没有长期的一些经验累积，又或者是提前算好了预期，不然我们这边是无法感知到这些数字背后是否存在别的信息。
所以我们的诉求其实主要存在两个，一个是要有一个大而全的看板实现整体业务情况可观测，另外一个是通过数据来检测出业务异常问题。
上面的数据可视化，我们拥有了清洗后的业务原始数据，有了原始数据，那么这边就有了更多的操作空间。具体计划去做的事情如下
1 | 根据业务特性确定关键维度 |
2 | 历史数据快照落库 |
3 | 数据对比曲线，提供参考价值 |
4 | 基于人工经验与算法，进行数据分析，判断问题维度 |
5 | 结合告警oncall系统，实现业务监控 |
2.3 架构
目前我们这边实现了数据落库与数据可视化，至于数据分析与监控我们正在按照上面的计划一步步去实现,整体项目技术架构如下
3. 当前观测数据现状
3.1 基于可观测平台上报实现数据监控
原理：
后台开发服务一般都会有公司内部定义的一套可观测系统，我们这边的业务就统一接入了伽利略平台，代码中引入相关sdk，就可以自动化进行主被调上报，并提供可视化与监控告警的能力。该平台也提供了属性上报，底层实现方式类似于Prometheus。
具体实现方案为将一些业务数据，我们这边利用伽利略的属性上报，上报到伽利略的数据库中，然后这边利用api查询接口，将数据拉到本地，再以图标或者机器人播报的形式，展示出去。
问题：
1. 数据实时性 伽利略的属性上报存在3分钟左右的延迟，对于一些场景，分钟级的延时对于一些秒杀类型活动不可接受
2. 数据不够用，这边只能支持后台主动上报的，如果有些纯前端不涉及后台的，我们这边无法感知。
3. 总感觉开发味道太重，更像是为开发服务，而不是为整个团队服务
3.2 基于灯塔实现数据监控
灯塔简介：
公司内部的数据分析和展示平台，灯塔增长平台包括数据接入、数据管理、用户管理、敏捷分析、主题看板和实验行动等模块，通过从数据到行动的全流程服务，降低业务实现数据驱动的门槛，提高业务数据驱动的效率。云上产品类似于数据湖，从接入到展示一体化管理
原理：
对于一些业务数据，产品都是会让开发上报一份流水到dc表中。那这边就可以基于灯塔去清洗这个数据，然后生成看板，不过这条链路一般都是产品自己和数据同学去做。
问题：
1. 延迟问题，这边数据会有半小时的延迟（主要是计算集群带来的）
2. 感觉更适合做的是天汇聚数据，而不是那种秒级数据监控看板
3. 有的时候因为计算资源问题，可能计算一次要很长时间。
3.3 总结
所以之前的两条链路其实都是存在一定的问题，但是作为开发来说，一定是需要一个数据看板，所以要找到一个合适的方案。
4. 基于clickhouse实现数据实时看板
4.1 数据源
从1可以看出来，我们的业务数据源主要有两种，一种是开发主动进行属性上报，一种是基于流水上报。
很明显，流水上报的模式更符合我们的要求，数据粒度更细，也符合产品统计的口径。而且产品的上报已经规范化，而且属性上报是需要侵入业务代码。所以数据源肯定是源流水更合理。
那么问题来了，源数据是上百亿量级的上报表，我们这边应该如何去设计一条链路去将这个数据实现可视化？而且方案选型不应该小众，对于开发来说上手成本要低，大家可以自驱去做这件事，这样做这件事就会更加有意义。
所以这边的目的其实不仅仅是做一个看板，而是要制定一套规范，从数据源到计算，再从数据库到展示，流程化管理，到时候中间过程也好管理，而且在这个降本增效的时代，也可以帮助我们统一管理计算资源，方便定位问题。
4.2 数据库选型
1 | 写远远大于读 |
2 | 不要求低延迟(秒级就可以) |
3 | 接受大批次更新 |
4 | 不需要事务 |
5 | 大部分场景只是计算uv，pv，不涉及复杂语句 |
这个时候clickhouse这个数据存储就很突出了。可以说刚好满足了我们的需求。
这边就不大量篇幅介绍clickhouse，有兴趣的可以自己调研一下
4.3 链路方案
确定了数据源以及数据库，那我们这边剩下需要解决的就是将整条链路串起来。
清洗链路：
原始的上报数据源太复杂了，基本游戏中心所有的数据都会上报到表中，但是很多数据其实我们是不关心的，所以这边需要清洗，筛选出我们真正需要的数据。这边的清洗逻辑我们采用了内部的oceanus中台，这个平台只需要配置相关的sql，就能实现数据清洗。大大降低我们上手成本。也方便我们后面数据管理。
oceanus可参考云上流计算oceanus，底层逻辑是基于Apache Flink，将一些数据源根据条件清洗到目的数据库中。
展示链路：
这边主要有两种，一种是利用开源的grafana平台，另外一种是基于内部datatalk平台。综合来看，datatalk相对更友善一点，一些简单逻辑只需要拖拖拽拽就可以，如果没有特别多的要求，那么这边其实已经满足预期了。grafana的话，可能扩展性会更好一点，但是需要写sql，虽然扩展性比较好，但是可能每个图标都要去研究一下具体配置，有点麻烦，而且datatalk是公司内战略产品，在一些权限的管控上可能比grafana的要好一点。
datatalk可参考云上腾讯云图数据可视化，展示层可以直接对接数据库。
链路图：
5. 数据可视化
5.1 数据源出库
上报的表，一般类型都是atta，这边首先需要做的是将表进行出库到cdmq虫洞平台(底层实现还是为kafka)，变成可以实时消费的数据类型。
虫洞底层出库的数据协议与kafka保持一致，但是在消费组上面存在一点不太一样，kafka这边直接新起一个消费者就可以，但是虫洞是需要你去申请一个消费组才能消费的。不过自动化审批，还是没什么阻碍的。
5.2 clickhouse建表
我们clickhouse用的是腾讯云上购买的，这样配套设施比较好，有问题也有人维护。建表语句如下
然后这边ReplicatedMergeTree后面是不用加东西的，集群会默认帮忙加，可以通过控制台看到具体执行的命令,其中order by决定了每个分区中数据的排序规则，可以简单理解为索引
5.3 清洗任务
这边oceanus上的清洗任务主要涉及两个概念，一个是表，一个是应用，表是定义数据入库与出库的规范，应用是管理具体的清洗逻辑与资源，将两张表串起来。
所以清洗任务首先需要建立两张表，一张来源表，一张是入库表。对于我们这个场景，来源表就是远端cdmq，也就是kafka，入库表就是对应clickhouse.
5.3.1 oceans上kafka表的建立
5.3.2 oceans上clickhouse表的建立
因为clickhouse是一个qps不高的数据库，所以这边都是推荐批量写，这边设置的就是2s或者1000条数据的时候，就把数据落盘。
5.3.3 新建一个应用
这边新建应用主要就涉及两个点
1. 清洗sql
2. 计算资源配置
其中清洗sql要关注的点为，如果入库源是kafka，那么这边是需要在代码里面指定消费组是什么。
oceanus还是挺好用的，这边如果说存在语法错误，这边都是会提示的，不过要关注一下，如果你在外面升级了表的版本，你应用里面默认是不会更新的，要自己指定一下
启动后，这边就可以通过应用运维看到对应的信息了,虽然存在一点延迟，不过也可以接受
5.4 数据展示
经过上面的应用，我们这边数据已经落库了，那我们就能基于这个数据库去实现我们要的看板了。上面也说了，我们这边选择的展示层是datatalk，这个应用我们之前也一直在使用，确实很方便，一些简单的图只要妥妥拽拽就行，复杂的我们也能自己去写sql。
5.4.1 数据源接入
这边只需要在创作台上面新建一个数据源连接就行，相关参数配置一下，配置完后，添加一下数据表就可以了。这个连接是后台事件，平台会在连接成功后发消息邮件进行通知。
5.4.2 做看板！
做了那么多前面的事，终于到了核心，做看板！datatalk的优势就出来了，一些简单的逻辑，拖拖拽拽一下就行
如果数据不能满足你的要求，这边也可以自己去写sql
5.4.3 看板样例展示
看板一做，一些活动上线的时候，前期不用再去给产品捞数据，解放开发，产品也反馈好用，毕竟秒级生效。
6. 踩坑记录
6.1 clickhouse 建表一直失败
我之前在腾讯云上建表，一直提升失败，后面发现，对于一些建表语句，这边必须要加一下 ON CLUSTER default_cluster
6.2 应用跑起来了，但是数据一直没有写入
这个之前也花了很多的时间去咨询去定位，以为是哪个地方的配置问题，看虫洞监控是存在消费的，但是看clickhouse数据库就一直为空。看监控一切正常，然后这边看集群节点运行日志，发现这边是存在参数解析错误。atta上面指定的是int，但是上报的是string，导致解析失败。。。建议后面对于一些参数都用string
6.3 云上kafka监控显示无消费
因为我们这边存在一个应用，是消费远端kafka写入clickhouse中，但是当我在远端监控观察的时候，发现这边消费速度一直为0，但是看clickhouse一直有数据写入。就很奇怪
后来问helper，这边底层的实现是一直消费，但是消费的时候并不会accept，这就导致从监控上来看像一直没有消费的样子，这边accept只有当应用在停止做savepoint或者定时做checkpoint的时候才会，然后如果这边停止后没有从上次的savepoint重启的话，这边默认从最新起点开始消费，这就会导致停止那段时间的数据丢失
作者:lixiongxu
联系客服
