最流行之大数据框架。
HADOOP 优缺点：
1. HADOOP 因其并行性架构，大大方便了分布式并行处理。 但是其缺陷也是明显的。
2. 非实时，非流式和离线：map-reduce计算模型适用于批处理任务，即在可接受的时间内对整个数据集计算某个特定的查询的结果，该计算模型不适合需要实时反映数据变化状态的计算环境。
3. 行与行间逻辑性差、相互间比较独立、数据处理逻辑比较对等：map-reduce计算模型是以“行”为处理单位的，无法回溯已处理过的“行”，故每行日志都必须是一个独立的语义单元，行与行之间不能有语义上的关联。 所以不支持迭代。很难支持ML，NLP，prediction 相关的运算。
4. 半结构化或者无结构化数据：相对于传统的关系型数据库管理系统，Map-Reduce计算模型更适合于处理半结构化或无结构话的数据。
5. 数据属性可以不固定： 因为Map-Reduce计算模型是在处理的时候对数据进行解释的，这就意味着输入的Key和Value可以不是数据本身固有的属性，Key、Value的选择完全取决于分析数据的人
6. 线性扩展模型：Map-Reduce是一个线性可扩展模型，服务器越多，处理时间越短。
7. map/reduce 有很多独立的元素组成，map操作是高度并行的，特别适合原来的grep, sed, sort, uniq 等脚本完成的事情，当然也包括访问日志分析，倒排索引，文档聚类等。所以不适合那些串行的逻辑。
8. 软件运行还不太稳定。
9. Hadoop必须将数据限制在一个物理数据中心。尽管Hadoop为批处理系统，但是它们还是被紧密耦合在一起。同时，在Hadoop集群的服务器中，它们无法接受超过数毫秒的延迟。 facebook通过Prism项目，系统增加了一个逻辑抽象层，因此Hadoop集群能够跨多个数据中心运行，从而有效地提升了容量方面的限制量级。 Facebook近期宣布，该公司目前拥有全球最大的Hadoop集群，数据容量达到了100拍字节。在原生Hadoop容量方面，Facebook已经达到了它们的最高上限，数据容量达到了100拍字节。不过，Facebook也表示这还不够大。Prism项目将把Hadoop的容量推向一个新高度。
http://sec.chinabyte.com/249/12600749.shtml
1、Hadoop不是专为企业数据而生
像许多开拓性的IT技术(如TCP / IP或Unix)一样，,Hadoop的概念并非来自企业用户，企业安全更是无从谈起。使用Hadoop的最初目的是管理公开可用的信息，,如Web链接。其是针对大量的非结构化数据在分布式计算环境中设计的，并没有形成书面的安全、合规、加密、政策支持和风险管理等协议。
2、Hadoop的安全完全依赖Kerberos
Hadoop使用Kerberos进行身份验证。然而,该协议却可能很难实现,因为其并没有涵盖企业在安全方面的需求,比如基于角色的验证、LDAP和活动目录的政策支持等。Hadoop还不能支持节点与节点之间的传输数据的加密。
3、Hadoop集群包含很多节点
传统的数据安全技术的概念是建立在保护一个物理实体(如数据库或服务器)基础之上，这与Hadoop集群独特的大数据分布式计算环境有所不同。传统的安全技术在这种分布式的、大规模的环境中不能有效发挥作用。
4、在Hadoop环境中，传统的备份及灾难恢复数据并不相同
Hadoop集群的分布式特性也使得许多传统的备份及恢复方法和政策无效。如果用户使用Hadoop，则需要将数据复制、备份、存储在一个单独的、安全的环境中。
5、Hadoop很少能够单独运行
为了获得好处的大数据处理结果，Hadoop需要结合使用其他技术。虽然这些工具能够帮助处理大数据的访问和使用,但其大多数也缺乏真正的企业级安全。强化Hadoop本身，只是应对大数据安全挑战的一个部分而已。
6、大数据的工作负载遵从统一规则
大数据没有附带单独的管理规定和要求。不管它用于存储还是管理数据，企业组织必须要建立符合监管要求的数据保护和安全政策，如HIPAA、PCI等。但在此基础上，传统安全技术仍不能完全解决大数据环境下的挑战。
7、维护成本不确定
到目前为止，还没有人能够确定一个安全漏洞未企业带来多大的风险成本。没有全面的安全风险评估，企业将无法评估其安全弱点，也无法确定其在安全保障方面投入了多少资金。
8、大数据用户凭自己的力量维护安全
目前，企业用户关于维护Hadoop集群安全的做法包括对外部访问的控制，以及限制允许访问集群的人员数量等。
9、保护数据集群需要额外的步骤
Hadoop环境下的漏洞仍旧存在的话，那维护数据安全的额外步骤就必不可少。用户必须定期扫描他们的集群环境，以发现其脆弱点。这也是在复制和备份数据的同时将其存储在一个单独的安全环境中的最佳实践。
10、Hadoop用户必须时刻保持更新
HADOOP性能
Hadoop会将Job的输入文件分割成64M固定大小的split，每个split启动一个maptask处理，这个split中的每个record都经过用户定义的map函数处理生成中间结果。若输入文件小于64M，则此文件单独作为一个split处理。故当输入文件中有大量的小文件时，那么管理这些小文件的开销以及maptask的创建开销会占据绝大多数的Job执行时间。
为了找到Hadoop合适的Job文件大小，我们在一个有50台退役机器组成的集群做了一组性能测试，结果如下表：
我们把一个任务的计算时间分为两部分：reduceshuffletime和reducetime. reduceshuffletime是reduce任务把map输出的<key，value>对copy到本地的时间，即reduceshuffletime=map时间+<key，value>对网络传输时间。reducetime就是rudece处理这些<key，value>对的时间。 各个任务的reduceshuffletime是完全线性的（随着任务量增加，时间线性增加）.上面两个时间的叠加影响下，在300G以内退役机器处理任务的时间是线性增加的。300G以上的任务需要分成若干个小任务串行运行，保证reduce处理在线性可控的区间内。
取决于文件的大小和数量，处理的复杂度以及群集机器的数量，相连的带宽，当以上四者并不大时，hadoop优势并不明显。比如，不用hadoop用java写的简单grep函数处理100M的log文件只要4秒，用了hadoop local的方式运行是14秒，用了hadoop单机集群的方式是30秒，用双机集群10M网口的话更慢，慢到不好意思说出来的地步。
//如果你的数据不够大，千万别用HADOOP。
http://blog.csdn.net/hguisu/article/details/12585383
MAP/REDUCE 之Merge/Combiner, shuffle过程
http://blog.sina.com.cn/s/blog_4e9440910100y97n.html
http://cyberaide.googlecode.com/svn/trunk/misc/cloud-papers/MapReduceMerge.pdf
map/reduce 例子
http://www.cnblogs.com/xia520pi/archive/2012/06/04/2534533.html
HADOOP 性能调优
map/reduce shuffle过程
http://langyu.iteye.com/blog/992916
Hadoop的map任务和reduce任务之间有个shuffle的过程。 shuffle就是combine,partition,combine的组合。
1. 一旦内存达到某个阀值，那么就要把数据spill到硬盘中，那么会涉及sort, merge, combine和partition过程。
2. 是map端的combine，是在map本地把同key的放在一起成列表
3. 是 map端的partition分割，把键值对按照key对应分配到reduce
4. 是reduce端的combine，把同key的再合并得到最后的reduce输入
调优
1. 内存使用阀值 到80%就 spill. 默认当 缓存的使用量达到80%(或0.8)的时候就开始写入磁盘,这个过程叫做spill(也叫做磁盘溢出),进行spill的缓存大小可以通过io.sort.spill.percent 参数调整
2. Merge 的spill到硬盘中的文件个数。 io.sort.factor参数指定。
3. reduce 运行阶段分为shuflle： copy， sort， reduce。 ,由于map任务数很多,所有这个copy过程是并行的,既同时有许多个reduce取拷贝map.这个并行 的线程是通过mapred.reduce.parallel.copies 参数指定的默认为5个,也就是说无论map的任务数是多少个。
1688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
