文章目录

• 01 | 从天气预报看什么是大数据
• 02 | 从萌芽到爆发，大数据经历了哪些发展？
• 03 | 为了追赶当下趋势，我们要做什么思想准备？
• 04 | 阿里美团这些大厂都在用什么大数据架构？
• 05 | 大数据开发必备工具——Hadoop
• 06 | 精准溯源：大数据中的数据到底是从哪儿来的？
• 07 | 专为解决大数据存储问题而产生的 HDFS
• 08 | HBase 和 Hive 你能分清楚吗？
• 09 | 让你彻底明白为什么大公司都在做云服务
• 10 | 消息系统 Kafka 与 Flume 如何抉择
• 11 | MapReduce 处理大数据的基本思想有哪些

本博客为拉勾教育课程《大数据技术基础 22 讲》笔记

大数据技能图谱

大数据体系如此庞大，它的职业发展路径无疑也有很多，我总结了 3 大方向，你可以根据爱好和自身情况等来具体选择。

• “大数据架构”方向。主要工作是从众多的大数据工具中选取合适的工具，并能够让这些工具在庞大的云服务器或者集群中良好的配合和运转，来支撑上层的应用。职业发展路径为：数据运维工程师 → 高级运维工程师 → 架构师 → 技术专家。所涉及的技能主要在上面图谱的左半部分，比如通用框架、流式计算、消息队列、资源调度等。
• “大数据开发”方向。每家公司的情况各不相同，业务也各不相同，因此要想数据能够在这些工具中良好地运转，以及适配公司业务，就需要大数据开发工程师来进行建设。职业发展路径为：开发工程师 → 高级开发工程师 → 组件代码提交者。所涉及的技能也是图谱的左半部分居多，但与架构方向不同，重点在于熟悉这些工具的用法。
• “数据挖掘与分析”方向。有了底层的框架和适配公司业务的各种系统，这时候就轮到数据挖掘与分析工程师来对数据进行精加工，从而在大数据中发现对业务有帮助的部分，最终实现数据到现金的转化。这一方向的职业发展路径为：数据清洗师 → 数据分析师 → 高级数据分析师 → 数据科学家。该方向的技能主要分布在图谱的右侧，比如数据可视化、机器学习工具、算法与数据结构等。

01 | 从天气预报看什么是大数据

为什么大数据会被广泛应用

大数据系统能够得到广泛应用，主要得益于以下两方面的进展。

（1）底层硬件的支撑
（2）数据生产方式

随着网络、手机、电脑等设备的普及，越来越多的人成了内容的生产者，也就是我们现在所说的自媒体。微信公众号、今日头条，以及今天盛极一时的抖音、快手，都是依赖大家自发地去制作和上传内容，在这些平台上，每天发布的内容数量要以千万甚至亿级来进行计算。

在我们的生活中，除了这种主观创造的内容数据，被动数据的生产则更加迅速：

• 手机会时刻记录下你停留的位置、你行走的步数；
• 路口的摄像头不停地记录着每天在这里发生的事情；
• 气象站的传感器 24 小时都在上传各种气象指标。

这些数据的生产是源源不断的，所以，每天都会有大量的数据产生并且被存储下来。

大数据的 4 个重要特点

基于以上两方面的发展，大数据系统才得以广泛应用，从中我们不难看出大数据的一些特征。

同样如果在网上搜索“大数据”，可能大家对它的定义不尽相同，但总体而言，都有着一些共同的特征。这些特征不外乎 4 点：数量多（Volume）、种类多（Variety）、速度快（Velocity）及数据价值（Value）。

大数据的工作环节

你明白了什么是大数据以及大数据的特点，就能够推断出大数据体系在实践中，包含哪些环节，以及要解决什么样的问题。

（1）数据的采集

各式各样的数据生产方式都需要我们配备完整的数据采集方案，譬如你想要在 App 上收集用户的行为信息，就需要进行各种数据埋点。

（2）数据的存储

虽然说存储的硬件成本降低了，但是终归还是有成本的，同时数据也不可能杂乱无章地堆放在存储设备上，所以对应的数据库和文件存储方案，需要经过精密的设计来支撑这种巨量的数据存取。

（3）数据的计算

目前主流的就是批处理和流处理两种方式，而针对这些方式，又有多种计算框架被研制出来，比如当前应用广泛的 Spark、Flink 等。

（4）数据挖掘与分析

鉴于大量的数据和低密度的价值，我们期望能够使用一些巧妙的方案，从中找到那些有用的信息甚至是结论，于是各种算法与工具层出不穷。

（5）数据的应用

从数据中挖掘到的有价值的信息正在我们的身边发挥着巨大的经济价值，内容推荐、气象预测，乃至疫情控制，都是在大数据的指导之下进行的。

（6）数据安全

大数据有着重要的价值，而这些数据一旦泄露也会成为不法分子危害我们权益的帮手。所以，如何保障数据安全也是一个重要的问题。

02 | 从萌芽到爆发，大数据经历了哪些发展？

大数据的发展过程

萌芽阶段（1980-2007）

2004 年前后，谷歌发表了三篇论文，也就是我们常说的大数据三驾马车：

• 分布式文件系统GFS；
• 大数据分布式计算框架MapReduce；
• NoSQL 数据库系统BigTable。

这 3 篇论文的发表惊醒了很多懵懂的人，也解决了大数据体系中最核心的 3 个问题：

• GFS 文件系统解决了数据的底层存储问题；
• 计算框架 MapReduce 解决了数据的处理运算问题；
• BigTable 数据库系统解决了数据的有序组织问题。

热门阶段（2008-2016）

• 随着网络、存储、计算等硬件的成熟；
• 智能手机成为移动业务的标配；
• Hadoop 项目不断成熟。

大量依赖大数据的个性化 App 在这个阶段如雨后春笋般涌出，并迅速壮大。做社交的Facebook，做云服务的亚马逊，做内容服务的今日头条等等都在这个时间内发展起来，赚得盆满钵满。

在这个阶段，大数据迎来了第一次发展的小高潮，世界各个国家纷纷布局大数据战略规划，将大数据作为国家发展的重要标准之一，同时这也意味着大数据时代正在悄然开启。

不断爆发（2017 之后）

最近这几年，大数据基本上渗透到了人们生活的方方面面。比如说：

• 无处不在的交通违法监控；
• 前面介绍过的天气预测；
• 疫情之下的健康码。

这些都是大数据的产物。

同时，当前优秀的互联网公司都已经建设起了比较完善的大数据体系架构，并且在各自的业务中进行应用。各种新的数据库、计算引擎、数据流转框架喷涌而出，并随着新的需求不断迭代。伴随着互联网的成熟和发展，这充分说明了技术对于大数据行业发展的重要性，随着人工智能、云计算、区块链等新科技和大数据的融合，大数据将释放更多的可能，迎来全面的爆发式增长。

大数据在互联网公司中的发展

说了这么多大数据总体的发展过程，那么大数据体系在互联网中到底是一个什么状态呢？

就我而言，我所接触的大数据体系可以说是伴随着推荐系统而来的。推荐系统可以看作是一种信息筛选的机制，与搜索系统等待用户主动检索不同，推荐系统则会主动把信息推荐给用户。

• PC 时代虽然就已经有了推荐技术，但是 PC 网页面积巨大，门户网站精心编辑的分类整整齐齐排放在网站上供大家自行查阅，用户对推荐的需求不是很大。
• 而来到了移动时代，一个屏幕的空间很小，如果在手机 App 上面星罗棋布各种信息，那估计再好的眼神也得变成近视眼，所以简洁成了移动端追求的目标。

那么如何能够又简捷又精准地抓住用户兴趣，于是推荐系统迎来了春天。

那么，推荐系统中需要解决的问题，就成了公司中大数据体系需要处理的问题。

• 推荐系统需要使用大量用户信息，那么大数据体系建设就需要解决用户信息的采集、存储问题；
• 推荐系统需要计算每个用户与任意商品或者资讯的匹配程度，那么大数据体系建设就需要解决大规模计算与建模的问题；
• 推荐系统需要更加快速响应，那么大数据体系建设就需要朝着实时的方向解决问题。

所以，围绕推荐系统的大数据体系，有了以下 3 个大的工作方向：

• 大数据架构
• 大数据分析
• 大数据开发

工作方向选择

（1）大数据架构方向

大数据架构方向涉及偏向大数据底层与大数据工具的一些工作。做这一方向的工作更注重的是：

• Hadoop、Spark、Flink 等大数据框架的实现原理、部署、调优和稳定性问题；
• 在架构整合、数据流转和数据存储方面有比较深入的理解，能够流畅地落地应用；
• 熟知各种相关工具中该如何搭配组合才能够获取更高的效率，更加符合公司整体的业务场景。

从事这一方向的工作，需要具备以下技术。

• 大数据框架：Hadoop、Spark、Flink、高可用、高并发、并行计算等。
• 数据存储：Hive、HDFS、Cassandra、ClickHouse、Redis、MySQL、MongoDB 等。
• 数据流转：Kafka、RocketMQ、Flume 等。

（2）大数据分析方向

这里所说的大数据分析方向是一个广义上的大数据分析，在这个方向上，包含了各类算法工程师和数据分析师，一方面要熟练掌握本公司业务，一方面又具备良好的数学功底，能够使用数据有针对性的建设数据指标，对数据进行统计分析，通过各类数据挖掘算法探寻数据之间的规律，对业务进行预测和判断。

从事这一方向的工作，需要具备以下技术。

• 数据分析：ETL、SQL、Python、统计、概率论等。
• 数据挖掘：算法、机器学习、深度学习、聚类、分类、协同过滤等。

（3）大数据开发方向

大数据开发是大数据在公司内使各个环节得以打通和实施的桥梁和纽带，爬虫系统、服务器端开发、数据库开发、可视化平台建设等各个数据加工环节，都离不开大数据开发的身影。大数据开发需要具备 2 方面的能力：

• 要了解大数据各类工具的使用方法；
• 要具备良好的代码能力。

从事这一方向的工作，需要具备的技术有这些：数仓、推荐引擎、Java、Go、爬虫、实时、分布式等。

03 | 为了追赶当下趋势，我们要做什么思想准备？

每个行业都有每个行业的思维方式，这些思维暗示着行业运转背后的规律。那么接下来，就让我们看一下，在大数据时代，有哪些思维方式可以帮助我们快速进入工作状态。

全量思维

在介绍全量思维之前，我们先来思考一个问题：如果要统计阳澄湖中大闸蟹的数目，你想采取怎样的方法？

