汇付天下第一届科技节

我觉得我们公司不算很大,汇付数据1000人不到,整个集团2000人不到,现在有13个子公司,这几年发展非常快,但是和 BAT 之类相比,真不算大。

今天是公司新大楼好了之后的第一次使用,举办的就是第一届汇付科技节。

我的团队很厉害,夺得唯一的一等奖,还有一个三等奖,虽然我觉得获得三等奖的机器学习项目更有技术含量,不过一等奖的数据门户大家一路做到现在,也着实不容易。

对于数据仓库、hadoop、机器学习等的相关研究,其实都是刚刚起步,还差得很远,继续加油。

什么是 Hadoop ?

今夜我们聊聊大数据之四

Google 提出了其用于自身数据处理的三篇论文,但是这个是 Google 的命根子,并没有开源,当时甚至连对外的应用都没有。

如同Linux 对于 Unix,聪明的程序员们总有办法克隆。

Yahoo 公司彼时还如日中天(如今,2016年3月,看到的新闻已经是 Yahoo 在寻找卖家了),其中的道格·卡汀,这位神一般的人物,在 Yahoo 组织开发了 Hadoop。而 Hadoop 这个单词就是以他儿子的一只大象绒毛玩具命名的。(这位仁兄后来创建了基于 Hadoop 的 Cloudera,几乎可以说是 Hadoop大数据实际应用领域最牛的软件公司。某种程度上回答一下开源软件不要钱,那么写开源软件的人怎么活下来的问题,软件还是需要实施和服务的,且每个公司的应用场景都不一样,所以这个还是可以赚钱的。)

hadoop

有据可查的 Hadoop 是在 2006年1月,在 Apache 上建立,包括使用了邮件列表、 Jira 和 wiki。到2015年6月,最新的 Hadoop 版本是 2.7。

中文维基百科对于 Hadoop 的定义非常清楚:” Hadoop框架透明地为应用提供可靠性和数据移动。它实现了名为MapReduce的编程范式:应用程序被分区成许多小部分,而每个部分都能在集群中的任意节点上运行或重新运行。此外,Hadoop还提供了分布式文件系统,用以存储所有计算节点的数据。MapReduce和分布式文件系统的设计,使得整个框架能够自动处理节点故障。它使应用程序与成千上万的独立计算的电脑和PB级的数据。现在普遍认为整个Apache Hadoop“平台”包括Hadoop内核、MapReduce、Hadoop分布式文件系统(HDFS)以及一些相关项目,有Apache Hive和Apache HBase等等。”

这段话要说解释,估计还要几万字。我们先把里面最基本的概念解释一下,之后各个击破,在以后的文字中介绍。

框架:在编程领域里面,框架一般指一套开发方法,包括开发项目的方法、各类工具、各类基础的程序函数、测试方法、服务器或应用的部署等。遵循某种框架可以既不失灵活性,又享受成熟的基础概念带来的好处。

MapReduce:这是Hadoop 的灵魂之一,形象的说就是把要一个人干十天的事情,转化为十个人用一天做。怎么把事情分解、然后再汇聚在一起,还要协调十个人的关系,这就是 MapReduce 要做的。Map 就是分解, Reduce 则是汇聚。理解了MapReduce ,就能明白为什么大数据的应用有很多泡沫、这两年横空出世的 Spark 为何又大大提高了运算速度等大数据领域中的爱恨情仇。

分布式文件系统:在 Hadoop 里面,一般称为 HDFS,我们的500G 的笔记本上找一个文件有时候都会觉得很慢,在windows 系统下要等好久,那么海量数据在服务器上怎么存储、怎么查找、怎么保证数据不坏等,这些是大数据应用的基石。

Hive、Hbase:在 Hadoop里面,有很多这样的名词,绝大多数都是为了传统数据库的使用者便于转换到 Hadoop 平台而诞生的项目,比如 Hive 可以理解为用 SQL 语句来搜索, Hbase可以按照字面理解为基于 Hadoop 文件系统的一种数据库。

