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

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

二是点查和多维分析融合，一个用户的行为分析系统通常有两类需求，一是指定用户查询;二是大批量用户行为分析，这就涉及到多维分析。传统。架构需要实现结合需要HBase和HDFS Parquet二者结合，点查单个用户需要使用HBase，批量查询需要使用HDFS，显然这样的成本比较高。如果使用Kudu，因为其可以同时满足KV查询和多维分析查询，整体架构会比较简单，成本也相对较低。

三是实时维表，在互联网应用中，Hadoop会存一些用户行为日志，但还有一些数据在数据库里，比如商品、用户等维表。数据库里的数据通常会每天全量导入，实时性比较差，当然也可以选择按小时导入，但这样数据库压力会很大，如果数据库增量导入大数据平台，然后再做全量merge，实时性会比较差。

网易的解决方案是使用工具直接把数据库实时同步到Kudu，Kudu的数据可以跟Hadoop用户行为数据直接做join连查，这样整个平台的实时性会做到秒级，性能也不错。

接下来，我想介绍一下我们的实时计算系统——Sloth。Sloth是一个基于SQL开发的流计算系统，它的SQL看起来与Hive SQL类似，同样支持DDL、UDF，join子查询等。我们的流计算系统基于Flink引擎开发，通过CodeGen的方式生成Flink代码，然后同步到集群执行。

在效果上，我们做到了Exactly Once跟增量计算模型，通过实时计算SQL算出来的结果跟用离线计算出来的结果一样，这是对数据正确性的重要保证。当然，Sloth也是在猛犸大数据平台上开发的。

以上是Sloth的开发界面，我们设计了写SQL的地方，同时也可以调试并完成实时计算任务。以电商系统为例，我们需要对商家按照销售额进行分类统计，比如说销售额0-100之间做分类，100-200区间内归为另一类，依此类推计算出每个区间内的商家个数。

以上图为例，第一条计算每个商家的销售总额，我们需要先定一个临时表tmp，再针对tmp做一个GROUP BY，相当于把商家销售额给GROUP BY计算，得出每个商家的销售额。

第二条是计算每个区间内的商家个数。此时，我们可以用GROUP BY销售额除以100，这是要查询的临时表tmp。两条SQL跟离线完全一样，如果表定义和实时计算一样的话，你是可以拿到Hive上运行的。

只要通过这两条SQL就可以完全实现计算任务开发，那它跟离线计算结果有什么不一样呢?它实时输出结果，而离线是一次性输出结果，提交这样的SQL就不停的输出销售额的分类统计。

（编辑：核心网）

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