你好，我是李智慧。专栏的模块一已经更新完毕，按照计划，今天是我们答疑的时间。首先要感谢订阅专栏的同学给我留言，每条留言我都看过了，有些留言对我的启发也很大，希望同学们可以多多跟我互动。我在每个模块都设置了一个答疑的主题，想跟你聊聊我在学习这个模块时的心得体会。另外，我也会贴出一些同学的疑问，跟你聊聊我的想法。
今天的主题是：我们能从Hadoop学到什么？
最近几年，我跟很多创业者交流，发现创业最艰难的地方，莫过于创业项目难以实现商业价值。很多时候技术实现了、产品做好了，然后千辛万苦做运营，各种补贴、各种宣传，但是用户就是不买账，活跃差、留存低。
很多时候，我们不是不够努力，可是如果方向错了，再多努力似乎也没有用。阿里有句话说的是“方向对了，路就不怕远”，雷军也说过“不要用你战术上的勤奋，掩盖你战略上的懒惰”。这两句话都是说，要找好方向、找准机会，不要为了努力而努力，要为了目标和价值而努力。而王兴则更加直言不讳：“很多人为了放弃思考，什么事情都干得出来”。
说了那么多，我们再回过来看看Hadoop的成长历程。从2004年Google发表论文，到2008年Hadoop成为Apache的开源项目，历时4年。当时世界上那么多搜索引擎公司似乎都对这件事熟视无睹，Yahoo、百度、搜狐（是的，搜狐曾经是一家搜索引擎公司），都任由这个机会流失。只有Doug Cutting把握住机会，做出了Hadoop，开创了大数据行业，甚至引领了一个时代。
所以，我们能从Hadoop中学到的第一个经验就是识别机会、把握机会。有的时候，你不需要多么天才的思考力，也不需要超越众人去预见未来，你只需要当机会到来的时候，能够敏感地意识到机会，全力以赴付出你的才智和努力，就可以脱颖而出了。
结合大数据来说，虽然大数据技术已经成熟，但是和各种应用场景的结合正方兴未艾，如果你能看到大数据和你所在领域结合的机会，也许你就找到了一次出人头地的机会。
另一方面，你看一下Hadoop几个主要产品的架构设计，就会发现它们都有相似性，都是一主多从的架构方案。HDFS，一个NameNode，多个DataNode；MapReduce 1，一个JobTracker，多个TaskTracker；Yarn，一个ResourceManager，多个NodeManager。
事实上，很多大数据产品都是这样的架构方案：Storm，一个Nimbus，多个Supervisor；Spark，一个Master，多个Slave。
大数据因为要对数据和计算任务进行统一管理，所以和互联网在线应用不同，需要一个全局管理者。而在线应用因为每个用户请求都是独立的，而且为了高性能和便于集群伸缩，会尽量避免有全局管理者。
所以我们从Hadoop中可以学到大数据领域的一个架构模式，也就是集中管理，分布存储与计算。我在思考题里提出如何利用个人设备构建一个存储共享的应用，很多同学也都提到了类似的架构方案。
最后我想说，使用Hadoop，要先了解Hadoop、学习Hadoop、掌握Hadoop，要做工具的主人，而不是工具的奴隶，不能每天被工具的各种问题牵着走。最终的目标是要超越Hadoop，打造适合自己业务场景的大数据解决方案。
正好提到了每期文章后留给你的思考题，在这里也分享一下我是如何设置思考题的。
关于思考题，你会发现，我留的思考题很多都是和当期内容没有直接关联的，甚至和大数据无关的。它们或是相似的问题场景，或是有类似的解决思路，或是引申的一些场景。
其实我是希望你在学习大数据的时候，不要仅局限在大数据技术这个领域，能够用更开阔的视野和角度去看待大数据、去理解大数据。这样一方面可以更好地学习大数据技术本身，另一方面也可以把以前的知识都融会贯通起来。
计算机知识更新迭代非常快速，如果你只是什么技术新就学什么，或者什么热门学什么，就会处于一种永远在学习，永远都学不完的境地。前一阵子有个闹得沸沸扬扬的事件，有个程序员到GitHub上给一个国外的开源软件提了个Issue“不要再更新了，老子学不动了”，就是一个典型例子。
如果这些知识点对于你而言都是孤立的，新知识真的就是新的知识，你无法触类旁通，无法利用过往的知识体系去快速理解这些新知识，进而掌握这些新知识。你不但学得累，就算学完了，忘得也快。
所以不要纠结在仅仅学习一些新的技术和知识点上了，构建起你的知识和思维体系，不管任何新技术出现，都能够快速容纳到你的知识和思维体系里面。这样你非但不会惧怕新技术、新知识，反而会更加渴望，因为你需要这些新知识让你的知识和思维体系更加完善。
关于学习新知识我有一点心得体会想与你分享。我在学习新知识的时候会遵循一个5-20-2法则，用5分钟的时间了解这个新知识的特点、应用场景、要解决的问题；用20分钟理解它的主要设计原理、核心思想和思路；再花2个小时看关键的设计细节，尝试使用或者做一个demo。
如果5分钟不能搞懂它要解决的问题，我就会放弃；20分钟没有理解它的设计思路，我也会放弃；2个小时还上不了手，我也会放一放。你相信我，一种真正有价值的好技术，你这次放弃了，它过一阵子还会换一种方式继续出现在你面前。这个时候，你再尝试用5-20-2法则去学习它，也许就能理解了。我学Hadoop实际上就是经历了好几次这样的过程，才终于入门。而有些技术，当时我放弃了，它们再也没有出现在我面前，后来它们被历史淘汰了，我也没有浪费自己的时间。
还有的时候，你学一样新技术却苦苦不能入门，可能仅仅就是因为你看的文章、书籍本身写得糟糕，或者作者写法跟你的思维方式不对路而已，并不代表这个技术有多难，更不代表你的能力有问题，如果换个方式、换个时间、换篇文章重新再看，可能就豁然开朗了。
接下来我们看一下同学们的具体问题。
我的判断是大数据与业务的结合，在每个垂直领域、每个垂直领域的细分领域，将大数据和业务场景结合起来，利用大数据发现新的业务增长点。
对技术人员而言，其实挑战更高了，一方面要掌握大数据的知识，这正是专栏想要输出的；另一方面，要掌握业务知识，甚至得成为业务领域的专家，能发现业务中可以和大数据结合的点，利用大数据和业务结合构建起技术驱动业务的增长点，这需要你在业务中有敏锐的观察力和领悟力。
实时计算的结果一般通过两种方式输出，一个是写入到数据库里，和离线计算的结果组成全量数据供业务使用；一个是通过Kafka之类的实时队列给业务，比如你提到的监控展示。关于大数据怎么和业务结合，我会在专栏第四模块与你讨论，请继续关注。
事实上并不会慢，影响文件读写速度的是磁盘的速度。同样的数据量、同样类型的磁盘，HDFS可以将数据分布在更多的服务器和磁盘上，肯定比单机上的几块磁盘速度更快。
HDFS常用的使用方式是结合MapReduce或者Spark这样的大数据计算框架进行计算，这些计算框架会在集群中启动很多的分布式计算进程同时对HDFS上的数据进行读写操作，数据读写的速度是非常快的，甚至能支撑起Impala这样的准实时计算引擎。
我在专栏第8期留了一个思考题，我看了大家的留言，发现很多同学可能没有意识到互联网处理一个请求的复杂性，这里我来谈谈我的理解。
这个思考题其实并不简单，考察的是一个典型的互联网应用，比如淘宝的架构是怎样的。简化描述下，这个过程是：
首先，一个请求从Web或者移动App上发起，请求的URL是用域名标识的，比如taobao.com这样，而HTTP网络通信需要得到IP地址才能建立连接，所以先要进行域名解析，访问域名解析服务器DNS，得到域名的IP地址。
得到的这个IP地址其实也不是淘宝的服务器的IP地址，而是CDN服务器的IP地址，CDN服务器提供距离用户最近的静态资源缓存服务，比如图片、JS、CSS这些。如果CDN有请求需要的资源就直接返回，如果没有，再把请求转发给真正的淘宝数据中心服务器。
请求到达数据中心后，首先处理请求的是负载均衡服务器，它会把这个请求分发给下面的某台具体服务器处理。
这台具体的服务器通常是反向代理服务器，这里同样缓存着大量的静态资源，淘宝也会把一些通常是动态资源的数据，比如我们购物时经常访问的商品详情页，把整个页面缓存在这里，如果请求的数据在反向代理服务器，就返回；如果没有，请求将发给下一级的负载均衡服务器。
这一级的负载均衡服务器负责应用服务器的负载均衡，将请求分发给下面某个具体应用服务器处理，淘宝是用Java开发的，也就是分发被某个Java Web容器处理。事实上，淘宝在Java Web容器之前，还前置了一台Nginx服务器，做一些前置处理。
应用服务器根据请求，调用后面的微服务进行逻辑处理。如果是一个写操作请求，比如下单请求，应用服务器和微服务之间通过消息队列进行异步操作，避免对后面的数据库造成太大的负载压力。
微服务如果在处理过程中需要读取数据，会去缓存服务器查找，如果没有找到，就去数据库查找，或者NoSQL数据库，甚至用搜索引擎查找，得到数据后，进行相关计算，将结果返回给应用服务器。
应用服务器将结果包装成前端需要的格式后继续返回，经过前面的访问通道，最后到达用户发起请求的地方，完成一次互联网请求的旅程。如果用架构图表示的话，就是下面的样子。
这张图来自我写的《大型网站技术架构：核心原理与案例分析》一书，对互联网实时业务处理感兴趣的同学，欢迎阅读这本书。大数据的数据来源最主要的就是网站数据，了解网站架构对学习大数据、用好大数据也很有帮助。
最后，我在今天的文章里贴了陈晨、虎虎、您的好友William、lyshrine、不求、Panmax、wmg、西贝木土的留言，我认为是比较精彩很有深度的，也把它们分享给你，希望其他同学的思考也能对你有所启发，也欢迎你给我留言与我一起讨论。
精选留言
2018-11-20 22:08:14
2019-01-08 15:25:31
随着互联网信息产业的发展，网络上时刻产生的数据以及沉淀的历史数据量规模呈爆炸式增长，而计算机硬件诸如CPU、内存等性能的增长速度远远跟不上数据的增长速度，因此传统的单机处理程序已经无法满足数据的处理需求。分布式处理系统应运而生，这是大数据系统的前身。
大数据系统主要处理大规模（一般指PB级别的数据量）的动态和存量数据，通过大量数据的读取和分析，能够从中找出人们从未关注到的甚至没有想到的 事物之间的关联关系，并以此为人们日常生活以及各种生产活动提供必需的决策支持。
对于大数据系统的运作原理，我想从一个设计者的角度来思考：
要清晰的知道，不论大数据系统功能多么强大，性能多么NB，体系如何庞杂，它本质上依然和传统软件的运作模型是一样的：I-P-O，没错，就是输入-计算-输出。以MapReduce为例，输入就是各taskStracker在本地各自读取数据分片；而计算过程有2大的步骤：1是map进程阶段将原始数据进行初步合并计算，并将得出的结果发给reduce进程，我把这个过程称为预处理，预处理后的数据量会降低到网络可以承受的地步；2是reduce收到map传来的预处理数据，并进行最终合并计算；输出部分:reduce进程将最终计算的结果保存到HDFS（本地数据块），并由HDFS将所有reduce保存的数据块合并成一个HDFS文件。你看，这个过程是不是就是一个IPO过程？只不过每个具体过程的执行者以及数量发生了改变。
OK，弄清楚了基本运作模型，接下来就是考虑：针对大规模数据分散存储（先不考虑实时数据哈）在大量服务器上的数据存储背景，如何设计一款软件，能够高效读取、处理这些数据，并有效输出呢？
首先是数据读写。现在大家都清楚，在数据规模达到PB级别的情况下，如果使用集中读取，集中处理的方式，单机的硬件和网络根本承载不了。所以最好的办法就是让数据所在的服务器自行读取本地数据并进行计算，然后将每个服务器计算结果汇总后在写入本地，当然所有服务器写入本地的数据最终又会汇总成为一个可以被识别的输出文件。那么如何让每台服务都知道自己应该读哪个数据，输出时又该如何写入呢，写入之后又如何能够合并成一个可以识别的输出文件呢？分布式文件系统就是一个很好的解决方案。（这就是HDFS的由来）
其次是数据计算。前面说过，我们要让数据所在的服务器自行读取文件在本地的数据块，并进行计算。首先是本地读取完数据块后，执行的初步计算并得出结果；然而问题来了，在所有本地服务计算完成后，他们的计算结果中一般都存在维度重叠的问题（即服务器1计算结果中有A B C三个维度统计数据，而服务器2中有A C D E4个维度的数据，此时不能直接将各服务器的结果写入输出文件），因此还必须将这些计算结果进一步合并，以保证每个维度的key是唯一的。因此计算过程应该有两部分任务组成：一是本地服务器计算统计后得出初步结果（也叫中间数据）；二是对这些中间数据进行最终合并计算。Hadoop的大部分计算框架基本都是这两部走的，只是具体执行方式不太一样罢了（比如spark会把中间数据放在内存中而不是HDFS从而提高运行速度等）
嘿嘿，弄清楚了设计原理，大家在回去看看李老师的课程，比如HDFS，MapReduce之类的，是不是感觉容易理解多了呢
本人今年刚转大数据，李老师的课是我学习的第一门大数据课程，刚到第十章，今后每隔几章我都会写一篇心得和大家分享，也请老师多多指教哈
2018-11-20 09:29:34
2018-11-20 10:29:47
2019-01-08 15:50:08
2019-12-10 16:58:39
2018-11-22 00:02:09
2019-09-27 07:47:12
1-1：我们能从 Hadoop 中学到的第一个经验就是识别机会、把握机会。有的时候，你不需要多么天才的思考力，也不需要超越众人去预见未来，你只需要当机会到来的时候，能够敏感地意识到机会，全力以赴付出你的才智和努力，就可以脱颖而出了。
能够敏感的意识到机会——这个其实不是那么容易做到，很多时候对于机会大部分人都是熟视无睹的，为什么？当时那么多公司，那么多牛人都傻逼吗？我解释不了，但有一点我能确定，那就是不管他们想没想过，他们没有实践或者没有成功的实践。我觉得如果对什么事情有敏锐的意识，首先，老早的就有机会在思考这个东西，其次，一旦有任何机会就马上去做，经过几次迭代也许就能搞出一个牛逼的东西出来。
1-2：我们从 Hadoop 中可以学到大数据领域的一个架构模式，也就是集中管理，分布存储与计算。这种模式随处可见，比如：我们小组一个leader多为成员，leader负责对外交互和路由工作，组员负责具体实现，这样整个小组都比较高效，如果各自为战，那对外交互的工作就多了，而且什么都有会什么都要懂什么都要负责。不过路由算法很关键，特别对于人，如果工作安排不合理，会导致大家都不满意，效率也就低啦！
1-3：我是希望你在学习大数据的时候，不要仅局限在大数据技术这个领域，能够用更开阔的视野和角度去看待大数据、去理解大数据。这样一方面可以更好地学习大数据技术本身，另一方面也可以把以前的知识都融会贯通起来。
计算机知识更新迭代非常快速，如果你只是什么技术新就学什么，或者什么热门学什么，就会处于一种永远在学习，永远都学不完的境地。
如果这些知识点对于你而言都是孤立的，新知识真的就是新的知识，你无法触类旁通，无法利用过往的知识体系去快速理解这些新知识，进而掌握这些新知识。你不但学得累，就算学完了，忘得也快。
所以不要纠结在仅仅学习一些新的技术和知识点上了，构建起你的知识和思维体系，不管任何新技术出现，都能够快速容纳到你的知识和思维体系里面。这样你非但不会惧怕新技术、新知识，反而会更加渴望，因为你需要这些新知识让你的知识和思维体系更加完善。
还有的时候，你学一样新技术却苦苦不能入门，可能仅仅就是因为你看的文章、书籍本身写的糟糕，或者作者写法跟你的思维方式不对路而已，并不代表这个技术有多难，更不代表你的能力有问题，如果换个方式、换个时间、换篇文章重新再看，可能就豁然开朗了。
首先，我要非常感谢老师，因为，一方面给了思路，另一方面给了信心和极佳的学习体验。
老师的《大型网站技术架构：核心原理与案例分析》我也学习过，通俗易懂，循序渐进，这八个字只有大牛才能做的把复杂的东西简单易懂的讲给他人。让我信心倍增，也一下子懂了互联网的大概技术，有一种醍醐灌顶的感觉。
我想说，我其实在极客时间订阅了几十门课，虽然一直在学，但是大部分还没学，而且我觉得我是永远学不完的，除非极客时间倒闭不更新了，因为出一个，我好像习惯了就想买一个，我变成了心甘情愿的韭菜，任由你们这些技术大牛来收割。之所以这样，我觉得买下来不费钱只要我坚持学下去就是值得的，另外买了令我安心，不学习那是不可能的，看书效率低，跟着大牛学习确实高效，另外也有了交流的地方，评论区也卧虎藏龙。
不过最终让我成为韭菜的原因有两个，一个是计算机基础原理，一个是英语，如果有牛人出这些专栏我会继续买，专栏买多了看多了，我至少有一样能力增强了，清楚那些出专栏的老师水平不行，至少讲课的水平不行，另外，发现好多重复的讲解，这时就有趣了，老师们的水平有极客时间来保证，不过同一个东西，有人讲的通俗易懂有完整的体系结构，有的讲解就比较晦涩，可见相对而言讲师中也有水货。
我之前专门补了一下，计算机组成原理、计算机网络原理、计算机操作系统原理、数据结构与算法这些基础知识，发现再学习某些专栏就简单多了，都能发现有些知识讲的有些突兀，其实如果能循序渐进的学习，就会少很多不快的感觉。
不过也必须承认，人是不同的，有些人就是聪明，看书快记忆力极佳反应灵敏思维逻辑缜密。我们小组去年招了五位名校研究生，其中两位就有这样的特点，进步非常快，我工作好久了，感觉我很快就会被秒杀了！他们能直接英文文档英文书，国内的几乎不看，就这一点我就完败，我只能磕磕绊绊的，时间允许我觉得我必须报个班，重新学习下。
2018-11-20 09:32:24
这句话很真实，感觉现在技术迭代太快了，并且门槛也不高，IT行业靠经验值、阅历的工作也越来越少。实际工作中，做一颗螺丝钉，工作之余不敢懈怠，要努力学习`造航母`的知识。
2020-06-17 15:18:50
2019-08-27 09:36:19
2018-11-20 20:13:30
2018-11-20 09:53:40
2018-11-20 09:33:29
看完了hadoop给我最大提示是:使用就是硬道理，机会来了你站在风口上，成功了！
2021-04-27 17:16:34
2019-10-05 16:28:50
2018-11-20 08:38:56
2019-04-18 15:24:46
2018-11-22 10:34:46
2018-11-20 09:50:42