← 回到 研究

生理信号采集系统的边缘到云端数据管线

Edge-to-Cloud Data Pipeline for a Multi-Modal BLE Biosensor Platform

实验室已有一套 BLE 多模态生理信号采集程序，我补上了它缺的后半段：数据怎么在采集过程中就安全地传到服务器，以及之后怎么让对的人拿到它。

角色
学生研究员
时间
2026.05 – 至今
机构
North Carolina State University　指导 Dr. Abraham Vazquez

为什么做这件事

原来的流程是：录完，CSV 躺在自己电脑上，再想办法拷到服务器。问题不在麻烦，在于这条路上每一步都可能悄悄丢东西 —— 有人忘了拷，笔记本电池耗尽，Wi-Fi 中途断开导致半个文件重传或者干脆没传。更麻烦的是数据到了服务器之后没有归属：谁录的、谁能看、谁删掉的，都无从查起。而这些数据是人体实验采来的，重录一次的代价不是重跑一遍程序那么简单。

我做了什么

  • 做了增量续传上传器：边录边传，只发服务器还没确认过的、以换行结尾的字节。每个文件各自维护「已确认到第几个字节」，断网重连后从那个字节接着传，不重发整个文件。
  • 一行没写完就不发。这条看着琐碎，但少了它，服务器会在采集中途收到半条记录 —— 而下游分析没法分辨「这行本来就短」和「这行还没写完」。
  • 重试发完全相同的字节区间和 SHA-256，服务端拒绝有空洞的区间、对完全相同的重发按重复处理。这样「重试」这个动作本身永远是安全的，不用担心重复上传把数据搞脏。
  • 用系统原生的文件事件（macOS 的 FSEvents、Linux/Jetson 的 inotify）唤醒上传，而不是定时轮询 —— 轮询要么慢要么费电，采集设备两样都输不起。
  • 结束是显式的：点「结束会话并退出」时写一份 SHA-256 校验文件。绝不拿「一段时间没动静」当采集已经结束的证据 —— 受试者中途休息和实验做完，在文件系统看来是一样的。
  • 服务端用 FastAPI + SQLAlchemy 实现账号体系：数据归属到人，管理员可以按用户、按 Session、按单个文件取数；删除进回收站而不是直接销毁，界面上倒计时显示距离服务器清理还剩多久。
  • 加了活动日志：登录、退出、权限变更、上传批次都留痕，管理员能看到谁在线、谁刚传过东西。
  • 写了一份面向非程序员的图文手册。实验室里录数据的人不都会编程 —— 系统再稳，没人会用就等于没有。

实验室原有的 BLE 采集程序只负责把数据写到本地磁盘。这部分工作补上了它后面的一整段：边采集边把数据可靠地送到服务器，以及在服务器上把数据归属到人。

整条链路。传感器的数据先落到采集电脑的磁盘上 —— 录制永远不依赖网络，断网也不丢。上传器在文件还在增长的时候就一段段往服务器送，服务器逐段确认；下载端再按用户和会话把数据取回来。
整条链路。传感器的数据先落到采集电脑的磁盘上 —— 录制永远不依赖网络，断网也不丢。上传器在文件还在增长的时候就一段段往服务器送，服务器逐段确认；下载端再按用户和会话把数据取回来。
上传器界面。实时显示本地写入速率、上传速率和积压量，让人一眼看出「传得上还是传不上」。下方是每个文件的进度；第一次运行时会问历史文件要不要补传，选择被记下来，之后随时可以勾选补传。
上传器界面。实时显示本地写入速率、上传速率和积压量，让人一眼看出「传得上还是传不上」。下方是每个文件的进度；第一次运行时会问历史文件要不要补传，选择被记下来，之后随时可以勾选补传。
管理员视图，一个账号一行，可以展开到具体会话或单个文件。上方的时间轴按上传时间筛选。删除是移进该账号自己的回收站，不是直接销毁。
管理员视图，一个账号一行，可以展开到具体会话或单个文件。上方的时间轴按上传时间筛选。删除是移进该账号自己的回收站，不是直接销毁。
账号管理与活动日志。上半部分是每个账号的在线状态、最近上传时间和当前登录数；下半部分记录登录、退出、权限变更这些动作 —— 数据属于谁、被谁动过，事后查得到。
账号管理与活动日志。上半部分是每个账号的在线状态、最近上传时间和当前登录数；下半部分记录登录、退出、权限变更这些动作 —— 数据属于谁、被谁动过，事后查得到。

用到的技术

  • Python
  • PyQt6
  • FastAPI
  • SQLAlchemy
  • BLE / bleak
  • 增量续传
  • SHA-256 校验
  • FSEvents / inotify
  • Hydra