重来

Zeppelin采用Java（主要）+Scala+R（少量）混合开发，采用maven作为build工具。涉及的主要技术stack如下：1)      前台：AngularJS、Node.JS、WebSocket2)      后台：Jetty（embedding）、Thrift、Shiro（权限）、Apache common-exec、Jersey REST API。

接上篇，本文接着分析zeppelin类图中右上角剩余的类，同样，在分析的过程中，我们重点关注该class的职责划分，以及与其他类配合，完成zeppelin的设计目标的过程。 InterpreterInfoSaving InterpreterInfoSaving是一个convenient类(提供的功能可以由其他类组合完成，设计目的是为了方便调用)，定义其目的就是为了将原来分散存储在各个interp

zeppelin的module、package、class众多，如何快速地理清头绪，抓住重点？本文分析zeppelin主要module中重点的类以及它们之间的关系，理清这些类的职责，对于理解zeppelin的运行过程至关重要。

本文主要分析类图中右下角的部分，如果说类图中右上角部分决定了zeppelin运行时对解释器进程的处理，那么右下角这部分类是决定了Note运行方式。 Note Note是单个’记事本’的内存对象，是zeppelin管理的最小单位，无论是做权限控制、共享、还是持久化，都是以Note为粒度的。从类关系上看，Note是由一些列的有序Paragraph组成，因此其绝大部分职责都是与管理Paragrap

zeppelin研究群和公众号

转发一篇zeppelin的主力committer Jongyoul Lee的讲解zeppelin的paragraph的运行机制的文章，原文地址：https://medium.com/apache-zeppelin-stories/how-apache-zeppelin-runs-a-paragraph-783a0a612ba9#.a85u5nlh4

上图是zeppelin的前后台交互模型，zeppelin采用单独的jvm来启动interpreter进程，该Interpreter进程与zeppelinServer进程之间采用Thrift协议通信，其中zeppelinServer是Thrift-Client端，而相应的InterpreterProcess是Thrift-Server端。下面是Paragraph的执行序列图(做了部分简化)：

主要分析zeppelin-distribution/target中的发布包的打包过程，即distribution目录结构中的bin、conf、Interpreter、lib等目录文件的来源。1.1.1 parent pom首先看一下${ZEPPELIN_HOME}/pom.xml文件中与package相关的几个重要的plugin的配置:  maven-dependency-plugi

Notebook的持久化系统主要的类图如下：各类主要的职责如下：1)      NotebookRepo是顶层接口，规定了持久化层基本的CRUD接口。2)      NotebookVersioned定义了Note的版本管理接口，目前其实现类只有GitNotebookRepo（该功能目前实现的不完善，既没有实现按照rev log进行过滤检索，界面上目前也没有入口）。3)

前面提到了interpreter是以单独的process启动的，想要debug interpreter，需要设置启动interpreter进程的jvm以debug方式启动，然后让IDE进行remote debug，具体步骤如下：1)      在bin/interpreter.sh脚本中JAVA_INTP_OPTS变量中加入如下参数：JAVA_INTP_OPTS+=" -agentlib:

通过我其他的zeppelin分析文章，大家可以从中了解zeppelin是什么样的。本篇试着阐述问题的另外一面，zeppelin为什么是这样的？本文从需求出发，探寻zeppelin的架构设计、技术选型、代码的模块划分和依赖关系最初的“出发点”。 zeppelin的核心功能用一句话总结就是：支持多个语言repl的解释器。这个核心功能的价值体现在： 站在使用者的角度，意味着： 1. 可以在一个...