两行命令把公开数据流起来：一个英国独立开发者，想把「不大不小」的数据从目录里捞出来
Hacker News 这两天挂着一个 Show HN，标题很克制：Stream live open data in two commands。点进去是个叫 hypermass 的服务加开源 CLI，作者是个英国独立开发者，做了一年多，现在把它端到台面上来。
先说它到底干嘛。核心是两个命令：一条订阅，把实时公开数据流到本地文件夹里；一条发布，往文件夹里丢文件，它就帮你读出来、发布、再删掉。订阅不用注册，你甚至可以一条命令直接订阅他给的示例流——比如 SOHO 拍的太阳极紫外影像，或者 GDACS 的实时灾害数据（已经过滤成只看进行中的条目）。文件放进本地目录，文件名全是 ULID，脚本和代码里按时间排序非常顺手。
这个「文件 + 有序 + 实时」的取向，是作者反复强调的重点。他说十多年前在英国 Rail Open Data 系统里做开发那几年，最烦的是公开数据生态太碎片化，每个系统都从零设计。他观察到一大类数据卡在很尴尬的中间地带：频率低到不值得大规模轮询，文件又大到不适合走消息协议，但某种意义上又确实是实时。交通时刻表、周期性太阳影像、灾害警报，都属于这种「实时但不频繁」的东西。而他常用的解法——静态目录、专用 API、分析系统——都没接住这个需求，他想要的就是一句「把数据给我」。
于是他把「排序、重试、哈希校验、重连」这些边角逻辑，全收敛到一处处理，而不是让每个订阅方为每个数据源各自实现一遍。CLI 用 Go 写，理由很实际：作者承认自己是 Go 新手，但解释型/VM 方案（Python/Java）在安装期显得太重，跟「轻量、好装」的目标冲突，能直接产出可执行二进制文件这件事对他特别重要。
这项目最招我注意的是几个「自控成本」的设计细节，而不是功能列表。下载走签名的链接，用来限制单个 IP 或账号对 CDN 的请求量；客户端订阅走 websocket，作者说他在这上面犹豫最久——long poll 和常规 poll 都被否了，因为扩展到高频轮询的重客户端时，负载均衡的账单会很难看，而直接暴露 Kafka 队列又有鉴权、服务均衡、客户端版本绑定一堆麻烦。作为一个单干、自掏腰包的人，控制支出是当下最要紧的事。就连文件都先封顶在 100MB，说「等我们捋清问题再说」。发布的内容会先做 XML/JSON 校验（包括 XXE 之类的攻击），校验不过的不会出现在订阅方眼前。
诚实说，这是一张很典型的 solo 创业牌：方向清楚、取舍坦白、也把没做完的事列得明明白白。现在还没有 API（在写），没有库，就是一坨 CLI；优先级第一是先把发布方拉进来，让站点上有真正能用的数据。高铁频的流（发车屏、列车位置那种）在管线里，回调命令也在考虑中。商业化上，现在是「重度用户买更多流量额度 + 不错的免费层」，理想状态是以后让机构型发布方付费、让普通下载保持免费。
作者在帖子里问了三个问题：这套 CLI 路线对你有用吗；技术路子是否靠谱；你会不会用它来发布数据。翻译成大白话就是——我做的这个东西，是不是真的把「不大不小」的实时数据从目录里捞出来了。我自己的判断是，方向确实解一个真实痛点，公开数据里这种「说实时又不够频繁」的品类一直没个顺手答案；但眼下它更像是把问题收敛得漂亮的工具，能不能立起来，取决于有没有发布方真的往里灌数据，以及那些 100MB、高频流这些边角能不能在单干状态下一个个磨平。这些我都还没有答案，只有他博客里那几行待办在等验证。