> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chaintable.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Notebooks 任务开发、调度与管控概述

> 了解如何在 Chaintable 平台中创建、配置、调度和运维你的 Notebook 实时/批处理清洗任务

***

# Notebooks 任务开发、调度与管控

在 Chaintable 生态中，Notebook 不仅仅是一个交互式探索代码的沙箱，更是**生产级区块链 ETL 任务、流处理状态机和时序指标重算的第一等公民（First-Class Citizen）**。

通过平台统一的 Web UI，你可以直接编写基于 function和blockx sdk 的清洗逻辑，并将其一键发布为具备高可用保障的分布式调度任务。

***

## 1. 创建和管理 Notebook

本节介绍如何通过平台简单的 UI 创建、配置和管理你的首个 Notebook 任务，并将其与底层计算资源安全绑定。

### 场景描述

开发者登录 Chaintable 控制台后，可以在“Notebook”板块一键新建工作区。每个 Notebook 在初始化时都会绑定一个独立的 **BlockX Serverless 轻量级运行时实例**。你可以在这里直接调用 `from blockdb import Table, BlockTable` 引入全域 SDK 接口。

平台提供完整的版本控制能力。每次你点击 Web UI 的 “Save Version” 或触发代码变更时，底层都会通过 Git 逻辑对当前 Notebook 里面的 Code Cells、环境变量配置进行快照式归档。

### TODO 待补充操作与开发计划

* [ ] **UI 截图与交互步骤补全**：待前端控制台 alpha.2 版本发布后，在此处补充“新建工作区 -> 绑定数据源 -> 分配计算节点”的完整 UI 交互截图。
* [ ] **底层环境持久化配置 (Requirements.txt)**：目前 Notebook 默认内置了 `blockdb-py` 与 `pandas`。未来需支持在 UI 上直接声明第三方 pip 依赖包，并在后台容器启动时自动拉取。
* [ ] **企业级 RBAC 权限隔离**：补充不同数据组成员（如 Architect、Data Engineer、Viewer）针对特定隔离空间下 Notebook 的读写、编辑与发布权限审批流说明。

***

## 2. Notebook 的触发类型与调度流

介绍永续执行（Streaming）、定时任务（Cron）和手动执行（Manual）的使用场景，以及它们在底层数据库引擎中触发的不同行为。

### 场景描述

当一个 Notebook 的清洗逻辑经过调试可以投产时，你需要为其配置触发策略。Chaintable 目前支持三种硬核特化调度模式：

1. **永续执行 (Streaming / Continuous)**：
   * **适用场景**：高频实时链上数据流解析（如实时监听 Transfer 事件）。
   * **运行机制**：任务启动后常驻后台。它会利用 `Aligned` 状态机或 `Subscribe` 组件，以无休止的 `for block in aligned.listen():` 心跳循环死锁并消费最新的实时区块变更。
2. **定时任务 (Cron / Scheduled)**：
   * **适用场景**：TimeTable 数据的多尺度 resampling 重算、每日/每小时的 Gas 消耗统计、跨域数据对账。
   * **运行机制**：依靠平台内置的分布式 Cron 调度器，时间到达时按物理挂钟时间自动唤醒轻量级容器执行。
3. **手动执行 (Manual / On-Demand)**：
   * **适用场景**：历史大范围高度区块数据分布式回填（Historical Backfill）、临时数据补录、Ad-hoc 报表分析。

***

## 3. Notebook 实例运维、监控与区块级追溯

观察每个 Block 自身逻辑的处理情况，实时复现和定位出错区块高度的执行过程。

### 场景描述

对于区块链 ETL 来说，最痛苦的不是系统挂掉，而是**遇到异常数据、智能合约极端边界情况（Edge Case）导致的代码中断**。Chaintable 为 Notebook 提供了独特的“区块级可观测性”。

在运维面板中，你可以清晰地观察到任务的 **Lag（数据消费延迟水位线）**。一旦任务由于未捕获异常而崩溃，监控系统不仅会捕捉到标准的 Python Traceback 堆栈，还会自动锁定**导致报错的精确区块链高度（Block Height）与块哈希（Block Hash）**。

### TODO 待补充操作与开发计划

* [ ] **沙箱 Debug 熔断模式联动说明**：补充当生产环境的运行任务发生异常时，运维人员如何一键复制该 Notebook 并在本地开启 `BLOCKDB_DEBUG=1` 环境变预演，在不污染物理 TiDB 底层的前提下完美复现出错区块。
* [ ] **Metrics 指标看板对接**：补充基于 `[metric]` 配置项下 `lag_threshold = "30m"` 的报警触发链路，即消费延迟超过 30 分钟时，如何通过 Webhook 自动推送通知给 Slack 或 PagerDuty。
* [ ] **自动回滚（Reorg Rollback）可视化**：在监控 UI 上，如何直观展现当区块链发生分叉重组（Reorg）时，Notebook 流任务物理调用影子表（Shadow Table）进行