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

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

一、做铺垫

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

其主要目的为:

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

降低业务方和Kafka测的成本

二、讲故事

做这件事情,其实有两种思路:

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

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

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

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

好处:避免做不必要的工作,每产生一份数据都是有价值的;

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

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

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

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

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

三、敲黑板

3.1 数据拆分的方法

按业务拆分

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

按数据规模拆分

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

3.2 做事方式

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

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

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180731G1KD8N00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券