有趣的是,计算机科学界有相当一部分人重新定义了他们的研究议程,以适应“大数据”的营销旗帜。因此,它显然是“当前的流行语”。作为一个研究数据库问题很长时间的人(从定义上讲,就是处理大数据),我想用四篇博文来解释我对“大数据”的理解,并讨论我认为的研究议程。
在我旅行的社区,大数据可能意味着以下四种情况之一:
数据量大,但分析量小。这里的想法是在非常大的数据集上支持SQL。没有人会从大的数据上运行“Select*”,因为这会让接收方承受tb的数据。相反,重点是在大量数据上运行SQL分析(count、sum、max、min和avg,带有可选的group_by)。我将其称为“小型分析”,以区分此用例与后面的用例。
大量数据的大量分析.所谓的大分析,我指的是数据聚类、回归、机器学习以及其他对大量数据进行的更复杂的分析。目前,用户倾向于使用统计包(如R、SPSS和SAS)运行大型分析。或者,他们使用线性代数包,如ScalaPack或Arpack。最后,这里使用了大量的自定义代码(自己编写代码)。
大的速度.我的意思是,能够为电子交易、网页上的实时广告放置、实时客户定位和移动社交网络等应用程序吸收和处理大量传入的数据。这种用例在大型Web属性和华尔街中最为普遍,两者都倾向于自行开发。
大的不同.许多企业都面临着将越来越多的数据源与不同的数据(电子表格、Web源、XML、传统dbms)集成在一起的问题。许多企业认为这是他们最头疼的问题。从历史上看,提取、转换和加载(ETL)供应商使用数量有限的数据源为这个市场提供服务。
综上所述,大数据可以是大容量、大速度、大种类。在这篇文章的其余部分,我将讨论对大量数据的小型分析。在接下来的三篇文章中,我将讨论其他三个问题领域。
大容量,小分析
据我所知,在三种不同的商业产品上,有超过5个多拍字节的生产使用数据仓库。毫无疑问,还有几十个。所有这些都运行在“无共享”服务器群上,拥有超过100个通常“健壮”的节点,通过故障转移到备份副本来存活硬件节点故障,并执行由上述定义的SQL分析组成的工作负载。所有人都报告了保持大型配置运行的操作挑战,并希望有新的DBMS功能。在每个人的列表中,第一是资源弹性(例如,在100台服务器的系统中增加50台服务器,自动重新划分数据以包括额外的服务器,所有这些都不会占用时间,也不会中断查询处理)。此外,更好的资源管理也是一个普遍的要求。在这里,多个成本中心共享共同的资源,每个人都想获得自己的公平份额。权威人士(例如Curt Monash)经常会指出其中一些数据仓库。
这个用例的第二个解决方案是Hive/Hadoop。我知道有几个多拍字节的存储库使用这种技术,最著名的是Facebook。同样,可能还有几十个,而且我知道许多IT公司正在创建这个解决方案的原型。在最近的文献中,有相当多的论文记录了Hadoop与并行dbms相比的低效率。通常,您应该预期至少有一个数量级的性能差异。这将导致在相同数量的硬件上响应时间下降一个数量级,或在更多数量级的硬件上实现相同的性能。如果选择后一种路线,这是一个购买大量铁和使用大量电力的决定。详细的我之前的博客对于杰里米·凯普纳来说,我不太喜欢这个解决方案。
此外,谷歌和其他大型Web属性似乎在使用这种工作负载的自制软件上运行大型配置。其中一些看起来很像商业rdbms(例如,F1),而另一些看起来很不一样(例如,BigTable)。
展望未来,我认为这个世界的主要挑战是100%的正常运行时间(即无论发生什么情况,永远不会停机)。当然,这是一个具有挑战性的“操作”问题。此外,这将需要安装新的硬件,安装补丁,以及供应商软件的下一个迭代,而不需要任何停机时间。更困难的是在不引起停机的情况下进行模式迁移。
此外,我预测SQL供应商将全部迁移到列存储,因为列存储比行存储快得多。实际上,随着时间的推移,所有行店供应商将不得不将他们的产品过渡到列店,以提高竞争力。对于一些遗留供应商来说,这可能是一个迁移挑战。
最后,包括压缩和加密在内的先进存储思想在这个领域有很大的发展机会。减少查询成本的抽样也很有意义。
除了是麻省理工学院的兼职教授,迈克尔Stonebraker与四家数据库技术的生产者或消费者创业公司有关。
没有发现记录