发表于2012-12-01 17:22| 566次阅读| 来源CSDN| 2 条评论| 作者包研

【CSDN现场报道】中国IT界技术盛会——Hadoop与大数据技术大会（Hadoop&BigData Technology Conference 2012，HBTC 2012）于2012年11月30日-12月1日在北京新云南皇冠假日酒店隆重召开。本次大会以“大数据共享与开放技术”为主题，聚焦于Hadoop与大数据，力邀数十位国内外Hadoop及大数据技术应用的产学界人士和实践企业，探讨大数据技术生态系统的现状和发展趋势，并围绕Hadoop与大数据热点技术和应用实践进行深入解析。

图：百度基础架构部数据平台技术经理 刘立萍

图：百度数据仓库的集成环境

很高兴在这里跟大家做这个交流分享，我之所以选这个题目，有这个考虑，随着应用的需求，当我们的数据处理能力越来越强以后，对数据消费的高的要求也提出来了，这在我们内部，把迭代关系画了三个阶段，我们也是这样做的。

第一，解决规模。2007到2011年，大概解决基础存储和计算的问题。整个的集群，搭建的这些平台，包括计算模式，在很多地方都计算过，单机群体达到五千，MPI的集群达到四千，各种计算模型，增量计算的这种 模型，规模运用，这个过程中，我们遇到一些问题，刚才阿里那些同事，也都是类似，我们随着这种碎片的计算越多，使得大家计算资源越来越不够，任务都不能用，我们整个的任务，还有数据都不能附用，2011到2013年，从计算为中心，转到数据为中心，对数据进行处理，这个过程中，实际上以数据仓库的技术为核心的。这个是我们现在正在做的事情，我把近期的进展跟大家通报一下。

第三个阶段也提一句，从2013年以后，大概已经是可以用了，我们到2013年，可以希望有一些叫数据智能，这种产品出来。接下来我就看看仓库这个东西。大致上的问题不多说，里面包含了很多的领域，以及很多的场景，我们解决的只是其中的一块，确实是，如刚才阿里同志所说的，我们任何的平台和系统不可能解决所有的问题，我们在分解的过程中，一会儿我简单过一下，应用场景，实际上大家看到的都类似，仓库是解决了增量、批量、流式这种混杂的模型，跟全套的解决方案，在整体中给大家展示一下，重点我会把流式和增量的要点给大家支持一下。上面的这种，大家都比较知道的，海量数据上面的分析，是让别人比较头疼要命的，我们是怎么做到的，这是我们的话题。

整个应用其实也是分这么几大块，对象不同，目的不同，计算的方式和模型不同，对象可能有网页，还有一些客户的信息，广告组客户的信息，我们现在主要是在海量的，规模大家都可见，一基础的为它为核心的仓库，满足未来的需求。这是我所带的团队，简单看一下就可以了，基础架构把数据平台作为基础设施的一步，他其实是为整个的分析团队，以及上层去应用做的。整个建立一个数字金字塔体系，给高管的就是一个信息，PM产品经理会挖掘一些产品的东西，工程师我们会做数据挖掘，计算处理，90%还服务于自己，有一部分也是对外的，希望有一天，也是希望像整个云服务的一部分。

这个我们是整个基础架构部大数据平台，是业务谈对最近的一部分，是最贴近应用方！在底层经过多年的积累，存储、计算，也有了很多的积累，我们实际上是一个三角形，包括存储和计算，最下面就是我们的分布式资源，上层，开始往上，是我们数据平台的一部分，包括查询引擎，传输在这里面，简单来说，这里面不会细提到的，但是我们这里一笔代过。计算随着计算模式的不同，有这些种，批量计算abaci、peta，小批量计算Minibatch process，流式计算stream process已经引入到我们的仓库当中，这是一个大的任务的一个计算忙性。底层资源管理matrix，上层通用调度，long Scheduler。在这上面是它的一个存储数据，其他的是一个全体系的一产品组成，大家这个可以参考，在各个行业都会分这几层，这里面不一一说了，后面就是产品的名字。

今天主要在数据仓库本身和刚才所说的多分析引擎这块。刚才也提到了，没有数据仓库之前，我们整个的计算，刚才所说的，他是非常混乱了，没有体系和管理，没有原数据，没有中间数据的这种决策，最上层的应用有很多的问题，实效不行，数据统计不出来，资源不断地屏障，实际上是一个数据没有治理，整个是一个杂乱的情况，是以数据为中心的，数据仓库用的目标，运用场景和典型的，就是有各种分析、挖掘和纯粹的，用户可以通过这种工具，比较方便的查询访问，提高访问效率，如果不会写，或者不知道数据的信息，你可能对数据不可见，可能也是数据散布在各种存储介质上，统一运输上是不可能的，实际上在思路上有几点，不一一念了。

