序言

我将试着把你的问题分解成几个部分，以便更清楚地了解你当前的需求，然后重新构建它。写这篇文章花了很长时间，所以如果你能从后面做两件事，我会非常感激：
持怀疑态度-没有什么可以代替你自己测试东西。互联网是一个非常有用的指南，但不能保证你得到的帮助（如果这个答案是有用的！）对你的具体情况是最好的。在分配给你的空间里，你不可能完全描述你目前的处境，因此，任何答案都必然会在某个地方缺乏。
再看看你是如何解释自己的——这是一个有效的问题，但由于你对系统的描述不够清晰，以及你试图实现的目标，这个问题被部分地打断了。在发布复杂问题之前，让不熟悉您系统的人查看您的问题可能会有所帮助。

问题定义

从多个客户机到中央服务器的感知数据流
您正在将数据从多个位置发送到单个持久性存储
在线监测
您将触发基于原始数据和一些潜在聚合数据的进一步操作
分析和一些计算，如机器学习和数据挖掘任务
您将对客户机的数据执行一些聚合，也就是说，您需要将所有客户机数据的聚合持久化（无论是临时性的）到某个地方

进一步假设

因为您讨论的是物化视图，所以我们可以假设所有客户机都将数据持久化在数据库中，可能是oracle。
来自你客户的数据是关于同一主题的。
你有大约100个客户，我们可以假设：
客户端的数量可能会改变
您希望能够添加客户端而不增加访问数据的方法的数量
你不为谷歌、亚马逊、facebook、quantcast、苹果等公司工作。

架构图

在这里，我不会对它的实际工作方式发表任何评论——这是一个基于我对你们的系统缺乏了解的讨论的开始。“原始数据持久性”可以是文件、kafka、数据库等。这是对将需要的组件的描述，以及对它们将如何连接的粗略猜测。

将假定体系结构应用于物化视图

物化视图是一个持久化查询。因此，您有两个选择：
创建一个将所有100个客户机数据合并在一起的查询。如果添加或删除客户端，则必须更改查询。如果您的任何一个客户端出现网络问题，那么一切都会失败
编写并维护100个物化视图。位于您中心位置的oracle数据库有100个传入连接。
正如您可能从权衡中猜到的那样，您必须使我不喜欢物化视图作为唯一的解决方案。我们应该努力减少重复代码和单点故障的数量。
不过，您仍然可以使用物化视图。如果我们把我们的图表，并删除所有重复的箭头在您的中心位置，这意味着两件事。
只有一个服务接受传入的数据
只有一个服务将所有传入的数据放在一个地方
然后可以为聚合层使用一个具体化视图（如果原始数据持久性不在oracle中，则必须首先将数据放入oracle中）。

变化的后果

现在我们已经决定，你有一个单一的数据管道-你的决定实际上变得更加困难。我们已经将您的客户机与中心位置分离，并将聚合层与原始数据持久性分离。这意味着现在的选择是你的，但他们也相当容易改变。

重新构思建筑

在这里，我们需要弄清楚哪些技术不会改变。
oracle数据库很贵，而且您的数据库每天要增加140gb（顺便说一句，这相当于50tb/年）。我不知道你是否真的存储了所有的原始数据，但是在那些卷上，你不太可能存储了——你只存储了聚合
我假设你有一些你喜欢的机器学习和数据挖掘技术。如果你不那么考虑得到一些，以防止疯狂支持一切
把所有这些放在一起，我们最终得出以下结论。实际上只有一个问题很重要：
您想从数据库中读取原始数据多少次。
如果答案只有一次，那么我们只描述了一些描述的中间件。如果答案不止一次，那么我会重新考虑，除非你有一些非常好的磁盘。你是否使用Kafka作为中间层完全取决于你。用你最熟悉的东西，用你最愿意花时间学习和支持的东西。你要处理的数据量是不小的，要想把这件事做好，还需要反复试验。

关于这一点的最后一点；我们已经定义了一个数据管道。一种数据流经系统的单一方法。通过这样做，我们增加了系统的灵活性。想添加更多的客户端，不需要做任何事情。想要改变系统背后的技术部分，只要界面保持不变就没有问题。想把数据送到别处，没问题，都在原始数据持久层。