发帖
雷达卡
香港企业采用大数据技术仍在起步，要考虑的事的确很多，但笔者认为厂商经常说得过于复杂，令企业设计大数据架构时存有疑问，例如在建构时选何制定方案使用方法及规模，相信是很多决策人希望了解的事，那么我们尝试化繁为简，由浅入深了解部署时的考虑点。
在我们考虑大数据时，注意力放在「大」这个字，但是在建设基础架构时，我们还应该注意「分散式」的数据处理。事实上，大数据软件需要处理大量资讯，而且在将资料复制到多个位置时，数据的容量便会倍增。但是，大数据的最重要属性并不在于它的规模，而在于它将大作业分割成许多小作业的能力，它能够将一个任务的资源分散到多个位置变为同时处理。在将大规模和分散式架构组合在一起时，我们就能发现大数据网络有一组特殊的需求，下面是需要考虑的六个要素：
1.不容有失 提升网络弹性
如果有一组分散式资源必须通过互联网进行协调时，可用性就变得非常重要。万一网络出现故障，便会出现不连续的计算资源与资料库崩坏。说白一点，大多数网络工程师的主要关注点是正常执行时间，但是，网络故障的原因又各不相同，包括设备故障（硬体与软体）、维护和人为错误。我们都知道伺服器故障是避无可避，网络的可用性也很重要，所谓完美的设计其实是不存在。
网络架构师应该设计一些能适应故障的弹性网络，网络的弹性取决于路径多样性(资源之间设置多条路径)和容错移转(能够快速发现问题和转移到其他路径上)。除了传统的平均故障时间间隔（MTBF）方法，大数据网络的设计标准一定要包括这些架构。
2. 解决网络拥塞
大数据应用程式不仅仅是规模大，而且还有突发性的流量「洪峰」。当一个程序启动后，数据就开始流转，在高流量时段时拥塞造成的问题可以很严重，例如可能引起更多的Queues增加延迟和packet lost。网络拥塞还可能令请求多次发出，这可能让本身负载繁重的网络无法承受。因此，网络架构设计时应该尽可能减少拥塞点，要网络具有较高的路径多样性，这样才能容许网络流量分流到大量不同的路径上。
3. 性能一致要比迟延性更重要
实际上，大多数大数据应用程式对网络延迟并不敏感。如果运算时间以秒计或以分钟计的话，即使出现较大延迟也是可以接受，例如为几千ms。然而，大数据应用程式一般具有较高的同步性。这意味着作业是并存执行的，而各个作业之间较大的性能差异可能会引发应用程式故障。除第1至2点提到网络的高效性，空间和时间上也要具有一致的性能。
4. 预留未来的扩展性
大多数大数据丛集实际上并不大，根据Hadoop Wizard的资料，2013年大数据丛集的平均节点数量只有100个。换句话说，即使每一台伺服器配置双重redundancy，支援整个丛集也只需要4个接入switch (假设是分别有72个10GbE网络接口的Switch)。
扩展性并不在于现在丛集现在有多大规模，而是在乎如何平衡地扩展支援未来的部署规模。如果基础架构设计现在只适合小规模部署，那么整个架构将如何随着节点数量的增加而不断进化？未来何时需要完全重新设计？这个架构是否需要一些近程资料和资料位置资讯？关键是扩展性并不在于绝对规模，而是更关注于实现足够规模解决方案的路径。
5. 网络分割 关键任务先行
网络分割是大数据应用环境的重要条件，形式上，要将大数据的流量与其他网络流量区分开来，这样应用程式产生的突发流量才不会影响其他关键任务网络负载。除此之外，运行多个作业的多个用户，以满足性能、合规性和审计的要求。这些工作要求在一些场合中实现网络负载的逻辑分离，某些场合还要作物理分离。
6. 应用感知力
虽然大数据的概念与Hadoop部署关系密切，但是它已经成为丛集环境的代名词。根据不同应用程式的特点，环境的需求随之不同。有一些可能对频宽要求高，一些则可能对延迟很敏感。总之，一个网络要支援多应用程式和多用户，它就必须要能够区分自己的工作负载，并且要能够正确处理各个工作负载，不仅仅是提供足够的频宽。
最后，应用程式体验取决于很多因素，包括网络拥塞和分割。创建一个满足所有这些需求的网络需要具备前瞻性，不仅要考虑基础架构能够支援的伸缩规模，还要考虑不同类型的应用程式如何共存于同一环境中。
京公网安备 11010802022788号