有数据仓库这个概念是海量的，跟传统式仓库没有什么区别，以用户为核心，可能让用户可以理解，不见主题，这些都是他的一个特点。在我们这个过程中，实际上是把这个非结构化的数据，变成了高价值的这种数据，进行了管理，分层提供出来了，基础数据这地方，就是一个把它结构化，整个变成一张巨大的大表，让关心数据的人可见，同时在各个部门，或者会见他自己的基于主题的这种，概念是一样的，实际上会使得效率和访问都变的容易。有了这些东西之后，我们可能在资源上面是可控的，并且在数据，各个层面上的管理，都有配套的平台和工具提供给大家，这样做的话，99%对原始的进行需求评比掉了，百度在很多年前，没有像谷歌，实际上一开始利用各种的，把这种分类，并且结构化，比如说这种方式弄出来，我们原来都是文本的方式，这个解决起来，我做过的话，代价是非常高的，有了这个以后，当然我们也在做这种工作，已经基本上完成了，把整个进行结构化，把这一层全屏蔽的话，尽量大大节省成本，最大的困难，就是你传统式仓库还要大，占整个成本的60%，对这种海量的要占的更高，百分之七八十。

这是整体的一个完整的图，蓝色的就是fkcs点，这个大家都是相同的，或者类似的，实际上在这个里面，这块就是我们整个的实时传输的通路，这个服务显然被理解成为一个在线的字典，对于在线的模块是一个缓解，实际上要求的是在一个级别，从一个日志下来，前一秒用户访问了什么东西，在下一个时间，策略上进行迭代，传输，刚才讲过，这是可靠的消息传输机制，这是仓库面的计算框架，上面是一个，他的计算核心，这一层都是计算模型，包括增量的这种，包括流式的模型。这边是批量或者是增量的一个模型，最大的这块，确实是基于这个了，确实我们是改进里面的效率，中间这块是要引入中心，把我们增量的计算模型引进来，同样也提供类似于这样子的接口，为上层服务。这个就不多解释了。

重点说一下我们在，我们在数据仓库，基于Hive，引入了哪些新的特色？前两点是现在所做的，也就是重要的工作，首先是一种数据质地，内容大于平台，对数据本身的研究，可能要比整个这个架构，性能这方面，在第一版的时候要大，我们把整个模型建起来了，比如主题、裸机，物理存储，刚才也说到，一张巨大的表，什么形势，怎么建，会不会屏蔽这些问题，都在这个层面上去解决。刚才也提到了，我们所有的仓库，为了满足后面的需求，一定有实效性的问题，我们在计算模型里面，最初因数了流式的计算模型，把原来的成果，运用在仓库里面，马上做这种增量的计算，实际上日志的这种，不能全量的这种，需要去借，来了哪些去见就可以了，代价、成本可能会更低，增量计算模型的，一会儿会简单介绍一下，吞吐、性能，还是非常好的。

在物理方面，现在也是在加这个，也是基于这个层面上，都在做的，现在还是行列的存储，因为他是有行的访问需求，有大宽秒的时候，成本不是很合适，这种对数据仓库来讲是必然，在此之上，能够拼出来一列两列的这种机制，PTI是我们引入的一个接口，前面的图也看了一下，正常的是这样的接口，在这个层面多了一个，未来的用户多了两大类，实际上对于这种上下文相关复杂计算是有缺陷的，我们对这种层面上，DCQ，在写一条过程中，其实是比较有优势的，性能效率更高，不管是怎么优化，他们其实在怎么优化，这个优化还是很难的，通过API会减少这种开销，使得在资源上会可控，我们也是增加了这么一个接口。

这个图，其实是被裁减了一下，没有太大的关系，把我刚才所说的东西体现了一下，红色的是我们在之前，用很大的精力去构建了一个部分，下一层其实是更原始的用了，类似于这种机制。

更多的还是介绍一下RT，把整个流式计算的模型，引入到数据仓库里面来，我们这个实际上，我不知道在这个场合下，百度同事有没有介绍过，是带着任务的，这个模型跟这个是很类似的，执行的也是一个图，他其实的这个性能，最新了解到，还是做的比较高，我们现在这个集群比较应用，他的集群要求还是很高的，我们这个机器是万兆网卡，40G内存的机器，500个节点的规模的话，整个的吞吐最大可以达到14G每秒，可以在两秒内返回，当时如果没有这么多的吞吐，流过来的数据的话，正常情况下是在毫秒解决。

一个系统，想做到这个高效，是一定有损的，重的就是实效，一定要快，会损失什么？会损失准确，可能会是不精准，不精准的意思可能会丢，如果死了，或者有问题的话，虽然有备份机制，还是不安全，如果做这种不重，不丢，可靠的话，这个大家还是有一些的。这个本身，这是他的一个特点，把这种你可以丢一些数据，但是一定要快，这样子的应用模式，那种精确的那种东西怎么办？刚才提到了，内部增量的计算模型，也同样提高到类似的效果，吞吐，如果吞吐量不大的时候，实效期也能保证，在15秒左右就能把数据处理完毕，大概是5级处理，每一级是复杂的计算。这两个就是互补，互相补充，那个系统就是一个精准系统，现在也是用在商务产品上的一些应用。

