火山引擎 DataLeap 下 Notebook 系列文章二：技术路线解析

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

在 Jupyter 的生态下，除了 Notebook 本身，火山引擎 DataLeap 研发团队还注意到了很多其他组件。彼时，JupyterLab 正在逐渐取代传统的 Jupyter Notebook 界面，成为新的标准。JupyterHub 使用广泛，是多用户 Notebook 的版本答案。

脱胎于 Jupyter Kernel Gateway(JKG)的 Enterprise Gateway(EG)，提供了火山引擎 DataLeap 研发团队需要的 Remote Kernel（上述的独立任务 Kernel 环境）能力。2020 上半年，火山引擎 DataLeap 研发团队基于上面的三大组件，进行二次开发，发布了 Notebook 任务类型。

（图：火山引擎 DataLeap 下 Notebook 整体架构）

 

JupyterLab 前端这一侧，火山引擎 DataLeap 研发团队选择了基于更现代化的 JupyterLab 进行改造，刨去了它的周边视图，只留下了中间的 Cell 编辑区，嵌入了火山引擎 DataLeap 数据研发的页面中。为了和火山引擎 DataLeap 的视觉风格更契合，从 2020 下半年到 2021 年初，团队还针对性地改进了 JupyterLab 的 UI。

另外火山引擎 DataLeap 研发团队还开发了定制的可视化 SDK，使得用户在 Notebook 上计算得到的 Pandas Dataframe 可以接入火山引擎 DataLeap 数据研发已经提供的数据结果分析模块，直接在 Notebook 内部做一些简单的数据探查。

JupyterHub提供了可扩展的认证鉴权能力和环境创建能力。首先，由于用户较多，因此为每个用户提供单独的 Notebook 实例不太现实。因此团队决定，按 火山引擎 DataLeap 项目来切分 Notebook 实例，同项目下的用户共享一个实例（即一个项目实际上在 JupyterHub 是一个用户）。这也与 火山引擎 DataLeap 的项目权限体系保持了一致。

Jupyter Enterprise Gateway提供了在分布式集群（包括 YARN、Kubernetes 等）内部启动 Kernel 的能力，并成为了 Notebook 到集群内 Kernel 的代理。

（图：Enterprise Gateway ）

EG 本身提供的 Kernel 类型，和火山引擎内部系统并不完全兼容，火山引擎 DataLeap 研发团队首先以 Spark Kernel 的形式对接了字节跳动内部的 YARN 集群。Kernel 以 PySpark 的形式在 Cluster 模式的 Spark Driver 运行，并提供一个默认的 Spark Session。

用户可以通过在 Driver 上的 Kernel，直接发起运行 Spark 相关代码。同时，为了满足 Spark 用户的使用习惯，火山引擎 DataLeap 额外提供了在同一个 Kernel 内交叉运行 SQL 和 Scala 代码的能力。

2020 下半年，伴随着云原生的浪潮，火山引擎 DataLeap 研发团队还接入了字节跳动云原生 K8s 集群，为用户提供了 Python on K8s 的 Kernel，还扩展了很多自定义的能力，例如支持自定义镜像，以及针对于 Spark Kernel 的自定义 Spark 参数。

目前 Notebook 任务已成为字节跳动内部使用较为高频的任务类型，用户可以在火山引擎 DataLeap 官网开通交互式分析的版本，使用到 DataLeap 的 Notebook 任务。

点击跳转 火山引擎大数据研发治理DataLeap 了解更多