显而易见，最直接的方法就是把阳澄湖的水抽干，把里面的大闸蟹都捞上来，然后一个一个地数一数共有多少只大闸蟹。

但是想到这个方案的瞬间你可能就会打消这个念头，因为这个方案实现成本太大，几乎是不可能完成的。

退而求其次，我们可以在阳澄湖的几个不同的区域撒一些网，看看每个区域能够捞到多少只大闸蟹，然后推断一下与之面积类似的区域的大闸蟹数量。这种方法比起前一种方法更加可行，但是获得的结果肯定不如前一种精确。

第二种方法就是“抽样”。抽样思维在很长的一段时间里，甚至在现在很多的行业和实验中，都扮演者十分重要的角色。在数据获取困难、处理难度大的情况下，抽样思维是一种非常优秀的权宜之计。

而与这种抽样思维相反的，就像我们的第一种方法——全量思维，即把所有大闸蟹都捞出来数一数。

你肯定会说，第一种方法实现成本不是巨大吗？然而在大数据场景下，数据的采集已经变得极其方便，数据的存储也不再昂贵，各种硬件的性能不断提高，数据的计算速度也越来越快。尤其是还有很多优秀的研发机构推出了强大的大数据架构方案，比如 Hadoop、Spark、Flink 等，进一步降低了全量处理的成本。

如果要做一个服装行业消费情况的分析，我们仅仅是从数据中随机地抽取一些用户消费记录来分析他们的消费情况，可能永远也没办法知道在人均消费 200 元的市场上，会有人一掷千金花费 200 万元来购置衣服。所以，在全量思维的情况下，任何没有经过全体数据验证的事情，都可能是存在问题的。

所以，在现在工作中，涉及获取数据的环节，我们通常是事先规划好所有能够获取的全部数据情况，拿用户阅读内容为例，用户阅读的内容不用说，用户点击的时间、用户阅读的比例、用户阅读的时长、用户阅读时点击的区域等行为信息都要一一记录下来，全部存储到用户行为日志中，在后续的处理过程中再进行选择，而不是在一开始就对数据进行取舍，导致在后面需要用时捉襟见肘。

容错思维

在全量思维的基础之上，第二个重要的思维是容错。

我们所处的世界是纷繁复杂的，不确定性使得我们的世界充满了各种异常、偏差、错误，所以我们收集的全量数据自然也存在着这些问题，数据的残缺、误差、采集设备的不足、对非结构化数据的不同认知等都会引起这些问题。过去，对数据的处理我们往往追求精益求精，希望借助严格的数据筛选策略和足够复杂的计算逻辑来获得完美的效果，然而，这是不符合实际情况的，极端复杂也导致了泛化性能不好，在测试阶段的优秀效果，到了实际的生产环境中往往水土不服。

比如说我们要做一个给新闻进行分类的项目，在项目之初我们往往会进入对新闻进行精确分类的死胡同，期望能够给每一条新闻分出一个明确的类别。然而，世界上的新闻是多种多样的，事实上，一条新闻可能属于一个类别，也可能属于多个类别，甚至在不同的读者看来，它属于不同的分类。在自然中的东西很少是泾渭分明的，我们的新闻自然也是如此，我们追求模型的准确率，从 75% 到 85%，再到 95%，然而我们永远不可能做到 100%，因为这种完美分类本身就是不存在的。

当然，我们不能在准确率不足的时候，以其本身的不确定性为借口。相反，我们应该：

• 去追求准确率的提升；
• 明白我们所关注的目标是最终的效果，比如说用户的阅读体验、用户的下单比例等。

在大数据的体系下，我们应该更加关注效率的提升，在这样一个前提下，要容忍那些本身就存在的误差甚至是错误。

相关思维

由于大数据数量众多，而数据中又存在着各种各样的误差，甚至是错误，数据之间的关系错综复杂。通过这些数据，我们会发现其中蕴含着各种各样奇怪的知识，而这些知识都属于“事实”，而非“因果”。比如说，当某个地区在百度上搜索“感冒”的人数超出了往常，你可能会从数据中推测出这里有很多人得了感冒，从而做出一些商业决策，比如说销售感冒药，但是你很难从这个数据中得出他们是为什么得了感冒。因为得感冒的原因很多：

• 可能是这个地方的天气突然转冷；
• 也可能是这个地区组织了大型集会活动，导致流感病毒的扩散加剧了；
• 还有可能是自然的流感季节到来。

在大数据背景下，我们不再追求难以捉摸的确定的因果关系，而是转向对相关关系的探索。通过对相关关系的分析，我们可以知道：

• 广东人比东北人更爱泡澡；
• 香山的 10 月中到 11 月中是全年流量高峰；
• 美国大选时义乌印谁的旗子多谁就会当选。

如此种种不胜枚举。通过数据掌握相关关系，可以让我们在商业决策中做出正确的决定，有时候甚至是出奇制胜的妙招。

这种相关思维甚至有点中国传统的中庸之道的味道，即知道是什么就够了，不需要知道为什么。相关关系不存在绝对性，而是存在着概率性的变化。在大数据之下发现的相关关系可能有着特定的环境和背景，比如随着中国的崛起，低端印刷产业转移到了东南亚；而我们义乌的旗子产量可能与美国大选的结果就不存在这种关系了。所以，我们要正确地认识相关思维，千万不要把因果关系与之画等号，在这个千变万化的世界中，相关关系也会随着内外部条件发生转移，唯一不变的就是变化。

高可复用

正是由于前面三个大数据思维，在我们的日常工作中，一定要保持一种数据复用的思维。当你逐渐明白了，全量的数据才能表示全量；当你能面对各种问题数据心平气和；当你能够从数据中找到各种各样的相关关系，那你一定能明白数据复用的重要性。

一个公司的数据看似由不同的部门产生，并用在不同的业务上，然而这些部门往往存在着千丝万缕的联系，这些业务也存在着不同程度的交叉。所以，一份数据如何能够进行不同程度的复用，将是你获得突破的核心思考。

比如说滴滴旗下有打车业务，有顺风车业务，有代价业务，有地图业务，有共享单车业务，还有社区团购业务。打车业务的大量打车信息，每一辆行驶中的汽车及其中的乘客，都是一个个丰富的数据收集器：

• 首先可以用来帮助计划车辆的调度、优化行车路线、提高公司的业绩；
• 同时，还可以给地图业务提供拥堵信息；
• 可以帮单车业务规划单车投放地点；
• 甚至根据打车人群为社区团购提供数据支撑。

这些还都仅仅是在公司内部的复用，这里给你留一个小小的思考，打车数据是否还可以用来做一些 ToB 的业务，从而为公司获得更加丰厚的利润呢？

所以，在这样的数据背景下，你所熟知的数据可能不被其他部门或者其他业务的人所熟知，跳出你的业务惯性，积极地思考数据所能够带来的价值，能够在什么地方发挥作用，是一个重要的思维方法。也正是因为这样，你的一个不经意的思考，可能带来意想不到的效果。

04 | 阿里美团这些大厂都在用什么大数据架构？

互联网大厂的大数据解决方案

滴滴的大数据体系

我们先来看一组来自滴滴出行的数据：

截止到 2019 年 7 月，滴滴注册用户已超过 5.5 亿，年运送乘客达 100 亿人次，每日处理数据 4875+TB，日定位数超过 150 亿，每日路径规划请求超过 400 亿次。

那这样庞大的数据量，背后是由一个怎样的大数据体系作为支撑呢？如下是在全球软件开发大会上讲解的滴滴大数据研发平台。

• 最上层的红色箭头标志展示的是一个基于大数据平台开发工程的发布流程，当然，这个流程跟大数据的关系并不是很大，任何一个工程基本都要遵照这个过程进行发布。
• 紧挨着的流程是机器学习部分，机器学习会涉及数据挖掘 / 数据分析 / 数据应用几个步骤。
• 再往下是实时计算解决方案和离线计算解决方案。
• 在架构图的最底层是相关的支持，包括了数据安全、数据管理、开发运维和计算引擎四个部分。

就滴滴公布的大数据发展历程来看。

• 滴滴大数据先经历了裸奔时代：引擎初建，即通过 Sqoop 从 MySQL 导入 Hadoop，用户通过命令行访问大数据；
• 然后逐步引进了相关的工具化建设，但是这个阶段的工具还处于各自为政、四分五裂的状态：租户管理、权限管理、任务调度等；
• 在那之后，逐步产生了平台化思维，开始搭建一站式的智能开发和生产平台，使其可以覆盖整个离线场景，并且内置开发和生产两套逻辑环境，规范数据开发、生产和发布流程；
• 最后，也就是最新的一套大数据架构，在一站式开发生产平台的基础上进行了更多的扩展，已经可以集离线开发、实时开发、机器学习于一体。

阿里云的大数据体系

飞天大数据平台和 AI 平台支撑了阿里巴巴所有的应用，是阿里巴巴 10 年大平台建设最佳实践的结晶，是阿里大数据生产的基石。下图是飞天大数据的产品架构：

• 最下面是计算存储引擎，这里面包含了通用的存储和计算框架。存储方面，OSS 是阿里云的云存储系统，底层的 HDFS 文件存储系统，以及其他的各种 DB 系统；在计算框架方面，有 MapReduce 这种离线计算平台、实时计算平台、图计算引擎、交互式分析引擎等。
• 在存储和计算的基础上，是全域数据集成，这里面主要是对数据的各种采集和传输，支持批量同步、增量同步、实时同步等多种传输方式。
• 集成后的数据进入到统一元数据中心，统一进行任务调度。
• 再往上是开发层，通过结合各种算法和机器学习手段开发各种不同的应用。
• 最上面的数据综合治理，其实是在大数据全流程起到保障作用的一些模块，包含了智能监控、数据安全等模块。

美团的大数据体系

这是美团早些年公开的大数据体系架构：

在图上我们可以看到。

• 最左侧是美团的各种业务服务，从这些业务的数据库和日志，可以通过数据传输、日志采集等手段对数据进行汇总，一方面对于计算需求，直接进入到 Storm 流式计算框架进行计算，把结果存储于 HBase 等各种数据库中，并在业务上应用；另一方面，数据汇总到Hadoop 框架的存储中心，经过各种解析和结构化存储在 Hive 表中，并在各种机器学习和数据挖掘项目中进行应用。
• 在底层，是围绕着 Hadoop 架构建设的调度系统、配置中心，以及数据开放平台。
• 在最右侧，是经过集成的查询中心和查询引擎，并通过平台化开发建立了一套数据分析产品平台。

