很少的信息很难给出明确的建议。因此，在你提供更具体的信息之前，我的回答一直含糊不清：

在本机实现上选择处理框架将为你带来以下优势：

• 具有理论上无限可扩展性的并行处理：如果你希望无法及时处理单个线程中的所有事件，则首先需要扩展（更多线程），最后扩展（更多机器）。框架负责线程与机器之间的所有同步，因此你只需要编写与一些高级原语（类似于C＃中的LINQ）粘合在一起的顺序代码即可。
• 容错能力：当你的代码搞砸了（未实现某些边缘情况）时会发生什么？什么时候资源不足？网络（到Kinesis或其他机器）暂时中断时？框架负责处理所有这些令人讨厌的小细节。
• 万一发生故障，重新启动应用程序时，大多数框架都会为你提供某种形式的一次处理：如何避免丢失数据？重新处理旧数据时如何避免重复？
• 托管状态：如果你的应用程序需要记住一段时间（计算总和/平均值或合并数据），那么在出现故障时如何确保状态与数据保持同步？
• 先进的功能：时间触发器，复杂的事件处理（=事件上的模式匹配），写入不同的接收器（Kafka用于低延迟，s3用于批处理）
• 存储的灵活性：如果要尝试使用其他存储系统，则在框架中编写应用程序时更改源/接收器要容易得多。
• 部署平台中的集成：如果要扩展到多台机器，扩展一个已经提供相关集成的平台通常要容易得多（在撰写本文时，主要应该是Kubernetes）。但是，所有框架还支持简单的本地设置，你只需在一台（更大）的计算机上进行扩展即可。
• 低级优化：当使用具有更高抽象度的新引擎时，框架生成的代码可能比你自己实现的代码（使用特定的内存布局或序列化的数据处理）要高效得多。

不利的一面通常是：

• 框架的复杂性：你需要从用户的角度了解框架的工作方式。但是，通常可以省去时间，而不必花时间编写自定义消费者/生产者的详细信息，因此它并不像最初看起来的那样糟糕。
• 代码的灵活性：你不能再编写任意代码。由于该框架为你处理并行性，因此你需要考虑数据块，并相应地调整算法。通常以一种或另一种形式直接支持标准SQL操作。
• 对资源使用情况的控制较少：由于平台是跨机器调度任务，因此你可能最终会遇到不幸的任务，并且平台可能提供的修复方案太少。请注意，由于数据偏斜和次优算法，大多数应用程序本质上都与不良的资源利用率相关联。