对于 Hadoop 做了简单的名词解释,之后再聊聊大数据到底能做什么,和传统的非大数据有什么区别,大数据的理念如何应用。

今夜,我们聊聊大数据(3) – 大数据的起源

大数据和其他很多概念一样,和科幻小说也有点渊源,不得不说,科幻小说的作家们都是具有无比的想象力。

最早提出大数据概念的是我在少年时代就非常崇拜的科幻小说作家:艾萨克·阿西莫夫,这位拿过七次科幻小说最高奖雨果奖的大师在其科幻巨作《基地》中提出了“心理史学”,利用宇宙级大数据分析预知世界文明的未来。1965年《基地》系列得到雨果奖“史上最佳科幻小说系列”

300px-Isaac_Asimov_on_Throne

阿西莫夫和坎贝尔(其编辑)联手为“基地系列”打造出一门全新的统计科学,称之为“心理史学”,这门学问由书中数学家 哈里·谢顿 穷尽毕生之力创建,根据大规模的人类活动数据,预测未来走向,规模一旦小于一颗星球或是一座帝国,结果就会失准。谢顿运用此一科学,预见银河帝国的殒落,整片银河将因此进入长达三万年的黑暗时期,直到第二帝国建立。

阿西莫夫从1942年写到1986,共有14册长篇,和数不清的短篇小说。我在国内的购书网站上看到过好几个版本的译作,值得一读。

在这部科幻小说中,人类的计算能力已经达到了无以伦比的境界,不是天气预报、商品推荐、个人信用这些了,而是国家、星球、宇宙的发展。所以将《基地》小说作为大数据的起源也算实至名归(目前的技术和作者的想象还相差甚远)。

科幻小说中的场景还是需要靠真实世界中辛勤努力,这方面的接棒者则是著名的 Google 公司。

2003年,Google在19th ACM Symposium on Operating Systems Principles (SOSP‘03)上发表论文,提出了 Google File System(GFS),支持以搜索引擎为典型实例的大规模、分布式、数据密集应用,解决了海量数据的底层存储和检索问题。2004年,Google 接着在 6th Symposium on Operating Systems Design & Implementation (OSDI 2004)上发表论文,提出了著名的 Map Reduce 计算架构及其实现,解决了海量数据的分布式计算处理问题。2006年,Google 又在 OSDI2006 上发表论文,提出了 Big table 架构及其实现,解决了海量数据,尤其是海量超链接数据的结构化存储和检索问题。

Google 的上述三篇经典论文,真正突破了云计算和大数据应用的主要瓶颈,奠定了这两个相关领域的应用基础和研究基础。这三篇论文所发表的研究成果,是 Google 公司每天都在实际运行的系统、无数用户每天都在实际应用的技术,经受住了实践的检验。这三篇论文对于云计算和大数据两个领域的研究和产业应用的影响是深远的。

这三篇论文出来之后,掀起了云计算和大数据应用和研究的热潮,Amazon、微软等纷纷推出了自己云计算平台。作为对 Google 上述三篇论文的开源实现,Hadoop 的出现让更多的草根研究者也有机会玩儿云计算和大数据,一时间各种层次的学术论文和应用系统汗牛充栋。

我们今天几乎所有对大数据的应用实践,不管是 Amazon 的 aws,还是国内的阿里云等等,技术基础都源于此。单就这一点来说,我们要感谢 Google。