当然，美团的大数据体系不是一蹴而就的，也是随着时间的推移不断迭代和演进的：

• 在最早的 2011 年，美团基本还处于数据裸奔的状态，只有在有需求的时候才手工开发一个数据报表；
• 在 2011 年下半年引入了整个数据仓库的概念，梳理了所有数据流，设计了整个数据体系；
• 2012 年上了四台 Hadoop 机器，后面十几台，到最后的几千台以支撑各个业务的使用；
• 对于实时计算部分，在 2014 年开始启动应用，与此同时，也开始进行各种平台化的封装，以使得这些开源的工具框架能够更好地为业务所用；
• 时至今日，距离这个分享又过去了五年，在美团最新公开的一些关于大数据的文章和视频分享上，我们也可以看到整个大数据体系发生了长足的进展，不管是在平台化的演进还是对于现今技术的应用方面，都已经有了飞速的变化。

大数据体系的共同点

一口气看了这么多互联网大厂的大数据体系解决方案：

• 其中有比较早期的大数据体系，如 2016 年的美团大数据架构；
• 也有比较偏向于业务型的大数据架构，如滴滴的大数据平台；
• 也有用于通用解决方案的大数据体系，比如阿里飞天大数据平台产品架构。

它们属于不同的公司，作用于不同的业务，当然会有很多的不同点，但是不难看出，在大数据体系的发展过程中，也存在着很多相同的部分。

（1）模块化

大数据体系涉及了关于数据的一系列动作。随着大数据体系建设的逐渐完善，各个步骤变得更加清晰可分，不管是存储、调度、计算都被拆分成单独的模块，从而可以支持更多的业务，并根据需要进行灵活的选用。

（2）平台化

实施大数据的公司往往都有各种各样的业务，早期的大数据一定是围绕着各个业务去单独建设的，但是随着时间的流逝，各个业务之间的大数据体系存在着各种各样的差异，这就使得业务之间的数据互动成了一个难以跨越的鸿沟，建设一个把各业务的相似点统一起来，又能够包容各业务的差别的平台，让这些数据发挥出更大的价值成了一个迫在眉睫的需求。

（3）实时化

实时化一直是互联网公司不懈追求的。在大数据体系的演进中也充分体现了这一点。

• 最早期的开源大数据框架 Hadoop 都是基于磁盘开发的，不管是底层数据的存储还是计算的中间结果存储都放在磁盘上，而且其中的计算框架 MapReduce 也是基于离线的数据批处理，没办法对实时数据进行计算。
• 而看现在几大公司的大数据体系，实时计算已经成了大数据体系中一个非常重要的组成部分。

（4 ）不完善

根据最近几年的工作经验，虽然大数据体系在不断地发展和变化，各种新技术不断地应用，但是大数据体系还远没有达到一个完善的水平，其中仍然存在着各种各样的问题。我们的数据在不停地生产，规模不断扩大，虽然说各种硬件的性能在提升，价格在下降，但是这仍然是公司非常巨大的一笔开支；同时，在大数据的治理方面还很欠缺，随着数据的不断增长，数据的共享和合理利用效率在不断地下降，同时在数据安全方面也存在着很大的隐患。所以，关于大数据架构的迭代还远没有结束，在未来肯定还会有更多更好的解决方案推陈出新，解决旧问题，满足新需求。

总结

在这一讲中，我们介绍了三个公司的大数据体系架构，从这几个案例中不难看出，目前的大数据体系基本上都包含了数据存储、数据传输、数据计算、机器学习平台以及数据的最终应用等部分，同时结合各自的业务形成了一些各自的特色。当然，不是说每一个公司都需要一个完整的大数据体系，由于它并没有十分完善并且开销巨大，我觉得每一个公司都应该考虑投入产出的效率，根据自己的需求和能力去逐步地建设。

05 | 大数据开发必备工具——Hadoop

Hadoop 的整体架构

经过了这么多年的开发与演进，Hadoop 早已成为一个庞大的系统，它的内部工作机制非常复杂，是一个结合了分布式理论与具体的工程开发的整体架构。

关于 Hadoop 最朴素的原理，就是要使用大量的普通计算机处理大规模数据的存储和分析，而不是建造一台超级计算机。这里有两个问题需要解决。

• 计算机的故障问题。想象我们使用一个有一万台计算机组成的集群，其中一台计算机出现问题的可能性是很高的，所以在大规模计算机集群上要处理好故障问题，就要做到一台计算机出现问题不会影响整个集群。
• 数据的依赖关系。集群由若干台计算机组成，数据也是分布在不同的计算机上面，当你需要计算一个任务的时候，你所需要的数据可能要从若干台计算机进行读取，而你的计算过程也要分配到不同的计算机上。当你的任务分成若干个步骤形成相互依赖的关系时，如何让系统保持高效和正确的运行是一个很大的问题。

下图是 Hadoop 系统的一个架构图，虽然现在已经有了非常多的组件，但是其中最核心的两部分依然是底层的文件系统 HDFS和用于计算的 MapReduce。接下来，我们来看一下 Hadoop 系统中的一些重要组成部分。

1.HDFS（分布式文件系统）

HDFS 是 Hadoop Distributed File System 的缩写，从名字就可以看出它是一个文件系统。它在 Hadoop 体系中帮助解决文件的底层存储问题，能够用来支持海量数据的磁盘存储，能够进行机器的线性扩充，只需要在集群中增加节点，存储能力就会同步增长。

不仅如此，HDFS 还具备非常强大的容错性能，其中的某些节点出现了故障不影响系统的使用，通常数据都有很多的副本。HDFS 屏蔽了那些存储的细节，并在客户端为大家提供了一套完整的文件管理命令，把底层的文件以一种结构化的目录形式展现给用户，我们可以像使用 Linux 文件操作命令一样使用 Hadoop 命令来访问对应的文件。

2.MapReduce（分布式计算框架）

在 Hadoop 中的 MapReduce 框架就解决了分布式计算的问题，包括其中的运算逻辑与数据依赖。在 MapReduce 的应用上，提供了一套编程模型，重点就是实现 map 函数和 reduce 函数：

• map 函数用于组织和分割数据；
• reduce 函数主要负责在分布式节点上的数据运算。

MapReduce 编程支持多种语言实现，比如 Java、Scala 等。

3.Hive（数仓系统）

在 HDFS 之上，Hive 是 Hadoop 体系的数据仓库工具，可以将结构化的数据文件映射成一个数据表，注意这里的重点是结构化的数据文件。在 HDFS 文件系统中可以存储结构化数据文件，也可以存储非结构化数据文件，而 Hive 是处理其中的结构化数据文件，它本身并不进行存储。

同时，Hive 提供了一套Hive SQL实现 MapReduce 计算，我们可以使用与 SQL 十分类似的 Hive SQL 对这些结构化的数据进行统计分析，所以从某种意义上来说 Hive 是对 MapReduce 进行包装后产生的工具。在公司中，Hive 是一个非常常用的数仓工具，很多公司都会把它当作基础数仓来使用。不过 Hive 也有一些不好用的地方，比如不能进行单条数据更新。

4.HBase（分布式数据库）

在存储方面，Hadoop 架构中还有一个 Hbase 数据库。HBase 是一个分布式高并发的K-V 数据库系统，它的底层当然也是由 HDFS 来支撑，而 HBase 通过对存储内容的重新组织，克服了HDFS 对小文件处理困难的问题，实现了数据的实时操作。

在互联网公司中，对于量级较大，且变动较多的数据通常适合使用 HBase 进行存取。比如说我之前所在的做内容的媒体公司，内容数据经常会发生更新等变动，我们对这些内容进行各种算法运算也经常需要单条或者小批量的存取，所以使用 HBase 来存储数据，非常方便。

5.Yarn（资源调度和管理框架）

在最早的 Hadoop 1.0 中其实是没有 Yarn 的，资源调度等功能都包装在 MapReduce 的 JobTracker 中，而 JobTracker 负担了太多的功能，接受任务、资源调度甚至是监控TaskTracker 的运行情况。当时存在一个问题，在集群规模非常大的时候会出现不稳定的情况，于是在 2.0 中对其进行了拆分，因此产生了独立的 Yarn。在拆分出 Yarn 之后，MapReduce 只负责计算，这也给后面其他计算框架替换 MapReduce 提供了方便，保障了 Hadoop 整个架构长盛不衰。

6.ZooKeeper（分布式协作服务）

ZooKeeper，直译是动物园管理员。这是因为很多项目都以动物的名字命名，而 ZooKeeper 最常用的场景是作为一个服务的注册管理中心。生产者把所提供的服务提交到 ZooKeeper 中，而消费者则去 ZooKeeper 中寻找自己需要的服务，从中获取生产者的信息，然后再去调用生产者的服务。

在我看来，ZooKeeper 像是一个锁，把控各种数据流转服务的中间环节，保障数据的一致性。比如说 HBase、Kafka 等都可以通过 ZooKeeper 进行注册。幸运的是在我们的开发过程中，不需要了解太多 ZooKeeper 的细节，主要是进行一些代码上的配置就可以了。

一口气讲了这么多 Hadoop 的组件，但是可以看到，在 Hadoop 的框架中还远远不止这些东西。不过最主要的、平时工作中接触最多的部分已经都有涉及。

下面我们来看一下 Hadoop 的一些优缺点。

Hadoop 的优点

强大的数据存储和处理能力。这个优点是显而易见的，也是最根本的。通过技术手段，Hadoop 实现了只需要增加一些普通的机器就可以获得强大的存储和运算能力。

隐藏了大量技术细节。使用 Hadoop 框架，我们不再需要关注那些复杂的并行计算、负载均衡等内容，只需要调用相关的 API 就可以实现大规模存储和计算。

良好的扩展能力。发展到今天，Hadoop 已经不是一个单一的解决方案，它提供了很多不同的组件，不限于我上面列出的这些。公司可以使用标准的方案，也可以根据自己的业务需求来进行细节上的调整甚至是自己的开发。比如说对于计算框架 MapReduce，在很多公司已经使用性能更好的 Spark 或者 Flink 进行了替换。

Hadoop 的缺点

实时性较差。由于 HDFS 存储底层都是在磁盘中进行的，以及原生的 MapReduce 的中间结果也都要存储在磁盘上，所以 Hadoop 的实时性不太好。

学习难度较大。虽然说 Hadoop 已经对很多复杂的技术进行了封装，但是仍然挡不住它是一个庞大而复杂的系统。尤其是其中的很多问题都需要在实践中不断摸索，要想学习整个体系几乎是很难在短时间内实现的。

