我最近开始在两个不同的内容管理系统之间进行内容存储库迁移项目。我们在一个源存储库中有大约11 PB的文档。我们希望通过使用源系统api进行查询并通过目标系统api进行保存，一次将它们全部迁移到一个文档中。我们将有一台独立的机器来进行迁移，并且应该能够管理（启动、停止、恢复）整个过程。对于这样的任务，您建议使用什么平台和工具？flink针对有界数据的dataset api是否适合此工作？
iqjalb3h1#
基本上就是大卫上面说的。我认为您将遇到的主要挑战是跟踪进度，以便检查点/保存点（从而重新启动）正常工作。这假设您有某种合理有效且稳定的方法来枚举源系统中所有1b文档的唯一ID。我们在以前的迁移项目中使用的一种方法（虽然不是使用flink）是使用文档创建时间戳作为“事件时间”。
ltskdhd12#
flink的datastream api可能比dataset api更好，因为流api可以停止/恢复，并且可以从失败中恢复。相比之下，dataset api从一开始就重新运行失败的作业，这对于可能运行数天（或数周）的作业来说并不合适。虽然flink的流式api是为无界数据流设计的，但它也可以很好地用于有界数据集。如果底层cmse能够支持并行迁移，那么flink将很容易适应这种情况。异步i/o特性在这种情况下会很有帮助。但是，如果您打算连续地进行迁移，那么我不确定您是否会从flink或spark这样的框架中获得多少好处。
2条答案
按热度按时间iqjalb3h1#
基本上就是大卫上面说的。我认为您将遇到的主要挑战是跟踪进度，以便检查点/保存点（从而重新启动）正常工作。
这假设您有某种合理有效且稳定的方法来枚举源系统中所有1b文档的唯一ID。我们在以前的迁移项目中使用的一种方法（虽然不是使用flink）是使用文档创建时间戳作为“事件时间”。
ltskdhd12#
flink的datastream api可能比dataset api更好，因为流api可以停止/恢复，并且可以从失败中恢复。相比之下，dataset api从一开始就重新运行失败的作业，这对于可能运行数天（或数周）的作业来说并不合适。
虽然flink的流式api是为无界数据流设计的，但它也可以很好地用于有界数据集。
如果底层cmse能够支持并行迁移，那么flink将很容易适应这种情况。异步i/o特性在这种情况下会很有帮助。但是，如果您打算连续地进行迁移，那么我不确定您是否会从flink或spark这样的框架中获得多少好处。