网络流量分析是一个不可或缺的网络工程工具，它几乎支持所有功能，包括快速故障修复、安全监控和容量规划。此外，它的处理量巨大，必须有一个保持连通的管道随时报告数据包，而这要求有效且灵活的后期处理和解析。它实际上并不完全符合大数据的定义——这里并不涉及艾字节数据，但是NetFlow监控系统是大数据挑战的一个微观体现。从有限的IT资源角度看，在任何规模的应用中都可能成为网络工程师的大学问。

大数据项目通常不会使用关系数据库。虽然关系数据库管理系统（RDBMS）提供了非常好用的功能，如灵活的接口、很容易管理的持久化和强大报表，但是它们却很难达到NetFlow的要求。要理解这其中的原因，我们需要先弄清楚一个问题：NetFlow数据的最近一次变化发生在什么时候？

零基数数据提供了难得的机会

除了存储数据的方式，大数据解决方案确实不同于以前的数据仓库。这个过程通常会有大量的提取、转换和加载 (ETL)操作，或者需要从许多系统一次性给中央存储设备输入大量数据。

但是，在应用各种MapReduce或开源数据方案（如Hadoop）之后，大数据平台会周期性阻塞CPU。无论如何根据数据应用情况调整和优化大数据及数据仓库共享，都会出现这样的情况。

在收集之后，, NetFlow、sFlow、CFlow、JFlow或IPFIX-Flow记录都不再会发生变化。关系数据库的B树过载可以简化更新记录的查找过程，但是查询时间完全浪费在历史流数据上。由于有太多的网络管理，所以流量数据会填满网络监控数据库，因此会对各个方面的性能产生严重影响。这些会引起硬件警报的流监控肯定不是什么好东西。

创建NoSQL流报告有一定的难度

一些NetFlow分析供应商坚持使用关系数据库，其最主要原因之一是他们还没有技术能力实现一个NoSQL解决方案。还有许多数据技术专注于提高高性能，如位图索引（如FastBit）和Hadoop等开源解决方案，但是FastBit并不是一种数据存储技术，而Hadoop则完全与网络数据无关。

专门给网络工程师开发一些新技术，同时要求提供快速仪表板、节约CPU和存储且简单易用，这肯定是不容易做到的。网络管理供应商必须有多年的监控经验、长期客户协作和在研发中投入大量的资源，才可能将这些重要方面正确地组合在一起。然而，在研发时一定要在三个主要方面有突破：提高性能、优化报表粒度和降低运营开支。

高性能可以通过组合运用普通文件的高压缩和内存内索引技术实现。在一些时候，使用这些技术可以在相同硬件上将速度或功能提高一个数量级。降低存储价格使用户可以调整事实表粒度，从而真正能够支持真实帮助台在规定时间内解决问题。能够存储几周时间细粒度的NetFlow历史数据，同时又不需要安装庞大的关系数据库服务器，这就是关键。在我们尝试处理一个服务质量映射问题的请求时，是不是很多时候仅仅是查找详细的流数据（其中包含一些有用的峰值数据）就耗费了全部的存储时间？如果流细节数据达到一个月或更多，那么问题就更严重了。

第三个优势是IT预算经理关心的问题，即采用专用的NoSQL流存储将会减少开支。使用更便宜的硬件、减少RDBMS授权数量和降低维护复杂性，都更容易让经理点头。

正好到假期时间

有许多网络流量分析和监控供应商推出了利用专用流存储的解决方案，它可以扩展支持最大型的企业应用。这些产品绕过了关系数据库的内在局限性，从而支持根据需要自由测量流量——支持网络中任意位置的测量。年底就要到来，管理层就要离开办公室去度假，现在正是在实验室发力的时候，然后看看这些大数据技术能够在来年产出一两个NetFlow成果。