下面是根据最近的工作内容来思考做事的方式，说是系统架构稍微有点标题党了，但是我感觉也可以说是广义的系统架构。
一、做铺垫
目前笔者在基础数据部门做实时计算相关的内容，近期接触到的主要工作是Kafka日志拆分，也就是把最基础的全量的日志Topic拆分成多个小的Topic，供业务方使用。
其主要目的为：
- 让业务方只关注自己需要的数据，让业务更加简单和专注
- 降低业务方和Kafka测的成本
二、讲故事
做这件事情，其实有两种思路：
- 业务方提需求，数据服务侧完成需求
- 数据侧主动进行日志的拆分
下面对这两种方式进行一下比较，分析其利弊。
2.1 业务方提需求，数据服务侧完成需求
好处：避免做不必要的工作，每产生一份数据都是有价值的；
弊端：被动接受需求，导致每一次工作安排都可能是被动的；并且对于研发人员来说，并没有自我驱动，提升自己的主观能动性；可能前期的架构在后期很容易就不适合；
2.2 数据侧主动进行日志的拆分
好处：一次性彻底完成事情，防止后续无休止的需求打扰正常工作安排；提升研发人员的主观能动性以及其对于业务的理解；促使研发从全局考虑，提前进行架构设计；
弊端：有可能拆分出来的数据无人使用或者近期无人使用，造成部分的资源浪费；
我们选择的是第二种，主动进行日志的拆分。因为通过比较可以发现，2.2这种方式相较于2.1是利远远大于弊的。
三、敲黑板
3.1 数据拆分的方法
-
按业务拆分
如果数据有非常明显的业务属性，那么就可以很直接的按照业务来拆分数据。比如快手这边可以按照视频、直播等业务来进行拆分。
-
按数据规模拆分
在进行日志拆分的过程中，有一份数据有几百个type，那么就很难按照业务来拆分。所以我们经过统计，发现其实拆出来top10（具体可以看自己的数据情况）以后，其他的数据规模并没有太大。
3.2 做事方式
-
不要只看眼前事，从全局和长远来考虑系统的架构
-
对类似的事情做总结，提取出来共性做架构
-
不局限于数据，要弄清楚其来龙去脉，全面理解事情
相关阅读：
吹NB：后续本公众号会更新更多关于管理开发、数据架构相关的问题，欢迎关注订阅“合格的程序猿”，代号：hgdcxy 。 长按识别下面二维码也可关注!
