【发布时间】:2020-05-03 03:17:07
【问题描述】:
我目前正在研究一个大型实验分析应用程序的框架。该实验包含大约 40 个仪器,每个仪器生成大约 GB/s 和 ns 时间戳。数据旨在按时间块进行分析。
为了实现,我想知道在 Flink 或 Spark 停止处理数据之前,这样的“块”又名批处理可以有多大。我想我打算重新收集处理过的数据是不言而喻的。
【问题讨论】:
标签: apache-spark bigdata apache-flink
我目前正在研究一个大型实验分析应用程序的框架。该实验包含大约 40 个仪器,每个仪器生成大约 GB/s 和 ns 时间戳。数据旨在按时间块进行分析。
为了实现,我想知道在 Flink 或 Spark 停止处理数据之前,这样的“块”又名批处理可以有多大。我想我打算重新收集处理过的数据是不言而喻的。
【问题讨论】:
标签: apache-spark bigdata apache-flink
一般来说,系统可以处理的数据量没有硬性限制。这完全取决于您拥有多少个节点以及您拥有什么样的查询。
听起来您主要希望在给定时间窗口内对每个仪器进行聚合,因此您的最大横向扩展限制为 40。这是您可以解决问题的最大机器数量。然后,问题出现在您的时间块有多大/聚合变得多么复杂。假设您的聚合需要一个窗口的所有数据都存在,那么系统需要每秒保持 1 GB。因此,如果您的窗口是一小时,则系统需要保存至少 3.6 TB 的数据。
如果机器的主内存不足,则需要将数据溢出到磁盘,这会显着减慢处理速度。 Spark 真的很喜欢将所有数据保存在内存中,所以这将是实际的限制。 Flink 几乎可以将所有数据溢出到磁盘,但磁盘 I/O 成为瓶颈。
如果您需要计算较小的值(如总和、平均值),则主内存不应该成为问题。
在分析旧数据时,系统可以进行批处理,并且有更多选项来处理卷,包括溢出到本地磁盘。如果您可以将一个窗口的所有数据保存在主内存中,Spark 通常会发光。如果您对此不确定,或者您知道它不适合主内存,那么 Flink 是更具可扩展性的解决方案。不过,我希望这两个框架都能很好地适用于您的用例。
我宁愿看看生态系统和适合你的西装。您想使用哪些语言?感觉就像使用 Jupyter notebooks 或 Zeppelin 最适合您的临时分析和数据探索。特别是如果你想使用 Python,我可能会先尝试一下 Spark。
【讨论】: