用于处理小型消息文件的技术堆栈



我们正在一个项目中解码以文本文件形式传输给我们的实时消息文件。该文件是一个非结构化文本,但我们有一个规范来解码它。有不同的主题,每个主题每小时至少接收 800 个消息文件,平均文件大小为 1 KB。要求是在文件到达时实时解码所有文件,并以结构化形式将解码数据存储在数据库中,该数据库必须拉到前端应用程序。收到文件后,前端显示的 ETA 不到一分钟。

这是我正在考虑的建议数据流:-

消息文件(.txt) --> 解码 --> 存储在数据库中 --> Web 应用程序

有人可以让我知道您对以下问题的回答吗?

  1. 我可以使用任何流媒体工具/技术实时处理消息文件吗?
  2. 是否可以使用像Cloudera这样的大数据堆栈来实时处理这些文件?由于每个文件的大小都是1KB,会不会影响HDFS中Name节点的存储和性能吗? 我指的是小文件大数据问题
  3. 如果我不能使用大数据,我能想到其他处理策略来实现这个ETA?

您的任务有一些未知的选项。

预期的总负载是多少?每小时 10 个主题 x 800 条消息 x 1KB 文本不需要任何特定的东西,您只需使用简单的东西,如 Spring Boot 应用程序或 Go 应用程序。你说的是大数据堆栈,我假设你会有很多主题。

像Cloudera这样的大数据堆栈至少有两个很好的大规模流处理工具:Kafka和Spark Streaming。 Kafka 是一个消息代理,可以通过支持复制、高可用性等来处理真正的高负载。 Spark Streaming 是一个框架,允许您动态处理数据。特别是如果你有一些复杂的处理逻辑。

关于小文件,这实际上取决于您的情况。为什么以及如何存储它们?

  1. 你可以只是不将这些文件存储在HDFS中,并把已经解码 HBase(或其他数据库,随心所欲)中的数据。HBase会处理 文件和区域本身。

  2. 如果要将此未解码的文件存储为某种原始数据 主集你可以把一个文件放在一些临时存储中,紧凑 几个文件合并为大文件,并将大文件写入HDFS。有一个 很多选项都可以使用 Kafka、Spark Streaming 或其他方式做到这一点 类似的框架。

此外,还有许多不同的流框架,如Apache Storm,Apache Flink,Apache Beam或Kafka Streams。它们中的每一个都有自己的优点和缺点。

最新更新