Hadoop 是非 Google 体系中大数据平台的基石之作,其衍生出非常庞杂的体系,之后将继续介绍 Hadoop 是如何诞生以及壮大,Yahoo 和 Apache 在其中的伟大作用,以及这个奇怪的单词到底什么意思。

  • 艾萨克·阿西莫夫部分文字介绍和照片来自维基百科-艾萨克·阿西莫夫条目
    ** Google 三篇论文介绍部分来自于:应该做什么样的研究:以Google为例 (http://blog.sciencenet.cn/blog-64396-649988.html)

今夜,我们聊聊大数据(2) – 多大才算大

这几年,IT圈内,谁不说说大数据和云计算,感觉就是落伍了。这样的名词还有很多,包括O2O、乔布斯等。浮躁之心的确是我们难以逾越的心魔。

大数据技术肯定有其存在的道理,Google、Apache等世界顶级的IT公司和组织为此做出了卓越的贡献,我坚决的不认为大数据是一个伪命题,并且大数据和相关的技术已经为我们展现了其魅力。但是为什么,还是让我们困惑:

  1. 多大才算大数据?
  2. 大数据用在哪里?
  3. 大数据和传统的数据库技术有什么区别?

关于什么是大数据有标准答案后面会说到,所以先来简单回答一下第二个问题。

谈及大数据一定是有应用场景的,肯定不是所有的数据库应用场景都需要和能使用大数据技术的。

数据的使用,在于应用场景和价值体现,而不是炫技。某些hadoop,或者spark系统的举例可以只加载了几千行的数据,但这是举例。一般来说,数据量没有达到1T规模的,用传统的数据技术在绝大多数场景下都可以满足应用。

维基百科中文版给的定义是: 大数据由巨型数据集组成,这些数据集大小常超出人类在可接受时间下的收集、庋用、管理和处理能力。“庋用”是一个很不常用的词语,对照英文版的定义:Big data usually includes data sets with sizes beyond the ability of commonly used software tools to capture, curate, manage, and process data within a tolerable elapsed time. “curate”也可以翻译成“策展”,用英文解释这个词更加明白一些:select, organize, and look after the items in (a collection or exhibition).

维基百科指出到大数据的大小经常改变,截至2012年,单一数据集的大小从数太字节(TB)至数十兆亿字节(PB)不等。

像在我们公司的一些主要应用,一个应用有几十乃至百来张表是很正常的,光用记录行数只能描述数据库的部分复杂度,而数据的容量的确是最客观的一个指标。从数据量来说,我们公司的业务数据差不多在2T左右,每天增加的量在1G左右,当然随着业务量的飞速发展和数据越来越多,增速很快。

我觉得谈大数据,至少需要1-2T这样的数据量,那么后面说到的大数据技术就可能比较合适了。维基上说得好:指的是所涉及的数据量规模巨大到无法通过人工,在合理时间内达到截取、管理、处理、并整理成为人类所能解读的形式的信息。在总数据量相同的情况下,与个别分析独立的小型数据集(data set)相比,将各个小型数据集合并后进行分析可得出许多额外的信息和数据关系性,可用来察觉商业趋势、判定研究质量、避免疾病扩散、打击犯罪或测定即时交通路况等;这样的用途正是大型数据集盛行的原因。

小结一下,大数据和传统数据最大的区别就是数据量要大,并且需要在指定的时间(当然越快越好)内完成复杂的处理。从目前来说,数据量的底限至少是1T。只有合适的应用场景才需要大数据技术。

worldrecord_pb_01S-360x200

worldrecord_pb_02S-360x200

worldrecord_pb_03S-360x200

接下来,让我们追本溯源,谈谈大数据的由来,hadoop等一堆名词的意义。

图片来源:Sybase IQ: A World Record in Pictures

今夜,我们聊聊大数据(1) – 前言

转眼负责汇付的数据部门两年半了,时髦的大数据其实也就最近一年开始研究,而实践则是半年里的事情。

不管是不是大数据,数据都是为了某种目的服务的,这几年大数据的概念如同“云”一样,喧嚣尘上,不免有很多炒作和不实之处。

一件事情,能被炒作的这么热,hadoop以及衍伸出的很多产品,存在肯定有其道理。对于大多数人来说,大数据好像没有什么用处。说到底,大数据就是一个工具,在需要的场景下使用自然有用。就像三十年前的电脑一样,到了今天,电脑似乎哪里都在了,但实际上,有时候拿个小本子做备忘录还是最方便的,如此道理。所以,大数据既不是灵芝仙丹,也不是洪水猛兽。

大数据简单而言,就是海量数据高速运算寻找相关性。(这个概念之后会再详细解说)

我所在公司的部分业务数据的数据表都达到了亿条以上,容量几个T,在一些查询、分析、风控等业务场景需求都需要在很短时间内计算出结果,因此,随着业务发展和技术预研,一些大数据的技术被逐渐引入,积累了不少心得。

自己也是一个初学者,边学习边提高,希望对各位有所裨益。

每篇文字不会太长,之前HR负责培训的同事告诉我,现在流行微课程,7-8分钟即可,故需要与时俱进,大家时间宝贵,在几百一千字里面,简明扼要的说明一个问题。(这个前言也就到这里了)

又想起了大数据这个时髦的名词

2016.9.28

转眼一年便过去,去年成都的匆匆忙忙,这一年里,作为公司大数据的布道者,倒是很忙碌和充实,我们的hadoop 集群真的搭建了,真的有应用在跑了,CDH 也基本作为未来支撑的主力。其他如 kafka、storm、ES 更是广泛应用。

blog 倒也是有好处,可以修订内容,保持内容的新鲜度。可惜写的人好像不多,大家习惯朋友圈、微博这类快速的简短的,有一个公众号已经很不错了。


2015.9.12

发现自己在2013年8月写过一篇,需要大数据么?

当时或许是大数据最为喧嚣之时,时过境迁,两年过去了,大数据的炒作和泡沫已经差不多了,真正的应用也逐渐走到了台前,且大数据的理念,海量数据、高效处理、寻找相关性已经深入人心。也差不多就是这两年,在数据采集、ETL、数据仓库、数据分析和建模、数据钻探、BI等诸多领域,包括大数据到底是什么,怎么把大数据理念付诸于实践。

8月在成都,西南财大,给公司的一个培训班做了培训,之后在公司内部又有两次培训,越说越觉得知识的匮乏,以及外面有些伪专家的诸多误人子弟。

是否也应该启用公众号,做做自媒体了?

用百度预测买世界杯足彩

看到周围很多朋友在世界杯开始的时候就买足球彩票,可是我基本是个假球迷,怎么办呢。于是世界杯第一轮小组赛后,我开始关注到百度有一个世界杯的数据预测。

但是,我是反过来用这个数据的,我叫做逆百度预测,也就是百度预测说谁赢,我就卖输。原因一开始很简单,因为大热的场子你买了也中不了多少钱,甚至还不够本,而押冷门,输了的话,本钱一样,但是赢了的话,要比前者多好几倍。

这是周日早上小组赛百度的预测

baidu

百度说德国胜率72,所以我就买平,百度说波黑胜率50,所以我买波黑输和平,结果如下

caipiao

这是我用这个方法操作的第二次,第一次也是赢了,因为英格兰,百度当然说英格兰赢,越是我就买英格兰输。

今天早上三场,同样的道理,我用百度数据逆算下来是,美国平葡萄牙,但是韩国实际输了,没想到,比利时我买的是胜或者平俄罗斯,如果不是比利时最后一球小胜,平还是对的。

由此可见,百度大数据预测是不准的,这不是百度的问题,这个和世界杯本身的偶然性有关,也和后面坐庄的赌博公司有关。大数据预测对于世界杯这样的事件预测不准也是正常的。

你的数据量够大够用hadoop了

这年头,好像不提hadoop,就对不起自己,也不管自己数据到底多少。搞it的人有时候会忘了出发点,而变成为了某样东西而去实现。

看到这篇文章,颇有同感,没有个几T的数据,用hadoop,真是自己找麻烦。

别老扯什么Hadoop了,你的数据根本不够大

本文原名“Don’t use Hadoop when your data isn’t that big ”,出自有着多年从业经验的数据科学家Chris Stucchio,纽约大学柯朗研究所博士后,搞过高频交易平台,当过创业公司的CTO,更习惯称自己为统计学者。对了,他现在自己创业,提供数据分析、推荐优化咨询服务,他的邮件是:stucchio@gmail.com 。

“你有多少大数据和Hadoop的经验?”他们问我。我一直在用Hadoop,但很少处理几TB以上的任务。我基本上只是一个大数据新手——知道概念,写过代码,但是没有大规模经验。

接下来他们会问:“你能用Hadoop做简单的group by和sum操作吗?”我当然会,但我会说需要看看具体文件格式。

他们给我一个U盘,里面有所有的数据,600MB,对,他们所有的数据。不知道为什么,我用pandas.read_csv(Pandas是一种Python数据分析库)而不是Hadoop完成了这个任务后,他们显得很不满意。

Hadoop其实是挺局限的。它无非是运行某个通用的计算,用SQL伪代码表示就是: SELECT G(…) FROM table GROUP BY F(…) 你只能改变G和F操作,除非要在中间步骤做性能优化(这可不怎么好玩!)。其他一切都是死的。

(关于MapReduce,之前作者写过一篇“41个词讲清楚MapReduce”,可以参考。)

Hadoop里,所有计算都必须按照一个map、一个group by、一个aggregate或者这种计算序列来写。这和穿上紧身衣一样,多憋得慌啊。许多计算用其他模型其实更适合。忍受紧身衣的唯一原因就是,可以扩展到极大极大的数据集。可你的数据集实际上很可能根本远远够不上那个数量级。

可是呢,因为Hadoop和大数据是热词,世界有一半的人都想穿上紧身衣,即使他们根本不需要。

可我的数据有好几百MB呢!Excel都装不下
对Excel很大可不是什么大数据。有很多好工具——我喜欢用的是基于Numpy的Pandas。它可以将几百MB数据以高效的向量化格式加载到内存,在我已经3年的老笔记本上,一眨眼的功夫,Numpy就能完成1亿次浮点计算。Matlab和R也是很棒的工具。

数百MB数据一般用一个简单的Python脚本逐行读取文件、处理,然后写到了一个文件就行了。

可我的数据有10G呢!
我刚买了一台笔记本电脑。16G内存花了141.98美元,256GB SSD多收200美元。另外,如果在Pandas里加载一个10GB的csv文件,实际在内存里并没有那么大——你可以将 “17284932583” 这样的数值串存为4位或者8位整数,“284572452.2435723”存为8位双精度。

最差情况下,你还可以不同时将所有数据都一次加载到内存里。

可我的数据有100GB/500GB/1TB!
一个2T的硬盘才94.99美元,4T是169.99。买一块,加到桌面电脑或者服务器上,然后装上PostgreSQL。

Hadoop的适用范围远小于SQL和Python脚本
从计算的表达能力来说,Hadoop比SQL差多了。Hadoop里能写的计算,在SQL或者简单的Python脚本都可以更轻松地写出来。

SQL是直观的查询语言,没有太多抽象,业务分析师和程序员都很常用。SQL查询往往非常简单,而且一般也很快——只要数据库正确地做了索引,要花几秒钟的查询都不太多见。

Hadoop没有任何索引的概念,它只知道全表扫描。而且Hadoop抽象层次太多了——我之前的项目尽在应付Java内存错误、内存碎片和集群竞用了,实际的数据分析工作反而没了时间。

如果你的数据结构不是SQL表的形式(比如纯文本、JSON、二进制),一般写一小段Python或者Ruby脚本按行处理更直接。保存在多个文件里,逐个处理即可。SQL不适用的情况下,从编程来说Hadoop也没那么糟糕,但相比Python脚本仍然没有什么优势。

除了难以编程,Hadoop还一般总是比其他技术方案要慢。只要索引用得好,SQL查询非常快。比如要计算join,PostgreSQL只需查看索引(如果有),然后查询所需的每个键。而Hadoop呢,必须做全表扫描,然后重排整个表。排序通过多台机器之间分片可以加速,但也带来了跨多机数据流处理的开销。如果要处理二进制文件,Hadoop必须反复访问namenode。而简单的Python脚本只要反复访问文件系统即可。

可我的数据超过了5TB!
你的命可真苦——只能苦逼地折腾Hadoop了,没有太多其他选择(可能还能用许多硬盘容量的高富帅机器来扛),而且其他选择往往贵得要命(脑海中浮现出IOE等等字样……)。

用Hadoop唯一的好处是扩展。如果你的数据是一个数TB的单表,那么全表扫描是Hadoop的强项。此外的话,请关爱生命,尽量远离Hadoop。它带来的烦恼根本不值,用传统方法既省时又省力。

附注:Hadoop也是不错的工具
我可不是成心黑Hadoop啊。其实我自己经常用Hadoop来完成其他工具无法轻易完成的任务。(我推荐使用Scalding,而不是Hive或者Pig,因为你可以用Scala语言来写级联Hadoop任务,隐藏了MapReduce底层细节。)我本文要强调的是,用Hadoop之前应该三思而行,别500MB数据这样的蚊子,你也拿Hadoop这样的大炮来轰。

亚马逊和YouTube都斩获艾美奖,它们的技术有什么不同?

老外还是技术派,敢想敢做,并且不是一个点的突破,而是整个行业的突破。你用创新算法,我艾美奖就敢给你。我们的广电总局在想什么,天知道,技术前瞻,那更是地知道了。

下面文章出自这里

几天前,PingWest报道了YouTube依靠推荐算法获得了艾美奖。现在,亚马逊的视频服务Prime Instant Video也确认获得了同类的技术与工程奖项,只不过在官方的声明中,用推荐算法(Personalized Recommendation Algorithm)来解释YouTube获奖的原因,而在亚马逊上用的是个性化推荐引擎(Personalized Recommendation Engines)一词。

简单的说,推荐引擎就是建立在算法框架基础之上的一套完整的推荐系统,算法引擎属于其中的一部分。除此以外,推荐引擎中还包括场景引擎、规则引擎、展示引擎。

场景引擎是用来计算的用户意图。它是将用户的行为与他们在Amazon Prime Instant Video中的需求相对接。虽然Amazon没有详细说明其方案,但大体上应该类似大部分场景引擎的思路,例如,将用户在Prime Instant Video页面的随意点击定义为“随意浏览”,将用户在Prime Instant Video中“Kids & Family”类目下的点击定义为“有定向目标的浏览”,将用户在“Kids & Family”类目下的影片收藏行为定义为“强需求的挑选”……以此类推。

规则引擎是一套预定义的决策方案,例如在以上的“强需求的挑选”意图下和“有定向目标的浏览”意图下,分别应该对应怎样的规则,再利用算法,这些意图转化为合适的推荐数据。如今这些规则中往往还会引入社交关系。

内容引擎则是为推荐的内容选取最合适的展示形式,即合适的位置。因为我们如今接触的推荐系统中往往有多种不同的推荐内容,例如“你可能感兴趣的视频”、“你的朋友爱看的视频”,有的推荐系统里甚至还有相关的用户等内容推荐,除此以外,Prime Instant Video首页的个性化推荐和点击进入某一个影片下的推荐也都是不同的。

(注:因为没有术语参考,所以以上引擎的名称定义是参照我此前采访的“百分点系统”推荐引擎所用名词。)

所以,与YouTube的奖项相比,亚马逊Instant Video的奖项更强调其整体推荐系统的技术架构以及与Instant Video产品功能设计相结合的能力。例如它能够通过主题、情绪、风格等分类方式帮助用户快速找到合适的类目,而其中的影片则是依据用户的兴趣和喜好做个性化的排序。这样的个性化功能设计还包括用户的个人商店、“看过这部影片的顾客也看过哪些影片”等。

实际上,对于亚马逊Instant Video而言,其主要竞争对手并非Youtube,这个以购买和租赁在线视频的服务当前最在意的敌人还是Hulu和Netflix。他们的战争除了用户提供更好的个性化内容之外,还包含应用的使用体验、价格、影片数量等多方面的较量。

我们此前报道过Netflix已经成功变身为一家视频内容制作商了,而Hulu不久前刚刚获得7.5亿美元的增资,也将中心放在了原创内容的生产上,Instant Video则在尝试让观众决定拍哪部电视剧,结局应该是什么样的。

在我看来,Instant Video拥有更广泛的竞争力。

首先,它背靠Amazon AWS,在视频存储技术和成本上都有显著的优势,在三家的价格中,Instant Video的年费是最低的,而Netflix是架设在亚马逊的云服务上的,所以在这方面显然难与之抗衡。

其次,Amazon拥有自己的硬件设备,Kindle Fire、Kindle Fire HD的市场表现帮助他们建立了一个强大的内容销售渠道,除此以外,Instant Video也支持iPad、iPhone、iPod touch、Roku、Xbox 360、PlayStation 3、Wii 和Wii U等设备。

再次,Amazon在书籍市场的绝对地位能够帮助他们更容易获取一些热门内容的影视版权,或是能够将热门视频内容改变成书籍,扩大其商业效益。而用户在书籍上购买的数据也能帮助他们在原创视频的制作和推荐上进行参考。

需要大数据么?

2016.9.28

这篇 blog 是写在2013.8.4,我觉得个人其中大部分的观点还是正确的,不过,这三年大数据以及相关技术的确发展的很快,更多的应用场景也被挖掘出来。看来是要重新写一点文字了。不管是机器人还是人看到这些文字,都可以。


2013.8.4

下面这些问题不是给纯粹技术人员看的,也不是给纯粹业务人员看的,如果你想在业务中引入大数据,那么可以冷静的思考一下。

1 大数据和传统数据有什么差别。

首先是数据量的差别。我觉得1亿条数据或者1T数据是一个分界岭,oracle、sql server,以及mysql等对于1亿条的数据还是可以很好的支持的,但是在应用层面如果设计的不是很好会有点瓶颈。还有就是数据增量的问题,如果一个月里面1亿条变成2亿条了,那么就开始准备大数据吧。

其次是需求。大数据讲的是通过数据来进行挖掘、建模和产生效益,传统的数据也有BI等,但是更多的报表汇总等。这一点我始终觉得是大数据时代和传统数据时代区别最大的地方,大数据时代侧重于从海量数据中产生价值,并且不需要抽样,处理的是全数据,且是实时或者准实时,并且是性价比较高的方式。

2 大数据要花很多钱么?

传统的应用设计模式,对于每天能产生百万条记录本身也要花费不少钱的,当然能够产生这么多有价值数据(特别是交易记录)的话,你的商业模式也会不差,所以有趣的是在国内,很多大数据应用都是在电商,比如淘宝、亚马逊、1号店等。

除了基础设施,主要的开销就是在hadoop、服务器和网络、分析软件和人上面了。并不是想象中那么便宜,即便hadoop是免费开源软件,光是hadoop的基础服务器群,就不少预算。阿里贷据说搭建了2000台服务器的hadoop集群。性能是需要硬件支撑的。分析软件、二次开发、运营维护等等,不会是键盘上一个键按下去,就搞定了这样的好事。(我们有一个使用mongodb的最小集群进行map/reduce计算的实际使用场景,至少我个人觉得周期并不短)

3 大数据到底带来什么?

前面说了一点,如果用得好,我们可以准实时(5s里面)获得所有需要的数据,并且是有各类基于维度统计、统计模型、自定义的计算。这也是令传统数据库产业链惊慌的,因为互联网、因为智能手机,产生了大量的数据,所以终于需要分析了。数据不再匮乏,怎么用倒是成了一个问题。

我们可以根据用户、交易的行为,通过建模得出我们想要的用户行为模式或者用户资料,然后在营销中得以实践,并不断修正模型。除了传统理解的数据以外,大量的非结构化数据一样可以纳入大数据的计算范畴,比如微博的记录、电子邮件的内容等等。