| 摘要：第四届中国云计算大会于2012年5月23日-25日于北京国家会议中心召开,大会以“发挥示范引领作用,推动云计算创新实践”为主题。在2012国内公共云全面开花、云计算实践元年之际，本次大会云集云计算核心专家，就国内外云计算核心技术以及行业应用创新实践进行了深入探讨。 |
以下为文字实录：
增量的数据处理模式
我之前的同事，他最后建议我还是用中文来演讲，我还是用中文发言了。现在开始争取用中文讲，今天我演讲的题目叫做“持续增量大数据处理平台”，我们在2009年到2010年在雅虎做的一个平台。首先我们来看什么是持续性的数据源？持续性数据源可以这么定义，随着时间的推移，时间的变化，会有不停的发生更新或增量或改变的数据来源，这是大处理最主要形式，举个简单例子，第一个例子，日志分析无论搜索日志还是点击，用户行为日志都是在前端形成的，不断的实施和生成，将日志搜集上来送到Hadoop上面进行处理，它是持续的过程，对这样的持续过程的不断采集和处理，这是持续的迭代式的过程。类似的例子还有增量式的索引，无论网页搜索、广告引擎都需要做日志建立，基本都是主流人使用增量式模式来做，从结构化数据中抽取新的增量数据，还是像广告引擎用户可以有新的卡片，这些数据以增量的形式出现，我们也需要用增量的模式处理这个数据。
还有个例子，看到微博、博客、社交网络，社交网络上用户的更新，这些数据持续出现，因为有这么多的持续增量数据处理场景出现，我们第一个问题怎样处理这些数据？如果我们来看一下这些数据，有三种比较常见的基本形式或者三种形式的组合，第一种是完全的数据集的形式，比如说爬虫所爬的全网网页库或者广告平台所有用户建立广告卡片的集合，是完全的数据集，在这个基础之上，我们刚刚说了增量，有什么样的增量，有增加的数据集，最典型的例子，日志，日志从来不会有后面的日志更新前面的日志总是增量不断增加的类型。
还有一种类型增量改变的问题，我们对用户行为进行分析，会对用户的基本信息的改变进行分析，比如说改了住址、年龄，这样的改变有没有对所有用户数据进行重新分析，没有必要，把增量改变部分拿出来分析。大家可以看到持续数据流有不同的形式，数据流有混合，当时在做系统的时候，我们看到在有系统之前的大家处理这些数据有一些现象或者是问题，第一个数据处理和管理混合在一起，对数据进行建模的分析，怎么组织的的增量之间是什么关系，是覆盖关系还是迭代关系，关心所有东西，新的增量数据在老的数据之前到达，这种情况在现实生产中会出现的，我们应用程序要处理这些问题，这些处理是每个应用程序处理自己这样的问题，我们当时观察到这么一个现象，观察到我们在做大量持续性数据处理的时候，普遍出现的现象。
因为这种阶段出现，有一个问题，如果想做跨过应用的优化，其实很快的事情，每个应用自己处理方法，自己不同的业务逻辑的管理，这很难处理。基于这些观察设计一个系统一定程度帮助我们的应用程序开发解决这些问题，首先希望设计一个应用面向持续数据流的处理，增量处理的支持一方面需要业务逻辑紧密联系，另一方面，把这些抽象化或者形式化、规范化。
下一个是希望通过这么一个平台，能够把我们的应用放到一起，做一些优化，把应用放到一起做一些统一的优化。下一点，我们希望提供数据和计算统一的管理平台，如果说简简单单是运算管理，问题是数据是独立的东西，在这种情况下，还要对数据进行管理，进行维护，我们希望能够有统一的平台和架构管理这些东西。再有，我们希望提供压缩和垃圾收集，数据这东西不可能无限存储，所以我们应该提供很好的机制，管理数据的生命周期，每个数据出现到失去有生命周期。最后一个单词大家可能不太认识了，翻译成中文叫追根溯源，实际在业务前端，前端展示的时候，最后显示结果看到了奇怪的现象，这些现象到底最初是由数据哪个环节产生的？所以这个是追踪很困难的事情地大量的数据源，各个不同部门做的各种各样处理，各种模型加载，数据经过复杂变化以后，到底还能不能找到源头在哪里，希望提供机制能找到它的源头，这是非常有意思的话题。
数据的存储和更新
首先讲数据是怎么存储的？在我们系统当中，最终在雅虎实现了以后，我们在600到700台左右，现在用户是处理雅虎中所有的内容信息，跟内容相关的存储、处理和共享，包括从雅虎的财经来的，体育来的，这些所有的内容信息都是在统一平台上处理。我们系统是基于Hadoop来建立的，核心还是Hadoop作为平台，在这之上，工作在管理有没有做重新开发，我们的预算部分用的PigZebra做的，其实在雅虎当中应该超过60%的应用用Pig书写的，Zebra可能太少见。
我们回到具体部分，数据通道，可想象成逻辑上的概念，我们的搜索日志可以变成一个数据通道，中国汉语变成一个数据通道，所以它是逻辑的抽象概念，实际上这种存在上面以一组文件形式存储，我们通过文件具体存储格式抽象化了。虽然说持续变化数据有更新，有改写，不可改写有什么好处，第一个大家都知道，我们很容易做一些并发性优化，能够变成确定性的执行过程，可改写过程做到确定性的执行是很困难的事情，因为是不可改写过程，我们又支持数据演化和变化，我们实际上提供的是显示的版本控制，每次数据的变化，每次数据改变都是通过增加新的版本形式来出现的。因为有版本控制，由于有版本控制，我们相信也需要有所谓的Schama演化过程，这个变化能够让数据用户比较容易或者比较自动的接受这个变化。我们有最基本数据信息，访问权限，生命周期。所以我们的系统中会额外保存每个数据源它的实际运算过程中的相应参数。
这边说到数据的通道可以被更新，我们看看数据通道怎么更新？数据通道实际上逻辑可以认为有一组片段组成的集合，有两种类型，一种是Base，一个片段认为数据在代表了全部数据结合信息，Delta到前一个生成时间所有改变量。因为我们的用户数据形成有增量的形式，我们用户用的时候可以全量使用和增量使用，提供一个机制帮助用户把全量和增量来做，合并的过程当中需要有每个数据源，数据通道对应三个聚合方程，第一个是所谓的Diff，这是求差的过程，很简单，取两个Base做它们之间的差别。第二个方程是Merge的过程，你需要能够生成新的Base。第三个方程是Chaining，通过这个方法可以任意组合生成需要的一些东西。
所有三个聚合方程每个数据都需要，也可以定义成Segments，因为你用户不关心这些，你需要定义。最后聚合的函数不管把谁写在前面都是一样，当你有一个Base和Delta聚合，把所有Delda结合以后再跟Bese聚合需要等价的，加这三个条件为了做优化。看上去列了很多条件，但实际上这个条件不难满足，大家比较熟悉这是很宽泛的一类，我们看常见的聚合方式的条件，只有添加，用在日志分析的场合，这个方程很容易写，用简单的方式就可以了，因为它只是添加的过程，Diff也很简单。可以想一下，Upsert是很常见的方式，这个操作也比较简单，你把所有相同的P放在一起，选择最右边，最晚出现的那一个，这个Diff也是一样，还有比较复杂的，允许用户定比较复杂的，聚合方程需要把数据累加起来，都能够满足前面要的三个约束条件，都是没有问题的。
数据处理的任务计算
刚才说完了数据的存储和数据更新部分。下面到了任务计算部分，看怎么来做，如果把数据的Channel，可以把Task看成对时间序列上施加的函数，所以为什么把这个提一下，这跟传统的不一样的是对数据的变换，最后根据数据演化过程，任何一个task对一个数据的变换而已。所以当你去定义这些Task的时候，跟传统的定义不同的地方除了定义它的怎么计算，数据源，输入输出之外，还有，NEW的模式是说从上一次执勤到现在中间的数比差，OLD很容易理解，上一次执行所用的数据集，大家可以看到这个地方已经极大简化了应用程序的开发，不用关心增量部分到底怎么出来，如果增量是5分钟一次，我们预算3分钟一次协调问题都不用担心，给我上一次的时间点就可以了。对ProductionModel也是很简单了。
我们看看Task执行的时候有什么样的模式，大概有4个基本模式，对于具体应用看一下，大家如果熟悉做搜索相关的，这是对新闻网页做一个过程，最初输入RSSFeed，有两个分支发现新闻网页中网站建立的模板，把这些东西去掉再做，我们关心内容是否重复，模板先去掉，每次把新闻网页做一个聚类。这个分支是主线分支，把每一篇新闻网页判断是不是含每个Templates，这个地方可以看到这个模式是一个NEW，处理完了以后生成也是增量的部分，因为你输入是增量，打上标签是增量。大家有对Showging为每个网页比较指纹判断它有没有重复，这跟每个网页单独算的，它是非增量性的运算。其实它是有状态的，为什么会依赖于这个状态，因为这种模式边表是比较小的，把边表放在内存里面处理。算指纹的过程有新的计算，不依赖于任何的数据，有了指纹以后就是简单比对的过程，积累了过去所有指纹的，通过这四种状态的输入输出模式能够判断出来。
有了这些数据怎么能做出来这个事情只是数据生产者需要做的消费者不需要做的，第二个是Workflow，把相关的组织在一起，每一片输入输出端口绑定到上面的，因为这个中间是临时数据，我们不需要做这样一种绑定的模式。每一个Workflow片，各种Trigger，第一个是Data-based，第二种是Time-based，第三种是Cascade，某一个片执行时间长度超过60分钟了，我们需要额外执行片，可以定义这样的模式。所有的Workflow的片执行的时候如果中间出现了失败，我们不会保留中间结果，中间的执行结果表示了相应所绑定的数据，Chinnel没有得到完全更新。
实际上像这个定义成两个片，这个已经是一个片，右边这一列是一个片，我们画的是一个图，这边是每天更新，这是每五分钟进行更新。
我们在定义Workflow的时候，我们会有绑定的过程，但这个绑定是形式化的绑定我们应用绑定到数据Chinnel上面，真正的绑定在执行的时候进行，我们所有判断取哪一段Base做什么聚合，都是在运行时进行的。Pig是很简单的脚本语言，很简单，输入有两个文章，做一个简单的求交，求交完了以后找出每一个网页和所在的site，我们有一个变量机制，用户写程序放一个变量程序就可以了，输入和输出，这个例子可以看到，我们输入数据用了Union的方法，是使用了cogroup，把它们两个结合到一块。所以这些东西对用户全部是透明的，在运行时期动态的生成。
最后讲一下我们现场提供了Compaction，当一个Task绑定数据的chinnel上面，执行没有通过这个数据点，是不可以回述，因为还可以用到。Prownenance还好一点。Benefits在哪儿？数据无限存储是没有意义，我们用户行为分析，我们做个性化用户行为分析，两年以前喜欢的东西到现在根本没有意义，很重要的目的是实际上没有效果的数据，应该把它给去掉，不应该保存在那儿。更重要一点mergeCost，把数据合理的进行规避，减少Cost，这是当时的想Off-Peak，要做的业务移到晚上去做，我们也可以降低，这是我们的优化的方向。
我们当时做的实验，用的RealproductionData，我们有三种情况，一种是mergeside，我们mergeside做的情况下性能是非常高的。所以为什么我们希望通过错峰的方法取一些方式来优化它，我们研究怎么样通过优化做聚合的时候，聚合的顺序能够优化性能。我们还做了一个实验，一兆多的数据，这种情况下可以看到，有差距，这种情况production可以忽略不计了。你数据太小情况下不会起什么作用。到底增量运算对整体业务性能有多少提高，一方面是应用需要，另一方面是业务性能，如果是增量把它切开，省了OLD，整个数据集大概是10个，这相当于Base是一样的。下面是FUTUREWORKS了，一旦做优化，我们做的系统中所有的应用放到一块，如果读取数据集会合到一块去优化，这个也会带来很大的提高。我们希望有更优化的Scheduling。
Smarter Coalescing的聚合，不大跟小一个一个聚，对性能有影响，希望有一套比较自动化的方法去实现。Column Storage Oplimization需要优化的格式放到一块提高性能。最后是Automaticschemaevolution完全自动化，通过自动演化的形式，当用户运行到此会把这个数据进行变换。
责任编辑：三水
评论表单加载中...
