张晓东:目前大数据中巨大挑战是数据库不能使用
作者：21CN科技出处：IT专家网2012-12-04 06:57数据库简单吗
目前大数据中巨大挑战在于现有的数据库是不能使用的，因为数据量太大了。对大数据来讲最主要的是在模型中做计算的约束非常大。
2012年11月30日至12月1日，Hadoop与大数据技术大会在北京新云南皇冠假日酒店举行。本次会议由中国计算机协会（CCF）主办，CCF大数据专家委员会协办，CSDN承办。大会以“大数据共享与开放技术”为主题，着眼于Hadoop生态系统优化管理与数据分析与挖掘，深度聚焦大数据共享平台与实践与应用。俄亥俄州立大学教授张晓东发表主题演讲。
  张晓东表示，目前大数据中巨大挑战在于现有的数据库是不能使用的，因为数据量太大了。对大数据来讲最主要的是在模型中做计算的约束非常大。
  以下为演讲实录：
  张晓东：谢谢组委会给我这样一个机会跟大家交流一下我们对大数据的研究和开发工作。
  今天我主要讲的是重点放在并行计算上，因为大家知道并行计算的历史已经有几十年了，但并行计算对大数据来讲是自然要做的事情，但我们已经换了整个计算的模式，现有的高性能计算的计算模式是不适应大数据的。
  第一步先讲一下在大数据中有哪些非常广的challenges，现有的数据库是不能使用的，很简单数据量太大了。同时，大数据的要求不光是高性能同时还要有更高的。而且没有什么硬件支持，都是用非常廉价的硬件。
  第二个问题都是学科的研究，因为它的应用范围非常广。数据的格式等都不一样。
  第三个问题是应用需求非常廉价的架构，所以可以看到现有的数据库是不适合的。它的价格是非常昂贵的，所以我们我现在用的主要是用开源的。
  现在我们进入到什么样的时代？大家听说过这样一个词叫“实践是检验真理的唯一标准”。今天我们进入到一个“数据是检验真理的一个重要的标准”的时代。我们进入了一个data driven的时代。这样对我们的算法有了新的需求。我今天的讲座想主要是聚焦在计算模式上的变化，计算尤其是系统设计发生了什么样的变化过去我们用的是高性能计算的模型，是scale u
p的模型，大家再回到1990年的时候就概括得非常好，叫叫BSP模型。过去的几十年中，我们做的所有的模型都是这样来做的。今天到了大数据有了几十年对高性能计算的研究，大数据是不是可以借用高性能计算的模型。因为我们的模型是scale-out的模型。
  对大数据来讲最主要的是在模型中做计算的约束是非常大的。我们看BSP模型，为什么在过去用到高性能计算上，今天在大数据不能用。之后再做并行计算，之后再做篡数，最后到了一个barrier，之后再来做。过去做的所有的高性能计算都是围绕这个模型来的。首先它是一个硬件的模型，因为它有很多的Key parameters，包括运算的速度、处理的速度、通信的速度。我们做软件的时候一定要见底message的成本。我们想了做计算和communication。
  如果我们有了硬件、有了软件同时又可以来来做exucution time。所以它很有生命力，22年前它就总结了高性能计算，它画了一个圈，我们所有的努力都在这里面。
  BSP模型有数据吗？因为高性能计算数据并不是重要的，主要是以计算为主的。大数据更不在里面了。今天做大数据计算的时候，是不能与硬件相关的我不能说到英特尔说要造一个大数据。所以我们现在用的。我们的模型是今天高性能计算是不能保证的。
  今天我们一定要做并行计算，并行计算给我们带来了什么样的障碍？scale-out是什么概念？给大家举一个例子，2008年的时候Google用processed算法计算一个PB的计算量，用了1个小时2分钟。2011年10PB的数据用了6小时27分钟。这个用的是map reduce。我们比较要有非常高的并行度。我们在高并行度下面遇到的第一个困难是，没有特殊的通信硬件来给我们支持。这不像高性能计算。第二，并没有一个globle的工具，Hadoop的模型非常简单。第三，没有软件的工具来帮助我们做。另外，当你放下了数据以后是不能传输的，基本上是不能动的。今天这个会议是为了Hadoop，Hadoop是一个basic big data processing engine。我们对引擎本身是没有抱怨的，问题是如何利用引擎处理大数据。如果我们只永远是的引擎只能做简单的分析。这个引擎有非常好的优点，第一它的dependency是非常小的。另外一个job是非常简单的。我们必须要有高可用性的big data。
  先很快地勾勒一下Hadoop在做的时候有什么问题，我们有mastnote，这个是基本设施。第一步过来的时候是submission而，job分到不同的note上。第二个是map face。第四是做reduce。所以用一句非常通俗的话，大家看到整个的过程，map reduce不是一个省油灯，你按步就班地往下走对data的要求非常大，所以存在了很多的问题。比如说从第一步开始看，有local或者是I/O。到最后一步如果把结果放到storage上必须要有空间。
  我们会发现出现了很多不改做的事情，我们的“油”怎么样被浪费了？过去的三年里我们一直在跟map reduce和Hadoop在打交道。。还有的是不必要的数据传输，如果一个数据在做recover的时候，我们要注意，如果用不好也是费用很高的。另外，map reduce是一个引擎，但在改引擎的时候给我们带来了很大的麻烦，因为这变成了个人所有了。还有一个是map reduce的模式是很简单的。这中methodology造成了很大的浪费。
  接下来我想介绍一下非常简单的方法：第一个是side walk。它并不在主流上，因为它只提供主流媒体的。第二，这个是开源的，是YSmart。第三个是data placement，我不想介绍。我想引出一个学术问题，如何在做placement的时候理论问题怎么解决。这个dataflow是一步一步在做，data transfer是跟着它走的。如果在做的时候想跟别人分享的话是分享不了的。或者是通过我的link来做communication的。
  如果我们看到了当application，你想做一个的话，现在的是不支持的。如果是在不同的系统上，他们两个想做一个communication也是不支持的。我们把这个叫做out-of -band。大家知道打篮球的时候有一个主场，教练是再一个非常特殊的地方，教练起什么样的作用？是用他的手势和眼给每一个队员做沟通，如果其他的球员想要告诉其他的另外的球员有一些要通
