分类 工具 下的文章

敏捷团队的角色定义

敏捷团队的角色定义作用:描述敏捷团队Team中涉及的各类角色,每个角色的工作内容。Team中的全体成员遇到问题之后可以找对应角色的人员来协助解决障碍。
PO
1、产品负责人,负责产品整体规划,设定阶段目标,明确产品演进思路和版本发布规划,对外的统一负责人
2、负责明确产品需求、编写故事和设置优先级,输出Product Backlog 。
3、规划工作至少提前研发团队一个月;需求细化至少提前一个Sprint。
4、负责组织需求评审
5、负责解答Team中所有人员关于需求的疑问
6、负责验收研发团队交付的系统,对系统出厂的质量负责
项目负责人
1、跟进项目进度,并对外汇报项目进展
2、依据敏捷Team的各类输出,翻译成周报的格式提交给管理层
3、协调资源
Agile Coach
敏捷教练,协助SM进行敏捷实践和过程改进,推动Team完成持续改进
SM
1、Scrum Master,负责指导Team成员开展工作,确保各项工作的高效开展
2、优化工作流程和机制,确保各个角色之间顺畅、高效的协同工作
3、解决团队开发中遇到的障碍
4、作为研发团队与外部的接口,为团队排除障碍,屏蔽外界干扰
5、保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings
需求分析师
1、在PO输出的Product Backlog基础上,与PO沟通,将对应的故事细化成软件需求
2、解答研发团队开发过程中的需求疑问
技术负责人
负责整个系统的架构设计工作,对系统的技术架构和技术选型负责
子系统负责人
1、作为子系统的整体负责人
2、基于运营中心整体架构的基础上,完成子系统的架构设计和关键技术选型工作,对子系统的技术架构和技术选型负责
3、为子系统研发团队排除技术障碍,解决技术难点
4、指导子系统研发团队的开发工作
过程改进
1、协助SM开展过程改进工作,具体如下:
《1》关注研发过程中涉及的各类环境,确保各类环境正常稳定运行
《2》协助大家完成TDD的工作
《3》关注CI运行情况,提醒团队解决CI中的问题
《4》优化CI的执行过程
《5》定期Review大家的工作,如:Wiki、代码
2、发现团队中大家技能的短板,与SM一起提升大家的技能水平
开发工程师
1、依据Sprint Backlog,选取对应的任务,完成详细设计、代码编写(含测试代码)、修复BUG
2、承担项目中部分技术难点的攻关
WEB前端工程师
1、依据UI的设计方案,实现方案中的交互效果
2、将静态页面转换成动态页面,并完成与后端逻辑代码的集成
3、在技术负责人或者子系统负责人的指导下,完成WEB前端技术难点的攻关和结构的优化
UI
与PO沟通,基于需求完成线框制作、人机交互设计、效果图设计
UE
1、依据UI的设计方案,完成静态页面的实现
2、负责静态页面的浏览器兼容性测试
3、协助WEB前端工程师完成交互效果的实现
测试工程师
1、Review需求分析师输出的需求,从测试的角度判断是否具备可测试性
2、编写测试用例
3、负责运营中心各子系统的测试工作(功能、性能、稳定等),对系统出厂的质量负责
4、跟进BUG的修复进展
5、定期分析BUG,输出测试报告,作为团队改进的数据输入
版本管理
1、负责SVN的管理,如:账号、权限、branche和tag的创建
2、明确版本号及输出版本的发布说明

数据的游戏:冰与火

我对数据挖掘和机器学习是新手,从去年7月份在Amazon才开始接触,而且还是因为工作需要被动接触的,以前都没有接触过,做的是需求预测机器学习相关的。后来,到了淘宝后,自己凭兴趣主动地做了几个月的和用户地址相关数据挖掘上的工作,有一些浅薄的心得。下面这篇文章主要是我做为一个新人仅从事数据方面技术不到10个月的一些心得,也许对你有用,也许很傻,不管怎么样,欢迎指教和讨论。
另外,注明一下,这篇文章的标题模仿了一个美剧《权力的游戏:冰与火之歌》。在数据的世界里,我们看到了很多很牛,很强大也很有趣的案例。但是,数据就像一个王座一样,像征着一种权力和征服,但登上去的路途一样令人胆颤

数据挖掘中的三种角色

