Zeppelin架构原理分析

大纲:

  • zeppelin整体架构分析
  • zeppelin-Interpreter
  • Zeppelin-note
  • zeppelin-paragraph

 

 

 

 

 

一、Zeppelin整体架构分析

 

首先上一张官方给出的Zeppelin整体架构图

Apache Zeppelin的架构比较简单直观,总共分为3层:

  • Zeppelin 前端
  • Zeppelin Server
  • Zeppelin Interpreter

Zeppelin前端是基于AngularJS(目前社区正在升级改造前端,但是对用户体验不会有影响)。

Zeppelin Server是一个基于Jetty的轻量级Web Server,主要负责以下一些功能:

  • 登陆权限管理
  • Zeppelin配置信息管理
  • Interpreter 配置信息和生命周期管理
  • Note存储管理
  • 插件机制管理

Zeppelin前端和Zeppelin Server之间的通信机制主要有Rest api和WebSocket两种。Zeppelin Server和Zeppelin Interpreter是通过Thrift RPC来通信,而且他们彼此之间是双向通信,Zeppelin Server可以向Zeppelin Interpreter发送请求,Zeppelin Interpreter也可以向Zeppelin Server发送请求。

关于zeppelin采用WebSocket技术的必要性问题,这里也做一下简单分析。zeppelin是共享式、Notebook式的大数据分析环境,以repl的方式执行以Paragraph为最小粒度的代码段。

1. 首先repl的方式强调实时反馈执行结果,特别是在大数据环境下,一段代码可能需要执行很长时间,在执行的过程中,zeppelin的用户期望看到执行进度和中间结果,需要在前后端之间建立一个长连接,便于实时传递数据。

2. 另外zeppelin的另一个亮点是其结果可视化能力,需要在前后台传递图片,并且支持较大数据量的传输的能力(相对传统http技术)。

3. 再者,由于是共享式环境,一个Note可能被多个用户同时看到、甚至编辑,需要在各个已经打开了同一个Note的web客户端之间同步Note的代码、执行结果和进度信息。

基于以上3点,zeppelin采用WebSocket技术是水到渠成的事情。

        上图是zeppelin的前后台交互模型,zeppelin采用单独的jvm来启动interpreter进程,该Interpreter进程与zeppelinServer进程之间采用Thrift协议通信,其中RemoteInterpreterProcess是Thrift-Client端,而相应的RemoteInterpreterServer是Thrift-Server端。每一个Interpreter都属于换一个InterpreterGroup,同一个InterpreterGroup的Interpreters可以相互引用,例如SparkSqlInterpreter 可以引用 SparkInterpreter 以获取 SparkContext,因为他们属于同一个InterpreterGroup。当前已经实现的Interpreter有spark解释器,python解释器,SparkSQL解释器,JDBC,Markdown和shell等。

 

二、Zeppelin-interpreter

2.1、Interpreter概念

Interpreter组件是指各个计算引擎在Zeppelin这边的适配。比如Python,Spark,Flink等等。每个Interpreter都run在一个JVM进程里,这个JVM进程可以是和Zeppelin Server在同一台机器上(默认方式),也可以run在Zeppelin集群里的其他任何机器上或者K8s集群的一个Pod里,这个由Zeppelin的不同InterpreterLauncher插件来实现。InterpreterLauncher是Zeppelin的一种插件类型。

Interpreter支持动态加载maven格式依赖包的能力,多JVM隔离runtime依赖。Thrift-Based跨语言IPC(Inter-Process-Communication)机制(规定repl解释器集成和平台之间的数据交换的格式和时序)。抽象出repl解释器生命周期管理接口,各repl解释器受zeppelinServer端控制。

每一个Interpreter都有一个对应的Scheduler实例,Scheduler将Job的提交与执行变成了一个异步的过程,即Job在Scheduler处进入队列等待提交,用户可以定期收到Job执行相关的信息。Zeppelin内部有三种Scheduler:

  • FIFOScheduler: 适用于Paragraph只能顺序执行的Interpreter,如SparkInterpreter, ShellInterpreter等。
  • ParallelScheduler: 适用于Paragraph可并行执行的Interpreter,如SparkSqlInterpreter, MarkdownInterpreter等。
  • RemoteScheduler: 与RemoteInterpreterProcess配合使用的,RemoteInterpreterProcess以独立的进程启动Interpreter,其内部同样运行了调度器,由于zeppelinServer运行在主进程中,与远程Interpreter进程(通过RemoteInterpreterServer启动的jvm,注意:不是运行InterpreterProcess类所在的进程,InterpreterProcess仍然运行在与ZeppelinServer相同的主进程中)不在同一个进程。RemoteScheduler的作用就作为运行在远程Interpreter进程的远程代理,RemoteScheduler与ZeppelinServer运行在同一个JVM进程中,负责向ZeppelinServer提供远程Interpreter进程中调度器的内部运行情况。

 

