architecture - 大数据项目可扩展架构

Question

我有 Web 开发背景，而且我对大数据解决方案完全陌生，所以不确定是否有适用于以下项目的标准方法。让我先描述一下请求。

大约有 10 万个客户（数据提供者），他们的任务是从一些外部系统收集信息。这些数据提供者以不同的格式存储数据，但所有约 100k 数据提供者的不同格式不超过 50 种。数据的本质是关于外部系统的效率（也可能是中断）。

这个想法是为所有外部系统提供一个带有分析功能的通用仪表板。所以不同的格式应该在某种程度上转换成一些通用的格式。拥有实时数据也很重要，因此如果其中一个外部系统发生中断，应该在中央仪表板中很快发出警报（1 分钟刷新时间应该是可以的）。

还：

1. 系统必须是可扩展的，因为一段时间后我们可能会有 50 万个客户端，而不是 10 万个
2. 未来，系统应该支持一些机器学习，根据一些数据预测低效/停机，提前预警
3. 中央仪表板应该是基于 Web 的解决方案并几乎实时显示数据
4. 应该有一些旧数据的自动存档
5. 中央仪表板应该足够快以从所有外部系统获取和分组数据

我需要帮助来了解如何构建系统以及一些关于我应该更多地了解哪些工具的建议。令人担忧的是，常规 SQL 数据库可能无法处理每分钟发送的 100k 数据包。所以我开始研究 NoSQL，但有很多不同的选择，我不知道它们之间的区别。

以下是我有的更具体的问题：

1. 这种情况下最好的数据库是什么？（Hadoop，MongoDb，...？）
2. 服务器基础架构应该是什么？不确定，也许它应该只是一个负载平衡服务器集群，它们正在处理来自数据提供者的数据请求，然后转换为通用格式并放入消息队列。其他一些进程将从队列中读取并写入数据库。
3. 我应该在什么级别将数据从不同格式转换为通用格式？我是否应该让不同的客户端根据格式将数据发送到不同的服务器，或者服务器是否应该负责转换逻辑，或者我是否应该强制客户端将数据转换为通用格式（这可能不是一个好主意，因为有很多客户端和没有那么多不同的格式）
4. 是否有任何现有的机器学习和分析工具可以使用？
5. 此架构中是否有任何现有工具可用于缓存或以其他方式优化中央仪表板的性能？
6. 我应该寻找像 MS Azure 这样的基于云的解决方案吗？
7. 现在，我正在考虑下面屏幕截图中描述的架构，如果您认为有任何问题，如果它不可扩展或其他原因，请告诉我？

谢谢，

标签： architecturenosqlbigdatascalability

Answer 1

我不能回答所有问题，但我会尽我所能告诉你我的意见，我可以肯定。

SQL 与 NoSQL。这是一个关键的选择。确保您选择正确，因为它们是完全不同的架构，而 NoSQL 有一定的限制、大量的 ACID 和关系概念。确保这些限制不会影响您的业务。另一方面，SQL 没有这样的限制，并且“常规 SQL 数据库可能无法处理......”根本不正确，因为使用标准关系 SQL，一切都是关于你付出的就是你得到的。当然，有些 RDBMS 处理的不是 *5 而是 *500 您描述的数据，但它们并不便宜 - 那是另一回事。

通用格式的数据。这是一个陷阱案。我的意见是，在将任何格式转换为标准格式之前，您应该远离数据库。您需要 1 种全球标准格式来封装所有 50 种（后来 150 种带有版本变化！！！）呈现不同的格式。而且您需要一些逻辑（肯定不在数据库中）才能转换为标准格式。这应该在没有数据库参与的情况下在应用程序级别完成。用这个来增加数据库的负担不会很好地扩展，也不会像使用一些用于此任务的应用程序解决方案那样容易维护。

Azure 具有可扩展性，让您摆脱基础架构问题以及高可用性。然而，它有它的代价。值得一试。