在Amazon里从事机器学习的工作时,我注意到了Amazon玩数据的三种角色。

  • Data Analyzer:数据分析员。这类人的人主要是分析数据的,从数据中找到一些规则,并且为了数据模型的找不同场景的Training Data。另外,这些人也是把一些脏数据洗干净的的人。
  • Research Scientist:研究科学家。这种角色主要是根据不同的需求来建立数据模型的。他们把自己戏称为不近人间烟火的奇异性物种,就像《生活大爆炸》里的 那个Sheldon一样。这些人基本上玩的是数据上的科学
  • Software Developer :软件开发工程师。主要是把 Scientist 建立的数据模型给实现出来,交给Data Analyzer去玩。这些人通常更懂的各种机器学习的算法。

我相信其它公司的做数据挖掘或是机器学习的也就这三种工作,或者说这三种人,对于我来说,
 

  • 最有技术含量的是 Scientist,因为数据建模和抽取最有意义的向量,以及选取不同的方法都是这类人来决定的。这类人,我觉得在国内是找不到的。
  • 最苦逼,也最累,但也最重要的是Data Analyzer,他们的活也是这三个角色中最最最重要的(注意:我用了三个最)。因为,无论你的模型你的算法再怎么牛,在一堆烂数据上也只能干出一堆垃圾的活来。正所谓:Garbage In, Garbage Out !但是这个活是最脏最累的活,也是让人最容易退缩的活。
  • 最没技术含量的是Software Developer。现在国内很多玩数据的都以为算法最重要,并且,很多技术人员都在研究机器学习的算法。错了,最重要的是上面两个人,一个是苦逼地洗数据的Data Analyzer,另一个是真正懂得数据建模的Scientist!而像什么K-Means,K Nearest Neighbor,或是别的什么贝叶斯、回归、决策树、随机森林等这些玩法,都很成熟了,而且又不是人工智能,说白了,这些算法在机器学习和数据挖掘中,似乎就像Quick Sort之类的算法在软件设计中基本没什么技术含量。当然,我不是说算法不重要,我只想说这些算法在整个数据处理中是最不重要的。

数据的质量

目前所流行的Buzz Word——大数据是相当误导人的。在我眼中,数据不分大小,只分好坏。
在处理数据的过程中,我第一个感受最大的就是数据质量。下面我分几个案例来说明:

案例一:数据的标准

在Amazon里,所有的商品都有一个唯一的ID,叫ASIN——Amazon Single Identify Number,这个ID是用来标识商品的唯一性的(来自于条形码)。也就是说,无论是你把商品描述成什么样,只要ASIN一样,这就是完完全全一模一样的商品。
这样,就不像淘宝一样,当你搜索一个iPhone,你会出现一堆各种各样的iPhone,有的叫“超值iPhone”,有的叫“苹果iPhone”,有的叫“智能手机iPhone”,有的叫“iPhone 白色/黑色”……,这些同一个商品不同的描述是商家为了吸引用户。但是带来的问题有两点:
1)用户体验不好。以商品为中心的业务模型,对于消费者来说,体验明显好于以商家为中心的业务模型。
2)只要你不能正确读懂(识别)数据,你后面的什么算法,什么模型统统没用
所以,只要你玩数据,你就会发现,如果数据的标准没有建立起来,干什么都没用。数据标准是数据质量的第一道关卡,没这个玩意,你就什么也别玩了。所谓数据的标准,为数据做唯一标识只是其中最最基础的一步,数据的标准还单单只是这个,更重要的是把数据的标准抽象成数学向量,没有数学向量,后面也无法挖掘
所以,你会看到,洗数据的大量的工作就是在把杂乱无章的数据归并聚合,这就是在建立数据标准。这里面绝对少不了人肉的工作。无非就是:

  • 聪明的人在数据产生之前就定义好标准,并在数据产生之时就在干数据清洗的工作。
  • 一般的人是在数据产生并大量堆积之后,才来干这个事。

另外,说一下Amazon的ASIN,这个事从十多年前就开始了,我在Amazon的内网里看到的资料并没有说为什么搞了个这样一个ID,我倒觉得这并不是因为Amazon因为玩数据发现必需建议个商品ID,也许因为Amazon的业务模型就是设计成以“商品为中心”的。今天,这个ASIN依然有很多很多的问题,ASIN一样不能完全保证商品就是一样的,ASIN不一样也不代表商品不一样,不过90%以上的商品是保证的。Amazon有专门的团队Category Team,里面有很多业务人员天天都在拼命地在对ASIN的数据进行更正。

案例二:数据的准确

用户地址是我从事过数据分析的另一个事情。我还记得当时看到那数以亿计的用户地址的数据的那种兴奋。但是随后我就兴奋不起来了。因为地址是用户自己填写的,这里面有很多的坑,都不是很容易做的。
第一个是假/错地址,因为有的商家作弊或是用户做测试。所以地址是错的,

  • 比如,直接就输入“该地址不存在”,“13243234asdfasdi”之类的。这类的地址是可以被我的程序识别出来的。
  • 还有很难被我的程序所识别出来的。比如:“宇宙路地球小区”之类的。但这类地址可以被人识别出来。
  • 还有连人都识别不出来的,比如:“北京市东四环中路23号南航大厦5楼540室”,这个地址根本不存在。

