话说道哥(Doug Laney)当年创立三V经,背景是电子商务:Velocity衡量的是用户“交互点”(Point-of-Interaction),如网站响应速度、订单完成速度、产品和服务的交付速度等。假设交互点是一个黑盒子,一边吸入数据,经过黑盒子处理后,在另一边流出价值,那Velocity指的是吸入、处理和产生价值的快速度。随后“快”进入了企业运营、管理和决策智能化的每一个环节,于是大家看到了形形色色描述“快”的文字用在商业数据语境里,例如real-time(实时),lightning fast(快如闪电的),speed of light(光速),speed of thought(念动的瞬间),Time to Value(价值送达时间),等等。
大家知道,购物篮分析是沃尔玛横行天下的绝技,其中最经典的就是关联产品分析:从大家耳熟能详的“啤酒加尿布”,到飓风来临时的“馅饼(pop-tarts)加手电筒”和“馅饼加啤酒”。可是,此“购物篮”并非顾客拎着找货的那个,而是指你买完帐单上的物品集合。对于快消品等有定期消费规律的产品来说,这种“购物篮”分析尚且有效,但对绝大多数商品来说,找到顾客“触点(touch points)”的最佳时机并非在结帐以后,而是在顾客还领着篮子扫街逛店的正当时。电子商务具备了这个能力,从点击流(clickstream)、浏览历史和行为(如放入购物车)中实时发现顾客的即时购买意图和兴趣。这就是“快”的价值。那传统零售业是不是只能盯着购物清单和顾客远去的背影望“快”兴叹了呢?也不见得,我有空时会写一篇小文“O4O:Online for Offline”专门写传统零售业怎么部署数据实时采集和分析技术突破困局。
如果预测未来数据的增长必将超出现有架构的上限,那就要规划新的架构了。这里不可避免要选择流处理结构,还是批处理结构,抑或两者兼具。Intel有一位老法师说:any big data platform needs tobe architected for particular problems(任何一个大数据平台都需要为特定的问题度身定做)。在下不能同意更多。为什么呢?比如说大方向决定了要用流处理架构,我们前面列举了很多品类,落实到具体产品少说上百种,所以要选择最适合的流处理产品。再看批处理架构,MapReduce也不能包打天下,碰到多迭代、交互式计算就无能为力了;NoSQL更是枝繁叶茂,有名有姓的NoSQL数据库好几十种。这时候请一个好的大数据咨询师很重要(这也是我在这里说大数据咨询服务有前景的原因)。
3)增量计算--也即先顾眼前的新数据,再去更新老数据。对传统的批处理老外叫做reboil the ocean,每次计算都要翻江倒海把所有数据都捣腾一遍,自然快不了。而增量计算把当前重点放在新数据上,先满足“快”;同时抽空把新数据(或新数据里提炼出来的信息)更新到老数据(或历史信息库)中,又能满足“全”。谷歌的Web索引自2010年起从老的MapReduce批量系统升级成新的增量索引系统,能够极大地缩短网页被爬虫爬到和被搜索到之间的延迟。我们前面说的“流处理和批处理肩并肩”也是一种增量计算。