从0开始学大数据(10)我们能从 Hadoop 学到什么?

2022年10月29日 84点热度

我们能从 Hadoop 学到什么

今天的主题是:我们能从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 可以将数据分布在更多的服务器和磁盘上,肯定比单机上的的几块磁盘速度更快。

HDFS 常用的使用方式是结合 MapReduce 或者 Spark 这样的大数据计算框架进行计算,这些计算框架会在集群中启动很多的分布式计算进程同时对 HDFS 上的数据进行读写操作,数据读写的速度是非常快的,甚至能支撑起 Impala 这样的准实时计算引擎。

互联网应用中,用户从手机或者 PC 上发起一个请求,请问这个请求数据经历了怎样的旅程?完成了哪些计算处理后响应给用户?

这个思考题其实并不简单,考察的是一个典型的互联网应用,比如淘宝的架构是怎样的。简化描述下,这个过程是:

首先,一个请求从 Web 或者移动 App 上发起,请求的 URL 是用域名标识的,比如 taobao.com 这样,而 HTTP 网络通信需要得到 IP 地址才能建立连接,所以先要进行域名解析,访问域名解析服务器 DNS,得到域名的 IP 地址。

得到的这个 IP 地址其实也不是淘宝的服务器的 IP 地址,而是 CDN 服务器的 IP 地址,CDN 服务器提供距离用户最近的静态资源缓存服务,比如图片、JS、CSS 这些。如果 CDN 有请求需要的资源就直接返回,如果没有,再把请求转发给真正的淘宝数据中心服务器。

请求到达数据中心后,首先处理请求的是负载均衡服务器,它会把这个请求分发给下面的某台具体服务器处理。

这台服具体的服务器通常是反向代理服务器,这里同样缓存着大量的静态资源,淘宝也会把一些通常是动态资源的数据,比如我们购物时经常访问的商品详情页,把整个页面缓存在这里,如果请求的数据在反向代理服务器,就返回;如果没有,请求将发给下一级的负载均衡服务器。

这一级的负载均衡服务器负责应用服务器的负载均衡,将请求分发给下面某个具体应用服务器处理,淘宝是用 Java 开发的,也就是分发被某个 Java Web 容器处理。事实上,淘宝在 Java Web 容器之前,还前置了一台 Nginx 服务器,做一些前置处理。

应用服务器根据请求,调用后面的微服务进行逻辑处理。如果是一个写操作请求,比如下单请求,应用服务器和微服务之间通过消息队列进行异步操作,避免对后面的数据库造成太大的负载压力。

微服务如果在处理过程中需要读取数据,会去缓存服务器查找,如果没有找到,就去数据库查找,或者 NoSQL 数据库,甚至用搜索引擎查找,得到数据后,进行相关计算,将结果返回给应用服务器。

应用服务器将结果包装成前端需要的格式后继续返回,经过前面的访问通道,最后到达用户发起请求的地方,完成一次互联网请求的旅程。如果用架构图表示的话,就是下面的样子。

一次互联网请求的旅程

大数据的数据来源最主要的就是网站数据,了解网站架构对学习大数据、用好大数据也很有帮助。

Baimi

世上只有两种编程语言:一种是总是被人骂的,一种是从来没人用的。