第二个是真地址,但是因为用户写的不标准,所以很难处理,比如:

  • 缩写:“建国门外大街” 和 “建外大街”,“中国工商银行”和“工行”……
  • 错别字:“潮阳门”,“通慧河”……
  • 颠倒:“东四环中路朝阳公园” 和 “朝阳公园 (靠东四环)” ……
  • 别名:有的人写的是开发商的小区名“东恒国际”,有的则是写行政的地名“八里庄东里”……

这样的例子多得不能再多了。可见数据如果不准确,会增加你处理的难度。有个比喻非常好,玩数据的就像是在挖金矿一样,如果含金量高,那么,挖掘的难度就小,也就容易出效果,如果含金量低,那么挖掘的难度就大,效果就差
上面,我给了两个案例,旨在说明——
1)数据没有大小之分,只有含金量大的数据和垃圾量大的数据之分
2)数据清洗是一件多么重要的工作,这也是一件人肉工作量很大的工作。
所以,这个工作最好是在数据产生的时候就一点一滴的完成。
有一个观点:如果数据准确度在60%的时候,你干出来的事,一定会被用户骂!如果数据准确度在80%左右,那么用户会说,还不错!只有数据准确度到了90%的时候,用户才会觉得真牛B。但是从数据准确度从80%到90%要付出的成本要比60% 到 80%的付出大得多得多。大多数据的数据挖掘团队都会止步于70%这个地方。因为,再往后,这就是一件相当累的活。

数据的业务场景

我不知道有多少数据挖掘团队真正意识到了业务场景和数据挖掘的重要关系?我们需要知道,根本不可能做出能够满足所有业务的数据挖掘和分析模型
推荐音乐视频,和电子商务中的推荐商品的场景完全不一样。电商中,只要你买了一个东西没有退货,那么,有很大的概率我可以相信你是喜欢这个东西的,然后,对于音乐和视频,你完全不能通过用户听了这首歌或是看了这个视频就武断地觉得用户是喜欢这首歌和这个视频的,所以,我们可以看到,推荐算法在不同的业务场景下的实现难度也完全不一样。
说到推荐算法,你是不是和我一样,有时候会对推荐有一种感觉——推荐就是一种按不同维度的排序的算法。我个人以为,就提一下推荐这个东西在某些业务场景下是比较Tricky的,比如,推荐有两种(不是按用户关系和按物品关系这两种),

  • 一种是共性化推荐,结果就是推荐了流行的东西,这也许是好 的,但这也许会是用户已知的东西,比如,到了北京,我想找个饭馆,你总是给我推荐烤鸭,我想去个地方,你总是给我推荐天安门故宫天坛(因为大多数人来北京就是吃烤鸭,就是去天安门的),这些我不都知道了嘛,还要你来推荐?另外,共性化的东西通常是可以被水军刷的。
  • 另一种是一种是个性化推荐,这个需要分析用户的个体喜好,好的就是总是给我我喜欢的,不好的就是也许我的口味会随我的年龄和环境所改变,而且,总是推荐符合用户口味的,不能帮用户发掘新鲜点。比如,我喜欢吃辣的,你总是给我推荐川菜和湘菜,时间长了我也会觉得烦的。

推荐有时并不是民主投票,而是专业用户或资深玩家的建议;推荐有时并不是推荐流行的,而是推荐新鲜而我不知道的。你可以看到,不同的业务场景,不同的产品形态下的玩法可能完全不一样,
另外,就算是对于同一个电子商务来说,书、手机 和服装的业务形态完全不一样。我之前在Amazon做Demand Forecasting(用户需求预测)——通过历史数据来预测用户未来的需求。

  • 对于书、手机、家电这些东西,在Amazon里叫Hard Line的产品,你可以认为是“标品”(但也不一定),预测是比较准的,甚至可以预测到相关的产品属性的需求。
  • 但是地于服装这样的叫Soft Line的产品,Amazon干了十多年都没有办法预测得很好,因为这类东西受到的干扰因素太多了,比如:用户的对颜色款式的喜好,穿上去合不合身,爱人朋友喜不喜欢…… 这类的东西太容易变了,买得人多了反而会卖不好,所以根本没法预测好,更别Stock/Vender Manager 提出来的“预测某品牌的某种颜色的衣服或鞋子”。