Hadoop 在经过不断的发展之后也已经形成了自己的生态圈，很多不同的组件都可以与Hadoop 搭配使用。很多公司都基于 Hadoop 框架搭建起了自己的大数据处理体系。目前，免费的 Hadoop 版本主要有三个：

• 一个是 Apache 版本，也就是最原始的发行版；
• 一个是 Cloudera 版本，简称 CDH；
• 还有一个 Hortonworks 版本，简称 HDP。

当然，所有的版本都是基于 Apache 版本进行改进的，而 CDH 版和 HDP 版则附加了很多新的特性，解决了一些工业级应用时的痛点。

06 | 精准溯源：大数据中的数据到底是从哪儿来的？

如果说把我们的大数据看成是石油加工的过程，那么在整个大数据的流程中，我们的数据采集工作就相当于石油的开采。数据就在源源不断地生产着，如果我们不对其进行采集，那么我们后续的环节也不复存在，所以做好数据采集是一个非常良好的开端。

在数据采集阶段，我们的任务就是要从业务场景中获取原始数据，并把这些数据收集聚合起来，传输到我们的服务器上进行存储。常见的数据采集方式有三种。

传感器

比如我们前面介绍的天气数据就需要放置很多传感器，用气压、温度、风力等传感器，不停地收集数据。在互联网公司的产品中也不乏基于传感器的数据采集：

• 手机上的指纹开屏；
• 使用指纹进行支付；
• 微信步数的采集；
• 各种手环和运动手表等还可以监测心率；

……

传感器采集主要依赖于各种各样的硬件设施，而在当前互联网中主要依赖硬件采集信息的还是比较少的。

爬虫采集

顾名思义，爬虫采集是通过一套程序去互联网上获取数据的方法。如果把一个互联网公司的数据划分成站内数据和站外数据，那么爬虫所获取的都属于站外数据。很多时候我们要做一些任务，只依赖自己的数据是不够的，而互联网上存在着大量开放的数据，通过爬虫系统可以获取很多有益于我们工作的数据。当然，使用爬虫来爬取数据一定要注意法律风险，很多公司的数据是禁止爬取的，在具体操作的时候一定不要触碰法律的红线。

日志采集

最重要的一种数据采集的方式就是日志采集。在这个移动互联网的时代，基本上每个互联网公司的输出都以手机 App 为主要的承载形式。阿里巴巴有淘宝、1688、饿了么等多个 App；字节跳动有抖音、今日头条、懂车帝等多个 App。用户在这些 App 上产生各种行为和活动，我们需要在代码中重点标记所需的行为记录，并把它们作为“日志”传输到服务器上。

跟硬件传感器相比，日志记录可以看作是一种软件传感器，依托手机 App 就可以实现，这通常是现在的互联网公司获取“站内数据”的主流方式。下图就是一个典型的日志采集场景：

用户在淘宝上浏览商品，点击下单支付，这些信息都通过日志的形式从前端传递到后端并通过网络输送到公司的服务器上，最终存储在数据库里。有了这些数据，公司又可以对用户进行分析，进一步推荐你可能感兴趣的商品并呈现在 App 的前端界面上。

在日志采集的数据中，通常又可以分成两种类型，一种称为事件，一种称为属性。

事件

事件是日志采集的重中之重，这里我们来详细介绍一下。在 App 中，用户的一种行为就被称为一个事件。如果把事件进行归类，我觉得可以分成三种基本事件：曝光事件、点击事件和用户停留事件。

（1）曝光事件

最简单的，一个 item 或者一个页面被展示出来，就称作曝光。在日志中记录曝光事件，就是记录每一个被展示出来的页面、商品或者内容。

（2）点击事件

而点击，则是用户在 App 中的点击行为。通常，App 中的各种页面都是通过点击进行跳转的，比如说上面的淘宝页面，你点击一次商品图片可以进入详情页，再点击一次加购可以加入购物车，然后点击支付可以进入到付款页面，依次类推，点击事件是用户行为转变的关键行为。

（3）用户停留事件

这个事件记录的是一个用户在某个页面，或者某种情况下停留的时间。比如说在抖音中，你在一个“美女视频”的播放中停留的时间比其他视频的停留时间都要长，我们就可以猜测你对“美女”更感兴趣。

有了上述的三种基本事件，同时综合这三种基本事件发生的不同场景，我们就可以测算各种数据指标。

• 在新闻推荐场景，使用新闻曝光和新闻点击可以计算某条新闻的点击率；
• 在视频场景，使用点击和用户停留时间可以计算观看完成比；
• 在交易场景，使用浏览点击和下单点击可以计算访购率。

属性

与事件的连贯性不同，属性的收集往往是一次性的。当我们打开 App 时，我们使用的手机型号、网络制式、App 版本等信息都作为属性一次性地收集起来。虽然说属性的收集过程比事件要简单，但是属性数据本身的价值并不比大量的事件低，所以，对于属性的日志收集也需要同等的对待。

数据埋点

在我们的公司中，实现日志采集所使用的手段被称为数据埋点。

通俗来说，数据埋点就是在我们 App 的前端，也就是 UI 层的代码中插入一段用于监视用户行为事件的代码。当用户在 App 上发生对应的行为时，就会触发这段代码，从而上传该埋点中事先已经定义好的事件信息。

当然，除了我们所熟知的手机 App，数据埋点还可以设定在 H5 页面、微信小程序等位置。通过埋点收集到的信息：

• 可以作为监控，看到 App 的长期表现；
• 也可以作为基础原料，进行复杂的运算，用于用户标签、渠道转化分析、个性推荐等。

数据埋点的困难

为了获取更多的流量，满足更多用户的需求，一个成熟的互联网公司往往有各种各样的用户渠道，因此，要想把数据埋点做好也有很多的困难。

• 来源众多。对于一款产品，可能有网页端、App 端，App 还分成安卓、iOS 甚至微软客户端，还有各种各样的小程序。这么多的来源，要把不同来源的同一处行为数据进行合并统计，而不同的来源开发语言不同，实现原理不同，埋点的难度可想而知。
• 页面众多。看似不起眼的一个 App，从你打开到浏览、下单、支付，这中间不知道要经过多少个页面，有多少种不同的形式，每个页面、每个形式又有若干种事件的组合，要想做好每一处埋点也不是一件容易的事情。
• 数据格式各不相同。不同的业务可能对于同一个页面的埋点存在不同的需求，数据埋点需要做到兼容并包、不重不漏，其实也是非常困难的。

说了这么多埋点的困难，那么埋点的方式有哪些呢？对于不同的方式，它们对于困难有什么解决方法，下面我们来看一下。

埋点方式

（1）手动埋点

说到埋点方式，最容易想到的当然就是手动埋点。前面也说过了，所谓的埋点就是程序员去增加一些代码，那么手动埋点自然是说程序员手动地去增加代码。这就意味着当有产品需求的时候，产品经理提出我们需要在某某页面、某某位置增加一个针对某某行为的埋点，然后程序员领取了这个需求，一顿操作上线这段代码。

这种埋点方式最大的好处就是没有其他的开发量，属于懒惰开发的一种情况，只有当需求提出的时候才去增加一个埋点。对于单个需求，开发比较迅速，但是它的缺点也显而易见，随着业务的增长，埋点的需求必然是一个接一个，永无止境，程序员做了大量相似的开发。而且每增加一个埋点，都需要从产品提出到需求沟通到程序员开发到上线走一遍，长期来说消耗是巨大的。

（2）半自动埋点

手动埋点耗时耗力，所以就要想着把流程改进一下。半自动的埋点通常出现在产品已经基本成熟的时期。程序员加班加点对于目前以及预期未来的业务流程进行了梳理，整理出一套常用的埋点方案，并把这套方案嵌入到业务代码中。当产品经理上线了一个与原有页面类似的新页面，不再需要程序员进行多余的开发，只需要调用之前的方案即可完成埋点。

不过，在半自动埋点的情况下，如果有一些全新的功能或者页面上线，还是需要进行开发的。

（3）全自动埋点

懒惰是进步的动力。全自动埋点与前面的两个理念完全不同，前面两种不管是手动还是半自动都是在有需求的时候才去埋点，而全自动埋点完全忽略了需求的存在，直接从最基本的事件和属性出发，把所有的东西都纳入埋点的范畴，事无巨细地记录下来，以后产品想要什么东西就自己去日志里统计就好了。

全自动埋点的优势显而易见，从根本上解决了埋点的需求，从此解放了双手，不再需要听什么埋点需求。但是缺点同样明显，开发一套如此完整的全自动埋点系统通常也极为困难，同时，收集全量信息，网络开销大、存储成本高，大部分没用的信息则会导致后续数据处理的速度缓慢。

不管采取何种埋点方案，有一点我希望提醒你。在处理埋点信息的时候一定要有一套统一的标准：同一个事件、同一个属性坚持只有一个埋点的原则，收集上来的日志由统一的部门进行汇总管理，进而统一数据口径。试想，如果对于同一个事件，不同的业务部门使用不同的埋点代码，由不同的部门进行计算，随着人员的变动和业务的更迭，最终将导致数据陷入永远无法核对清楚的困境，想想就是一种灾难。

进阶

为了更好地理解数据埋点采集日志与后续环节的关系，我在这里画了一张数据埋点的框架形式，当然，数据埋点的框架可以有很多种，这里只是作为一种说明。

从上图，我们可以看到，在开发了埋点代码的前端环境中监控用户的行为，当用户产生行为的时候会通过 HTTP 请求把这些事件进行上报，进入到日志收集服务中。日志收集服务会把这些日志转发到日志记录服务中，日志记录服务通过简单的日志加工汇总成为原始日志。在这个位置，通过实时的 ETL 把原始日志处理成标准的格式，比如说汇总成我们所需要的用户 ID 与商品 ID的关联，以及是否有曝光、点击、下单、购买行为，并形成中间层日志，用于各种实时任务。

同时，原始日志和中间层日志通过 Kafka 消息队列同步到 HDFS 中以备后面的离线分析。在上面的一个分支则是后端服务的日志采集，直接通过 Kafka 队列收集信息。实际上，除了前端产生的日志，后端服务同样也会产生各种日志信息，不过这里多用于服务运行状态的检测。

总结

凡是要进行数据的处理，就不得不涉及数据的获取。在当下的互联网公司中，大部分都是以网页、App、小程序为数据源，通过用户的访问日志进行数据的收集。在收集数据的时候，有很多方法，也有很多困难，但是我的建议是尽量选择那些能够保障数据一致性的方法，这样在后续的数据处理、数据应用环节才能够更加快速有效。如果你的日志收集工作没有做好，后面的数据就会一团乱麻，那么大数据体系将无从提起。

