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

如果用MapReduce这样的离线计算，我会得到四条数据会得到0~100区间内有2条记录， 100~200区间内有1条记录。但如果用流式计算，可能就会遇到问题，为什么这么说呢?如果你现在已经处理了3条数据，就是说(1，、30)，(，2，、10)，(3，、80)这三条数据，这个情况下你说出的输出的结果是0-100有三个商家。当第四条数据参与计算后，系统可能就会输出0-100有三个有3个商家，100-200有一个有1商家，这个结果就是有误的，这是因为实时计算没有去纠正已经输出的计算结果。的原则是不停得计算并输出结果。

那么，这个问题如何解决呢?早期的Flink缺少该功能，我们就在Flink的基础上做了改造。所谓的增量计算是指在遇到上述情况时需要撤销前一步计算结果，上游算子需要不停得向下游算子发出撤销操作请求，直到数据纠正过来最终输出正确结果。

通过该方式，我们保证了SQL计算的正确性。

一个SQL任务分为DDL和DML语句，Sloth通过SQL方式编写， DDL的作用是在Kafka之上的DDL，也可定义在其他输入源之上定义流表用户的job就是定义在Kafka之上的DDL，也可定义在其他输入语言之上。流表定义完成之后，我们需要做就可以编写很多DML操作数据，计算结果。

一个SQL的job分为DDL和DML语句，对于纯SQL语句，我们需要先对其进行编译。首先，我们编译每条DDL，对每条DML单独编译每条SQL语句;其次，生成执行计划，将不同SQL的执行计划串联起来，因为它们彼此之间存在输入输出关系。然后，根据不同SQL计划之间的依赖关系，我们会生成一个全局Sloth执行计划;最后，我们将该执行计划生成代码，将代码提交给Flink执行，这就是整个Sloth的执行过程。

接下来，我会介绍网易在Spark多租户方面的工作，这个项目叫做Kyuubi(该项目的开源地址： https://github.com/netease-bigdata/kyuubi https://github.com/yaooqinn/kyuubi)，实际上是类似于HiveSever2的程序。大家可能都知道，Hive一般有两种使用模式，一种是client模式，所有的SQL解析都客户端在这之中完成。一种是HiveSever2模式，整个SQL解析放到server端完成。

在公司实际使用过程中，我们更希望用户的使用行为通过Server端完成，否则会很难管理，因为客户端根本不在平台掌控范围之内，我们很难进行各种升级及配置变化。只有当MetaStore和HDFS 配置不暴露给用户，我们才能更好得管控。Hive的社区比较完善，在这方面没有问题，但是Spark还有些不足。其实，所谓的Kyuubi只是在类似HiveSever2的基础上提供服务， 提供SparkSQL服务，而不是Hive SQL服务。

Kyuubi基于Spark Thrift Sever改造，Spark Thrift Sever类似于HiveSever2，但是它不够完善。由于我们在此基础上增加了多租户的功能，因此可以支持网易内部各业务线的使用。要想实现多租户功能，首先要把SparkContext变成多实例，之后每次执行代理真正的用户身份执行;其次，我们提供了Spark SQL集群，用户请求负载均衡到每台Kyuubi服务器，并且这部分是高可用的，一台服务器挂了会立刻切换到另一台。

此外，我们对安全性也进行了改进，支持kerbros。其实，整个网易猛犸平台都是强安全认证系统，每个用户都有自己的kerberos key tabkerbros，所有系统拿kerberoskerbros做认证访问都是带认证的，Kyuubi要融入这个体系同样需要支持kerberoskerbros。

Kyuubi的主要特点如下：一是具备统一接口，与HiveSever2相比，Kyuubi提供SwiftThrift的API，无论是Beeline客户端、JDBC客户端、ODBC客户端还是网易猛犸自助分析查询平台、有数可视化BI平台，Kyuubi都可以用标准的方式连接到Spark。

二是有弹性的资源控制能力，Kyuubi支持session级别的资源配置，每个session所需的队列、资源核数和内存都可以进行配置。

三是支持SparkContext的动态缓存。创建一个SparkContext耗时较长，所以我们要对SparkContext进行缓存设置，让用户不需要每次查询都动态创建SparkContext。

此外，我们也支持Spark动态资源分配特性，启用SparkContext需要启用一堆Spark执行器。如果业务需要较快的响应速度，那就直接发SQL，不需要等待进程启用。

四是Kyuubi安全特性，首先是支持Kerberos还有代理执行，最后支持集成我们自己的spark-authorizer权限验证插件，该插件对Spark没有侵入性，主要用于查询优化的最后阶段。实际上，具体权限对接的是rRangerr中的权限控制中心，通过集成Spark-authorizer，我们能够做到细粒度的权限控制。

此外，我们也支持服务的高可用和负载均衡，Kyuubi基于负载均衡的方式设计，通过将ZK作为Namespace来实现。具体过程为，Kyuubi将自己注册到ZK，ZK形成服务列表，注明各服务的存活状态，客户端会与ZK通讯拿到该服务器列表，从中挑选Kyuubi服务器执行。通过这种方式，我们将负载均衡到众多Spark查询设备上，从而避免了单点故障，保证了服务的可用性。

总结来看，Kyuubi以HiveServer2 Thrift API为接口协议，提供Spark SQL服务。相比传统的Spark，Kyuubi主要增加了企业级特性，如果公司多租户场景较多且业务线复杂，多租户功能是比较要紧的事情比如多租户、权限、负载均衡等。

最后，我介绍一下网易在未来的规划。首先，我们会进一步完善高性能查询引擎。目前，我们正在用的查询引擎是Impala，虽然性能较优，但我们还希望可以在与Kudu配合等方面进行更多优化。

二是实现实时和离线计算混步。针对网易目前庞大的集群数量，我们希望可以通过混部步来解决该问题。首先，晚上是离线计算的高峰期，任务通常会等到所有数据完成也就是凌晨定时起来跑，实时计算的高峰期与用户使用高峰期一样都在白天，因此可以与离线计算实现错峰运行。在集群规模较大的情况下，这种方式的意义非常明显，我们希望可以解决这种方式带来的隔离、弹性等方面的问题。

三是集成更多硬件做加速，比如GPU或者FPGA。

四是智能任务诊断和优化。因为网易内部数据量和任务非常庞大，我们希望可以通过智能化任务诊断的方式辅助技术支持人员更好得完成工作，未来希望可以达到AIops的程度。

相关阅读：

初探大数据分析挖掘平台Jarvis

大数据使用的5种主要数据挖掘技术

（编辑：核心网）

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