一、概述

Notebook 是一種支持 REPL 模式的開發(fā)環(huán)境。所謂「REPL」，即「讀取-求值-輸出」循環(huán)：輸入一段代碼，立刻得到相應(yīng)的結(jié)果，并繼續(xù)等待下一次輸入。它通常使得探索性的開發(fā)和調(diào)試更加便捷。在 Notebook 環(huán)境，你可以交互式地在其中編寫你的代碼、運(yùn)行代碼、查看輸出、可視化數(shù)據(jù)并查看結(jié)果，使用起來非常靈活。

在數(shù)據(jù)開發(fā)領(lǐng)域，Notebook 廣泛應(yīng)用于數(shù)據(jù)清理和轉(zhuǎn)換、數(shù)值模擬、統(tǒng)計(jì)建模、數(shù)據(jù)可視化、構(gòu)建和訓(xùn)練機(jī)器學(xué)習(xí)模型等方面。

但是顯然，做數(shù)據(jù)開發(fā)，只有 Notebook 是不夠的。在火山引擎 DataLeap 數(shù)據(jù)研發(fā)平臺(tái)，我們提供了任務(wù)開發(fā)、發(fā)布調(diào)度、監(jiān)控運(yùn)維等一系列能力。我們將 Notebook 作為一種任務(wù)類型，加入了數(shù)據(jù)研發(fā)平臺(tái)，使用戶既能擁有 Notebook 交互式的開發(fā)體驗(yàn)，又能享受一站式大數(shù)據(jù)研發(fā)治理套件提供的便利。如果還不夠直觀的話，試想以下場景：