过教练，教练再把手势和信息传过去才可以。我们今天做的就是out-of -band。因为教练只给一个眼、给一个手势或者是喊一声，他不会影响主战场。
  但今天的map reduce是不存在这样的情况的。所以刚才说的所有的事情都可以通过Side Walk来实现。我们管out-of-band叫做auxiliary Datum。这是user来defind的。如果做不好的话，user是可以做大量的数据的传输。它的问题是对存在着各种各样的问题。
  第二个问题，写一个MR Program是很不容易的，user是想说This complex code is for a simple MR job。一般来讲如果一个user放在上面不想走这条路。如果你有一个MP可以直接翻译过去。这大大地提高了，而且可以通过机器来做各种各样的计算。但他们的proexctivty是不一样的。人在实际中用手来写是不一样的，75%是又机器来生成的。他在做translation的时候，扔进去就出不来。我们会发现如果你用手写一个MP Program大概差了四倍的time。我们对TPC-H Q21来做了一个分析。它可以自动一个一个地生成，生成了5个jobl。里面有很多其他的东西比如说key等都没有考虑。手写的program可以绑在一起可以产品一个MR Job，你可以想象这和五个比省了多少油。但如果按照center by center的话就生成了五个。我们为什么不把这个放进去呢？如果手写的时候你的性能肯定是不错的。如果你要用SQL-to - MR的时候，能不能在这上面既有很高的速度也有很高的性能呢？
  我举一个例子这是一个很典型的，如果用Hive是这个时间，用YSmart是这个时间。如果做Hadoop我相信你们应该听说过YSmart，可以去网站登录。你可以用YSmart，它现在是一个非常有效地做，同时是最后的stage进入到里面去。
  最后一个问题，在现有的Hadoop没有给你任何的信息，User是不知道的，你怎么放进去的时候取这个数据的时候要非常地低。我们在去年的SDE的文章中提出了四个问题，第一个问题如果要做placedata的时候一定要非常快。我们知道RCfile已经在Facebook中间，它已经有超过10亿人在用，把数据放起来之后要有一个Data loaders。其他的impact包括了Facebook，包括了Apache。下面的问题是包括Twitter所做的也用了RCfile。RCFile出来以后有很多的学术文章对它做批评。我们想说为什么RCfile为什么这么广泛的应用，你没有理论的基础是不好说的。我们想通过一个数学模型，通过一个非常stander的模型来分析对各种各样的placement是有效的。我们学过了很多的cache，也就是说你怎么码好这些数据。最后通过不同变化在cache当中可以得到结论。我们想能不能也做这样的工作。有不同的placement过来，第一，有一个basic operation。第二是把它这个partiitions放到其中。刚才我们说的东西比如说像CIF，就把row group分开。包括RCfile是这样来放的。
  现在想做的是，有了一个uinforme的演示之后，通过各种各样的perpormance是怎样的。最后是你做这样的设计是不是也改变了Hadoop的引擎。最后我们发现考了三个方面都是很basic的话，那么也是它广泛应用的原因。他们现在在整个的关键信息在什么地方？从Facebook的角度来讲，这个是一个Hadoop，用它的时候第一要存到Hive的数据中，如果一个user首先用的是YSmart做一个translation。
  第一，一个Hadoop是一个大数据中心的引擎。本身它就可以做分析，我们一个引擎只能完成一个转的操作问题是我们如何将引擎最原始的动力化为今天的支撑。后面我们画的括号里面sidewalk的问题。因为我们相信Hadoop是一个引擎。RCFile和Ysmart在critical path起了很重要的作用。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。