从Kafka日志拆分来看系统架构

下面是根据最近的工作内容来思考做事的方式，说是系统架构稍微有点标题党了，但是我感觉也可以说是广义的系统架构。

 

一、做铺垫

 

目前笔者在基础数据部门做实时计算相关的内容，近期接触到的主要工作是Kafka日志拆分，也就是把最基础的全量的日志Topic拆分成多个小的Topic，供业务方使用。

 

其主要目的为：

• 让业务方只关注自己需要的数据，让业务更加简单和专注
• 降低业务方和Kafka测的成本

 

二、讲故事

 

做这件事情，其实有两种思路：

• 业务方提需求，数据服务侧完成需求
• 数据侧主动进行日志的拆分

 

下面对这两种方式进行一下比较，分析其利弊。

 

2.1 业务方提需求，数据服务侧完成需求

 

好处：避免做不必要的工作，每产生一份数据都是有价值的；

 

弊端：被动接受需求，导致每一次工作安排都可能是被动的；并且对于研发人员来说，并没有自我驱动，提升自己的主观能动性；可能前期的架构在后期很容易就不适合；

 

2.2 数据侧主动进行日志的拆分

 

好处：一次性彻底完成事情，防止后续无休止的需求打扰正常工作安排；提升研发人员的主观能动性以及其对于业务的理解；促使研发从全局考虑，提前进行架构设计；

 

弊端：有可能拆分出来的数据无人使用或者近期无人使用，造成部分的资源浪费；

 

我们选择的是第二种，主动进行日志的拆分。因为通过比较可以发现，2.2这种方式相较于2.1是利远远大于弊的。

 

三、敲黑板

 

3.1 数据拆分的方法

 

• 按业务拆分

如果数据有非常明显的业务属性，那么就可以很直接的按照业务来拆分数据。比如快手这边可以按照视频、直播等业务来进行拆分。

 

• 按数据规模拆分

在进行日志拆分的过程中，有一份数据有几百个type，那么就很难按照业务来拆分。所以我们经过统计，发现其实拆出来top10（具体可以看自己的数据情况）以后，其他的数据规模并没有太大。

 

3.2 做事方式

 

• 不要只看眼前事，从全局和长远来考虑系统的架构

• 对类似的事情做总结，提取出来共性做架构

• 不局限于数据，要弄清楚其来龙去脉，全面理解事情

 

相关阅读：

需求面前，工程师应该怎么思考？

程序猿，认清自己处于什么阶段

Flink概念：编程模型【下】

 

吹NB：后续本公众号会更新更多关于管理开发、数据架构相关的问题，欢迎关注订阅“合格的程序猿”，代号：hgdcxy 。 长按识别下面二维码也可关注!