这里面是一个内核，数据仓库的层面增加一些状态，这些是无状态的，比如说过滤、投影、联合，未来想去做这种，就一定有窗口的概念，一定有实效性，可能会另起其他的这种系统，本身还可以，实际上可以支持动态指数的增加，增加处理，提上去，动态的不停地去做，处理以后，把这个干掉，这个也可以增删减，客户端比较友好，下面的图也可以看到，用户在这边，定义这个流，有一张图，描述整张的过程，去提交你选择哪条流，并且去更改，在这个集群上，就会做到，下面是订阅了一些数据源，可以继续还是导到你任意系统的输入里面，也可以导到永久介质里面，最简单最可靠的方式，提供最有效的方法，如果这一个图，画的复杂无比，用起来的时候，也不会是那么的可靠。

在我们数据仓库的后面，现在正在做的有哪些工作？一个是在数据内容层面上，把数据覆盖率提升，把整个公司的这种引用的东西存储在里面，数据模型不断地完善，去建设，面向应用的场景和数据模型要建好。刚才说了ETL本身的效率是很要命的事情，不仅是数据仓库本身的一条，还有在上面的一条，还有上面多维统计的一条，这些都有有效的框架，可调试可运行，类似于谷歌的这种技术的引入，还有刚才所说的小批量计算出来。

后面面临的问题，规模提到了100P，做到况机房集群存储的访问，数据同步的这种方案和策略，使得各种需求都不间断的应用。异构数据的ETL和访问。

OLAP，这就是一个数据仓库上面的一个概念，本身就是多元分析，这个应用场景，更多的解决了，至少我们看来是报表的问题，统计分析是一个很重要的一个领域，在我们数据上，特别是在我们公司这样的指标体系，产品什么情况？都是由数字表示的，这个情况哪个地方降了升了，什么原因导致波动，哪个地方精辟的话可以解决。我们所做的要求还是蛮高的，OLAP的设计目标，访问的压力大，数据量也很大，性能要求也很强，实际上更多的时候是一种报表需求，会看几张固定的报表，加上任意纬度上的分析，这是没有办法的优化，现在的需求，80%是在报表上，所以在上面做很多优化，20%是任意的纬度上，任意四到五个纬度上，查询和访问量会比较大，在以上的时候，响应的时间，在秒级，在十秒的话，应该怎么做这个系统。偶尔有的时候，还会对这一数据进行访问，全部的扫描和查询，要求高的可靠性，这是他的一个难点，但是也好办，在我们工程师的设计下，我们系统对他有针对性的优化办法，无外乎就是这么几点。简单来说，后面我写了，查询和分布。怎么减少扫描量，使得扫描原始数据的量，能达到最高呢？这里面提到一些技术，压缩这里面我会单提一下，因为都是统一的数字数据，压缩可以做到很高，本身具有这样的优势，整个的扫描量会达到惊人的量级，本身这个不是一个独立的系统，上下游都是通的，因为他是引擎，刚才说了下游就是接了刚才的实时系统，数字更新和可见的程度是非常高的。

我们现在引擎的核心的技术大概是这么两点，一个是数据的可扩展性，MPP最大的区别，把这些语句和事务型的东西做了分布，我们这个，这个模型本身很简单，算的就这么几种，我们这么做就是有效的，在数据分布上，也是行列组织，用这种范围查询，就是这种排序的T，加上按照数据量，是分组分块，现在就是1G ，测试是最高到40比1，这也是很惊人的，最上层，支持SQL92这种接口。原则上很简单，我之所以提这一点，我们的公司，或者我们的其他企业，可以去做，比较简单，但是他非常有效，可以做的很高，只要根据业务模型，业务模型分析的很清楚，要什么，不要什么，不要的砍掉，附加的砍掉，某个点上做到极值，就可以做到这样。到底怎样？在一百个节点的规模下，现在整个存储量大概是500T，一天更新1T，查询量是2亿，写入的速度是这么多，单节点是保守的估计，1.5G，压缩起来，我是按照1比10去算的，实际上可以达到300G左右。在前面，我记得是哪个谷歌的什么系统，三秒钟文了一P数据，访问的速度跟这个类似，达到了类似的性能。平均的是在毫秒级，最大的访问压力是五千，这个是一百个节点，查询的成功率是5个9，这样可以稳定服务好长时间。这部分的检索系统是一个检索系统，计算模型是一个分布式的检索系统，下面是一个数据分布的一个集群，所有的这种，只在下面的集群的节点上执行简单的操作。包括这种过滤排序的这种算子。

数据模具是这样的，大部分的情况，都是大小表，这本身就简化了很多，我们内部也经常会去比，跟谷歌比，我们到底做什么样的系统，他们的发展轨迹和应用场景完全不同，把问题简化以后，就可以做到这个性能。