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

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

一、做铺垫

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

其主要目的为：

让业务方只关注自己需要的数据，让业务更加简单和专注

降低业务方和Kafka测的成本

二、讲故事

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

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

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

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

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

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

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

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

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

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

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

三、敲黑板

3.1 数据拆分的方法

按业务拆分

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

按数据规模拆分

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

3.2 做事方式

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

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

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