> ## 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.

# 函数式数据处理

> 深入理解 Chaintable 的逻辑与算力解耦范式，以及无状态函数在多场景下的确定性执行机制

***

为了打破大规模链上数据清洗时的性能瓶颈，Chaintable 采用了\*\*函数式数据处理（Functional Data Processing）\*\*范式。

在这里，你的核心工作是编写纯粹的数据处理函数（Function）。你**不需要操心如何连接数据库、如何编写复杂的 SQL Insert 语句，更不用操心目标表的写入冲突与并发锁**。你只需定义数据的转换规则，剩下的全部由平台托管。

***

## 1. 核心哲学：逻辑与算力的深度解耦

Chaintable 将“业务逻辑”与“底层算力”进行了绝对的剥离，由以下三大支柱共同支撑：

### 纯粹的逻辑定义（Stateless Function）

你只需要编写一个简单的 Python 函数，定义“如何将这一行/这一块原始链上数据转化为业务数据”。这个函数在逻辑上是\*\*无状态（Stateless）**且**幂等（Idempotent）\*\*的，它不依赖也无法修改外部全局环境，只严格关注输入与输出。
**标准的计算函数示例：**

```python theme={null}
def trace_to_token_transfer(record):
    # 1. 防御性过滤：排除代理调用等非转账行为
    if record.get('call_type') == 'delegatecall':
        return None

    # 2. 核心边界校验：必须有有效价值且包含交易 ID
    if not (record.get('value', 0) > 0 and record.get('tx_id')):
        return None

    # 3. 声明式输出：仅返回 dict / list[dict] / None
    # 平台会自动捕获返回值，并将其无缝、安全地持久化到目标 Block 表中
    return dict(
        id=record['id'],
        token_id='0x000000000000000000000000000000000000EEEE',  # 原生 ETH 标识
        from_addr=record['from_addr'],
        to_addr=record['to_addr'],
        value=record['value'],
        tx_id=record['tx_id'],
    )

```

### 计算的无限扩展（BlockX Serverless Cluster）

由于你编写的函数是完全无状态的，这意味着它们具备天然的**可并行性**。当面对海量历史区块回填或极高频的实时流时，BlockX 并发引擎可以将成千上万个函数调用（Function Calls）在瞬间分发到数百个 Serverless 计算节点上运行，实现计算能力的线性弹性扩展。

### 计算状态共享与智能 IO 拦截

在链上数据处理中，函数往往需要点查某些依赖状态（例如：查询某个智能合约的 Decimal 精度，或验证某个地址是否在黑名单中）。如果每个并发函数都去请求一次节点，会瞬间对基础设施造成毁灭性的 IO 压力。

* **世界状态假设**：BlockX 在执行层实现了智能拦截机制。在一个 Task 计算周期内，相同的数据库查询或节点 RPC 请求会被自动拦截、合并并缓存。
* **开发者红利**：你可以放心地在函数里编写简单的、符合直觉的点查逻辑，BlockX 会帮你实现“一次网络请求，全域节点共享”，在保护上游节点的同时大幅度提升吞吐量。

***

## 2. 函数的使用范围

在 Chaintable 中，不论是数据索引还是数据应用，你的主要工作都是编写计算函数一项。根据产品开发阶段的不同，同一个 Function 可以无缝部署在三个完全不同的场景中执行，且**保证逻辑语义的绝对对齐（Deterministic Execution）**：

```
       ┌───────────────────  Your Python Function  ───────────────────┐
       │                                                              │
       ▼                               ▼                              ▼
【 1. 数据生产场景 】            【 2. OpenAPI 场景 】          【 3. Notebook 调试 】
 运行于 BlockX 弹性集群         运行于 OpenAPI 交付集群         运行于本地 Notebook 进程
 面向海量区块, 大规模并发        对外暴露为低延迟 HTTP 接口      实时 Print 日志, 断点 Debug

```

### 1. 数据生产场景（Data Ingestion）

这是函数最核心的运行场景。

* **执行主体**：BlockX 高并发集群。
* **运行机制**：由事件驱动循环触发，BlockX 负责将函数瞬间分发到计算节点，并行处理数以万计的区块事件。此时开启**任务级 IO 缓存优化**，全力利用集群算力。

### 2. OpenAPI 场景（Data Delivery）

当数据在 BlockDB 中生产完成后，你需要将这些高价值数据交付给下游的在线应用（如网页、App、DApp 后端）。

* **执行主体**：OpenAPI 执行集群。
* **运行机制**：你可以一键将该 Function 发布为标准的 **OpenAPI（HTTP 接口）**。当下游应用调用接口时，该函数充当轻量级的“API 后端逻辑”，直接从 BlockDB 读取数据、执行聚合或格式转换并即时响应。这允许你在不改变底层存储结构的前提下，通过修改函数逻辑，极其灵活地调整对外提供的数据视图。

### 3. Notebook 调试与本地处理（Sandbox & Debug）

在正式发布任务之前，你需要对逻辑进行验证。

* **执行主体**：Notebook 进程自身沙箱环境。
* **运行机制**：函数直接运行在当前的 Notebook 实例中。开发者可以传入少量的测试区块数据进行小规模计算，实时观察变量状态、查看 `print()` 打印日志，执行调试。

***

## 3. 跨环境执行行为的对齐规范

为了确保“所见即所得”，Chaintable 在底层做了严苛的跨语言与跨环境行为对齐：

* **严谨的确定性**：无论是本地 Notebook 里的单步调试，还是 BlockX 里的多核并发，亦或是 OpenAPI 的即时响应，函数的**计算结果在逻辑层面上严格一致**。
* **透明的层级优化**：唯一的区别在于执行层的性能优化。Notebook & OpenAPI 采用标准执行模式，侧重于响应的**极低延迟（Low Latency）**；而 BlockX 则在保持标准语义的基础上，附加了**大规模并发下的状态合并与 IO 缓存**。

对于开发者而言，掌握函数编写，即可掌握数据生产，数据交付和数据测试的核心能力。