系统与数据库2019www-cs.stanford.edu
从笔记本到 Lambda：将日常作业外包到数千个容器
From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of Containers
进阶 · 约 50 分钟读完前置知识：容器与无服务器基础、分布式系统基础、构建/任务并行
导读
这篇论文（USENIX ATC 2019）研究如何把笔记本电脑上的日常构建、测试和数据处理任务外包给成千上万个容器或 AWS Lambda 函数并行执行，核心是降低容器冷启动和依赖打包带来的开销，让突发式并行计算变得实用。论文以 Stanford 的 gg 系统为载体，探索在保持低样板代码（boilerplate）的同时实现跨平台自动伸缩。
HN 关注点：用 Lambda/容器做大规模并行任务的启动延迟与成本权衡，以及这套思路能否用于科研流水线等真实场景。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
亲历天文观测流水线从业者认为该系统的低启动延迟和自动伸缩对低延迟引力波/多信使观测有实际价值。
这太棒了！我编写并运维一个低延迟分析多个天文台数据的流水线框架，目前正在为背景模拟这类任务加入突发性能扩展。Kubernetes 的启动时间和为 AWS Lambda 打包庞大库确实是挑战。如果能以低样板开销、相对平台无关的方式降低启动时间并实现自动伸缩，对这类分析将是颠覆性的。例如，若能低延迟地完成分析并探测到引力波与电磁波联合源，就能迅速用其他望远镜跟进，就像我们首次直接观测到千新星那样。虽然 GW170817 的伽马射线定位精度不足以真正帮助寻找对应体，但对其他类型候选体（如我项目中的引力波+中微子）而言，快速定位将是巨大改进。如果你能完成在合并前估计引力波源参数这类难事（例如判断是否为双中子星合并，足够近时很可能发出可探测的光），就可以让快速转向望远镜在合并时刻对准源。更不用说突发处理还能让你在低延迟下用统计方法做更聪明的事（获得更高灵敏度）。
stefco_查看英文原文
This is really great! I wrote and operate a pipeline framework for analyzing data from multiple astronomical observatories in low-latency [1], and I'm currently adding this sort of burst-performance scaling for things like background simulations. Things like Kubernetes spin-up time or packaging huge libraries for AWS Lambda are, indeed, challenges. Getting those startup times down and doing autoscaling in a relatively platform-agnostic way with low boilerplate overhead would be really game-changing for these sorts of analyses (among other applications). If you can run an analysis in low-latency and detect a joint gravitational wave/EM source, for example, you can quickly follow it up with other telescopes, like we did with the first direct kilonova observation [2]. Though the gamma-ray detection localization wasn't good enough to really aid counterpart searches for that event (GW170817), there are other types of candidates (like GW+neutrinos, my project) for which this rapid localization would be a huge improvement. And if you can do really hard things like estimate the GW source parameters before merger (e.g. whether you're looking at a binary neutron star merger, which is likely to emit detectable light if it's close enough), you can try to get fast-slewing telescopes pointing on source at merger time. Not to mention that burst processing would let you do more clever things with your statistics (getting better sensitivity) in low-latency as well. So stuff that makes this easier is really exciting! Maybe if the API is amenable to my own solution I'll be able to implement this as a backend :) [1] http://multimessenger.science [2] https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.119.161101
补充补充资料：Bazel 的远程执行 API 与 GCP 托管服务是同类方案。
如果你还不知道，Bazel 有对应的 Remote Execution API，以及 GCP 上的相应服务。
juomba查看英文原文
If you are not aware already - Bazel has a corresponding Remote Execution API - https://docs.google.com/document/d/1AaGk7fOPByEvpAbqeXIyE8HX_A3_axxNnvroblTZ_6s/edit#heading=h.ole76l21af90. Corresponding GCP offering - https://console.cloud.google.com/apis/library/remotebuildexecution.googleapis.com
质疑质疑：许多场景下单台 EC2 或自动伸缩组可能比海量 Lambda 更经济。
是否存在让这种方案变得不经济的用例？我去年和 AWS 打交道时发现，有些情况下确实不如就用一台 EC2 实例（或一个自动伸缩组），而不是用无数个 Lambda 来处理每个小任务。
s_Hogg查看英文原文
Is there a use case for this where it becomes uneconomic? I was working with AWS last year and found that in some cases it really was better to just have a single EC2 instance (or auto-scaling group) rather that ~9999999999999 lambdas to handle each individual task.
补充提供论文对应系统的 GitHub 源码和往期 HN 讨论链接。
源码似乎在这里：https://github.com/StanfordSNR/gg，更多信息见这条 HN 讨论：https://news.ycombinator.com/item?id=16570548。
albertwang查看英文原文
Source appears to be here: https://github.com/StanfordSNR/gg Some more info linked here: https://news.ycombinator.com/item?id=16570548
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
- 自称作者的回复
- 代码
- github.com/StanfordSNR/gg被提到 3 次
历次讨论
- 2019Hacker News 讨论帖185 分 · 18 评
- 2019Hacker News 讨论帖12 分 · 0 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选