拿别人做的圆角模板，在非IE下好好地，到IE下就是变了形。原因是td中那个高度老是莫名其妙的有19px。
后来看到这篇文章:
http://dancewithnet.com/2007/07/26/ie6-height-bug/
在IE6中设置display:block的空容器一个较小高度时，如<p style="height:1px;"></p>，会发现其高度不能小于某个值，比如在字体大小为12px时这个值是15px，在浏览器默认字体大小时这个值为19px，你可以通过调整IE6中的“查看>字体大小”来观看这个高度的变化。解决方案：
- 设置font-size:0,但是这个容器的高度最小为2px,所以没有办法实现高度为1px的效果
- 在容器中增加内容或其他空标签，如 、<br />，并设置line-height:0,但该容器会存在一个和其父容器字体大小有关的外边距，这个问题在IE7中也会出现，
- 在容器中增加内容或其他空标签，同时设置font-size:0，line-height:0，
- 上述解决方案在某些字体下会有非常大难以预料的变化，如font-family:fixedsys;时
- 设置zoom:0.03，这个会受到font-size、font-family的影响而显示不同效果，并且在IE7下不可见，如
- 设置overflow:hidden，这是目前看到的最完美的解决方案
照此，我将样式设置为overflow:hidden
将td中的img改为td背景图片，//使用img就会撑大
在td中增加
增加样式line-height:0
这才解决问题。
Continue reading ie圆角,19px,挥之不去的最小高度
style="width: 858px; height: 363px">1 kB = 1024 B (kB - kilobajt) 千 1 MB = 1024 kB (MB - megabajt) 兆 1 GB = 1024 MB (GB - gigabajt) 吉 1 TB = 1024 GB (TB - terabajt) 太 1 PB = 1024 TB (PB - petabajt) 拍 1 EB = 1024 PB (EB - eksabajt) 艾 1 ZB = 1024 EB (ZB - zettabajt) 皆 1 YB = 1024 ZB (YB - jottabajt) 佑 1 BB = 1024 JB (BB - brontobajt)
Continue reading bit单位大小
按:
好文就得收藏,本文较为宏观的介绍了hadoop的历史，功能等。
版权声明：
写本文由leftnoteasy发布于http://leftnoteasy.cnblogs.com 本文可以被全部或者部分的使用，但请注明出处，如果有问题，可以联系wheeleast (at) gmail.com, 也可以加我的新浪微博：http://weibo.com/leftnoteasy
前言：
很久没有写写博客了，之前主要是换工作，耽误了很多的时间，让人也变得懒散，不想花大时间来写东西。另外就是也确实没有什么自己都觉得有意思的东西拿来写写，对一般的知识什么的，我比较倾向于往evernote上面记笔记。不过最近对于Hadoop看得比较多，对它的发展也比较关心，最近了解得越多，也就越相信Hadoop的未来，这里写一篇文章与大家分享分享，为什么我相信Hadoop一定是分布式计算的未来。
写在前面的话：
今天听同事分享了一篇很有意思的讲座，叫做"Why Map-Reduce Is Not The Solution To Your Big-Data Problem"(为什么Map-Reduce不是你的“大数据”问题的解决方案)。同事很牛，也分享了很多非常有价值的观点，不过他预言Map-Reduce将会在5年之内消失（而且还呼吁有做存储方面的牛人来预言一下，Hdfs将在5年之内消失），这个话题如果成立的话，让我这个目前在Hadoop工程师，感到无比的压力。这里不为了争个你死我活，只是谈谈自己的一些想法。另外由于这位同事的分享是内部进行的，这里就不透露分享中具体的内容了，只谈谈自己的观点。
（本文需要对Hadoop有一定的基础方可理解）
Hadoop为何物？
虽说Hadoop的名声很大，但是总还是有同学不太了解的，这里一笔带过一下。
Google分布式计算三驾马车：
Hadoop的创始源头在于当年Google发布的3篇文章，被称为Google的分布式计算三驾马车（Google还有很多很牛的文章，但是在分布式计算方面，应该这三篇的影响力最大了）：http://blog.sina.com.cn/s/blog_4ed630e801000bi3.html，链接的文章比我介绍得更清晰，当然最好还是看看原文了，这是做分布式系统、分布式计算的工程师必修课。
Google File System用来解决数据存储的问题，采用N多台廉价的电脑，使用冗余（也就是一份文件保存多份在不同的电脑之上）的方式，来取得读写速度与数据安全并存的结果。
Map-Reduce说穿了就是函数式编程，把所有的操作都分成两类，map与reduce，map用来将数据分成多份，分开处理，reduce将处理后的结果进行归并，得到最终的结果。但是在其中解决了容错性的问题。
BigTable是在分布式系统上存储结构化数据的一个解决方案，解决了巨大的Table的管理、负载均衡的问题。
Google就靠着这几样技术，在搜索引擎和广告方面取得了举世瞩目的成就。不过Google不是傻的，这三篇文章虽然都是干货，但是不是直接就可以用的。话说Google发表了这三篇文章后，在学术界引起了轩然大波，大家对这三样东西提起了浓厚的兴趣，都想着是不是可以实现一下，以为己用。
Doug Cutting：
Doug Cutting之前是一个非常有名的开源社区的人，创造了nutch与lucene（现在都是在Apache基金会下面的），nutch之前就实现了一个分布式的爬虫抓取系统。等Google的三驾马车发布后，Doug Cutting一看，挖靠这么厉害的技术，于是就实现了一个DFS(distributed file system)与Map-Reduce（大牛风范啊），集成进了Nutch，作为Nutch的一个子项目存在。那时，是2004年左右。
在互联网这个领域一直有这样的说法：
“如果老二无法战胜老大，那么就把老大赖以生存的东西开源吧”
当年与Google还是处在强烈竞争关系的Yahoo!于是招了Doug兄进来，把老大赖以生存的DFS与Map-Reduce开源了。开始了Hadoop的童年时期。差不多在2008年的时候，Hadoop才算逐渐成熟。
现在的Hadoop:
现在的Hadoop不仅是当年的老二Yahoo的专用产品了，从Hadoop长长的用户名单中，可以看到Facebook,可以看到Linkedin，可以看到Amazon，可以看到EMC, eBay，Tweeter，IBM, Microsoft, Apple, HP...(后面的一些未必是完全使用)。国内的公司有淘宝、百度等等。
我来定义一下Hadoop：
Hadoop是一套开源的、基础是Java的、目前能够让数千台普通、廉价的服务器组成一个稳定的、强大的集群，使其能够对pb级别的大数据进行存储、计算。已经具有了强大稳定的生态系统，也具有很多使用的延伸产品。比如做查询的Pig, 做分布式命名服务的ZooKeeper, 做数据库的Hive等等。
为什么世界上只有一个Hadoop？
我的前公司是国内某一个著名互联网公司的子公司，专注做云计算，我也在这个公司最兴盛的时候进入，当时宣传的口号是“做最好的云计算”，就是希望自己开发一套存储计算系统（就是类似于前面提到过的dfs与map-reduce），并且克服一些Hadoop的缺点（比如说用c++去实现，克服Java的一些性能问题）。后来结局可能大家也猜到了，投入了很多钱，招了不少牛人，确实也做出了还算不错的云计算（至少在国内是数一数二的）。但是最终不管从稳定性还是效率上还是scalable来说，都远远被Hadoop甩在了后面。虽然我前公司这个云计算项目是否会成功，这里没办法预测，但是前途终究还是比较黯淡的。
最近一年还听说国内不少的互联网巨头都成立了云计算部门，做“自己的”云计算，有些小得像创业时期一样的公司，都宁愿自己写一套map-reduce框架，不愿意直接使用Hadoop。可能这个跟国人的想法，武功秘笈一定要自己藏着，不让别人学，传男不传女。对别人白给你的东西，非常不放心，觉得大家都能学到的东西，肯定竞争力是不够的。
除开心态问题不谈，但从技术实力上来说，一般国内公司的核心开发团队的能力和当年的Yahoo!比，还是有非常大的差距的，至少像是Doug兄这样的大牛是很罕见的，从开发者的实力来说，就差了不止一个档次。
其次从积累来说，Hadoop从初创到现在也经过了至少7年的积累的，碰到过很多刁钻客户的问题都慢慢克服了（比如Facebook的超大数据存储），带给用户的经验教训是很充足的，比如说性能调优这一块，就有非常多的文章去介绍。而自己开发一个，什么都需要从头再来。
最后也是最重要的是，Hadoop形成了一个强大稳定的生态系统，里面有生产者（共享改进的代码、fix bug），也有消费者（使用项目并且反馈经验），Hadoop的用户也可以获得较大的经济利益（不花钱买软件，还可以增加效率）。对于一个开源社区来说，构建出一个完整的生态系统是非常非常的困难，一旦构造出来了，项目就会很稳定的往前去进步。
Hadoop的优势
之前分析了一些“虚”的东西，比如生态系统什么的，这里说说一些实际的东西。
Benchmark:
Hadoop现在保持了很多漂亮的记录：
存储：现在世界上最大的Hadoop集群目前在Facebook，可以存储30PB的数据
计算：Hadoop是目前Terasort记录的保持者（参见：http://sortbenchmark.org/)，Terasort是给出1TB的随机数据，看谁能够在最短的时间内完成排序，Hadoop使用了1400多个节点，在2分钟内完成1T的数据排序。
这里顺便说一下，之前给出网站里面有很多的benchmark，可以看到Hadoop的集群是最大的，使用的机器最多的，像是TritonSort这样的集群，使用了区区50多个节点，最终的结果并不比Hadoop差太多，但是这里得注意一下。TritonSort是专门用来做排序的，里面加入了相当多的优化，但是Hadoop是一个通用的集群，并没有为了一种任务进行如此多的优化。从用户的角度上来说，愿意花钱去买一个只会排序的电脑是意义不那么大的。
注：左右两边属于两种不同的terasort，hadoop是其中一种的记录保持者
能做什么？
前面说的基本的存储和计算Hadoop是一定能胜任的，下面谈谈一些“高级”的功能。
常见的数据库操作，比如orderby、select这样的操作都可以的，Hive就是支持这样的Sql模型，能够将Sql语句最终转化到Map-Reduce程序中去。其性能和可用性已经得到了证明，Facebook就用它做了不少的数据分析的工作
常见的机器学习、矩阵分析算法，目前Mahout作为一个发展迅速的项目，在逐渐填补Hadoop在机器学习领域的空白，现在常见的分类、聚类、推荐、主成分分析算法（比如SVD）都已经有相应的Map-Reduce实现了。虽然目前从用户群和效率上来说是不够的，但是从它的发展来说应该会很快的达到工业界的标准
Hadoop的劣势
现在Hadoop依然有很多的问题没有解决，这让有些人非常的怀疑Hadoop的未来，这里谈谈Hadoop的一些重要的劣势
HA(High Availability)高可用性:
这一点是Hadoop非常弱的一个缺点，不管是Hdfs还是Map-reduce，都是采用单master的方式，集群中的其他机器都是与一台中心机器进行通信，如果这个中心机器挂了，集群就只有不工作了（不一定数据会丢失，但是至少需要重启等等工作)，让可用性变得更低。这个一般叫做单点失败(single point of failure,SPOF)。
虽然现在有些公司已经给出了解决方案，比如EMC就有用Vmware搭建虚拟集群，对master节点进行镜像备份，如果master挂掉，那么立刻换上镜像备份的机器，使其可用性变高，不过这个终究不是一个内置的解决方案，而且Vmware这一套东西也并不便宜。
不过之后这个问题将会得到非常好的解决，我在Hadoop的未来这一章将说以说。
Hadoop目前解决得不那么好的一些算法：
Join等:
Map-Reduce还有一个问题是，对于Join这个最常见的数据库操作，支持力度还是不够，特别是针对那种上TB的数据，Join将会很不给力，现在已经有了一些解决方案，比如说SIGMOD'2010的这篇文章：
A Comparison of Join Algorithms for Log Processing in MapReduce
不过在现在的情况下，只有尽量的避免大数据库的Join操作
需要进行很多轮迭代、循环的算法：
对于循环，Map-Reduce稍好，比如矩阵计算，高斯消元法这样的，循环的次数的确定的算法，实现起来还是不难，只是有点慢。但是迭代就更麻烦了，因为现在的Map-Reduce的mapper和reducer是不太方便去弄这样的终止条件。
还有就是迭代次数超多的算法（比如说矩阵的SVD分解），在超大矩阵的情况下，迭代次数可能会上亿次。而Map-Reduce在每次迭代的时候都会把数据往文件里面读写一遍，这样的浪费的时间是巨大的。
其实Map-Reduce不是绝对没有办法去解决这些问题，而只是现在这个还不是最重要的日程，Hadoop还有很多很多的东西可以优化，比如说前面提到的HA，这些东西只有往后放放，我将在之后的Hadoop的未来部分，谈谈未来版的Hadoop怎么去解决这些问题。
编程复杂，学习曲线陡峭：
对于一般的map-reduce框架，hello world程序就变成了word count，就是给出一堆的文本文件，最终统计出里面每一个不同的单词出现的次数，这样一个简单的任务（可能在linux shell下一行就写出来了），在Map-reduce中需要几十行，一般新人从理解word count到写出自己的word count，到跑通，一个星期是肯定需要的。这样陡峭的学习曲线让许多人难以深入。
另外还有一点Hadoop被人所诟病的是，代码丑陋，虽然Hadoop是用高级语言Java写成的，但是里面对每一个步骤都要分成mapper和reducer，这个被戏称为新时代的汇编语言。
一般来说，做数据分析的人程序都写得不咋地（强哥这样的达人除外），能写写matlab，R，或者spss就差不多了，如果要让他们去写map-reduce，那就等于叫他们别干活了。而大数据的重要的作用就是用来做数据分析，Hadoop的未来发展必须得抓住这群数据分析师的心。
其实现在已经有一些实验中的产品，让用户可以用高级语言编程，不会再看到丑丑的map-reduce了。我在前公司的时候就与团队一起做了还不错的尝试，至少，数据分析师可以用Python来编程了。map-reduce变成了一个底层的东西，现在不是某些人在分析性能的时候就贴上汇编代码吗，之后可能会变成在前段的程序效率不行的时候，就贴上后端Java的map-reduce程序。
所以对这个难题之后肯定会解决掉，底层分布式程序开发与用户将被清楚的分开，之后想要写word-count一定会像hello world一样简单。
Hadoop的未来怎么样？
http://www.slideshare.net/hortonworks/apache-hadoop-023 (hadoop 0.23)
给出这样的一个官方文档，谈谈之后的hadoop的发展。目前的hadoop的稳定版是0.20.x，这个0.23是个未来版，估计将在今年的Q4进行beta的发布（目前看起来，至少代码是写了很多了） 。
HDFS Federation
首先是一个叫做HDFS Federation的东西，它将hdfs的命名空间进行了扩展，目前的HDFS的所有文件的meta信息都保存在一台机器的内存中，使得HDFS支持的文件数目是有限的，现在进行了这样改动后，将hdfs的命名空间做成了分布式的，对之后方便对不同的用户文件夹进行管理，还有从HDFS的实现上来说，都会更为简单。
下一代的Map-Reduce：
节点数：从目前的4000增加到6000-10000台
并发的任务数:从目前的40000增加到100000
更高级的硬件支持，目前支持的硬件主要是8core, 16G ram, 4T disk, 之后将会支持16+core, 48/96G ram, 24/48T disk
架构的改变，对现在的JobTracker-TaskTracker的结构做了很大的改进，现在会用ZooKeeper去保存master的状态，避免了之前提到的SPOF
更多的编程模式的支持（这个很重要）
比如MPI，迭代程序的处理，并且在Hadoop中运行这些类型的编程模式，并且这些程序将会被Hadoop统一管理
总结：
之前谈了Hadoop的优势、劣势等等，综合来说就是，优势是很明显的（比如这么多牛公司在用，并且也贡献了很多的代码），远远超出了其他的分布式系统，劣势虽然不小，但是改进这些不足的地方是在计划中，已经在实施了。而且Hadoop不仅在学术界或者是工业界，都有很高的地位，综合了这些天时地利人和，那前途还是非常光明的
Continue reading 【转】为什么Hadoop将一定会是分布式计算的未来？
