时至今日,大数据这个概念已充斥了整个IT界,各种“搭载”了大数据技术的产品,各种用于处理大数据工具更如雨后的春笋触目皆是。同时,如果某个产品还没抱上大数据的大腿,如果某个机构还没捣鼓过基于Hadoop、Spark、Impala、Storm等高大上的工具,更会予以过时黄花的评价。然而,你的数据量真的需要使用Hadoop这样工具吗?你业务处理的数据类型真的需要大数据技术来支撑吗?
文章出自有着多年从业经验的数据科学家Chris Stucchio,纽约大学柯朗研究所博士后,搞过高频交易平台,当过创业公司的CTO,更习惯称自己为统计学者。下面我们一起看他的观点。
Hadoop只是运行某个通用计算的工具,正因为如此,在使用过程中你会受限于多种规则,比如所有计算都必须按照一个map、一个group by、一个aggregate或者这种计算序列来写。这种束缚就像穿上一层紧身衣,但是正因为Hadoop和大数据是热词,世界有一半的人都想穿上紧身衣,即使他们根本不需要。因此,你的数据量真的需要使用Hadoop这类工具吗?
1. 好几百M的数据,Excel装不下!这种级别完全和“大”无关,类似Pandas这样的工具就可以处理的很好,它可以把几百M的数据加载到内存,一眨眼功夫Numpy就能完成亿次浮点计算。
2. 数据体积高达10G!这种级别的数据仍然称不上大数据,当下的笔记本的内存都可以添加到16G了,而且许多工具并不是一次性将数据完全加载到内存的。
3. 数据有100GB/500GB/1TB!1个2TB的硬盘才几百块,买一块换上,然后果断装PostgreSQL等。
对比Python这样的脚本,Hadoop在编程方面不存在任何优势;同时因为跨节点的数据流开销,Hadoop通常情况下要慢于其他技术,然而如果你的数据超过5TB,那么你真的需要捣腾Hadoop了。
Chris从数据体积上分析了你的数据是否称得上大数据,是否真的需要使用大数据技术,然而衡量大数据的因素还有Velocity、Variety以及Value,下面我们就一起看MongoDB分享的“大数据除大以外的东西”,下为译文。
“大数据”,套用《银河系漫游指南》里的经典语录就是“is Big. You won’t believe how vastly,hugely, mind-bogglingly big it is. I mean you may think there’s a lot of data in Wikipedia but that’s just peanuts to Big Data”。这也是许多人在碰到大数据时走入的误区——他们首先假设自己必须使用大数据技术处理,然而我们离大数据还差很远,那么大数据是如何得来的?
回溯20世纪90年代,人们认识到数字化的存储数据比用纸要廉价的多,当一个东西便宜到一定的地步时,它就成为一个必然的选项。人类就会出于本能的去储存所有数据,因为“未来我们可能需要它们”,而且储存已经这么便宜了,为什么不做呢?
而从1990年美国科学家一篇名为“Saving All The Bits”的文章中发现,那个时候科学家已经不得不面对保存所有数据的挑战,Peter Denning解释了NASA保存所有哈勃太空望远镜产生数据面临的挑战:该设备每天产生的数据需要2500张光盘来存放,这个速度不仅淹没了网络和存储设备的性能,同样还超出了“人类的理解能力”。但是请不要忽视一点,随着储存技术和经济状况的发展,这2500张光盘只等价于当下100美元左右的硬盘,而且我们似乎也并不需要储存一个太空望远镜产生的如此大量数据。
今天我们几乎可以存储任何具有业务目的明显的数据,比如信用卡销售及问卷调查。同时,我们还可以存储所有业务目的不明显的数据,比如:用户在一个网页上的行为、电缆接线盒中用户观看的TV频道、借助物理网开关灯或者门的行为。但是从价值上看,后一类行为的价值无疑很低。
一笔信用卡交易包含了很多数据,比如:人的信息、地理位置、价值等。在销售周期中,你会很自然的捕捉这些数据。然而用户在一个网站上产生的行为显然不会那么有价值,你可能收集到用户访问的URL、阅读某个页面花费的时间,但是这些记录的价值显然不如信用卡交易那么丰富。当然如果你要给你的用户分类时,这些记录还是拥有一定价值的。
然而当下存储的成本已经越来越少了,你的数据越多,你就可以从数据分析趋势中获得更多的价值。每条TV频道转换的信息确实无关紧要,但是如果你把这些数据与调度机广告数据放到一起将其视为一个聚合数据集,你将可以清楚的知晓用户的行为,这些数据将给广告者和程序设计人员提供有价值的见解。
同样,智能家庭系统中收集到的信息价值就更低了,你可能只会得到一些事件和状态信息,同时系统可能产生大量的数据,价值必须通过大量的筛选、过滤等处理才能体现。大数据最大的挑战就是从大量的碎片项中获取信息,也可能是使用许多具有丰富价值的数据做依托,然后从中剥丝抽茧,寻找真知。需要注意的是,这并不是大海捞针,而是从一堆针中给一些针定性。
造成需要大数据的原因是,你不仅拥有大量的数据,同样拥有大量访问这些数据的请求,而Big Data看起来能满足这个需求。
BigData的数据更倾向于冷数据,也就是你不会经常访问的数据,除了分析之外可能不会再次被使用。它可能很快被新鲜的冷数据代替,而新的冷数据又会产生新的分析,但是Big Data的范围需要与热数据分开,因为将两个需求混合得到的结果必然低于预期,这样一来冷数据与热数据的分析必然都差强人意。无论如何区分冷热数据都是个好的思想,不管是存储还是应用程序都应该区别对待。但是总有一些人不分场景为用户提供Big Data这个“仙丹”。
因此,请重视你的数据,分清楚数据的类型,以业务为需求,不必要将所有的数据混合到一起去打造1个大数据。
对于MongoDB的官博,Hakka Labs的创始人Pete Soderling在博文给以了回应。首先,他肯定了随着时间延续储存成本递减这条。其次,他还补充了两点,更多开放API造成用户数据太多以及公司们幕后操作的“数据共享”。随后,Pete则给出了自己的看法,下为译文。
不可否认,你们说的有一定的道理,但是重要的是,在过去几年中,那些具有前瞻性的公司都做了一件非常重要的事——设计一个健壮的数据处理管道去收集、聚合级处理它们不断增长的数据。之所以这么做,最主要的原因就是用一种固定的方式分析数据之间的关系,就像MongoHQ说的在一堆针中给一些针定性,如果不这么做的话,这些关系必将消失。
但是这同样提出了一个问题,什么样的处理管道才是健壮的?简单的把数据扔入Hadoop显然不是,这里分享来自Stripe、Tapad、Etsy及Square的例子,一探现实世界中的数据管道。
1. Stripe的处理方式
Stripe的Avi Bryant为我们分享了如何建立一个健壮的数据管道。
2. Tapad的数据管道
Dag表示最后一点让流计算的追溯成为可能,同时还可以自动同步其它存储系统中的数据。Dag还解释了存储方面使用了多个数据技术的原因,还剖析了这些技术的优势。
3. Etsy处理数据的方式
通过Etsy数据团队技术经理Rafe Colburn,我们了解到了Etsy的数据处理方式。
4. Square的分析方式
Square数据管道设计的非常复杂,在接触到技术经理Pascal-Louis Perez后,他为我们分享了Square的数据管道架构战略视图。
鉴于系统中支付流的重要性,Square将“reconciliation”这个概念贯穿了整个数据管道系统,验证每个数据转换的正确性。通过Pascal了解到,这种方法最大问题就是规模问题。对于每次付款收讫都会产生“10-15个核算实体,协调系统同样需要”,一次交易产生的操作已经够多了。Square的方法是使用流处理系统,这就允许为不同流映射不同的数据域。