网易大数据平台架构实践分享!
整个Kudu的大致架构如下, 它有一个管理服务器负责管理,数据通过分区方式分片到众多切分成Tablet,然后存储到Tablet Server。每个Tablet Server负责多个Tablet,每个Tablet对应多个MemRowSet。 MemRowSet写满之后就会存到磁盘形成DiskRowSet上,每个DiskRowSet是Base +Delta结构, 看起来与HBase类似,主要的不同在于前者扫描性能更优,因为Base中的Kudu属于列存模式,所以性能更好。 其次,DiskRowSet之间没有记录重叠,这与HBase不太一样。这样做最大的好处在于扫描时不用多个DiskRowSet之间做合并,只需要扫描单个DiskRowSet之间扫描就可以了。 此外,Dalta数据结构用物理offset偏移量做key,扫描时可快速定位到记录的变更很容易就可找到Delta的位置信息,而HBase用记录主键做逻辑定位,这就是Kudu扫描性能更佳的原因 性能相对更慢一些。 Kudu的问题主要有以下几点,一是在使用Impala查询引擎的情况下,性能与Parquet相比有不小差距。虽然官方测试报告中指出kudu的性能比Parquet更优,但经过我们的实际测量,结果刚好相反(下图为实际测量结果,Q16、Q17、Q19相差十分明显)。 其二,Kudu缺少Spilt和Merge功能,Ranger分区缺少自动分裂的过程,当分区越来越大之后,我们就没有办法处理热点问题了。 为了解决上述问题,网易做的第一个优化是Kudu Runtime Filter,这是为了加速kudu的性能。比如,如果需要做大小表的join,一般可能有两种做法,一是大表和小表都根据join key来做shuffle,把相同的join key数据shuffle到同一台机器上,但这种做法开销比较大。 二是小表广播,将小表广播到所有查询服务器上,与大表一起做join,网易在这部分采用的是Kudu Runtime Filter。 我们的做法是为小表join key生成Runtime Filter,这样做的好处在于kudu在扫描底层数据时会拿Runtime Filter去底层过滤数据,这样的结果就是返回Impala层的数据会大大减少。以下图为例,红色是一个的scan操作, 可以看到kudu返回的记录数会变的很少,特别是返回数据集较小的情况下。 经过改进,Kudu的性能有了很大提升。下图黑色的是原生kudu,橙色的是加入Runtime fliter的版本,二者对比,后者在性能上确是有很大提升。整体来看,kudu的性能比Parquet要低30%左右,但一般情况下是够用的,因为毕竟它有数据更新的能力,自然会牺牲一些查询性能。 此外,我们也做了kudu Tablet Split自动分裂功能,主要对Ranger分区做了分裂,分裂思路比较简单,主要是修改元数据,整个过程瞬间在线完成,不会涉及数据真正的变更,。具体做法是在元数据上标识将一个Tablet分为两个,此后都遵循该原则,但只有在Compaction时才会发生真正的物理分裂。 此外是主从协同。当主发生分裂时,会通过Raft协议同步所有副本同时分裂。通过这个方式,我们完成了Kudu的分裂,线上管理也很方便。 接下来介绍一下Kudu的应用场景,一是对实时性要求较高的场景,Kudu可以做到秒级实时,而HDFS只能做半小时以上的准实时,如果数据实时性要求很高,小文件会比较多进而影响性能。 (编辑:惠州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |