docs: 边缘/具身智能方向定位与可行性分析

docs/edge-positioning-feasibility.md

@@ -0,0 +1,144 @@
+# BanDB Flux：边缘/具身智能方向 —— 定位、可行性与路线图
+
+> 写于 2026-06-06。本文是一次"老大视角"的冷水复盘：先核代码、再判战场、再逐条体检你提的护城河，最后给一条不再"换皮"的路线。结论先放最前面，论据在后。
+
+---
+
+## 0. 一句话结论（TL;DR）
+
+- 你这次的转向（从"通用数仓前置"→"边缘/具身智能"）**方向是对的**，但**没逃出原来的困局**：你换掉的不是对手，是对手的名字。在边缘赛道，"轻量 / 单二进制 / 低内存"不是护城河，是**入场券**——因为对手（Zenoh、MCAP）本来就是单二进制、为边缘而生的。
+- 你提的三大护城河里：**Multi-Raft 互备**本能对、工具用错；**去中心化调度**属于产品越界，建议砍掉；**时空索引 + 边缘切片上传**是唯一真正值得做、也最能打的差异化——但它**现在代码里不存在**。
+- 这个项目**真正的、卖得动的价值**不是任何一个应用故事（故事每换一次就冒出一个更强的现成对手），而是两样东西：
+  1. **自研内核的深度**（LSM + Bloom + Compaction、Raft + group-commit fsync、自研 TCP/TLV + 钩子）——对后端/基础架构岗，这才是金子，诚实讲就够强。
+  2. **唯一活得下来的差异化**：**可编程的、落盘前的网络层钩子 + 边缘侧查询/过滤，只上传命中切片**。录制与传输类对手（MCAP / Zenoh / COS）都不在采集入口做"变换 + 拒绝 + 查询"。这是你代码里真有、别人没有的那道缝。
+- 别再追求"第四次换皮"。停下来做三件事：**(a) 把内核深度讲清楚；(b) 把唯一差异化做实；(c) 做一个有数字的 benchmark demo。** 一个能跑出数字的 demo，胜过四根 PPT 支柱。
+
+---
+
+## 1. 现状盘点：真货 vs PPT（已逐条核代码）
+
+| 卖点 | 代码里的真实状态 | 判定 |
+|---|---|---|
+| BanNet 自研 TCP 框架 | `network/banNet` 有连接管理、worker pool（`TaskQueue`）、TLV 打解包 | ✅ 真 |
+| PreHandle / PostHandle 钩子 | `service/router.go` 有 `SetPreHandle/SetPostHandle` 可挂载回调 | ✅ 真（但目前只有挂载点，没挂任何实际 ETL/校验逻辑） |
+| LSM 存储引擎 | `storage/` 有 MemTable(跳表)、WAL、SSTable、Bloom、Compaction、迭代器 | ✅ 真 |
+| Raft | `Raft/` 有 WAL group-commit fsync、快照 | ✅ 真（**单组、单 Raft**；README Roadmap 自己写着"多节点部署工具仍待完善"） |
+| **双通道"抢占式优先级调度"** | `connection.go` 只有 `msgChan`(小缓冲, 注释"高优") 和 `msgBuffChan`(大缓冲) 两条 channel，**没有任何抢占/优先级选择器** | ⚠️ **PPT**：架构图里的"抢占式 Channel"是愿景，不是实现 |
+| MVCC | 仅 `fsm.go` 一处 version 字样 | ⚠️ **PPT**：基本没实现 |
+| Multi-Raft / 分片 | 无 | ❌ 不存在 |
+| 时空 / 多维索引 | 无（只有 timestamp 前缀 key 能做范围扫） | ❌ 不存在 |
+
+**红线**：你新方案的四大支柱里，"双通道优先级调度"是空的。面试官一句"打开看看那个抢占式调度器"，你会**第二次挂墙上**。每根支柱的纪律只有一条：**要么把它做出来，要么把这句话从简历上删掉。**
+
+---
+
+## 2. 战场判断：你换的不是对手，是对手的名字
+
+旧定位（通用大数据数仓前置）的对手是 **Kafka / Spark / Flink**——打不过，已确认。
+新定位（边缘/具身智能）的对手**不是 Kafka**，而是机器人原生栈里这几个，而且它们个个都比 Kafka 更贴你的脸：
+
+1. **ROS 2 / DDS（Fast DDS）**：机器人通信与数据流的事实标准。
+2. **rosbag2 + MCAP**：**MCAP 从 ROS 2 Iron（2023.5）起就是 rosbag2 的默认录制格式**。它天生多模态、带时间戳、带 schema、可索引；而且**专门为资源受限机器人提供了 `fastwrite` 预设**（最高写吞吐、最低资源占用）。这正是"边缘端高频多模态落盘"的现成答案。
+3. **Eclipse Zenoh / `rmw_zenoh`**：Rust、单二进制、pub/sub/query，**明确为资源受限边缘/机器人设计、刻意比 DDS 更轻**。**已在 ROS 2 Kilted Kaiju（2025）成为 Tier-1 中间件**。它就是"零 JVM、轻量、边缘机器人传输与缓冲"——和你想讲的故事高度重叠。
+4. **云厂商对象存储的多段续传（COS / S3 multipart）**：自带断点续传 + ETag/MD5 校验。
+
+**关键结论**：在这个战场，"我是单二进制、低内存、零依赖"**不是差异化**，因为 Zenoh 和 MCAP fastwrite 本来就是。这句话必须在简历和面试里**主动承认**——它是战略前提，不是卖点。能让你区别于它们的，只剩下"**在采集入口做可编程的变换/过滤/查询**"这一件事（见 §5）。
+
+---
+
+## 3. 三大护城河逐条体检
+
+### 护城河 1：Multi-Raft 多机互备 —— 本能对，工具用错
+- **对的部分**：机器人 A 摔碎、数据随之消失，这是真痛点；"设备间互为备份"的方向是对的。
+- **错的部分**（面试官会精准戳破）：
+  - **CAP / quorum**：Raft 要多数派才能提交。野外 swarm 的局域网**分区是常态不是例外**。A 当 Leader 又被孤立（掉坑里），它**没来得及复制到多数派的那批 in-flight 写，正好就是会丢的那批**——Raft 不保护未提交日志。你想救的恰恰救不到。
+  - **带宽与发热**：把每台机器人的高频多模态数据（**包括相机帧**）同步复制给另外两台，写放大 3 倍、网络负载 3 倍，压在本就被 4K60+IMU 榨干、热到降频的硬件上。这与"轻量边缘"**正好相反**。
+  - **Multi-Raft 的工程量**：多 Raft Group + 分片 + 成员变更，是 TiKV/etcd 级别的工程。你现在连**单组多节点**都还没打磨好（README 自承）。
+- **诚实的替代解**：要做对等互备，用**异步反熵复制（anti-entropy / gossip）已落盘的数据块**（最终一致），**不要**在高频采集热路径上跑同步强一致 Raft。这样既救了数据，又不拖垮硬件。**建议**：简历上别写"Multi-Raft 边缘强一致互备"；写就要能扛住上面三连问。
+
+### 护城河 2：去中心化"边缘共识调度"（Raft 选个临时指挥官）—— 砍掉
+- 这是**产品越界**：存储 + 传输 + **集群编排**，三个产品塞进一个简历条目，每个都是多年工程。
+- **技术上也站不住**：Raft 给你的是"一致的日志"，**不是一个好的任务分配器**。"谁去采集区域1、谁去清洗区域2"是多机器人任务分配（MRTA）问题，和"对日志达成共识"是两回事。用 Raft 选主 ≠ 解决了调度。
+- **建议**：从简历主线删除，最多作为"未来探索"脚注存在。它只会稀释你真正能打的点。
+
+### 护城河 3：时空索引 + 边缘切片上传 —— 最强、最该做、但现在没有
+- **这是三条里唯一真正的差异化**，也和"可编程钩子"这条真货同源。"在边缘本地查询命中切片、只上传 1MB 而不是 1GB"——这是 MCAP/Zenoh/COS **都不擅长**的（MCAP 是录制 + 离线索引，不是带谓词下推的在线可查询存储）。
+- **但要把话说准，别被反杀**：
+  - **时间范围扫描是 LSM 免费送的**——timestamp 前缀 key 天然支持 range scan，TSDB 就是这么在 LSM 上建的。所以别说"KV 丢失了时间索引"，那是送给面试官的破绽。
+  - **真正缺的是**：(a) `put/get/delete` 是错误的 API 面（需要 range-scan + schema 感知的摄入接口）；(b) **多维/空间索引现在不存在**（"距坐标 5 米内"需要空间填充曲线/R-tree，或退化成扫描 + 过滤）。
+  - **可落地的诚实版**："边缘侧**时间范围扫描 + 谓词过滤**，只打包上传命中切片"——这个能做、也够亮。"完整时空索引"是过度承诺。
+
+---
+
+## 4. 对你两点反驳的"反驳"（你邀请的，照单全收）
+
+### 你说："别在 iOS 采集时顺手洗数据，会拖垮硬件" —— ✅ 对，但有个洞
+- **认同**：iPhone 在 4K60 编码 + IMU 几百 Hz 时 CPU/ISP 已满载，主线程再跑光流/高频对齐会发热降频甚至崩。**采集与处理解耦、先用 append-only 快速落盘**，是正确的系统思维。这是你这几轮里最扎实的一点。
+- **洞**：**iOS 上没有"daemon 进程"**。iOS 沙箱不允许常驻后台守护进程——BanDB 在 iOS 上只能是**嵌入到 App 里的库**，不是独立进程。所以"跨平台统一 daemon"的说法对 iOS 这一半是错的（Jetson/Linux 那一半对）。而且 AVFoundation 本来就把采集高效写盘了——你要能说清**BanDB 比"直接写文件 + 一个 manifest"多给了什么**（答案应该指向 §5 的钩子 + 边缘查询，而不是"我也能落盘"）。
+
+### 你说："不是 RTMP 实时直传，而是 WAL 式本地落盘 + 异步断点续传 + hash 校验，0 丢包" —— ✅ 逻辑对，但**这恰恰不是护城河**
+- **认同**：本地先持久化、再异步搬运、收齐校验通过才删本地——这个闭环设计是对的，思路清晰。
+- **致命点**：**你正在防守的这件事（可靠的、可断点续传的、带 hash 校验的上传），正是云 SDK 最擅长、已经做好的商品级能力。** COS/S3 的 multipart upload 自带分块、断点续传、ETag/MD5 校验；restic/rsync 之流也是。所以"断点续传 + hash 校验"**不是壁垒，是 table-stakes**。你以为这是王牌，其实它是对手的主场。**别把它当卖点讲**——讲了反而暴露你把"现成能力"误当成"自研创新"。
+
+---
+
+## 5. 这个项目真正的用途与价值（去掉幻想后剩下的）
+
+把每一层换皮故事剥掉、把每一个有现成强对手的卖点划掉之后，**剩下的才是真的**：
+
+1. **作为作品集 / 简历资产 —— 自研内核深度才是金子。**
+   对 junior/mid 的后端、存储、基础架构岗，真正打动人的是：你**从零实现了硬核内核**——LSM（Bloom + Compaction + 迭代器）、Raft（group-commit fsync 摊销整批 fsync）、自研 TCP 框架（TLV + 生命周期钩子），并能讲清你踩过的坑：**写放大、fsync 批量化、背压、墓碑边界**。这套东西**不依赖任何应用故事**就成立。应用场景只是把它具体化的外壳。
+
+2. **唯一活得下来的差异化 —— 采集入口的可编程性。**
+   录制类（MCAP）、传输类（Zenoh/DDS）、上传类（COS）三家都**不在数据落盘前做"变换 + 校验 + 拒绝 + 查询"**。BanDB 的 `PreHandle` 钩子 + 边缘侧 range-scan/谓词过滤，能在**数据进系统的那一刻**做：
+   - 流式脱敏 / 字段裁剪 / 格式校验 / 丢弃畸形或超时帧（**逐帧校验，注意：这不是"时间同步"——同步是硬件触发/PTP/approximate-time 的事，别声称你解决了"画音不同步"**）；
+   - 边缘本地按时间范围 + 谓词扫描，**只上传命中的"黄金切片"**。
+   这一条，是你区别于所有现成轮子的那道缝。**把定位、简历、demo 全部压在这一条上。**
+
+---
+
+## 6. 路线图：停止"换皮循环"，只做三件事
+
+> 这份路线的目的，是**打破"每被驳倒一次就换一个应用主题"的循环**。修复它的不是更好的故事，而是把下面三件做实。
+
+### (a) 把内核深度讲清楚（已有，整理即可）
+- 一页纸技术说明：LSM 各层、Bloom 命中率数据、Compaction 策略、Raft group-commit fsync 的 before/after 数字（你 commit 历史里就有这个优化）。
+
+### (b) 把唯一差异化做实（新建，2~3 个外科手术式 PR）
+1. **挂一个真实的 PreHandle 过滤器**：一个示例 ETL 钩子——校验时间戳单调性、丢弃超时/畸形帧、字段脱敏。让"可编程钩子"从挂载点变成有内容的演示。
+2. **边缘查询接口**：在现有 LSM 上加一个 `scan(start_ts, end_ts) + predicate` 的范围扫描 API（**不引入空间索引，先用扫描 + 过滤**），输出"命中切片"。
+3. *(可选，能则加)* 若要保留"双通道优先级"这句话，就**真做一个抢占式调度器**（`select` 优先 `msgChan` 再 `msgBuffChan`，或加权），否则从所有材料里删掉这句。
+
+### (c) 一个有数字的 benchmark demo（决定成败）
+- 在**内存封顶**的配置下，灌入**合成 IMU 高频流（N kHz）**，证明：**0 丢帧 + WAL 可恢复 + 内存不超顶**，给出吞吐/延迟/内存三个数字。
+- **一个能在受限配置下跑出数字的 demo，胜过四根 PPT 支柱。** 具身智能岗的面试官多是"硬件实在派"，闻得出 vaporware。
+
+---
+
+## 7. 简历话术（诚实版，按岗位分两档）
+
+**A. 后端 / 存储 / 基础架构岗（推荐主线——卖内核深度）**
+> "从零用 Go 实现了一个轻量 KV 存储引擎 BanDB：LSM 存储路径（MemTable 跳表 + WAL + SSTable + Bloom + 分层 Compaction）、自研 TCP 框架（TLV 协议 + 生命周期钩子）、以及基于 Raft 的写复制（实现了 WAL group-commit，将整批写的 N 次 fsync 摊销为 1 次）。围绕写放大、fsync 批量化与背压做了系统性调优，并以合成高频流验证了 [X] 写入吞吐 / [Y] 内存上限。"
+
+**B. 具身智能 / 边缘方向（外壳——只在 §5 那道缝上发力，且主动承认入场券）**
+> "面向边缘高频多模态采集，基于自研 TCP 钩子与 LSM 引擎，实现了**采集入口的可编程预处理**（落盘前流式校验/裁剪/丢弃畸形帧）与**边缘侧时间范围查询**，使设备只上传命中谓词的关键切片而非整段原始流。明确定位为 rosbag2/MCAP、Zenoh 等成熟栈**之外的、采集入口可编程缓冲层**，而非替代机器人中间件。"
+
+**禁区**（写了就准备被钉）：不写"Multi-Raft 边缘强一致互备"、不写"去中心化共识调度"、不把"断点续传 + hash 校验"当创新卖点、不声称解决了"画音同步"、不声称"完整时空索引"。
+
+---
+
+## 8. 面试官的杀手问题清单（先自己答上）
+
+1. "rosbag2/MCAP 已是 ROS 2 默认录制格式且有 fastwrite 预设，Zenoh 已是 ROS 2 Tier-1 且单二进制，为什么用你的？" → 答案只能是 §5 第 2 条（采集入口可编程 + 边缘查询切片），别答"我轻量"。
+2. "断点续传 + hash 校验，COS multipart 不就自带吗？" → 承认是商品能力，转向你真正多给的东西。
+3. "你说的双通道抢占式调度，给我看调度器代码。" → 要么有，要么早删了这句。
+4. "野外网络分区下，你的 Raft 强一致互备怎么保证可用性？丢的不正好是 Leader 没复制出去的那批吗？" → 这就是为什么把它降级为异步反熵复制。
+5. "相机帧是 blob 流不是 KV，put/get 是对的抽象吗？" → 承认需要 range-scan/schema-aware 接口，这是路线 (b) 第 2 项。
+
+---
+
+## 附：本文依据的外部事实（2026-06 核验）
+
+- MCAP 自 ROS 2 Iron（2023-05）起为 rosbag2 默认存储格式，含面向资源受限机器人的 `fastwrite` 预设。
+- Eclipse Zenoh / `rmw_zenoh` 在 ROS 2 Kilted Kaiju（2025）达到 Tier-1 中间件状态（Fast DDS 仍为默认）。
+- 以上用于论证"边缘赛道真正的对手不是 Kafka，且'轻量单二进制'在该赛道是入场券而非护城河"。