在交互式運(yùn)行和可視化圖表的加持下，你很快就調(diào)試完成了一份 Notebook。簡單整理了下代碼，根據(jù)使用到的數(shù)據(jù)配置了上游任務(wù)依賴，上線了周期調(diào)度，并順手掛了報(bào)警。之后，基本上就不用管這個(gè)任務(wù)了：不需要每天手動(dòng)檢查上游數(shù)據(jù)是否就緒；不需要每天來點(diǎn)擊運(yùn)行，因?yàn)檎{(diào)度系統(tǒng)會(huì)自動(dòng)幫你執(zhí)行這個(gè) Notebook；執(zhí)行失敗了有報(bào)警，可以直接上平臺(tái)來處理；上游數(shù)據(jù)出錯(cuò)了，可以請(qǐng)他們發(fā)起深度回溯，統(tǒng)一修數(shù)。

二、選型

2019 年末，在決定要支持 Notebook 任務(wù)的時(shí)候，我們調(diào)研了許多 Notebook 的實(shí)現(xiàn)，包括 Jupyter、Polynote、Zeppelin、Deepnote 等。Jupyter Notebook 是 Notebook 的傳統(tǒng)實(shí)現(xiàn)，它有著極其豐富的生態(tài)以及龐大的用戶群體，相信許多人都用過這個(gè)軟件。事實(shí)上，在字節(jié)跳動(dòng)數(shù)據(jù)平臺(tái)發(fā)展早期，就有了在物理機(jī)集群上統(tǒng)一部署的 Jupyter（基于多用戶方案 JupyterHub），供內(nèi)部的用戶使用。考慮到用戶習(xí)慣和其強(qiáng)大的生態(tài)，Jupyter 最終成為了我們的選擇。

Jupyter Notebook 是一個(gè) Web 應(yīng)用。通常認(rèn)為其有兩個(gè)核心的概念：Notebook 和 Kernel。

Notebook 指的是代碼文件，一般在文件系統(tǒng)中存儲(chǔ)，后綴名為ipynb。Jupyter Notebook 后端提供了管理這些文件的能力，用戶可以通過 Jupyter Notebook 的頁面創(chuàng)建、打開、編輯、保存 Notebook。在 Notebook 中，用戶以一個(gè)一個(gè) Cell 的形式編寫代碼，并按 Cell 運(yùn)行代碼。Notebook 文件的具體內(nèi)容格式，可參考 The Notebook file format (https://nbformat.readthedocs.io/en/latest/format_description.html)。

Kernel 是 Notebook 中的代碼實(shí)際的運(yùn)行環(huán)境，它是一個(gè)獨(dú)立的進(jìn)程。每一次「運(yùn)行」動(dòng)作，產(chǎn)生的效果是單個(gè) Cell 的代碼被運(yùn)行。具體來講，「運(yùn)行」就是把 Cell 內(nèi)的代碼片段，通過 Jupyter Notebook 后端以特定格式發(fā)送給 Kernel 進(jìn)程，再從 Kernel 接受特定格式的返回，并反饋到頁面上。這里所說的「特定格式」，可參考 Messaging in Jupyter(https://jupyter-client.readthedocs.io/en/stable/messaging.html)。

在 DataLeap 數(shù)據(jù)研發(fā)平臺(tái)，開發(fā)過程圍繞的核心是任務(wù)。用戶可以在項(xiàng)目下的任務(wù)開發(fā)目錄創(chuàng)建子目錄和任務(wù)，像 IDE 一樣通過目錄樹管理其任務(wù)。Notebook 也是一種任務(wù)類型，用戶可以啟動(dòng)一個(gè)獨(dú)立的任務(wù) Kernel 環(huán)境，像開發(fā)其他普通任務(wù)一樣使用 Notebook。

三、技術(shù)路線

在 Jupyter 的生態(tài)下，除了 Notebook 本身，我們還注意到了很多其他組件。彼時(shí)，JupyterLab 正在逐漸取代傳統(tǒng)的 Jupyter Notebook 界面，成為新的標(biāo)準(zhǔn)。JupyterHub 使用廣泛，是多用戶 Notebook 的版本答案。脫胎于 Jupyter Kernel Gateway(JKG)的 Enterprise Gateway(EG)，提供了我們需要的 Remote Kernel（上述的獨(dú)立任務(wù) Kernel 環(huán)境）能力。2020 上半年，我們基于上面的三大組件，進(jìn)行二次開發(fā)，在字節(jié)跳動(dòng)數(shù)據(jù)研發(fā)平臺(tái)發(fā)布了 Notebook 任務(wù)類型。整體架構(gòu)預(yù)覽如圖。

JupyterLab

前端這一側(cè)，我們選擇了基于更現(xiàn)代化的 JupyterLab (https://jupyterlab.readthedocs.io/en/stable/getting_started/overview.html) 進(jìn)行改造。我們刨去了它的周邊視圖，只留下了中間的 Cell 編輯區(qū)，嵌入了 DataLeap 數(shù)據(jù)研發(fā)的頁面中。為了和 DataLeap 的視覺風(fēng)格更契合，從 2020 下半年到 2021 年初，我們還針對(duì)性地改進(jìn)了 JupyterLab 的 UI。這其中包括將整個(gè) JupyterLab 使用的代碼編輯器從 CodeMirror 統(tǒng)一到 DataLeap 數(shù)據(jù)研發(fā)使用的 Monaco Editor，同時(shí)還接入了 DataLeap 提供的 Python & SQL 代碼智能補(bǔ)全功能。

額外地，我們還開發(fā)了定制的可視化 SDK，使得用戶在 Notebook 上計(jì)算得到的 Pandas Dataframe 可以接入 DataLeap 數(shù)據(jù)研發(fā)已經(jīng)提供的數(shù)據(jù)結(jié)果分析模塊，直接在 Notebook 內(nèi)部做一些簡單的數(shù)據(jù)探查。

JupyterHub

JupyterHub（https://jupyterhub.readthedocs.io/en/stable/） 提供了可擴(kuò)展的認(rèn)證鑒權(quán)能力和環(huán)境創(chuàng)建能力。首先，由于用戶較多，因此為每個(gè)用戶提供單獨(dú)的 Notebook 實(shí)例不太現(xiàn)實(shí)。因此我們決定，按 DataLeap 項(xiàng)目來切分 Notebook 實(shí)例，同項(xiàng)目下的用戶共享一個(gè)實(shí)例（即一個(gè)項(xiàng)目實(shí)際上在 JupyterHub 是一個(gè)用戶）。這也與 DataLeap 的項(xiàng)目權(quán)限體系保持了一致。注意這里的「Notebook 實(shí)例」，在我們的配置下，是拉起一個(gè)運(yùn)行 JupyterLab 的環(huán)境。另外，由于我們會(huì)使用 Remote Kernel，所以在這個(gè)環(huán)境內(nèi)，并不提供 Kernel 運(yùn)行的能力。

在認(rèn)證鑒權(quán)方面，我們讓 JupyterHub 請(qǐng)求我們業(yè)務(wù)后端提供的驗(yàn)證接口，判斷登錄態(tài)的用戶是否具備請(qǐng)求的對(duì)應(yīng) DataLeap 項(xiàng)目的權(quán)限，以實(shí)現(xiàn)權(quán)限體系對(duì)接。

在環(huán)境創(chuàng)建方面，我們通過 OpenAPI 對(duì)接了字節(jié)跳動(dòng)內(nèi)部的 PaaS 服務(wù)，為每一個(gè)使用了 Notebook 任務(wù)的 DataLeap 項(xiàng)目分配一個(gè) JupyterLab 實(shí)例，對(duì)應(yīng)一個(gè) PaaS 服務(wù)。由于直接新建一個(gè)服務(wù)的流程較長，速度較慢，因此我們還額外做了池化，預(yù)先啟動(dòng)一批服務(wù)，當(dāng)有新項(xiàng)目的用戶登入時(shí)直接分配。

Enterprise Gateway

Jupyter Enterprise Gateway (https://jupyter-enterprise-gateway.readthedocs.io/en/latest/) 提供了在分布式集群（包括 YARN、Kubernetes 等）內(nèi)部啟動(dòng) Kernel 的能力，并成為了 Notebook 到集群內(nèi) Kernel 的代理。在原生的 Notebook 體系下，Kernel 是 Jupyter Notebook / JupyterLab 中的一個(gè)本地進(jìn)程；對(duì)于啟用了 Gateway 功能的 Notebook 實(shí)例，所有 Kernel 相關(guān)的功能的請(qǐng)求，如獲取 Kernel 類型、啟動(dòng) Kernel、運(yùn)行 Cell、中斷等，都會(huì)被代理到指定的 Gateway 上，再由 Gateway 代理到具體集群內(nèi)的 Kernel 里，形成了 Remote Kernel 的模式。

這樣帶來的好處是，Kernel 和 Notebook 分離，不會(huì)相互影響：例如某個(gè) Kernel 運(yùn)行占用物理內(nèi)存超限，不會(huì)導(dǎo)致其他同時(shí)運(yùn)行的 Kernel 掛掉，即使他們都通過同一個(gè) Notebook 實(shí)例來使用。

EG 本身提供的 Kernel 類型，和字節(jié)跳動(dòng)內(nèi)部系統(tǒng)并不完全兼容，需要我們自行修改和添加。我們首先以 Spark Kernel 的形式對(duì)接了字節(jié)跳動(dòng)內(nèi)部的 YARN 集群。Kernel 以 PySpark 的形式在 Cluster 模式的 Spark Driver 運(yùn)行，并提供一個(gè)默認(rèn)的 Spark Session。用戶可以通過在 Driver 上的 Kernel，直接發(fā)起運(yùn)行 Spark 相關(guān)代碼。同時(shí)，為了滿足 Spark 用戶的使用習(xí)慣，我們額外提供了在同一個(gè) Kernel 內(nèi)交叉運(yùn)行 SQL 和 Scala 代碼的能力。

2020 下半年，伴隨著云原生的浪潮，我們還接入了字節(jié)跳動(dòng)云原生 K8s 集群，為用戶提供了 Python on K8s 的 Kernel。我們還擴(kuò)展了很多自定義的能力，例如支持自定義鏡像，以及針對(duì)于 Spark Kernel 的自定義 Spark 參數(shù)。

穩(wěn)定性方面，在當(dāng)時(shí)的版本，EG 存在異步不夠徹底的問題，在 YARN 場景下，單個(gè) EG 進(jìn)程甚至只能跑起來十幾個(gè) Kernel。我們發(fā)現(xiàn)了這一問題，并完成了各處所需的 async 邏輯改造，保證了服務(wù)的并發(fā)能力。另外，我們利用了字節(jié)跳動(dòng)內(nèi)部的負(fù)載均衡（nginx 七層代理集群）能力，部署多個(gè) EG 實(shí)例，并指定單個(gè) JupyterLab 實(shí)例的流量總是打到同一個(gè) EG 實(shí)例上，實(shí)現(xiàn)了基本的 HA。

四、架構(gòu)升級(jí)

當(dāng)使用 Notebook 的項(xiàng)目日漸增加時(shí)，我們發(fā)現(xiàn)，運(yùn)行中的 PaaS 服務(wù)實(shí)在太多了，之前的架構(gòu)造成了

部署麻煩。全量升級(jí) JupyterLab 較為痛苦。盡管有升級(jí)腳本，但是通過 API 操作升級(jí)服務(wù)，可能由于鏡像構(gòu)建失敗等原因，會(huì)造成卡單現(xiàn)象，因此每次全量升級(jí)后都是人工巡檢檢查升級(jí)狀態(tài)，卡住的升級(jí)單人工點(diǎn)擊下一步。同時(shí)由于升級(jí)不同服務(wù)不會(huì)復(fù)用配置相同的鏡像，所以有多少服務(wù)就要構(gòu)建多少次鏡像，當(dāng)服務(wù)數(shù)量達(dá)到一定量級(jí)時(shí)，我們的批量升級(jí)請(qǐng)求可能把內(nèi)部鏡像構(gòu)建服務(wù)壓垮。

JupyterLab 需要不斷的根據(jù)用戶增長（項(xiàng)目增長）進(jìn)行擴(kuò)容，一旦預(yù)先啟動(dòng)好的資源池不夠，就會(huì)存在新項(xiàng)目里有用戶打開 Notebook，需要經(jīng)歷整個(gè) JupyterLab 服務(wù)創(chuàng)建、環(huán)境拉起的流程，速度較慢，影響體驗(yàn)。而且，JupyterLab 數(shù)量巨大后，遇到 bad case 的幾率增高，有些問題不易復(fù)現(xiàn)、非常偶發(fā)，重啟/遷移即可解決，但是在遇到的時(shí)候，用戶體驗(yàn)受影響較大。

運(yùn)維困難。當(dāng)用戶 JupyterLab 可能出現(xiàn)問題，為了找到對(duì)應(yīng)的 JupyterLab，我們需要先根據(jù)項(xiàng)目對(duì)應(yīng)到 JupyterHub user，然后根據(jù) user 找到 JupyterHub 記錄的服務(wù) id，再去 PaaS 平臺(tái)找服務(wù)，進(jìn) webshell。

當(dāng)然，還有資源的浪費(fèi)。雖然每個(gè)實(shí)例很小(1c1g)，但是數(shù)量很多；有些項(xiàng)目并不總是在使用 Notebook，但 JupyterLab 依然運(yùn)行。

穩(wěn)定性存在問題。一方面，JupyterHub 是一個(gè)單點(diǎn)，升級(jí)需要先起后停，掛了有風(fēng)險(xiǎn)。另一方面，EG 入流量經(jīng)過特定負(fù)載均衡策略，本身是為了使 JupyterLab 固定往一個(gè) EG 請(qǐng)求。在 EG 升級(jí)時(shí)，JupyterLab 請(qǐng)求的終端會(huì)隨之改變，極端情況下有可能造成 Kernel 啟動(dòng)多次的情況。

基于簡化運(yùn)維成本、降低架構(gòu)復(fù)雜性，以及提高用戶體驗(yàn)的考慮，2021 上半年，我們對(duì)整體架構(gòu)進(jìn)行了一次改良。在新的架構(gòu)中，我們主要做了以下改進(jìn)，大致簡化為下圖：

1. 移除 JupyterHub，將 JupyterLab 改為多實(shí)例無狀態(tài)常駐服務(wù)，并實(shí)現(xiàn)對(duì)接 DataLeap 的多用戶鑒權(quán)。
2. 改造原本落在 JupyterLab 本地的數(shù)據(jù)存儲(chǔ)，包括用戶自定義配置、Session 維護(hù)和代碼文件讀寫。
3. EG 支持持久化 Kernel，將 Kernel 遠(yuǎn)程環(huán)境元信息持久化在遠(yuǎn)端存儲(chǔ)(MySQL)上，使其重啟時(shí)可以重連，且 JupyterLab 可以知道某個(gè) Kernel 需要通過哪個(gè) EG 連接。

鑒權(quán) & 安全

單用戶的 Jupyter Notebook / JupyterLab 的鑒權(quán)相對(duì)簡單（實(shí)際上 JupyterLab 直接復(fù)用了 Jupyter Notebook 的這套代碼）。例如，使用默認(rèn)命令啟動(dòng)時(shí)，會(huì)自動(dòng)生成一個(gè) token，同時(shí)自動(dòng)拉起瀏覽器。有了 token，就可以任意地訪問這個(gè) Notebook。

事實(shí)上，JupyterHub 也是起到了維護(hù) token 的作用。前端會(huì)發(fā)起一個(gè)獲取 token 的 API 請(qǐng)求，再拿著獲取的 token 請(qǐng)求通過 JupyterHub proxy 到真實(shí)的 Notebook 實(shí)例。而我們直接為 Jupyter Notebook 增加了 Auth 的功能，實(shí)現(xiàn)了在 JupyterLab 單實(shí)例上完成這套鑒權(quán)（此時(shí)，使用了 DataLeap 服務(wù)簽發(fā)的 Token）。

最后，由于所有用戶會(huì)共享同一組 JupyterLab，我們還需要禁止一些接口的調(diào)用，以保證系統(tǒng)的安全。最典型的接口包括關(guān)閉服務(wù)(Shutdown)，以及修改配置等。后續(xù) Notebook 所需的配置，轉(zhuǎn)由前端保存在瀏覽器內(nèi)。

代碼 & Session 持久化

Jupyter Notebook 使用 File Manager(https://github.com/jupyter-server/jupyter_server/blob/main/jupyter_server/services/contents/filemanager.py) 管理 Contents 相關(guān)讀寫（對(duì)我們而言主要是 Notebook 代碼文件），原生行為是將代碼存儲(chǔ)在本地，多個(gè)服務(wù)實(shí)例之間無法共享同一份代碼，而且遷移時(shí)可能造成代碼丟失。

為了避免代碼丟失，我們的做法是，把代碼按項(xiàng)目分別存儲(chǔ)在 OSS 上并直接讀寫，同時(shí)解決了一些由于代碼文件元信息丟失，并發(fā)編輯導(dǎo)致的其他問題。例如，當(dāng)多個(gè)頁面訪問同一份代碼文件時(shí)，都會(huì)從 OSS 獲取最新的 code，當(dāng)用戶存儲(chǔ)時(shí)，前端會(huì)獲取最新的代碼文件，比較該文件的修改時(shí)間同前端存儲(chǔ)的是否一致，如果不同，則說明有其它頁面存儲(chǔ)過，會(huì)提示用戶選擇覆蓋或是恢復(fù)。

Notebook 使用 Session 管理用戶到 Kernel 的連接，例如前端通過 POST /session 接口啟動(dòng) Kernel，GET /session 查看當(dāng)前運(yùn)行中的 Kernel。在 Session 處理方面，原生的 Notebook 使用了原生的 sqlite(in memory)，見代碼(https://github.com/jupyter-server/jupyter_server/blob/main/jupyter_server/services/sessions/sessionmanager.py)。盡管我們并不明白這么做的意義何在（畢竟原生的 Notebook 重啟，一切都沒了），但我們順著這個(gè)原生的表結(jié)構(gòu)繼續(xù)前進(jìn)，引入了 sqlalchemy 對(duì)接多種數(shù)據(jù)庫，將 Session 數(shù)據(jù)搬到了 MySQL。

另一方面，由于我們啟動(dòng)的 Kernel，有一部分涉及 Spark on YARN，啟動(dòng)速度并不理想，因此早期我們?cè)黾恿斯δ?，若某個(gè) path 已有正在啟動(dòng)的 Kernel，則等其啟動(dòng)完畢而不是再啟動(dòng)一個(gè)新的。這個(gè)功能原先使用內(nèi)存中的 set 實(shí)現(xiàn)，現(xiàn)在也移植到了數(shù)據(jù)庫上，通過 sqlalchemy 來訪問。

Kernel 持久化 & 訪問

在 Remote Kernel 的場景下，一個(gè) JupyterLab 需要知道它的某個(gè) Kernel 具體在哪個(gè) EG 上。在之前一個(gè)項(xiàng)目一個(gè) JupyterLab 的狀態(tài)下，我們通過負(fù)載均衡簡單處理這個(gè)問題：即一個(gè) Server 總是只訪問同一個(gè) Gateway。然而當(dāng) JupyterLab 成為無狀態(tài)服務(wù)時(shí)，用戶并非固定只訪問一個(gè) JupyterLab，也就不能保證總訪問用戶 Kernel 所在的 EG。

另一個(gè)情況是，當(dāng) JupyterLab 或 EG 重啟時(shí)，其上的 Kernel 都會(huì)關(guān)閉。當(dāng)我們升級(jí)相關(guān)服務(wù)時(shí)，總是需要通知用戶準(zhǔn)備重啟 Kernel。因此，為了實(shí)現(xiàn)升級(jí)對(duì)用戶無感，我們?cè)?EG 這層開發(fā)了持久化 Kernel 的特性。

Kernel Gateway 在啟動(dòng) Kernel 時(shí)，記錄了關(guān)于 Kernel 的一些元信息，包括啟動(dòng)參數(shù)、連接 Kernel 使用的 IP/Port 等。有了這些信息，當(dāng)一個(gè) Kernel Gateway 重啟且 Remote Kernel 不關(guān)閉，就有辦法重新連接上。原本這些信息默認(rèn)在內(nèi)存 dict 中維護(hù)，開源倉庫中有一套存儲(chǔ)在本地文件的方案；基于這套方案，我們擴(kuò)展了自研的存儲(chǔ)到 MySQL 的方案。

在多實(shí)例的場景下，每一個(gè) EG 實(shí)例依然會(huì)接管的各自的一部分 Kernel，并記錄每個(gè) Kernel 由誰接管（探活、Cull Idle、連接使用等）。在其關(guān)閉前，需要清除接管信息，以便下次啟動(dòng)或其他實(shí)例啟動(dòng)時(shí)撈起。

為了減少 client(正常是 JupyterLab) 任意訪問 EG 的情況，一方面我們沿用了負(fù)載均衡的策略，另一方面 JupyterLab 在請(qǐng)求 Kernel 相關(guān)操作前，會(huì)先請(qǐng)求 EG 一次，由 EG 決定 JupyterLab 具體請(qǐng)求哪一個(gè) EG IP/Port。

當(dāng) EG 服務(wù)本身重啟或者升級(jí)時(shí)，會(huì)在進(jìn)程退出之前去清除接管信息。當(dāng)頁面繼續(xù)訪問時(shí)，JupyterLab 服務(wù)將會(huì)隨機(jī)分發(fā)相應(yīng)請(qǐng)求，由其它的 EG 服務(wù)繼續(xù)接管。

收益

架構(gòu)升級(jí)簡化后，整套 Notebook 服務(wù)的穩(wěn)定性獲得了極大的提升。由于實(shí)現(xiàn)了用戶無感知的升級(jí)，不僅提升了用戶的使用體驗(yàn)，運(yùn)維的成本也同時(shí)降低了。

部署的成本也極大地降低，包括算力、人力的節(jié)省。由于剝離了內(nèi)部依賴，我們得以將這套架構(gòu)部署在各種公有云、私有化場景。

五、調(diào)度方案

在前面，我們重點(diǎn)關(guān)注了怎么將 Jupyter 這套應(yīng)用嵌入到 DataLeap 數(shù)據(jù)研發(fā)中。這只覆蓋了我們 Notebook 任務(wù)的頁面調(diào)試功能。實(shí)際上，同時(shí)作為一個(gè)調(diào)度系統(tǒng)，我們還需要關(guān)心怎么調(diào)度一個(gè) Notebook 任務(wù)。

首先，是和所有其他任務(wù)類型相同的部分：當(dāng) Notebook 任務(wù)所配置的上游依賴任務(wù)全部運(yùn)行完畢，開始拉起本次 Notebook 任務(wù)的運(yùn)行。我們會(huì)根據(jù)任務(wù)的版本創(chuàng)建一個(gè)任務(wù)的快照，我們稱之為任務(wù)實(shí)例，并將其提交到我們的執(zhí)行器中。

對(duì)于 Notebook 任務(wù)，在實(shí)例運(yùn)行前，我們會(huì)根據(jù) Notebook 任務(wù)對(duì)應(yīng)的版本，從 OSS 拷貝一份 Notebook 代碼文件，用于執(zhí)行。在具體的執(zhí)行流程中，我們使用了 Jupyter 生態(tài)中的 nbconvert (https://nbconvert.readthedocs.io/en/latest/) 來實(shí)現(xiàn)在沒有 Jupyter 應(yīng)用的前提下在后臺(tái)運(yùn)行這份 Notebook 文件，并將運(yùn)行后得到的結(jié)果 Notebook 文件傳回 OSS。nbconvert 的工作原理比較簡單，且復(fù)用了 Jupyter 底層的代碼，具體如下：

1. 根據(jù)指定的 Kernel Manager 或 Notebook 文件里的 Kernel 類型創(chuàng)建對(duì)應(yīng)的 Kernel Manager(https://github.com/jupyter/jupyter_client/blob/main/jupyter_client/manager.py)；
2. Kernel Manger 創(chuàng)建 Kernel Client，并啟動(dòng)一個(gè) Kernel；
3. 遍歷 Notebook 文件里的 Cell，調(diào)用 Kernel Client 執(zhí)行 Cell 里的代碼；
4. 獲取輸出結(jié)果，按照 nbformat 指定的 schema 填入 NotebookNode，并保存。

下圖是調(diào)度執(zhí)行 Notebook 的 Kernel 運(yùn)行流程和通過調(diào)試走 EG 的 Remote Kernel 運(yùn)行流程對(duì)比?？梢钥闯觯鼈兊逆溌凡]有本質(zhì)上的區(qū)別，只不過是在調(diào)度執(zhí)行時(shí)，不需要交互式的 Kernel 通信，以及 EG 的這些 Kernel Launcher 使用了 embed_kernel 在同進(jìn)程內(nèi)啟動(dòng) Kernel 而已。走到最底層，它們都是使用了 ipykernel 的（其他語言 kernel 同理）。

六、未來工作

Notebook 任務(wù)已成為字節(jié)跳動(dòng)內(nèi)部使用較為高頻的任務(wù)類型。在火山引擎，我們也可以購買 DataLeap，即一站式大數(shù)據(jù)研發(fā)治理套件，開通交互式分析的版本，使用到 DataLeap 的 Notebook 任務(wù)。

有的時(shí)候，我們發(fā)現(xiàn)，我們有比 Jupyter 社區(qū)快半步的地方：比如基于 asyncio 異步優(yōu)化的 EG；比如給 Notebook 增加 Auth 能力。但社區(qū)的發(fā)展也很快：比如社區(qū)將 Jupyter 后端相關(guān)的代碼實(shí)現(xiàn)，統(tǒng)一收斂到了jupyter_server；比如 EG 作者提出的 Kernel Provider 方案，令jupyter_server可以直接支持 Remote Kernel。

因此我們并未就此止步。目前，這套 Notebook 服務(wù)和 DataLeap 數(shù)據(jù)研發(fā)的其他前后端服務(wù)，仍存在著割裂。未來，我們希望精簡架構(gòu)，實(shí)現(xiàn)徹底的整合，使 Notebook 并非以嵌入的形式融合在 DataLeap 的產(chǎn)品中，而是使其原生就在 DataLeap 數(shù)據(jù)研發(fā)中被支持，帶來更好的性能，同時(shí)又保留所有 Jupyter 生態(tài)帶來的強(qiáng)大功能。另一方面，隨著 DataLeap 數(shù)據(jù)研發(fā)平臺(tái)對(duì)流式數(shù)據(jù)開發(fā)的支持，我們也希望借助 Notebook 實(shí)現(xiàn)用戶對(duì)流式數(shù)據(jù)的探索、調(diào)試、可視化等功能的需求。相信不久的將來，Notebook 能夠?qū)崿F(xiàn)流批一體化，來服務(wù)更加廣泛的用戶群體。