对于需求的预测,我发现,长期在这个行业中打拼的人的预测是最准的,什么机器学习都是浮云。机器学习只有在你要面对的是成千上万种不同商品和品类的时候才会有意义。
数据挖掘不是人工智能,而且差得还太远。不要觉得数据挖掘什么事都能干,找到一个合适的业务场景和产品形态,比什么都重要

数据的分析结果

我看到很多的玩大数据的,基本上干的是数据统计的事,从多个不同的维度来统计数据的表现。最简单最常见的统计就是像网站统计这样的事。比如:PV是多少,UV是多少,来路是哪里,浏览器、操作系统、地理、搜索引擎的分布,等等,等等。
唠叨一句,千万不要以为,你一天有十几个T的日志就是数据了,也不要以为你会用Hadoop/MapReduce分析一下日志,这就是数据挖掘了,说得难听一点,你在做的只不过是一个统计的工作。那几个T的Raw Data,基本上来说没什么意义,只能叫日志,连数据都算不上,只有你统计出来的这些数据才是有点意义的,才能叫数据。
当一个用户在面对着自己网店的数据的时候,比如:每千人有5个人下单,有65%的访客是男的,18-24岁的人群有30%,等等。甚至你给出了,你打败了40%同类型商家的这样的数据。作为一个商户,面对这些数据时,大多数人的表现是完全不知道自己能干什么?是把网站改得更男性一点,还是让年轻人更喜欢一点?完全不知道所措。
只要你去看一看,你会发现,好些好些的数据分析出来的结果,看上去似乎不错,但是其实完全不知道下一步该干什么?
所以,我觉得,数据分析的结果并不仅仅只是把数据呈现出来,而更应该关注的是通过这些数据后面可以干什么?如果看了数据分析的结果后并不知道可以干什么,那么这个数据分析是失败的。

总结

综上所述,下面是我觉得数据挖掘或机器学习最重要的东西:
1)数据的质量。分为数据的标准和数据的准确。数据中的杂音要尽量地排除掉。为了数据的质量,大量人肉的工作少不了。
2)数据的业务场景。我们不可能做所有场景下的来,所以,业务场景和产品形态很重要,我个人感觉业务场景越窄越好。
3)数据的分析结果,要让人能看得懂,知道接下来要干什么,而不是为了数据而数据。
搞数据挖掘的人很多,但成功的案例却不多(相比起大量的尝试来说),就目前而言,我似乎觉得目前的数据挖掘的技术是一种过渡技术,还在摸索阶段。另外,好些数据挖掘的团队搞得业务不业务,技术不技术的,为其中的技术人员感到惋惜……
不好意思,我只给出了问题,没有建议,这也说明数据分析中有很多的机会……
最后,还要提的一个是“数据中的个人隐私问题”,这似乎就像那些有悖伦理的黑魔法一样,你要成功就得把自己变得黑暗。是的,数据就像一个王座一样,像征着一种权力和征服,但登上去的路途一样令人胆颤
转载自酷壳 – CoolShell.cn    http://coolshell.cn/articles/10192.html

jenkins中修改svn密码

在jenkins的“系统管理”界面里是找不到设置svn账号的入口的。
一是每个job可以自己设置svn的账号和密码。
另外还可以使用http://host:port/jenkins/scm/SubversionSCM/enterCredential(将host:port修改为真实ip)、端口,可以修改jenkins中缓存的svn的用户名和密码。 但这个方法效果未经测试。

jira工作日志中填写说明

工作日志只能修改剩余估算时间(Remaining Estimate)和花费时间(Time Spent),原估算时间(Original Estimate)不能修改。
剩余估算时间:以为整个时间是估算的,所以就是剩余估算时间;
花费时间:工作真正花费的时间,大于0的整数,不带单位就是分钟;
开始时间(Start Date)主要用于对日志进行排序,方便阅读;
jira 3.13.4-#354 提供了四种对 剩余估算时间和花费时间的处理方法,也就是 调整估算时间:
自动调整:这个选择 剩余估算时间=(原来的剩余估算时间- 花费时间),如果剩余估算时间小于0,用0代替;花费时间=(原来花费时间+本次花费时间)
Leave existing estimate of:这个选择 剩余估算时间不变,花费时间=(原来花费时间+本次花费时间)
设置剩余的估算时间 Y :这个选择,剩余估算时间=Y(输入值);花费时间=(原来花费时间+本次花费时间)
Reduce estimated time remaining by Y :剩余估算时间=(原剩余估算时间-Y(输入值));花费时间=(原来花费时间+本次花费时间)
备注的写法根据 调整估算时间 的不同,建议的写法也不同
选择1:第一种就是写清楚做了什么;
选择2:除了写清楚做了什么,还要写清楚为什么还要保持剩余时间不变;主要适用于碰到难题,折腾了一天,没有进展;
选择3:除了写清楚做了什么,还要写清楚为什么重新剩余估算时间,这是直接修改,相当于重新估算;这个主要用于项目内容的大范围变更;
选择4:除了写清楚做了什么,对这个工作原来为什么估计不足;因为花费时间不等于要减掉的估算时间,这个应该是最常使用的功能,属于正常的调整;
http://www.maming.com/2010/07/15/jira-create-work-log/