07 | 专为解决大数据存储问题而产生的 HDFS

文件系统

首先我们来看一下什么是文件系统。不管是操作系统还是运行的各种软件，抑或是我们所正在介绍的 Hadoop 工具，其实都是一些程序。在运行的时候，这些程序实际上都在存储和搜索数据。正如我们所熟知的，在电脑中，常用的存储有内存和硬盘两种形式：

• 内存的速度快，但是价格更贵，所以使用的存储容量较小；
• 硬盘价格便宜，速度要慢很多。

在我们的电脑中一般都使用硬盘来进行长期存储，而内存用来存储程序运行时的数据。所以，对于我们的硬盘来说，最基本的功能就是读取和写入功能。但是，这里有很多问题需要解决：

• 硬盘上的位置如何划分；
• 怎么能够尽快在硬盘上找到需要的数据；
• 对于一块空间如何保障读数据和写数据不是同时进行的；
• ……

针对这么多的问题，提出了一个抽象的概念——文件。一个文件就是一个单元，占用一个独立的地址空间，程序可以读取文件或者创建新的文件。而对这些文件进行管理，解决这些文件的结构、访问、保护、寻址等功能的系统，我们就称为文件系统。而我们所要介绍的 HDFS，全称 Hadoop Distribute File System，也就是分布式文件系统的意思，HDFS 是文件系统的一种实例。

HDFS 基础

前面我们已经简单介绍过 HDFS，它可以利用廉价的普通服务器作为其存储，组建一个大规模存储集群，为各类计算提供数据访问的基础。那么 HDFS 的文件系统比起一般的文件系统有什么特色呢？其实 HDFS 文件系统最大的特色就是它在分布式架构上的处理，同时 HDFS 的设计适合一次写入，多次读出的场景，且不支持文件的修改，所以不适合反复修改数据的场景。

HDFS 的架构

在了解 HDFS 的整体架构前我们先来理解一下 HDFS 里的一些小知识。

（1）数据块

HDFS 默认最基本的存储单位是 64MB 的数据块（在 2.x 版本中是 128MB），大小通过配置可调。对于存储空间未达到数据块大小的文件，不会占用整个数据块的存储空间。

（2）元数据节点（NameNode）

元数据节点算是 HDFS 中非常重要的一个概念，用于管理文件系统的命令空间，将所有文件和文件夹的元数据保存在文件系统树中，通过在硬盘保存避免丢失，采用文件命名空间镜像（fs image）及修改日志（edit log）方式保存。

（3）数据节点（DataNode）

数据节点即是真正数据存储的地方。

（4）从元数据节点（Secondary NameNode）

从字面来看像是元数据节点的备用节点，但实际不然，它和元数据节点负责不同的事情，主要负责将命名空间镜像与修改日志文件周期性合并，避免文件过大，合并过后文件会同步至元数据节点，同时本地保存一份，以便在出现故障时恢复。

整体架构图如下所示：

在架构图中，除了我们上述介绍的几种节点，还有一个 Client，即客户端。

• 客户端是我们平时用来和 HDFS 服务进行交互的部分，客户端中内置了一套文件操作命令来帮助我们访问 HDFS 服务，比如说我们上传文件、下载文件；
• 同时客户端还负责把我们上传的文件按前面说的数据块进行切分，以方便后续的存储；
• 因此，客户端当然也负责与 NameNode 和 DataNode 进行交互以获取文件位置或者读写文件操作等。

HDFS 的优缺点

1.优点

（1）高容错性。

在 HDFS 文件系统中，数据都会有多个副本。其中的某一个副本丢失（某一个节点的机器损坏）并不影响整体的使用，可以自动恢复。

（2）适合大数据处理。

数据规模：能够处理数据规模达到 GB、TB、甚至 PB 级别的数据；

文件规模：能够处理百万规模以上的文件数量，相当之大。

（3）提供数据一致性保障。

（4）任意一个节点所占用的资源较少，可以在廉价的机器上运行，支持线性扩张。

2.缺点

（1）不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。

（2）无法高效地对大量小文件进行存储。

• 存储大量小文件的话，它会占用 NameNode 大量的内存来存储文件、目录和块信息。这样是不可取的，因为 NameNode 的内存总是有限的；
• 小文件存储的寻址时间会超过读取时间，它违反了 HDFS 的设计目标。

（3）不支持并发写入、文件随机修改。

对于一个文件，只能有一个线程写入，不可以多个线程同时写入。基本不能进行文件的修改，只支持数据的追加，如果想修改需要使用新文件覆盖整个旧的文件。

hdfs的安装及基础操作这里不做过多赘述。

安装可参考：https://herobin.blog.csdn.net/article/details/107710192

相关指令可参考：https://herobin.blog.csdn.net/article/details/107712085

08 | HBase 和 Hive 你能分清楚吗？

上一讲知道了HDFS 是 Hadoop 中用来管理文件的系统，是 Hadoop 的核心之一。在实际的生产工作中，仅仅有一套文件管理系统还不能很好地支撑我们业务的需求，我们还希望对数据进行更加便捷的操作，这一讲，我们就来了解下，在日常工作中经常用的而且与 HDFS 有紧密联系的两个工具 Hive 和 HBase。

Hive

在 Hadoop 系统中，负责计算的部分是 MapReduce，也就是说我们要处理 HDFS 中存储的数据，进行各种统计分析以及运算的话需要去开发一个 MapReduce 程序。

虽然说 MapReduce 已经对分布式计算进行了很好的封装（这部分我们会在<11 | MapReduce 处理大数据的基本思想有哪些>中讲到），但是使用其 API 进行开发对于很多人来说仍然是一件很困难的事情。比如说很多的数据产品经理或者运营人员只是想统计一下数字，却要去学习如何写代码开发的一套程序，这个难度可想而知，因此 Hive 便应运而生。Hive 会解析 SQL 语句然后转化成 MapReduce 的程序运行，只是学习 SQL 语句对于一个产品经理来说就要简单得多了。

下面我们就来介绍一下 Hive。简单来说，Hive 就是一个数据仓库，仓库中的数据都是在 HDFS中管理的数据文件，同时 Hive 支持类似 SQL 语句的功能，你可以通过这些语句来进行数据分析，Hive 会把这些语句转换成可执行的 MapReduce 代码，然后进行计算。这里的计算，仅限于查找和分析。

Hive 所处理的是已经存储起来的数据，这种计算也就是我们所说的离线计算（区别于实时计算）。通过 Hive 的操作，可以让你在操作数据时感觉是在使用 MySQL，从而减少你的学习成本。

接下来，我们来看一下 Hive 的基本体系架构。如下图所示：

Hive 的体系架构

上面这张图来自早期的 Hive 架构文档，分成两大部分，左侧是 Hive 的主体，右侧是Hadoop 系统，右上是 MapReduce，右下是 HDFS，中间有几条线连接，说明了 Hive 与 Hadoop 两大核心的关系。

（1）UI

用户界面，我们也可以认为是一个客户端，这里主要负责与使用者的交互，我们通过 UI 向系统提交查询和其他操作。当然，在 Hive 中还封装了 ThriftServer，我们可以在开发中使用 Java、 Python 或者 C++ 等语言来访问 Server，从而调用 Hive。

（2）驱动器（Driver）

驱动器在接收 HiveQL 语句之后，创建会话来启动语句的执行，并监控执行的生命周期和进度。在图中可以看到，驱动器既负责与编译器的交互，又负责与执行引擎的交互。

（3）编译器（Compiler）

编译器接收驱动器传来的 HiveQL，并从元数据仓中获取所需要的元数据，然后对 HiveQL 语句进行编译，将其转化为可执行的计划，按照不同的执行步骤拆分成 MapReduce 和 HDFS 的各个阶段的操作并发送给驱动器。

（4）执行引擎（Execution Engine）

在编译和优化之后，执行器将执行任务。它对 Hadoop 的作业进行跟踪和交互，调度需要运行的任务。

（5）元数据仓（Metastore）

元数据指的是我们构建的 Hive 表的表名、表字段、表结构、分区、类型、存储路径等等，元数据通常存储在传统的关系型数据库中，比如 MySQL。

Hive 的优缺点

Hive 的优点有很多，我主要从以下几个方面为你讲解。

（1）简单易上手

只需要了解 SQL 语言就可以使用 Hive，降低了使用 MapReduce 进行数据分析的难度，很多互联网公司都会使用 Hive 进行日志分析，比如说淘宝、美团等等，使用 Hive 统计网站的 PV、UV 等信息，简单便捷。

（2）Hive 提供统一的元数据管理

通过元数据管理可以实现描述信息的格式化，使得数据可以共享给 Presto、Impala、SparkSQL 等 SQL 查询引擎。

（3）可扩展性好

跟 Hadoop 的其他组件一样，Hive 也具备良好的可扩展性，只需要添加机器就可以部署分布式的 Hive 集群。

（4）支持自定义函数（UDF）

SQL 的功能虽然非常多，足够支撑我们平时常用的统计方案，但是对于一些个性化的定制方案，使用 SQL 明显要麻烦很多，Hive 支持使用自定义函数的方式来加入自己编写的功能，方便了开发人员。

当然 Hive 也是有缺点的。

（1）速度较慢

由于 Hive 的底层数据仍然是存储在 HDFS 上的，所以速度比较慢，只适合离线查询。在写程序时一般也是使用 Hive 来一次性加载数据，不适合在代码中反复访问。

（2）不支持单条数据操作

这个仍然是跟 HDFS 的存储相关，我们不能任意修改 HDFS 里的数据，所以 Hive 也不行，要想修改数据只能整个文件进行替换。

HBase

跟 Hive 不同，HBase 是一个在 Hadoop 大数据体系中应用很多的NoSQL 数据库，HBase 源于谷歌发表的论文：Bigtable。HBase 同样利用 HDFS 作为底层存储，但是并不是简单地使用原本的数据，只是使用 HDFS 作为它的存储系统。也就是说，HBase 只是利用 Hadoop 的 HDFS 帮助其管理数据的持久化文件。HBase 提供实时处理数据的能力，弥补了早期 Hadoop只能离线处理数据的不足。

HBase 的表结构

下图是 HBase 的表结构：

（1）行键（Row Key）

