挑战大容量数据
来源:用户上传
作者:
□ 编译:彭敏
“我有太多的数据要分析”业务分析人员常常这样抱怨。今天，对于非常大容量数据集的定义是由十年之前人们对于大数据集的定义演变而来的，这非常具有戏剧性。十几年前，几个GB的数据都被看作是大数据集，几十个GB的则被认为是巨大数据集。那时候，有一些人就致力于改善一些技术，以帮助人们以合理的速度来分析GB级的数据。
但是即使是现在，分析非常大容量数据集将继续成为一个重要的问题，这种现象已经变得越来越明显。随着近期存储技术的进步，以及存储产品价格的降低，TB（兆兆字节）级的数据量已经很普遍了，现在大数据集已经以PB(字节)为单位来衡量。
在存储技术缓慢前进的同时，数据分析处理方面的进展却遭遇瓶颈。在一个PB级的系统中查找一些数据没有问题，Google, Yahoo!，以及其他的搜索引擎技术提供商可以帮你做到。但是，通过分析这些数据而发现相关性和趋势（对于业务分析师来说是有意义的）却仍然是一个巨大的挑战。
为什么我们需要去分析这些数据―首先，在今天日益数字化的世界里，我们触网的数据在急速增长。
而且，今天大部分商业活动都在用IT来实现，或者支持任何可以想象的业务。这意味着，百万兆的、数字化的互动和交易每时每刻都在各种网络上产生和实现。这所有的数据去向何方？一些数据最终停留在数据库中，大部分数据按照常规最终放在日志文件中，因为即使是PB级的存储系统，如果要把在相当长时间内累积的所有交易数据都保存起来的话，那也不够用。
因此，对于BI从业者和企业所有者来说，分析大量未开发数据的能力简直像圣杯那样令人崇敬。想象一下，如果公司能够分析从他们的系统中导出的所有数据，而不是其中很少一部分的话，他们的生意将是什么样子。
如果网络安全分析人员能够快速地将所有的网络事务与有关雇佣、解雇和赔偿金变化的HR数据库事务一起分析的话，他也许可以预先获知一个内部的入侵威胁信息。
如果CFO能够将财务事务和网络系统的日志事务一起分析的话，他就能够发现财务违规情况。
如果市场人员能够将网站的交事务和来自ERP系统的事务，以及呼叫中心的呼叫细节记录一起综合分析的话，他就能够对一个正在广泛开展的市场活动进行实时的调整。
通过分析大量的、所有类型的公司数据，我们的洞察力将会提高，但是尽管如此，我们被迫不要去问那些问题，因为我们现有的BI技术缺乏解答这些问题的分析能力。
数据和信息
数据和信息，这两个词互相替代的情况非常普遍，但事实上两者有着相当明显的区别。如果你用如下方式来思考这二者之间不同的话，你会发现这很容易理解:
◆对于分析系统来说，数据是输入的东西，而信息是输出的东西。
◆分析是一个将数据转变为信息的过程。
这看起来很基础，但是记清区别或者差异却是很重要的。因为根据它，我们不再依赖于传统的，以数据库和数据仓库为中心的方法，为解决大容量数据分析的问题开启了一种不同的路径。
在网站运营者的工作中，一个关于网络流量问题分析的情节会经常出现:
获取网络流量数据的目的是为每个对象形成它在网络上移动的一个单独数据包。在网站上浏览某个网页的人，一个简单的操作就将产生不少的网络流量事务，这种事务是从两个方面来获得的，一是用户对网站发出的请求;另一个是网站对用户的请求所作出的反应。一个单独的网络流量事务由一个来源（一个源IP地址）、一个目标（一个目的地IP地址），以及一些关于数据移动的大小的概念（不是信息）组成，一个独立事务的分析价值接近于零，但是只要将网络流量事务结合一个单独的网页查找，总量聚集足够大的话，我们就能获得一些基本的运营信息，比如:
有多少数据是针对某一个特定的网页而传输的？这种传输花了多长时间？在传输过程中是否发生了错误？
这样，运营者立刻就能对网站的所有表现获得一个有价值的认知和洞察。
但是，除了这种简单的信息之外，应该还可以搜集到更多的东西。在这个例子中，如果我们继续进行数据聚集，做更多的总结练习，我们甚至可能获得一些业务方面的信息，比如:
◆服务的质量―在一个特定的时间段，一个特定的用户对网络造成了多大堵塞？在这个过程中，有多少网络错误发生？
◆IT搜寻及记帐―在一个月内，一个业务应用造成了多大的网络堵塞？
◆投诉和入侵防护―哪些用户造成的网络堵塞量最高？
以上这些都是业务分析人员可能有兴趣问的问题，但是传统的BI工具无法给出答案。
这个例子不仅揭示了数据和信息之间存在的差别，而且也解释了从数据到操作和业务信息的转变过程中什么是需要去提高或者改善的。
对数据转换信息过程的要求
上面的例子谈及的是，每一个单独的请求在数据转换为信息的过程是如何有效实现的，包括:
◆当一个大数据集与其他的数据相结合的时候（比如，网络流量数据与业务应用数据相结合），可能会产生有意义的信息。
◆有必要设计一个合适的步骤，首先将数据转变为操作性信息，然后再转化为业务信息。
◆恰当地加快进程。如果要等到事情发生一个月之后的话，它就不能帮助任何人去确定某个安全攻击行为。
不幸的是，这三个要求彼此之间是互相冲突的。进程需要涉及的数据越多，我们就希望从中获得越多的有用信息，但是进程所要花的时间也就越长。这一点也不奇怪，因为大部分的分析应用软件都是为一些大数据集设计的，比如他们关注：事件相关性，因为它可以在一个小些的数据集上进行;或者操作性信息，因为它要求的是最少量的处理进程。
当我们试图从数据里获取有价值的信息，分析过程就会越来越长，而当我们试图将这个过程应用在大数据集上时，发现一切做起来是那么的费力和效率低下。
我们知道，传统的分析方法在从大数据集上获得有用信息的能力上有非常严重的局限性，所以让我们来寻找替代方法。
挑战仍存
在处理非常大容量数据上，为人所知的抽取信息方法有如下几种:
◆搜索。人们经常将搜索与分析技术相混淆。信息抽取是数据转换的过程，当应用搜索技术时，搜索过程的确是高效的，但是它只能寻找那些在数据里已经存在的东西，而不能产生信息;
◆BI 或BA（业务分析）。这是一种依赖于数据库技术的方法，尽管最常见，但是当处理非常大容量数据时它可能立刻就崩溃了或者不可用。延时性是用BI/BA的方法分析非常大容量数据集时遇到的最主要障碍。
如果每天每个小时都有TB级的数据产生的话，一个只是为了跟上这些数据量，将新数据放进数据库中的高扩展性数据库就成为必须。而不要忘了，如果一个大银行试图用数据库去分析它日常的网页堵塞数据，通常需要花大约23小时去往数据库中添加一天24小时的新数据，然后另花2个小时来对这些数据进行分析查询。所以银行每天的行动落后就成了一件自然的事情，因为它被迫去抽取数据样本，显然，对于业务分析人员来说，如果分析的是样本而不是全部，就令人产生可靠性的质疑。
如果为了进行分析查询而追求TB级的数据量，如果数据库每天都在增长，分析查询的等待时间（延时）将以指数级增长，并最终使整个系统瘫痪。这也是为什么业务信息很少提供给非常大容量数据集的最主要原因。
新的希望
新的技术已经产生，以应对数据容量的挑战。
在分析非常大容量数据集的时候，以下三个问题需要解决:
首先，非常有必要在复杂多样的数据源之间建立联系。
第二，一定存在某种数据分析方法，它的第一步不是将数据导入数据库中。数据嵌入和随后的数据索引工作都是在速度极慢的数据库操作中进行的。
第三，一定存在某种数据分析方法，它只是分析新数据而不影响信息质量。这种将新数据转变为信息的能力，与将老数据转变为信息的能力，是对付在非常大数据集上进行分析查询所带来的指数级复杂性的惟一方法。
有些技术试图去解决这些问题。比如，串流数据库就是针对第二个问题的，它专注于一个相对较小的时间窗口里的数据分析，这样就能只关注于新数据分析上。
特殊的分析应用，比如网页分析和网络堵塞分析，正试图通过将数据库嵌入过程流程化的方法来改善第一个问题。通过网站或者网络测试设备，并抽取这个测试设备到数据库的映射。这些应用可以获得一些性能上的改善或提高。但是只有很少的公司把这些问题放在一起来对待。
转载注明来源:https://www.xzbu.com/8/view-1082046.htm