Hadoop map和reduce的个数

一般情况下,在输入源是文件的时候,一个task的map数量由splitSize来决定的,那么splitSize是由以下几个来决定的
goalSize = totalSize / mapred.map.tasks
inSize = max {mapred.min.split.size, minSplitSize}
splitSize = max (minSize, min(goalSize, dfs.block.size))
一个task的reduce数量,由partition决定。
在输入源是数据库的情况下,比如mysql,对于map的数量需要用户自己指定,比如
jobconf.set(“mapred.map.tasks.nums”,20);
如果数据源是HBase的话,map的数量就是该表对应的region数量。
map和reduce是hadoop的核心功能,hadoop正是通过多个map和reduce的并行运行来实现任务的分布式并行计算,从这个观点来看,如果将map和reduce的数量设置为1,那么用户的任务就没有并行执行,但是map和reduce的数量也不能过多,数量过多虽然可以提高任务并行度,但是太多的map和reduce也会导致整个hadoop框架因为过度的系统资源开销而使任务失败。所以用户在提交map/reduce作业时应该在一个合理的范围内,这样既可以增强系统负载匀衡,也可以降低任务失败的开销。
1 map的数量
map的数量通常是由hadoop集群的DFS块大小确定的,也就是输入文件的总块数,正常的map数量的并行规模大致是每一个Node是10~100个,对于CPU消耗较小的作业可以设置Map数量为300个左右,但是由于hadoop的没一个任务在初始化时需要一定的时间,因此比较合理的情况是每个map执行的时间至少超过1分钟。具体的数据分片是这样的,InputFormat在默认情况下会根据hadoop集群的DFS块大小进行分片,每一个分片会由一个map任务来进行处理,当然用户还是可以通过参数mapred.min.split.size参数在作业提交客户端进行自定义设置。还有一个重要参数就是mapred.map.tasks,这个参数设置的map数量仅仅是一个提示,只有当InputFormat 决定了map任务的个数比mapred.map.tasks值小时才起作用。同样,Map任务的个数也能通过使用JobConf 的conf.setNumMapTasks(int num)方法来手动地设置。这个方法能够用来增加map任务的个数,但是不能设定任务的个数小于Hadoop系统通过分割输入数据得到的值。当然为了提高集群的并发效率,可以设置一个默认的map数量,当用户的map数量较小或者比本身自动分割的值还小时可以使用一个相对交大的默认值,从而提高整体hadoop集群的效率。
2 reduece的数量
reduce在运行时往往需要从相关map端复制数据到reduce节点来处理,因此相比于map任务。reduce节点资源是相对比较缺少的,同时相对运行较慢,正确的reduce任务的个数应该是0.95或者1.75 *(节点数 ×mapred.tasktracker.tasks.maximum参数值)。如果任务数是节点个数的0.95倍,那么所有的reduce任务能够在 map任务的输出传输结束后同时开始运行。如果任务数是节点个数的1.75倍,那么高速的节点会在完成他们第一批reduce任务计算之后开始计算第二批 reduce任务,这样的情况更有利于负载均衡。同时需要注意增加reduce的数量虽然会增加系统的资源开销,但是可以改善负载匀衡,降低任务失败带来的负面影响。同样,Reduce任务也能够与 map任务一样,通过设定JobConf 的conf.setNumReduceTasks(int num)方法来增加任务个数。
3 reduce数量为0
有些作业不需要进行归约进行处理,那么就可以设置reduce的数量为0来进行处理,这种情况下用户的作业运行速度相对较高,map的输出会直接写入到 SetOutputPath(path)设置的输出目录,而不是作为中间结果写到本地。同时Hadoop框架在写入文件系统前并不对之进行排序。
http://blog.sina.com.cn/s/blog_4439f9310101bxss.html

hadoop客户端该如何配置

