Bigdata项目可扩展架构

Question

我有网络开发的背景，而且我对bigdata解决方案完全陌生，所以不确定是否有类似下面项目的标准方法。我先来描述一下这个请求。

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

我们的想法是为所有外部系统提供一个包含分析功能的通用仪表板。因此，不同的格式应该在某种程度上转换为某种通用格式。 实时获取数据也很重要，因此如果在其中一个外部系统中发生中断，应该在中央仪表板中快速提醒（1分钟刷新时间应该没问题）。

此外：

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

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

以下是我提出的更具体的问题：

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

谢谢，

Answer 1

我无法回答所有问题，但是我会尽我所能告诉你我的看法。

SQL vs NoSQL。这是一个关键的选择。确保您选择正确，因为它们是完全不同的体系结构，并且NoSQL具有某些限制，低俗的ACID和关系概念。确保这些限制不会影响您的业务。另一方面，SQL没有这样的限制，并且“常规SQL数据库可能无法应付...”根本不成立，因为使用标准关系SQL所付出的一切就是所得到的。当然，有些RDBMS不能处理* 5而是* 500的数据，但它们并不便宜-这是另一回事。

通用格式的数据。这是一个陷阱案例。我的意见是，在将任何格式转换为标准格式之前，您都应该远离数据库。您需要一种全局标准格式，该格式封装了所有50种（后来的150种版本都有版本变化！！！）表示不同的格式。而且，您需要在某些地方（肯定不是在数据库中）将某些逻辑转换为标准格式。这应该在应用程序级别完成，而无需数据库的参与。用这种方法来负担数据库将无法很好地扩展，也无法像使用某些用于该任务的应用程序解决方案那样容易维护。

Azure具有可伸缩性，可帮助您摆脱基础架构问题和高可用性的困扰。但是它有它的价格。值得肯定地检查一下。