关于为什么要采用单独的JVM进程来启动repl解释器,原因有以下两点:

  • zeppelin旨在提供一个开放的框架,支持多种语言和产品,由于每种语言和产品都是各自独立演进的,各自的运行时依赖也各不相同,甚至是相互冲突的,如果放在同一JVM中,仅解决冲突,维护各个产品之间的兼容性都是一项艰巨的任务,某些产品版本甚至是完全不能兼容的。
  • 大数据分析,是否具有横向扩展能力是production-ready一项重要的衡量指标,如果将repl进程与主进程合在一起,会验证影响系统性能。

因此,在有必要的时候,zeppelin采用独立JVM的方式来启动repl进程,并且采用Thrift协议定义了主进程ZeppelinService与RemoteInterpreterService进程(解释器进程)之间的通信协议。

 

2.1、Interpreter模块其他部分概念

  • InterpreterFactory:维护所有Interpreter的配置信息并存储在interpreter.json文件中,并管理所有的Interpreter
  • InterpreterGroup:一个InterpreterGroup中包含多个Interpreter,同组内的Interperter共享相同的配置信息,例如Spark和SparkSQL interpreter在一个InterpreterGroup内。
  • InterpreterSetting:一个InterpreterGroup会有一个InterpreterSetting,其中包含着相应的配置信息,例如Spark Master。
  • 所有的InterpreterSetting都被持久化在Interpreter.json文件里。用于维护Note与InterpreterGroup直接的绑定关系,即每篇Note可以绑定不同的InterpreterGroup.
  • InterpreterContext:用于存储Paragraph相关的信息,Interpreter在具体解析执行Paragraph时会用到InterpreterContext。
  • InterpreterResult:用于存储Job的状态信息以及执行结果,具体包括:
    • 状态码:SUCCESS,INCOMPLETE,ERROR,KEEP_PREVIOUS_RESULT
    • 类型:Text(Default),Table,Html,Angular等
    • 内容:字符串数组

 

 

 

 

 

三、Zeppelin-Note

 

3.1、Note模块概念

Notebook部分有一些重要的概念是需要理解的:

  • Notebook Server:用于建立并维护前端网页与后端服务器之间的Websocket连接;它其实是一个job listener,接收并处理前端网页发来的Note执行请求,在后端生成并执行相应的job,并将job执行的状态信息广播到所有的前端页面。
  • Message:Message类是前端网页与后端Notebook Server之间的通信协议,传输在Websocket上,主要用于描述Note执行相关的信息。
  • Notebook,Note,Paragraph,Job:
    • Notebook:Zeppelin认为整个运行实例是一个Notebook,其中可以用很多篇Note。
    • Note:每一篇Note就是一个具体的页面,其中可以有很多个Paragraph,就是代码段落。
    • Paragraph:每一个Paragraph就是一个代码段落,因此Paragraph是一个可执行单元,等同于一个Job。
    • Job:Job是Zeppelin后端调度和执行的单位,会在具体的Interpreter上运行。

3.2、Note模块主要功能

Note是单个’记事本’的内存对象,是zeppelin管理的最小单位,无论是做权限控制、共享、还是持久化,都是以Note为粒度的。从类关系上看,Note是由一些列的有序Paragraph组成,因此其绝大部分职责都是与管理Paragraph有关:

1. Paragraph的CRUD、相对顺序控制

2. 与处理前后端数据双向推送的AngularObject的管理

3. 整体和单个Paragraph 执行,以及执行过程的基于Observer模式的执行过程Hook

4. Note基本的样式外观控制

为了“分离关注点”,其他的功能,如:

1. Note相关的Interpreter加载和初始化

2. 持久化与反持久化,包括延迟持久化

3. 权限控制

 

 

 

4、Zeppelin-paragraph

Paragraph代表着一段代码以及支撑其执行所需要的“环境信息”,是代码执行的最小单位。Paragraph的职责如下:

1. 获取代码文本,并解析分离类似%spark的interpreter声明段和可执行代码段。

2. 代码执行,以及执行过程控制(进度和终止)

3. 代码执行结果获取

4. 代码中变量查找以及替换

 

5、一次Query的执行过程

以SparkInterpreter举例

SparkInterpreter的工作原理如下:

  • 内部基于SparkILoop以及SparkIMain实现,功能类似于Spark-Shell,即逐行的解析代码。
  • 用zeppelin-<Interpreter hash code>-<Paragraph Id>作为Spark中的Job Group Id,进而用Job Group Id来从SparkContext中获取执行进度信息。
  • 将SparkInterpreter进程内创建的SparkContext绑定到SparkIMain里面,进而预定义一些环境配置以及语法糖,例如ZepplinContext。
  • 用ByteArrayOutputStream来捕获SparkIMain的输出,并转化为可显示的输出结果。

SparkSqlInterpreter的工作原理如下:

  • 运行在SparkInterpreter之上,即在SparkInterpreter中运行SqlContext或者HiveContest
  • SparkSqlInterpreter的执行结果都会以Table的类型返回给前端,因此前端页面会用相应的Angular JS代码将结果呈现为图表。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

EdwardsWang丶

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值