Hadoop集群主要是由三部分组成的:主节点、从节点和客户端,即master、slave和client。我们在搭建hadoop集群的时候通常只考虑了主节点和从节点的搭建,却忽略了客户端。当我们搭建完成后,我们在其中的一台机器上运行wordcount或者计算π时,实际上我们已经默认将一台主节点或者一台从节点当做客户端来使用了,但是,如果我想把客户端独立,该如何单独配置客户端呢?
答案其实很简单,只要在配置slave的时候,不要把客户端添加到slave里,即客户端和hadoop集群其他的节点配置是一摸一样的,但不参与运算
完整的hadoop集群搭建过程,请参考:《Hadoop集群搭建详细简明教程》

slave配置

slave配置

行存储和列存储比较–理解hbase的基础

目前大数据存储有两种方案可供选择:行存储和列存储。业界对两种存储方案有很多争持,集中焦点是:谁能够更有效地处理海量数据,且兼顾安全、可靠、完整性。从目前发展情况看,关系数据库已经不适应这种巨大的存储量和计算要求,基本是淘汰出局。在已知的几种大数据处理软件中,Hadoop的HBase采用列存储,MongoDB是文档型的行存储,Lexst是二进制型的行存储。在这里,我不讨论这些软件的技术和优缺点,只围绕机械磁盘的物理特质,分析行存储和列存储的存储特点,以及由此产生的一些问题和解决办法。
一.结构布局
行存储数据排列

行存储

行存储


列存储数据排列
列存储

列存储


表格的灰色背景部分表示行列结构,白色背景部分表示数据的物理分布,两种存储的数据都是从上至下,从左向右的排列。行是列的组合,行存储以一行记录为单位,列存储以列数据集合单位,或称列族(column family)。行存储的读写过程是一致的,都是从第一列开始,到最后一列结束。列存储的读取是列数据集中的一段或者全部数据,写入时,一行记录被拆分为多列,每一列数据追加到对应列的末尾处。
二. 对比
从上面表格可以看出,行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上,可以保证写入过程的成功或者失败,数据的完整性因此可以确定。列存储由于需要把一行记录拆分成单列保存,写入次数明显比行存储多,再加上磁头需要在盘片上移动和定位花费的时间,实际时间消耗会更大。所以,行存储在写入上占有很大的优势。
还有数据修改,这实际也是一次写入过程。不同的是,数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次,列存储是将磁盘定位到多个列上分别写入,这个过程仍是行存储的列数倍。所以,数据修改也是以行存储占优。 数据读取时,行存储通常将一行数据完全读出,如果只需要其中几列数据的情况,就会存在冗余列,出于缩短处理时间的考量,消除冗余列的过程通常是在内存中进行的。列存储每次读取的数据是集合的一段或者全部,如果读取多列时,就需要移动磁头,再次定位到下一列的位置继续读取。 再谈两种存储的数据分布。由于列存储的每一列数据类型是同质的,不存在二义性问题。比如说某列数据类型为整型(int),那么它的数据集合一定是整型数据。这种情况使数据解析变得十分容易。相比之下,行存储则要复杂得多,因为在一行记录中保存了多种类型的数据,数据解析需要在多种数据类型之间频繁转换,这个操作很消耗CPU,增加了解析的时间。所以,列存储的解析过程更有利于分析大数据。
三. 优化
显而易见,两种存储格式都有各自的优缺点:行存储的写入是一次性完成,消耗的时间比列存储少,并且能够保证数据的完整性,缺点是数据读取过程中会产生冗余数据,如果只有少量数据,此影响可以忽略;数量大可能会影响到数据的处理效率。列存储在写入效率、保证数据完整性上都不如行存储,它的优势是在读取过程,不会产生冗余数据,这对数据完整性要求不高的大数据处理领域,比如互联网,犹为重要。
改进集中在两方面:行存储读取过程中避免产生冗余数据,列存储提高读写效率。
如何改进它们的缺点,并保证优点呢?
行存储的改进:减少冗余数据首先是用户在定义数据时避免冗余列的产生;其次是优化数据存储记录结构,保证从磁盘读出的数据进入内存后,能够被快速分解,消除冗余列。要知道,目前市场上即使最低端CPU和内存的速度也比机械磁盘快上100-1000倍。如果用上高端的硬件配置,这个处理过程还要更快。
列存储的两点改进:1.在计算机上安装多块硬盘,以多线程并行的方式读写它们。多块硬盘并行工作可以减少磁盘读写竞用,这种方式对提高处理效率优势十分明显。缺点是需要更多的硬盘,这会增加投入成本,在大规模数据处理应用中是不小的数目,运营商需要认真考虑这个问题。2.对写过程中的数据完整性问题,可考虑在写入过程中加入类似关系数据库的“回滚”机制,当某一列发生写入失败时,此前写入的数据全部失效,同时加入散列码校验,进一步保证数据完整性。
这两种存储方案还有一个共同改进的地方:频繁的小量的数据写入对磁盘影响很大,更好的解决办法是将数据在内存中暂时保存并整理,达到一定数量后,一次性写入磁盘,这样消耗时间更少一些。目前机械磁盘的写入速度在20M-50M/秒之间,能够以批量的方式写入磁盘,效果也是不错的。
四. 总结
两种存储格式各自的特性都决定了它们不可能是完美的解决方案。 如果首要考虑是数据的完整性和可靠性,那么行存储是不二选择,列存储只有在增加磁盘并改进软件设计后才能接近这样的目标。如果以保存数据为主,行存储的写入性能比列存储高很多。在需要频繁读取单列集合数据的应用中,列存储是最合适的。如果每次读取多列,两个方案可酌情选择:采用行存储时,设计中应考虑减少或避免冗余列;若采用列存储方案,为保证读写入效率,每列数据尽可能分别保存到不同的磁盘上,多个线程并行读写各自的数据,这样避免了磁盘竞用的同时也提高了处理效率。 无论选择哪种方案,将同内容数据聚凑在一起都是必须的,这是减少磁头在磁盘上的移动,提高数据读取时间的有效办法。
行存储列存储