这是我们一行数据的唯一标识，比如说我们平时的数据都会有一个唯一 ID，就可以用来作为 Row Key。但是需要注意的是，HBase 在存储 Row Key 的时候是按照字典顺序存放的，所以如果你的 Row Key 不是以分布均匀的数字或字母开头的，很可能造成存储集中在某一台机器上，这会大大降低查询效率，所以这种时候需要设计存储的 Row Key，比如在每个 ID 的前面都加一个 HASH 值来提升查询性能。

（2）列簇（Column Family）

可以看作是一组列，实际上一个列簇的作用也是用来管理若干个列，优化查询速度。所以列簇的名字要尽量短，同时对于经常需要一起查询的列放在一个列簇下面。比如说对于用户信息，一个用户的静态属性（姓名、年龄、电话、地址等）可以放在一个列簇下面，动态属性（点赞、收藏、评论等）可以放在一个列簇下面。HBase表中的列簇需要预先定义，而列不需要，如果要新增列簇就要先停用这个表。

（3）单元（Cell）

指的是一个确定的存储单元。通过 Row Key、列簇 、列名以及版本号来确定。

（4）时间戳（Timestamp）

用来标记前面说的一份数据的不同版本。

（5）区域（Region）

一个 Region 可以看作是多行数据的集合。当一个表的数据逐渐增多，需要进行分布式存储，那么这个表就会自动分裂成多个 Region，然后分配到不同的 RegionServer 上面去。

HBase 的优缺点

HBase 的优势在于实时计算，所有实时数据都直接存入 HBase 中，客户端通过 API 直接访问 HBase，实现实时计算。由于它使用的是NoSQL，或者说是列式结构，从而提高了查找性能，使其能运用于大数据场景，这是它跟 MapReduce 的区别。

除此之外，它还有其他优点。

• 容量大性能高。一张 HBase 表可以支持百亿行、数千列的存储，而查询效率不会有明显的变化。同时 HBase 还可以支持高并发的读写操作。
• 列存储，无须设定表结构。对于传统数据库，比如 MySQL 是按行来存储的，检索主要依赖于事前建立的索引，在数据量很大的时候增加列或者更新索引都是非常缓慢的，而 HBase 每一列都是单独存储的，每一行每一列的那一个单元都是独立的存储，也就是数据本身即是索引。也因为如此，列可以在写入数据的时候动态地进行添加，而不需要在创建表的时候就设定。在具体存储时，每一行可能有不同的列。

而 HBase 不能支持条件查询，也不能用 SQL 语句进行查询。在使用的时候，一般只能使用Row Key 来进行查询。

HBase 与 Hive 的使用

在实际的工作中，HBase 与 Hive 在我们的大数据架构中实际上处于不同的位置，通常搭配来进行使用。

由于 HBase 支持实时随机查询的特性，主要使用 HBase 进行大量的明细数据的随机实时查询。比如说以用户 ID 为 Key 的用户信息，以 Itemid 为 Key 的商品信息、各种交易明细等等。在数据收集上来之后通过解析实时流然后存储到 HBase 中，以备查询。而在查询 HBase 的时候一般也是对整条数据进行查询。

就我们前面已经介绍的，Hive 本身并不解决存储的问题，它只是把 HDFS 中的结构化数据进行了展示，而最核心的功能是实现了对这些结构化文件的查询。在日常的工作中，通常使用 Hive分区表来记录一个时间段内的数据，并进行离线的批量数据计算，比如统计分析各种数据指标。

由于同为 Hadoop 体系的重要工具，Hive 与 HBase 也提供了一些访问机制。有时候我们希望能够在 Hive 中查询 HBase 的数据，可以通过关联外表的形式，在 Hive 上创建一个指向对应Hbase 表的外部表。

09 | 让你彻底明白为什么大公司都在做云服务

前面几讲，我们介绍了很多关于大数据体系架构、数据采集和数据存储相关的方法和工具。很多人可能觉得：

• 大数据体系的东西太多了，我们是小公司用不到这些东西；
• 要构建一套完整的大数据体系需要很大的一个团队，我们付不起这么高的价格；
• 我们只想用其中的一些部分。

如果有这样的问题，我们该怎么办呢？这里就可以使用云服务进行解决。这一讲，我们就来看一下云服务都可以提供什么样的功能。

什么是云服务

在我看来，云服务其实有两层含义：

• 离得远，远在云端的服务；
• 不需要了解细节，藏在云后面的服务。

所以，云服务就是互联网提供的各种服务器，计算、存储、数据库，甚至是大数据、人工智能服务，并且这些服务是弹性可伸缩、按需支付的。你不需要了解服务背后的实现细节，只需要知道它能够满足什么需求，并按需进行购买就可以了。

云服务都能提供什么服务

互联网公司大多数提供的都是线上服务。比如要做一个熟肉电商平台，我们需要有网络服务，有存储设备存放商品信息，需要有交易系统让用户完成支付，甚至还需要数据分析平台来分析什么产品卖得好。

如果说这些东西从一开始就完全由自己来建设，那将是一笔非常大的开销。不仅要购买服务器，还要雇用很多开发人员来开发系统并保障这些服务的正常运转。对于这里面的大部分环节，我们的需求可能跟其他电商平台并没有什么区别，比如说卖衣服、卖鞋的电商平台等。我们完全可以共用同一台服务器，共用同一套支付系统。

或者是在某些特殊的时间，我们对服务器的需求有突然的变化，比如说我们搞了一个 6 月 6 日吃肉节，这一天的客户激增，需要十台服务器和平时十倍的网络流量才能支撑，而在剩下的一年 364 天则没有这种需求。因此在这个时候选择使用一些云服务来建设自己的需求是可以节约成本的，你只需要支付一定的费用，然后专注于核心的环节。

那么我们就来看一下，现在的云服务都可以提供什么服务。

上图是亚马逊的云服务网站截图，亚马逊云服务又称作 AWS（Amazon Web Services），是主流的云服务供应商之一。AWS 在全球多个地理位置部署了若干的云服务区，这些可用服务区通过低延迟、吞吐量高而且高冗余的网络连接在一起。

从上图中可以看到，AWS 提供了大量的基于云和大数据的产品，其中包括计算、存储、数据库、分析、网络、移动产品、开发工具、物联网、安全管理和各种企业级应用等。亚马逊是全球市场占有率第一的云服务公司，像 Airbnb、Netflix 等都在使用 AWS 的服务。

在亚马逊云上还提供了很多免费的服务（如上图），供开发者进行试验和尝试各种功能。可以看到 EC2 就是亚马逊云服务器，而 S3 则是亚马逊云存储，RDS 是云数据库，这些都有免费的额度，如果你感兴趣可以试用一下。

上面这张图来自阿里云。可以看到，与亚马逊云一样，阿里云也提供了非常丰富的线上产品，涉及了存储、计算、数据库、安全、大数据、人工智能等方方面面。阿里云是中国最大的云计算平台，不仅为自家的产品提供服务，同时也有微博、知乎等客户。

对于云服务，我们可以大致分成下面 3 种情况。

（1）SaaS：软件即服务

SaaS（Software-as-a-Service）为用户提供了对供应商云端软件的访问。用户无须购买软件，而是向提供商租用基于 Web 的软件，来管理企业经营活动。常见的比如邮件服务、ERP 系统、办公系统、疫情期间的远程协同工具等，这类服务都可以成为 SaaS 服务。SaaS 服务的定制化程度高，往往都是满足已经确定的需求，用户很难对其做个性化的改变。

（2）PaaS：平台即服务

PaaS（Platform-as-a-Service）为用户提供云环境，用于开发、管理和交付应用。除存储器和其他计算资源以外，用户能够使用预构建工具套件，开发、定制和测试自己的应用。PaaS 可帮助企业用户和开发人员，以本地部署解决方案无法企及的速度创建应用程序。

（3）IaaS：基础设施即服务

IaaS（Infrastructure-as-a-Service）处于更加底层的服务，比如服务器资源、存储资源、网络和计算资源，都属于 IaaS 服务。可想而知，IaaS 的灵活性更高，供应商只负责提供这些硬件资源，同样的，在开发和维护上的工作也就更多。

我们再拿熟肉电商平台的例子来说：

• 使用 IaaS 服务意味着省去了买服务器、搭建网络环境等环节，只需要在供应商提供的虚拟机器上搭建自己的开发环境，然后开始写代码；
• 而 PaaS 服务则不需要搭建开发环境，只需要按照供应商给出的开发指南进行开发；
• 而 SaaS 服务连开发步骤也省去了，只需要在供应商提供的网站的基础上，修改一下名称和图片就可以开始卖熟肉了。

云服务的好处

1.节约成本

使用云服务最大的好处就在于能够帮助你节约成本。像我们在讲的大数据体系，要想独立构建这样一套完整的体系需要很多的服务器资源、网络资源以及人力成本，直接使用云服务省去了自己构建的麻烦，只需要根据需求去进行应用就好了。

2.可扩展性

除了节约成本，可扩展也是云服务的一大好处。就像前面说的例子，在搞活动的时候我们可能需要比平时多十倍的机器和带宽，而在剩下的时间里，不需要那么多资源。而云服务的供应商有着充足的资源，当我们需要的时候，按需求进行扩展，比如说只购买一天的量来应对特殊的情况，而且这种扩展的成本往往都非常低，云服务供应商可以提供很好的无缝衔接。

3.紧跟最新技术

理所应当，如果使用云服务你就不需要关心升级和更新。云服务供应商对于技术方面往往都会做很多种版本的支持，这样你可以根据自己的需要进行选择。它会帮你配置好各种复杂的依赖，即使你想使用最新的版本也基本上可以得到满足，而不需要自己去解决细节问题。当然，在云服务的背后有强大的技术团队来进行支撑。

4.流动性

由于所有的操作都可以云端进行，比如你可以把数据放在云存储上，运算也可以使用云计算，甚至连交易平台也使用云上的服务，所以你只需要一个能够联网的设备，比如说笔记本，或者是一个 iPad，就可以进行办公。云服务使得流动性变得更好，你可以随时随地根据自己的需求进行连接。

5.故障恢复

你的云端设备可以匹配最佳的企业系统，如果服务器发生故障，它将自动将故障转移到另一台服务器，不会损坏你本来服务器的稳定性。在小型组织的 IT 环境中，这项技术是绝对无法实现的，因为实施这种故障转移将耗费巨大资金，并且消耗很多的时间。

大数据与云计算的关系

根据前面的介绍，我们可以了解到，使用云服务可以让我们以更低成本和更快速地构建起自己所需要的资源和服务。所以，通过使用云服务，我们可以把各种云端的软硬件资源和服务都当作软件来进行合理的使用。

