网易大数据平台架构实践分享！

整个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只能做半小时以上的准实时，如果数据实时性要求很高，小文件会比较多进而影响性能。

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!