数据管道最佳实践架构
Architecture for DataPipline Best Practice
给定：
某种外部来源的数据导入。可以按定义大小的块读取数据。例如一次 10 个项目。例如电子邮件。
现在每个块都必须通过一些步骤来转换数据、过滤项目等等。
块之间或块的项目之间没有关系。处理顺序也不重要
问题
现在我在想，如果我用akka做这个，什么样的结构才是正确的，以获得最好的并行化和性能。
1.) 我是否更有可能将所有演员创建为 children 链。所以 importActor 有一个 Child 这是第一步。第一步有第二步 child 等等。
或者更可能有一个 ImportActor，它具有所有步骤并一个接一个地调用？
2.)现在一个演员一次只能处理一条消息。为了并行化导入过程，我考虑使用 PipeTo 机制。这是一个好主意吗？还有更好的选择吗？
3.) 我会为每个块创建一个像 "Import_Chunk1_Actor" 这样的参与者，还是将所有消息推送到单个 "ImportActor"？
如果你在 SO 上的其他任何地方问这样的问题，你会受到重创。它有点含糊，容易自以为是，所以会尽量objective
我说的是尝试几种方法，而不是花时间在完成工作的代码上。做脚手架式的工作真的很快。
1) 根据您的描述，您将有一个输入，然后是代表“一次 10 个项目”的多个演员，不过这些可能只是在路由器后面。因此，在开发过程中，您不必担心有 10 个，只做一个，然后使用配置和微小的调整来扩大规模——正如您建议的那样，如果您使用任务，则可能只有 1 个演员完成所有工作。然后在这些中的每一个中，我都会有相同级别的流程。这在很大程度上取决于你此时是否有任何状态。您可以使用 become 语义将 actor 锁定到特定的工作流中，您可以只处理在任务中启动下一个状态的消息，继续告诉 actor 进行下一阶段。我觉得你推荐的童星是最没有吸引力的。
一个 actor 一次只处理一条消息，因此如果您希望它具有高吞吐量，则可以减少它处理的时间。您可以通过任务或传递给另一个参与者（例如工作人员或聚合器）来执行此操作。 PipeTo 在以下场景中很有用：在任务中生成消息的事物正在生成正确类型的消息以发送给另一个参与者，而您不想对其进行任何操作。它只是一个延续。这没什么问题，actor 系统中你最终完成一些工作的部分可能会包含在一个任务中，如果可以的话，就使用它。某种形式的延续比 actor 阻塞要好——但如果 actor 一次只做一件事，这有关系吗？ Thread being blocked 是线程被阻塞。关于任务要记住的一点是，你开始使用像 akka 这样的东西可能是因为基于 task/concurrent 的编程的陷阱——你可以很容易地把它买回来。
当你到达这一点时，它会很明显。如果您有多个参与者，您可能会使用路由器——或者如果您开始启动大量任务，您可能可以使用 1-2 个参与者和多个消息链来完成大部分任务。至于哪个更好——我知道有 3 个使用 actor 系统的人可以整天争论相对优点。如果您消除演员中的所有状态，您可以只使用 1 个演员来处理消息并触发任务。你可以有 2-3 层，你可能有一些东西来聚合 3 个任务 and/or 10 个工人。世界是你的牡蛎
关键是这一切都取决于未说明的要求。
给定：
某种外部来源的数据导入。可以按定义大小的块读取数据。例如一次 10 个项目。例如电子邮件。
现在每个块都必须通过一些步骤来转换数据、过滤项目等等。
块之间或块的项目之间没有关系。处理顺序也不重要
问题
现在我在想，如果我用akka做这个，什么样的结构才是正确的，以获得最好的并行化和性能。
1.) 我是否更有可能将所有演员创建为 children 链。所以 importActor 有一个 Child 这是第一步。第一步有第二步 child 等等。
或者更可能有一个 ImportActor，它具有所有步骤并一个接一个地调用？
2.)现在一个演员一次只能处理一条消息。为了并行化导入过程，我考虑使用 PipeTo 机制。这是一个好主意吗？还有更好的选择吗？
3.) 我会为每个块创建一个像 "Import_Chunk1_Actor" 这样的参与者，还是将所有消息推送到单个 "ImportActor"？
如果你在 SO 上的其他任何地方问这样的问题，你会受到重创。它有点含糊，容易自以为是，所以会尽量objective
我说的是尝试几种方法，而不是花时间在完成工作的代码上。做脚手架式的工作真的很快。
1) 根据您的描述，您将有一个输入，然后是代表“一次 10 个项目”的多个演员，不过这些可能只是在路由器后面。因此，在开发过程中，您不必担心有 10 个，只做一个，然后使用配置和微小的调整来扩大规模——正如您建议的那样，如果您使用任务，则可能只有 1 个演员完成所有工作。然后在这些中的每一个中，我都会有相同级别的流程。这在很大程度上取决于你此时是否有任何状态。您可以使用 become 语义将 actor 锁定到特定的工作流中，您可以只处理在任务中启动下一个状态的消息，继续告诉 actor 进行下一阶段。我觉得你推荐的童星是最没有吸引力的。
一个 actor 一次只处理一条消息，因此如果您希望它具有高吞吐量，则可以减少它处理的时间。您可以通过任务或传递给另一个参与者（例如工作人员或聚合器）来执行此操作。 PipeTo 在以下场景中很有用：在任务中生成消息的事物正在生成正确类型的消息以发送给另一个参与者，而您不想对其进行任何操作。它只是一个延续。这没什么问题，actor 系统中你最终完成一些工作的部分可能会包含在一个任务中，如果可以的话，就使用它。某种形式的延续比 actor 阻塞要好——但如果 actor 一次只做一件事，这有关系吗？ Thread being blocked 是线程被阻塞。关于任务要记住的一点是，你开始使用像 akka 这样的东西可能是因为基于 task/concurrent 的编程的陷阱——你可以很容易地把它买回来。
当你到达这一点时，它会很明显。如果您有多个参与者，您可能会使用路由器——或者如果您开始启动大量任务，您可能可以使用 1-2 个参与者和多个消息链来完成大部分任务。至于哪个更好——我知道有 3 个使用 actor 系统的人可以整天争论相对优点。如果您消除演员中的所有状态，您可以只使用 1 个演员来处理消息并触发任务。你可以有 2-3 层，你可能有一些东西来聚合 3 个任务 and/or 10 个工人。世界是你的牡蛎
关键是这一切都取决于未说明的要求。