流

与数据集类似，流是从数据进入Foundry到被下游系统处理的数据表示。流是围绕行集合的封装，这些行集合由持久的“热缓冲区”和由文件系统支持的“冷存储”存储。使用Foundry流的好处是，它们提供与Foundry数据集相同的基本功能（分支、版本控制、权限管理、模式管理等），同时还提供数据的低延迟视图。

流本质上是表格的，因此是结构化的。它们以开源格式存储，例如Avro ↗，以及关于列本身的元数据。此元数据作为模式与流一起存储。

流存储

热缓冲区

当记录流入Foundry流时，它们存储在一个热缓冲区中，该缓冲区可用于所有支持读取流的下游应用程序。这种热缓冲区对于实现低延迟变换和可用性至关重要。它为数据摄取提供至少一次语义，并为平台中的数据处理提供非必填的精确一次语义。

冷缓冲区

Foundry流中的所有数据每隔几分钟从热缓冲区转移到冷存储。我们称此过程为“归档”，它使数据可作为标准Foundry数据集使用。这意味着任何Foundry应用程序都可以操作流数据，即使它不实时处理来自热缓冲区的数据。Foundry流的数据集视图在平台中表现得完全像标准的Foundry数据集。

流处理

从流中读取数据

启用低延迟的Foundry产品能够读取数据的混合视图。通过从热存储和冷存储层读取数据，产品可以提供数据的完整视图。此视图使产品能够访问仍在热存储中的低延迟记录以及已转移到冷存储的旧数据。通过这种方式，Foundry流可以同时享受热存储的低延迟和冷存储的较低存储成本。

事务

与标准Foundry数据集不同，流本身没有固有的事务边界。相反，每一行被视为其自身的事务，并在每行基础上跟踪状态。这允许以细粒度级别读取流，以便Foundry可以支持基于推送的变换，而无需批处理或轮询。

流类型

您可以根据流的吞吐量需求为每个流配置流类型。这些流类型设置适用于流将数据写入上文提到的热缓冲区存储的方式。只有在流指标表明流在写入热缓冲区存储时受到瓶颈限制时，才需要修改流类型设置。延迟和吞吐量是权衡的，因此在检查流指标后才设置高吞吐量/压缩流类型。 我们支持以下流配置：

1. 高吞吐量： 适用于每秒发送大量数据的流。启用此流类型可能会引入一些非零延迟，以换取更高的吞吐量。因此，在启用它之前，应检查流指标。如果平均批处理大小等于最大批处理大小，或者因为Kafka生产者批次过期而任务出错，可能需要启用高吞吐量设置。
2. 压缩： 启用此配置时，在将数据生成到热存储缓冲区时压缩消息批次。压缩有助于减少发送数据的大小，从而降低网络使用和存储成本，但会增加一些用于压缩和解压缩的CPU使用。我们仅建议在流包含大量重复字符串且遇到非零延迟、低于预期吞吐量或记录丢失等网络带宽问题时启用此流类型。

您可以在定义页面创建新流时设置流类型。您还可以在流设置中更新现有流的流类型。为此，导航到Foundry中的流数据集，然后在工具栏中选择详情。然后，转到流设置。您可以在此处更改流类型并启用/禁用压缩。

分区

为了保持高吞吐量，Foundry将输入流分成多个分区以进行并行处理。创建流时，您可以通过吞吐量滑块控制我们创建的分区数。请注意，尽管数据被分区，但对流的所有读取和写入操作都如同只有一个分区一样操作。此行为为Foundry流的消费者和生产者提供了设计透明性。

给定流的每个额外分区都会增加流可处理的最大吞吐量。一个好的经验法则是，每个分区可以将吞吐量增加大约5mb/s。

支持的字段类型

Foundry流支持与Foundry数据集相同的数据类型，包括：

• BOOLEAN
• BYTE
• SHORT
• INTEGER
• LONG
• FLOAT
• DOUBLE
• DECIMAL
• 字符串
• MAP
• ARRAY
• STRUCT
• BINARY
• DATE
• TIMESTAMP

流任务

所有流任务在内部表示为任务图，它提供流管道的可视化表示。随着数据的处理，它根据有向边在任务图中流动，直到达到数据接收器。

检查点

Foundry流通过在检查点中存储活动状态和当前处理位置来提供处理数据时的容错能力。

检查点由数据源定期生成，并与来自源的数据一起流经任务图。 一旦检查点到达任务图末端的所有数据接收器，源在该检查点之前发出的所有行也必须到达接收器。

检查点允许流任务从最新检查点的位置重新启动，而不是重新处理已看到的数据。检查点存储任务图中每个操作符的状态，以及流中的最后处理数据点。在流任务的任务详情页面上，您可以实时查看流最后几个检查点的状态、大小和持续时间。

流一致性保证

Foundry中的流操作具有两个一致性保证：至少一次和精确一次。

至少一次语义

至少一次语义保证消息至少会下游传递一次，但在检查点出错或重试的情况下可能会多次传递。这意味着可能会出现重复，消费应用程序应设计为处理或容忍重复消息。

至少一次语义的好处

• 确保没有消息丢失，提供高水平的消息耐久性。
• 与精确一次语义相比，通常提供较低的延迟，因为消息可以在不阻塞记录的账簿的情况下传递。

至少一次语义的缺点

• 需要下游消费应用程序能够处理重复消息。

精确一次语义

精确一次语义保证每条消息将被传递和处理一次，确保没有重复或丢失的消息。这是消息传递保证的最强级别，可以大大简化消费应用程序的设计。

精确一次语义的好处

• 确保没有消息丢失，提供高水平的消息耐久性。
• 消除消费应用程序处理重复消息或实施幂等处理的需要。
• 确保处理结果的一致性，因为每条消息仅处理一次。

精确一次语义的缺点

• 与至少一次语义相比，通常会引入更高的延迟，因为需要额外的协调和跟踪以确保消息不被重复。Foundry流通过检查点解决了这个问题。

延迟权衡

在至少一次和精确一次语义之间进行选择通常涉及延迟和处理复杂性的权衡。至少一次语义通常提供较低的延迟，因为它们不需要复杂的协调或跟踪机制，但将更多责任放在消费应用程序上，以处理重复和维护一致性。当启用精确一次时，记录只有在每个检查点完成后才可见下游（默认是两秒）。值得注意的是，记录仍然以流速度处理，但只有在“最终确定”时才会显示在下游。

另一方面，精确一次语义提供更强的保证，可以通过确保每条消息仅处理一次来简化消费应用程序的设计。然而，这种保证需要较高的延迟，因为需要额外的开销。

目前Foundry中的流源仅支持提取和以至少一次语义导出。流管道确实支持至少一次和精确一次语义，这可以在Pipeline Builder的搭建设置部分进行配置。