行存储列存储


http://www.infoq.com/cn/articles/bigdata-store-choose

Hadoop 2.0激活大数据应用开发

Hadoop生态系统还在不断演进。倒退几年,我们还仅仅把Hadoop看作是HDFS(分布式文件系统)、MapReduce(软件编程模型)以及一些元素(工具与API)的组合,它们逐渐成为了大数据的代名词。
然而上周在圣何塞举行的Hadoop峰会2013让我们意识到,Hadoop已经发生了本质上的变化。Hadoop 2.0登上历史舞台,随之而来的增强特性为我们带来了一套新的数据编程方式,尽管依然依附于Hadoop,但它已经为我们提供了打破Hadoop固有印象的可能。
在Hadoop 2.0中,新增强的功能虽然还是围绕HDFS以及相关组件,如HBase数据库、Hive数据仓库以及Knox安全网关等,但是最引人关注的还是2.0中的YARN组件。YARN的名称来自于字母缩写“Yet Another Resource Manager”,直译可以称为另一个资源管理器。利用YARN,用户可以完全放弃原有的MapReduce,通过与批处理完全不同的新的交互方式来运行Hadoop。
商业智能咨询顾问Colin White 指出,Hadoop 2.0的HDFS对架构进行了重新设计,从而消除了某些单点故障的隐患。这仅仅是开始,更关键的进步在于API层面。White表示:“具有革命性的变化来自于YARN,它使得我们可以使用另外一种文件系统,为环境添加更多的灵活性,这是企业级用户最想要的功能。”
事实上,很多用户已经在讨论在Hadoop中运行其他的文件系统,比如IBM的通用并行文件系统,或者用Lustre的文件系统进行高性能集群计算。而YARN的出现,使得MapReduce不再是必需品,而变成了一种选项。
  Gartner分析师Merv Adrian表示,“核心Hadoop”的概念在未来也许将不复存在,数据架构中类似可插拔的选项已经提上了Hadoop的议事日程,任何层面都不再是只提供唯一解决方案,万事皆有可能。
  Hadoop以及相关工具在近几年中层出不穷,Adrian向TechTarget记者表示,当Web应用开发者开始决定创建一个专有数据存储之后,他们往往会选择把它开源。
  Adrian说:“Hadoop社区是吸引创新的支点,但Gartner建议企业用户尽量使用商用版的Hadoop解决方案。免费下载的开源产品可以用来进行沙盒实验。”
  用Adrian的话来说,近些年来发生的最大变化是数据存储的“爆炸”,许多都跟NoSQL相关。人们开始质疑传统SQL数据模型存在的弊端,而Hadoop更像是一个大的帐篷,把包括NoSQL运动在内的所有数据相关变化全部包容在内。
  这一变化的原因包括三点:首先,大规模扩展的关系型数据库系统成本过于昂贵;其次,数据库Schema的限制往往成为创新的阻力;最后,关系型数据库不能很好地支持Web应用。
  现在,关注各种类型数据存储的架构师和开发者都能够在Hadoop生态系统中找到他们想要的。在Hadoop峰会上,关于新范式的热情是显而易见的,就如同几年前Java和AJAX一样。Java语言是新时代应用开发的起点,AJAX也同样。如今的Hadoop与AJAX很像,成为一个符号化的概念,而围绕它的技术或者编程语言才是实体。
  很重要的一个观点是,Hadoop社区在做的事情代表了数据管理的一个主要发展方向。这些有着奇奇怪怪名称的开源工具以及API将能够让开发者以更创新的方式开发大数据应用,而这在之前是难以实现的。
