5）降低对精确性的要求。大体量、精确性和快不可兼得，顶多取其二。如果要在大体量数据上实现“快”，必然要适度地降低精确性。对数据进行采样后再计算就是一种办法，伯克利BlinkDB通过独特的采用优化技术实现了比Hive快百倍的速度，同时能把误差控制在2-10%。

这世界上没有免费的午餐，实现了“快”必然要付出代价。要么做加法，增加硬件投入、改变架构设计；要么做减法，降低精确性、忍受实时但非全时的智能。其实，这个好比看报纸，时报、日报信息快，需要采编投入，但因为短时间内所能获得信息的局限性，缺乏深度和全景式的文章；周报、月刊则反之。

“快”很贵。有些行业，肯定是越快越好的，比如说金融领域，所以他们愿意买贵得离谱的SAP HANA或IBM Netezza。对绝大多数企业来说，需要精打细算。关键还是，对每一个问题，仔细调研清楚“足够快”的定义。心里有底，做事不慌。

“快”容易错。丹尼尔·卡尼曼在《思考，快与慢》中讲到快思考容易上当，在那一瞬间，“眼见为实”、厌恶损失和持乐观偏见等习惯常常引导我们作出错误的选择。基于“快”数据的分析同样会有这样的问题，可能是数据集不够大导致了统计偏差，或是因为“快”而牺牲了精确性。

再进一步，“快”出错了常常“覆水难收”。Wolters Kluwer的一个高级分析师Marcia Richards Suelzer说：“我们现在可以在几纳秒内作出灾难性的错误计算，随即将其广播到世界的各个角落。我们不再具有计算延迟带来的缓冲性”。技术带来了分析的快速性和全球的连接性，同时也把我们创造破坏的能力放大了。美国新闻向来是求“快”，彭博社误报“中国经济刺激计划”导致全球股市大涨，至少结果还不错，CNN在2008年误报乔布斯有心脏病导致苹果股价大跌就不那么美好了（彭博社还在同年误报乔布斯的死讯）。

简单地总结，Variety和Velocity是Volume的左右护法，它们修正和充实了“大”的内涵。Velocity带来了诸般好处，也需要付出代价。下一篇讲Veracity 鱼龙混杂、真假难辨。