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代码将结果呈现为图表。