http://www.searchbi.com.cn/showcontent_74554.htm

数据分析的广阔前景

数据分析作为一个新的行业领域正在全球迅速发展,它开辟了人类获取知识的新途径。
目前,数据库技术、软件工具、各硬件设备飞速发展,在这些软硬件技术与设备的支持下,信息技术应用已在各行各业全面展开,尤其是对通信、互联网、金融等行业的发展
做出了巨大贡献,并且经过长期的应用积累大量丰富的数据。但大部分企业对其存储信息利用率极低。庞大的历史数据是否有价值?有何价值?是否可以综合利用分析?是否能够为领导决策提供参考依据?
回答是肯定的,数据分析这一项工作越来越受到领导层的重视,借助数据分析的各种工具从海量的历史数据中提取、挖掘对业务发展有价值的、潜在的知识,找出趋势,为决
策层的决策提供有力的依据,对产品或服务的发展方向起到积极作用,有力推动企业内部的科学化、信息化管理。
从20世纪90年代起,欧美国家开始大量培养数据分析师,直到现在,对数据分析师的需求仍然长盛不衰,而且还有扩展之势。根据美国劳工部预测,到2018年,数据分析师的
需求量将增长20%。就算你不是数据分析师,但数据分析技能也是未来必不可少的工作技能之一。
数据分析师如此抢手的原因何在呢?
一个简单的原因就是社会越发达,人们对数据的依赖就越多。无论政府决策还是公司运营,科学研究还是媒体宣传,都需要数据支持。那么,对数据有如此大的依赖,就必然导致对数据分析的大量需求。因此,将数据转化为知识、结论和规律,就是数据分析的作用和价值。
那数据究竟会庞大到什么地步呢?
据国际知名咨询公司估计,到2020年,全球每年产生的数据量将达到3500万亿GB,打个比方,就是用普通的DVD一张一张地摞起来,可以从地球摞两个堆一直到月球。
面对这样庞大的数据,数据分析师的职责就不仅仅是单纯的分析了,更重要的是与相关业务部门进行合作,将数据真正应用到业务中,根据实际的业务发展情况识别哪些数据可用,哪些不适用,而不是孤立地在“真空环境”下进行分析。这就要求数据分析师不仅具备洞察数据的能力,还要对相关业务的背景有深入的了解,明白客户或业务部门的需求,从而将数据信息化、可视化,最后转化为生产力,帮助企业获得利润。这就是整个数据“供应链”。当然数据分析师也需要理解这个“供应链”。
那怎样才能成为一名优秀的数据分析师呢?
学习数据分析需要时间和经验的积累,而不能一蹴而就。在工作中运用不同的分析方法对数据进行分析,并与业务部门同事积极沟通,加深自己对整个行业或研究内容的理解,相信在两到三年内,一个优秀的数据分析师就会诞生。

数据分析是什么

摘自《谁说菜鸟不会数据分析》,基础理论到哪里都是一样的,这里就没写个人心得了。只想强调一点:Hadoop可以作为数据分析的一种工具!
PS:如果你是一个研究hadoop的程序员的话,在你的心里一定是hadoop更重要,但是在数据分析这个领域,hadoop只是其中的一种工具,还有大量做数据分析的在使用其他工具。
数据分析是指用适当的统计分析方法对收集来的大量数据进行分析,将它们加以汇总、理解并消化,以求最大化地开发数据的功能,发挥数据的作用。数据分析是为了提取有用信息和形成结论而对数据加以详细研究和概括总结的过程。这里数据也称观测值,是通过实验、测量、观察、调查等方式获取的结果,常常以数量的形式展现出来。
数据分析的目的是把隐藏在一大批看似杂乱无章的数据背后的信息集中和提炼出来,总结出研究对象的内在规律。在实际工作当中,数据分析能够帮助管理者进行判断和决策,以便采取适当策略与行动。例如,如果企业的高层希望通过市场分析和研究,把握当前产品的市场动向,制订合理的产品研发和销售计划,就必须依赖数据分析才能完成。
在统计学领域,有些学者将数据分析划分为描述性数据分析、探索性数据分析以及验证性数据分析。其中,探索性数据分析侧重于在数据之中发现新的特征,而验证性数据分析则侧重于验证已有假设的真伪性。
从另一个角度看,描述性数据分析属于初级数据分析,常见的分析方法有对比分析法、平均分析法、交叉分析法等;而探索性数据分析以及验证性数据分析属于高级数据分析,常见的分析方法有相关分析、因子分析、回归分析等。我们日常学习和工作中涉及的数据分析方法主要是描述性数据分析,也就是大家常用的初级数据分析。