而大数据架构的基本的特征，首先就是可以横向扩展，通过增加机器来满足原本单个机器无法处理的存储和计算的问题。譬如说我们所讲的 Hadoop 架构，它的高可用性是通过合理的软件设计和架构设计来实现的，而不是使用高端的硬件设备来实现的。

所以，从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。云服务中的虚拟化技术和弹性扩展能力可以支持大数据平台快速地扩展或者缩减存储和计算的资源。云存储为大数据提供了可扩展、高可用性、高持久性、安全的存储资源，保证了大数据平台的高效运行。

未来的趋势是，云平台作为计算资源和存储资源的底层，支撑着上层的大数据平台，而大数据的发展为云服务的落地找到了更多的实际应用。大数据和云的融合是重大的趋势，这两个技术是相辅相成的关系。

大公司为什么要做云服务

我们已经知道，对于个人，或者中小公司，选择云服务主要是为了能够低成本地使用大数据相关的技术，而当你的公司成长到一定的规模，本身就需要非常大规模的集群、存储和算力，需要雇用专业的人员来开发维护，同时对于业务也要有自己的解决方案。这个时候把空闲的机器资源发展成为云服务平台，业务方案也可以抽象成更为通用的方案做成云服务，这些东西一方面可以支持自己的业务发展，同时又可以出售给中小型公司和个人，从而为公司带来丰厚的利润。

就拿亚马逊来说，提到亚马逊，你可能会想到亚马逊电商、亚马逊电子书，然而亚马逊云服务才是其最大的利润来源。上图是 2017 年亚马逊一季度利润。可以看到在大约 10 亿美元的利润中，亚马逊云服务占了 89%。最近几年，阿里、腾讯等公司也纷纷加大了云服务的投入，希望能够通过这块业务带动公司整体业绩的增长。可想而知，在未来，云服务会更加普遍，更加多样化。

10 | 消息系统 Kafka 与 Flume 如何抉择

如果说数据就像我们的石油，在石油被开采之后，需要通过管道运输到储油罐中。这一讲，我们就来介绍一下大数据体系下承担着输油管道角色的工具——Kafka 和 Flume。

什么是 Kafka

首先，我们来看一下 Kafka 是什么。在大数据的架构中，数据的采集和传输是一个非常重要的环节，如何保障如此大批量的数据能够不重不漏的传输，当发生故障时如何保障数据的有效性，当网络堵塞时如何进行缓存，这需要相应的基础设施对其提供支持。

我们这一讲说的是消息系统，那么你自然也知道 Kafka 也是一个消息系统。所谓的消息系统其实很简单，就是把数据从一个地方发往另外一个地方的工具。当然，只说是消息系统还不能够体现出 Kafka 的优越性，Kafka 也有其自己的特色，它是一个高吞吐量、分布式的发布 / 订阅消息系统，然而最核心的是“削峰填谷”（后续会具体讲解）。

Kafka 支持多种开发语言，比如 Java、C/C++、Python、Go、Erlang、Node.js 等。现在很多主流的分布式处理系统都支持与 Kafka 的集成，比如 Spark、Flink 等。同时，Kafka 也是基于 ZooKeeper 协调管理的系统，说到这里，你可以再返回《05 | 大数据开发必备工具——Hadoop》中，看一下 Kafka 在大数据架构中所处的位置。

Kafka 的结构与概念

经过了简短的介绍，我们大致可以了解 Kafka 是什么了，在 Kafka 的基本结构中，有两个重要的参与者：

• 消息的生产者（Producer）；
• 消息的消费者（Consumer）。

如下图所示，Kafka 集群在消息的生产者和消费者之间建立起了联系的机制，来保障消息的运输。生产者负责生产消息，将消息写入 Kafka 集群，而消费者从 Kafka 集群中拉取消息，也可以称为消费消息。Kafka 所要解决的就是如何来存储这些消息，如何进行集群调度实现负载均衡，如何保障通信等等问题。

接下来我们介绍几个 Kafka 中重要的概念。

1.生产者与消费者

生产者负责将消息发送给 Kafka，它可以是 App，可以是服务，也可以是各种 SDK。

而消费者则使用拉取的方式从 Kafka 中获取数据。

每一个消费者都属于一个特定的小组（Group），同一个主题（Topic）的一条消息只能被同一个消费组下某一个消费者消费，但不同消费组的消费者可同时消费该消息。依赖这个消费小组的理念，可以对 Kafka 中的消息进行控制，如果需要对消息进行多个消费者重复消费，那么就配置成多个消费组，而如果希望多个消费者共同处理一个消息源，那么就把这些消费者配置在一个消费组就可以了。

2.消息

消息就是 Kafka 中传输的最基本的单位，除去我们需要传输的数据，Kafka 还会给每条消息增加一个头部信息以对每一条消息进行标记，方便在 Kafka 中的处理。

3.主题（Topic）

上面我们说到了主题，在 Kafka 中，一个主题其实就是一组消息。在配置的时候一旦确定主题名称，生产者就可以把消息发送到某个主题中，消费者订阅这个主题，一旦主题中有数据就可以进行消费。

4.分区（Partition）和副本

在 Kafka 中，每个主题会被分成若干个分区。每个分区是一个有序的队列，是在物理上进行存储的一组消息，而一个分区会有若干个副本保障数据的可用性。从理论上来说，分区数越多系统的吞吐量越高，但是这需要根据集群的实际情况进行配置，看服务器是否能够支撑。与此同时，Kafka 对消息的缓存也受到分区和副本数量的限制。在 Kafka 的缓存策略上，一般是按时长进行缓存，比如说存储一个星期的数据，或者按分区的大小进行缓存。

5.偏移量

关于偏移量的概念，我们可以理解成一种消息的索引。因为 Kafka 是一个消息队列的服务，我们不能对数据进行随机读写，而是要按照顺序进行，所以需要给每条消息都分配一个按顺序递增的偏移量。这样消费者在消费数据的时候就可以通过制定偏移量来选择开始读取数据的位置。

在我们平时的数据开发工作中，更多的往往是作为生产者或者消费者来使用 Kafka，而不需要关注 Kafka 系统的部署和维护，感知比较明确的就是上面说到的这些概念，基本都是我们在代码中需要进行配置的。当然，在 Kafka 中还有一些基本组成部分，比如代理、ISR 以及对 ZooKeeper 的使用等，如果你对 Kafka 有更加深入的学习需求，可以进一步查看这些内容。在我们加入了上面这些组成元素之后，我们再来看一下 Kafka 的结构图。

大致的流程为，生产者生产数据，然后把数据推送到 Kafka 集群中，并确定数据流的主题。Kafka 集群配合 ZooKeeper 集群完成调度、负载均衡、缓存等等功能，等待消费者消费数据。

Kafka 的特点

经过不断发展，Kafka 已经成为主流的消息队列工具，类似的工具还有 RabbitMQ、Redis 消息队列、ZeroMQ、RocketMQ 等等。

我们在前面说过，Kafka 最大的特色就是“削峰填谷”，这是它在应用上的特点，这里的谷和峰指的是数据流量的谷和峰，削峰填谷的含义即在数据生产方 A 和数据消费方 B 对数据流量的处理能力不同的时候，我们就可以使用 Kafka 作为中间传输的管道。那么在具体的设计上，Kafka 有什么特点呢，接下来让我们看一下。

1.消息持久化

Kafka 选择以文件系统来存储数据。很多消息系统为了提升大规模数据处理和快速传输的能力，并不会对数据进行持久化存储，或者只是缓存非常少量的数据，而 Kafka 会把数据存在磁盘上，一方面是磁盘的存储容量大，另外一方面是经过持久化的数据可以支持更多的应用，不管是实时的还是离线的，都可以进行支持。

2.处理速度快

为了获得高吞吐量，Kafka 可是下了不少功夫。我们知道硬盘是使用物理磁头来进行数据读写的，通常磁盘的速度都以转数来描述，比如 5400 转、7200 转。因为随机寻址的话，需要通过转动移动到下一个地址。但是由于 Kafka 是队列的形式，创造性地对磁盘顺序读写，大大增加了磁盘的使用效率，既获得了大存储量，又提高了速度。同时 Kafka 中还加入了很多其他方面的优化，比如通过数据压缩来增加吞吐量、支持每秒数百万级别的消息。

3.扩展性

与大数据体系中的其他组件一样，Kafka 也同样支持使用多台廉价服务器来组建一个大规模的消息系统，通过 ZooKeeper 的关联，Kafka 也非常易于进行水平扩展。

4.多客户端支持

前面我们也提到了，Kafka 支持非常多的开发语言，比如 Java、C/C++、Python、Go、Erlang、Node.js 等。

5. Kafka Streams

Kafka 在 0.10 之后版本中引入 Kafka Streams，能够非常好地进行流处理。

什么是 Flume

简单介绍完了 Kafka，我们再来看一下另外一个工具 Flume。

我们先回忆一下数据采集的过程：作为前端用户使用的客户端，不管是 App、网页还是小程序，在用户使用的时候，会通过 HTTP 链接把用户的使用数据传输到后端服务器上，服务器上运行的服务把这些回传的数据通过日志的形式保存在服务器上，而从日志到我们将数据最终落入 HDFS 或者进入实时计算服务中间还需要一些传输。

当然，这个过程有很多种实现方法，比如说在 Java 开发中，我们可以借助 kafka-log4j-appender 类库把 log4j（日志记录类库）记录的日志同步到 Kafka 消息队列，由 Kafka 传输给下游任务。然而这种方式比较简陋，并不太适合大规模集群的处理，因此，这里就有一个日志采集工具，那就是 Flume。

Flume 是一个高可用、分布式的日志收集和传输的系统。Flume 有源（Source）、通道（Channel）和接收器（Sink）三个主要部分构成。这三个部分组成一个 Agent，每个 Agent都是独立运行的单位，而 Source、Channel、Sink 有各种不同的类型，可以根据需要进行选择：

• Channel 可以把数据缓存在内存中，也可以写入磁盘；
• Sink 可以把数据写入 HBase；
• HDFS 也可以传输给 Kafka 甚至是另外一个 Agent 的 Source。

Flume 中的概念

1.源（Source）

Source 是负责接收输入数据的部分，Source 有两种工作模式：

• 主动去拉取数据；
• 等待数据传输过来。

在获取到数据之后，Source 把数据传输给 Channel。

2.通道（Channel）

Channel 是一个中间环节，是临时存储数据的部分，Channel 也可以使用不同的配置，比如使用内存、文件甚至是数据库来作为 Channel。

