我认为您不会找到任何可以检查您所有要求的东西，但这里有一些需要注意的事项：

• 自动 ETL 映射：有一个名为Karma的工具由南加州大学信息科学研究所的一个团队启动。它从您的 ETL 映射中学习并帮助自动化未来的映射。它是我所知道的唯一有助于自动化 ETL 过程的开源工具，但如果还有其他工具，我会非常感兴趣。
• 大规模 ETL：有很多工具可以用于您正在寻找的可扩展性。我个人可以推荐看一下Storm和Spark。Storm 非常适合将处理步骤连接在一起，只要有足够的资源，就可以对流数据进行近乎实时的计算。不太相似的 Spark 有一个具有类似用例的流组件，但如果您需要进行 ETL 的数据是固定的要处理一次的数据集，那么标准 Spark 可能会更好地满足您的需求。
• 数据存储：您可能还需要考虑所有这些数据在 ETL 生命周期中的存储位置。您可能需要像Kafka这样的东西来处理大量数据流。或者也许HDFS来存储文件的静态集合。

几乎任何 ETL 工具都可以管理固定宽度、CSV、TSV 或 PSV 输入，并且几乎任何工具都应该能够管理 100B 记录。问题的限制部分实际上与您的目标格式是什么以及您需要什么磁盘吞吐量有关。

i2.4xLarge 的预期吞吐量为 250mb/s。如果 8xLarge 是 32 台机器的两倍，那么您将看到在约 138 小时内写入 PB 的能力。更不用说首先引入源数据的时间和带宽。除非我的数学完全不正确，否则这意味着 30 PB 可以在大约 6 个月内写入磁盘。

您希望将这么多数据标准化或转换为人类可读格式（它只会变得更大），这似乎很奇怪，更奇怪的是您希望利用机器学习作为该大小的转换/负载的一部分.

您的解决方案需要在本地硬件上，以保持成本合理。

我不能推荐一个系统（商业或开源），它可以在几天内扩展到在 30 PB 上执行这种 ETL 所需的程度。在这种规模下，我会研究大量内存、内存支持/前端 SSD 以及 FPGA 上的定制开发以进行实际转换。当然，如果我对写入时间的数学计算是错误的，那么整个答案都是无效的。