创建了数据桶来存储中间数据（比如函数返回的结果），并将orchestration的功能变成由桶触发。

现有的function orchestration将serverless应用建模为，根据调用依赖连接函数的workflow。它规定了函数调用的顺序，但对函数之间何时以及如何交换数据却视而不见。

在没有这些知识的情况下，无服务器平台假定一个函数的输出完全被下一个函数立即消耗。而在许多应用中，情况并非如此，比如批处理分析中的"洗牌"操作和流分析中动态积累的数据处理。

以上都导致函数之间的交互非常昂贵。

Background

Limitations of Current Platforms

给了两个例子，在这两个例子中，现有的function orchestration和数据传输方式冲突了。

data analytics的shuffle操作
batched stream analytics

Data-Centric Function Orchestration

Key-insight

核心是需要细粒度、解耦的数据交换。

中间数据（即函数返回的结果）通常是短暂的和不可改变的：在它们被生成后，它们等待被消耗，然后变得失效了。因此，文章将data consumption明确化，并使其能够触发目标函数。 开发者可以指定何时以及如何将中间数据传递给目标函数，并触发它们的激活，然后可以驱动整个工作流的执行。由于中间数据一旦生成就不会更新，使用它们来触发函数就不会产生一致性问题。

这种模式带来了三个优点

打破耦合
高可用性（统一的API）
知道when和how消耗中间结果，让平台能够根据这些信息进行一些优化

Data Bucket and Trigger Primitives

文章设计了数据桶，来保存中间数据。开发者可以用触发器来配置每个数据桶，指定数据何时以及如何调用目标函数并被其消耗。当执行一个工作流程时，源函数会将它们的结果直接发送到指定的桶中。每个桶检查是否满足配置的触发条件（例如，所需的数据是完整的并准备好被消费）。如果是这样，该桶会自动触发目标函数，并将所需数据传递给它们。这个过程发生在所有的桶中，它们共同驱动着整个工作流程的执行。

出发原语主要可以分成三类

Direct trigger primitive
Conditional trigger primitives
- ByBatchSize
- ByTime
- ByName
- BySet：当一组指定的数据对象全部完成并准备好被消耗时，它就会触发函数。它可以用来启用fan-in。
- Redundant：指定了要储存在桶中的对象，并在其中任何k个对象可用并准备好被消耗时触发函数
Dynamic trigger primitives
- DynamicJoin：当一组数据对象准备好时，它可以触发组合函数，这可以在运行时动态地配置。
- DynamicGroup：它允许一个桶将其数据对象划分为多个组，每个组都可以由一组函数来完成。数据分组是根据对象的元数据（例如，对象的名称）动态地进行的。一旦一组数据对象准备就绪，它们就会触发相关的函数集。

Programming Interface

还是在讲接口有哪些、能干什么。

Pheromone System Design

Overview

每个worker节点遵循本地调度器的指令，运行多个executor，根据需要加载和执行用户函数代码。 worker节点还维护着一个共享内存的对象存储，以保存由函数产生的中间数据。对象存储提供了一个数据桶接口，通过它，函数可以在一个节点内以及与其他节点有效地交换数据。它也同步那些必须与远程持久键值存储保持一致的数据。当新数据被放入对象存储时，本地调度器会检查相关的桶触发器。如果触发条件得到满足，本地调度器就会在本地调用目标函数，或者在全局协调器的帮助下远程调用目标函数。全局协调器运行在单独的机器上，并通过全局视图对桶的状态进行跨节点协调。

Scalable Distributed Scheduling

两层的分布式调度方案：一个工作流请求首先到达一个全局协调器，该协调器将请求路由到一个工作节点的本地调度器。 本地调度器在可能的情况下调用后续函数在本地执行工作流，从而减少调用延迟，不产生网络开销。

如果本地调度器收到的请求超过了本地执行器的能力，调度器会将它们转发到全局协调器，后者会将它们转发到其他资源充足的工作节点。调度器没有立即转发超出的请求，而是等待一个可配置的短时间：如果在这段时间内有任何本地执行器可用，那么所请求的功能就会启动，并在本地提供请求。

一个全局协调者不仅负责将请求从过载节点转到非过载节点，而且还负责驱动一个大型工作流的执行，该工作流需要在多个工作节点上运行，这些工作节点共同承载工作流的许多功能。一个协调者从多个工作节点收集大型工作流的相关功能的桶状态，并根据需要触发下一个功能。每个节点在发生任何变化时都会立即将本地桶的状态与协调器同步，这样协调器就能保持一个最新的全局视图。

Pheromone采用了一个shared-nothing模型，大大减少了本地调度器和全局协调器之间的同步，从而实现了高扩展性。其实就是每个coordinator负责一些不相交的流。

桶的管理是用一个节点上的共享内存对象存储空间来维护。设计包括了垃圾回收和节点上共享内存耗尽时的远端存储转移。

快速的数据共享。实际上就是只传指针。

Fault Tolerance

讲了一下Fault Tolerance，但是我感觉没啥必要。