3.接收器（Sink）

Sink 则是封装好的输出部分，选择不同类型的 Sink，将会从 Channel 中获取数据并输出到不同的地方，比如向 HDFS 输出时就使用 HDFS Sink。

4.事件（Event）

Flume 中传递的一个数据单元即称为事件。

5.代理（Agent）

正如我们前面介绍的，一个代理就是一个独立的运行单元，由 Source、Channel 和 Sink 组成，一个 Agent 中可能有多个组件。

Kafka 与 Flume 的比较

可以看到，在数据传输方面，Flume 和 Kafka 的实现原理比较相似，但是这两个工具有着各自的侧重点。

• Kafka 更侧重于数据的存储以及流数据的实时处理，是一个追求高吞吐量、高负载的消息队列。
• 而 Flume 则是侧重于数据的采集和传输，提供了很多种接口支持多种数据源的采集，但是 Flume 并不直接提供数据的持久化。

就吞吐量和稳定性来说，Flume 不如 Kafka。所以在使用场景上，如果你需要在两个数据生产和消费速度不同的系统之间传输数据，比如实时产生的数据生产速度会经常发生变化，时段不同会有不同的峰值，如果直接写入 HDFS 可能会发生拥堵，在这种过程中加入 Kafka，就可以先把数据写入 Kafka，再用 Kafka 传输给下游。而对于Flume 则是提供了更多封装好的组件，也更加轻量级，最常用于日志的采集，省去了很多自己编写代码的工作。

由于 Kafka 和 Flume 各自的特点，在实际的工作中有很多是把Kafka 和 Flume 搭配进行使用，比如线上数据落到日志之后，使用 Flume 进行采集，然后传输给 Kafka，再由 Kafka 传输给计算框架 MapReduce、Spark、Flink 等，或者持久化存储到 HDFS 文件系统中。

11 | MapReduce 处理大数据的基本思想有哪些

前面我们已经知道 Hadoop 的两大核心：

• 分布式文件存储系统，这个我们已经介绍过了；
• 分布式计算框架，作为最早的分布式计算框架 MapReduce，就是我们这节课的主角。

回顾一下我在《05 | 大数据开发必备工具——Hadoop》中介绍的关于 MapReduce 的例子，如果我们要进行人口普查，一定不会说是从黑龙江数到海南，再从上海数到乌鲁木齐，把整个中国的人都数一遍，哪怕他是全世界数数最快的人，估计一辈子也数不完。

实际上，我们是先按照地区进行划分，把省的任务划分成若干个市的任务，把市的任务划分成若干个区县的任务，甚至划分到每个小区、每栋楼，作为最小的单位。给每个单位安排一个负责人，每个负责人只需要负责自己片区的人数统计，然后再由负责人逐级向上汇总，把所有人的统计结果汇总起来，就能得到全国的人口普查数据。如果说其中一个负责人有事情，不能完成，就可以换一个人继续这个地区的统计，而不会明显地影响全国的人口普查进度，这样的任务，哪怕是小学刚毕业的人都可以很好地完成自己片区的统计，这种分而治之的思想也就是MapReduce 思想的根源。

MapReduce 的架构

如果理解了上面的小例子，你也就理解了 MapReduce 的基本理念。MapReduce 即是采用了这种分而治之的处理数据模式，将要进行的数据处理任务分成 Map（映射）和 Reduce（化简）这两个处理过程。

在 Map 操作中进行数据的读取和预处理，把国家划分成地区，然后一个负责人负责一个片区，这就是 Map。统计之后负责人一起汇总结果，这就是 Reduce。

这样做最大的好处就是可以把大规模数据分布到普通性能的服务器中进行预处理，然后将处理后的结果重新进行整合，从而得到需要的结果。当然，要让这么多机器共同完成一项任务，还有很多细节的问题需要处理。

除了计算本身，MapReduce 还解决了协调这些集群中的服务器的问题，比如在若干台机器中执行运算的顺序、计算压力的分配、操作的原子性等等，如果让我们自己去编写一套程序那将是一个非常复杂的系统。但是 MapReduce 解决了这些问题，我们只需要关注如何把问题拆解成 Map 部分和 Reduce 部分就可以了。

跟 HDFS 一样的，MapReduce 也是采用主从结构的架构，架构图如下所示：

1.Job

Job 即是作业，一个 MapReduce 作业是用户提交的最小单位，比如说我们在下面即将动手运行的 WordCount 运算就可以称为一个作业。

2.Client

Client 就是客户端，是用户访问 MapReduce 的接口，通过 Client 把编写好的 MapReduce 程序提交到 JobTracker 上。

3.JobTracker

在 MapReduce 中，为了实现分布式的管理架构，使用了领导和随从的模式。而 JobTracker 就是这个体系中的领导。一个 MapReduce 集群只有一个JobTracker，这个节点负责下发作业，同时，它要收听来自很多 TaskTracker 的状态信息，从而决定如何分配工作。在这个集群中，JobTracker“既当爹又当妈”，而且只有一个，存在单点故障的可能，必须给它安排一个好点、稳定点的机器，不然如果它罢工了，将导致集群所有正在运行的任务全部失败。

4.TaskTracker

TaskTracker 在集群中则扮演了随从的角色，主要负责执行 JopTracker 分配的任务，同时 TaskTracker 通过 Heartbeat（心跳信息）汇报当前的状态，JobTracker 根据这些状态再进行任务的分配。随从是具体负责工作的，人多力量大，一个集群自然可以有多个 TaskTracker。在一个实际的节点上，会有一个 TaskTracker ，还有我们在 HDFS 环节介绍的 DataNode，这样，一个节点既是计算部分又是存储部分，在进行运算时，可以优先进行本机数据本机计算，从而提升效率。

5.Task

Task 称为任务，是在 MapReduce 实际计算时的最小单位，Task 有两种：MapTask 和ReduceTask，由 TaskTracker 进行启动。

6.Split

除了在图中出现的概念，还有一个 Split，称为一个划分，这是 MapReduce 处理的元数据信息，Split 会记录实际要处理的数据所在的位置、大小等等。在《07 | 专为解决大数据存储问题而产生的 HDFS》中，我们介绍了数据块的概念，Split 实际的数据就存储在 HDFS 的数据块中，通常我们会把 Split 的大小设置成与数据块大小一致，每次需要处理的数据存放在一个位置，这样可以减少不必要的网络传输，节约资源，提升计算速度。

了解完这么多概念，我们再回顾一下整个处理流程：

• 我们编写一个 MapReduce 程序，这可以称为一个 Job，在这个程序中往往包含较多的 Map 操作，和较少的 Reduce 操作；
• 通过 Client 把 Job 提交到 JobTracker 上，JobTracker 会根据当前集群中 TaskTracker 的状态，分配这些操作到具体的 TaskTracker上；
• TaskTracker 启动相应的 MapTask 或者 ReduceTask 来执行运算。

在具体的运算中，MapTask 读取 Split 的数据，根据事先写好的程序对其中的每一条数据执行运算，比如说后面的单词计数代码，我们输入的是若干文本文件，Map 操作处理每一行文本，并为一行中的单词进行计数，然后把结果保存下来。而在 ReduceTask 中，获取之前 Map 的预处理结果，并对数据进行分组，比如说相同单词分为一组，然后进行加和运算。对于 Reduce 的输出结果，会存储三个副本。

MapReduce 的特点

1.简化了分布式程序的编写

就像我们前面介绍的，MapReduce 解决了很多分布式计算的底层问题，使得开发者不用关心复杂的调度和通信问题，只把精力放在如何实现 MapReduce 过程就可以了。

2.可扩展性强

这是大数据处理框架的通用特点，只需要使用普通的机器就可以解决大规模数据处理的问题，当资源不足时只需要增加普通的机器节点就可以解决问题。

3.容错性强

在集群中，避免不了各种节点的故障问题，但是 MapReduce 会自动地处理这些问题，屏蔽故障节点，使用正常的节点重新处理问题，这些都不需要使用者关心，直到任务处理完毕。

MapReduce 的硬伤

虽然说 MapReduce 有非常多的好处，但是它的硬伤同样明显。

1.学习成本高

虽然说 MapReduce 已经处理了大量的分布式问题，但是仅仅是统计一些数据也要完全理解 MapReduce 的思想，学习编写一个 MapReduce 程序，这对于很多人是非常不友好的。我们前面讲到的 Hive 就是为了减轻这种问题而产生的，但是 MapReduce 仍然是非常底层的技术，而且不是所有的算法都可以使用 MapReduce 来实现，很多功能无法使用这种并行的方式来解决。

2.时间成本过高

MapReduce 是纯粹的批处理模式，也就是说所有的数据都是事先已经存储好的，MapReduce 只是对这些数据进行批量的处理，这对于互联网中大量的流式数据无法给到很好的支持，如果我们想要处理今天的数据，要等到今天的数据都已经存储好再进行计算，而不能随来随算。同时， MapReduce 的所有中间结果都是存放在磁盘中的，网络传输这些数据和磁盘读写消耗了大量的时间。

动手环节

创建三个文本文件

• f1.txt：hello world
• f2.txt：hello hadoop
• f3.txt：hello mapreduce

把刚才新建的三个文件从本地存储到 HDFS 中去：

hadoop fs -put input/f1.txt /input
hadoop fs -put input/f2.txt /input
hadoop fs -put input/f3.txt /input

接下来我们使用命令来执行官方提供的jar包的WordCount 程序：

hadoop jar ../share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.1.jar wordcount /input /output

注意，jar 后面的第一个参数是要执行的 jar 包路径，第二个参数是选择 jar 包中的程序，第三个参数是 HDFS 上的输入目录，最后一个参数是输出目录，由于 WordCount 的代码中会去创建输出路径，所以我们不需要提前创建好。

如果执行成功，我们可以通过输出的日志看到 MapReduce 过程执行完成，如下图所示：

执行成功之后，我们查看 output 路径下的结果：

hadoop fs -cat /output/part-r-00000

你可以看到如下结果：

hadoop  1
hello   3
mapreduce       1
world   1

这一结果已经对我们文本中出现的单词数量进行了统计。

总结

这一讲，我们介绍了 Hadoop 中的另一个核心模块 MapReduce，并且动手运行了一个示例程序。MapReduce 的思想虽然非常强大，但是从 MapReduce 的硬伤可以看出来，MapReduce 已经不太适合互联网的需求，在实际的应用中，现在 MapReduce 已经被更加强大计算框架所替代，比如 Spark 和 Flink。