大数据开发基础课

开篇词-如何在庞大的大数据体系中明确路径

模块一：大数据简介

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

模块三：大数据开发

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

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

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

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

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

12 | Spark 与 Flink 的爱恨情仇（上）

13 | Spark 与 Flink 的爱恨情仇（下）

模块四：大数据挖掘与分析

16 | 计算机视觉 VS 自然语言处理，你选哪个？

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

从今天开始，我们就正式进入大数据基础的学习课程。正如我在开篇词中介绍的，这个专栏的目标是：

让你能够快速地了解大数据体系的全貌；
建立大数据时代的思维模式；
能学习到一些简单的大数据工具使用方法。

那么达到这些目的的第一步是了解什么是大数据，即先来解决 “What” 的问题。

在定义 “大数据” 之前，我们先来回顾一下这些年关于天气预报的一些变化。

天气预报的变化

小时候我们家每天晚上都要看新闻联播，但主要目的不是了解国家大事，而是等着看新闻联播后的天气预报。那时获取天气情况基本上就只有这一个渠道，每天晚上看一下第二天的天气情况，为即将的出行做准备。这可能是我这一代人共同的童年记忆。

但那时的天气预报只能对后一天的天气进行一个大概预估，包括最高温、最低温、阴晴雨雪等，精确度还比较低。比如天气预报说明天会有降雪，但是究竟会不会下雪，下多大的雪，都是一个未知数。但不出意外，老师会告诉你：明天带铁锨过来！

而现在，我们随时随地都可以打开一个天气 App：

不仅可以看到明天的天气预测，甚至还可以看到后面长达 40 天的预测；
而对于最近 1～2 天的天气情况，可以精确到小时，甚至是分钟级别；
除了阴晴雨雪，还有实时的湿度、气压、紫外线指数等各项详细信息。

在日常生活中，尤其是面临突发状况时，这么精准而详细的天气预报可以起到非常有效的防范作用。比如前阵子哈尔滨发布暴雪警告，并宣布受降雪影响较大的地区学生停课，而影响较小的地区则可以根据实际情况自行决定，这在很大程度上减少了极端天气带来的损失。你看这是多么幸福的一个时代——智能、便利。

为什么在开篇我要提 “天气预报” 呢？

因为气象预测是一个浩大的工程，尤其是在我们这样一个幅员辽阔的国家。

过去实况数据的采集和传输工作大部分都要靠人力完成。气象观测员每天要定时记录百叶箱内的温度、湿度等，并通过打电话、发电报等方式将全国的观测数据进行汇总。
而现在，只需要在各个位置投放气象相关的传感器，并把这些设备接入网络中，然后用后端服务器对这些上传的数据进行收集和计算，就可以自动化地实现过去需要耗费大量人力和时间才能完成的事情。

这就是大数据系统的应用给我们的生活带来的变化。

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

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

（1）底层硬件的支撑

1997 年，我拿到的第一台电脑内存只有 16 MB，硬盘只有 2 GB。放现在来看，这样的配置就是一个 “笑话”，但在当时，这已经算是一个中等偏上的个人电脑配置了。而就是这样一台电脑，在那个年代竟然要花 7000 元，这个价格在今天随随便便都可以配一个 16 GB 内存、2 TB 硬盘的机器，内存和硬盘的容量增加了 1000 倍！更别说，虽然都是 7000 元，但是二十多年前一元钱的购买力是明显超过现在的。

我记得当时用电脑玩《三国群英传》的游戏，100+ MB 的存储大小还需要我对硬盘各种清理才能有空间容纳，而现在一个游戏动辄几十个 GB，我们的电脑存储起来都不在话下。

可见，我们的数据存储成本比起二十多年前已经极低极低了。

也正是这样，在气象相关的数据收集上，不再是只能保存重要数据，而是可以保存更多更完整的数据，到需要用到的时候，就可以取出来进行挖掘分析。

当然，除了存储以外，计算性能、网络带宽，这些年都在快速地发展，这些都为大数据的运算处理以及大数据集群的构建提供了有力的硬件支撑，在这方面我想你也有非常深刻的感受。

（2）数据生产方式

在硬件发展利好的基础上，数据生产的方式也随之发生了巨大的改变。

就拿自己工作的环境来说，我最早在互联网新闻行业做开发。

在过去，新闻都是由专业的编辑采编而成，全国上下大大小小的新闻报社机构以及互联网编辑，一天最多也就能生产 10000～20000 条专业的新闻。

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

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

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

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

大数据的 4 个重要特点

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

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

（1）大量数据

要说大数据数量多，这是无可争议的。正如我们上面所说的，硬件的发展及数据生产方式的变化，使得数据的数量急剧膨胀。使原本散落的信息变得连贯起来，并不停地生产，不停地交换。有一种说法是，最近两年所产生的数据量与过去人类产生的数据总量基本一致，而且在接下来的一段时间里，仍将继续保持这样快速的增长速度。

（2）种类繁多

现在的数据不再局限于一些精密的数字，你写的一段话、拍下的一张照片、录制的一段音频或者视频，都是大数据的组成部分。这些主要源于我们的视觉、听觉，在不久的将来，我们的触觉、味觉、嗅觉等数据也会进入机器获取的范畴，从而形成完整的数据获取体系。

（3）高速

在大数据的背景下，所有环节都变得更快了。这里的高速不单单指数据的生产速度，还有数据的交换速度、处理速度等。比如，当你在京东商城浏览商品的时候，你的每一次点击都会以毫秒级的时延传输到服务器上，而服务器集群又会根据你的这些行为，迅速地为你推荐出新的商品，在你下一秒的浏览内容中展示出来。显然，如果这个过程太慢，可能还没等后台的数据计算完成，你就已经关掉了京东转头去了淘宝，那岂不是会损失客户？所以，高速也是大数据体系一直不懈追求的目标。

（4）数据价值

我们拥有了大量数据，一定是期望这些数据能给我们带来一些价值。显然，大数据是有价值的，但是大数据价值有一个特色——价值密度低。

比如，危险品生产车间的监控摄像头在 24 小时不间断地记录并回传着数据，但是这些数据通常都是毫无变化的，它日复一日地记录着，每隔一段时间就需要删除一些，以便腾出存储空间。当出现异常的时候，比如说在视频中发现了高温点，可能是车间中存在火苗，这个时候需要立即调用消防系统对火苗进行扑灭，从而防止危险发生。像这种存在价值的数据可能只是摄像头记录的一个微小片段，所以说数据的价值密度较低。

以上就是大数据的一些重要特点。也就是说，符合这些特征的数据，我们基本可以认为是 “大数据”。

大数据的工作环节

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

（1）数据的采集

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

（2）数据的存储

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

（3）数据的计算

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

（4）数据挖掘与分析

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

（5）数据的应用

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

（6）数据安全

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

总结

这一讲，我们以天气预报的变化为例，讲解了大数据的特点及工作环节。

经过这一讲的介绍，我希望你对什么是大数据有了一个初步的印象，最好还能够有一些自己的思考。大数据这个词并不是单纯地表示数据量大，同时它还有很多其他的特点，并且形成了一个概念体系。虽然大数据到现在并不成熟、并不完善，但是它确实已经深入到我们生活的各个部分。

当然，尤其对于我们这些在互联网行业摸爬滚打的人，大数据切切实实地在我们的工作中占据着举足轻重的地位。

那在你的生活和工作中，哪些都应用到大数据呢，你可以根据本讲所学分析下它们的特点表现在哪些方面，欢迎在评论区留言。

下一讲，我们将学习 “从萌芽到爆发，大数据经历了哪些发展”，让我们下一讲再见。

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

在上一讲中，我就什么是大数据做了简要的介绍，涉及大数据的主要步骤，以及每个步骤要解决什么样的问题。相信你对大数据已经有了一个初步的认知。这一讲，让我们一起来探讨下大数据的发展过程，看看大数据这个词最初起源于哪里，经历了什么样的变化，最后，随着大数据的发展，我们该如何选择学习路径。

大数据的发展过程

萌芽阶段（1980-2007）

说起萌芽，一般都是这样的一个 “套路”：某位知名人士首先创造性地使用了一个新的词汇，然后这个词逐渐流传开来，成为某件重要的事情。大数据也不例外。

早在 1980 年，大数据这个词被阿尔文 · 托夫勒写在了他的新书《第三次浪潮》里，不仅如此，他还声称大数据是第三次浪潮的华彩乐章，这就是大数据一词的由来。阿尔文 · 托夫勒是一位著名的未来学家，他非常成功地预测了大数据的爆发。

随着时间的推移，到 2000 年，最早在网络上兴起的论坛和博客开始引起大众的兴趣，随后，各种社交网络、自媒体逐渐开始壮大，2008 年 9 月《自然》杂志也推出了名为 “大数据” 的封面专栏。象征着大数据概念已经成为大家普遍认同的事实。这个阶段，大数据正式诞生了。在这个时间段的中国，以腾讯、网易、新浪、搜狐、百度为代表的主流互联网公司，依赖社交、搜索、门户等产品迅速崛起。

虽然说大数据这个词已经成为科技行业的热门词汇，但是面对技术的变革，很多公司还没有明白，自己做的事情跟大数据到底有什么关系，大数据该如何从一个概念落地到工程生产中。2004 年前后，谷歌发表了三篇论文，也就是我们常说的大数据三驾马车：

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

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

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

但论文的公布，只是一种思想和方案的共享，谷歌并没有公开自己的技术细节。

随后一个叫作 Doug Cutting 的码农开了一家小公司，想要做一个超越谷歌搜索的开源搜索引擎，尽管当时的谷歌搜索基本是独步天下的状态了。他先是开发了一个叫 Nutch 的项目，但随着谷歌公布的三驾马车论文，他将目标转向实现 GFS 和 MapReduce 方案，并想办法融合进自己的 Nutch 项目里。后来这个模块被雅虎看中了，于是 Doug Cutting 带着他的项目加入了雅虎，顺手拿了他儿子的一个大象玩具给这个项目命名为 Hadoop。

由于 Hadoop 是一个开源项目，在那个大数据技术刚刚兴起的时间点，受到了众多公司的追捧，并在 2008 年成了 Apache 的顶级项目。至此，大数据生态体系逐渐形成，主流互联网公司开始上马相关的项目。

很快，移动互联网时代到来了。2007 年，苹果推出了第一代 iPhone，开创了智能手机的先河。同年底，谷歌也发布了 Android 手机操作系统。2008 年支持 3G 网络的 iPhone 问世，并加入了 App Store 功能。随后，各大互联网公司将自己的战略重心由 PC 端转移到移动端，实时，大批量的数据源源不断地产生。

不断爆发（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、爬虫、实时、分布式等。

当然，除了上面这三个大的方向，在整个互联网大数据体系中，还有非常多的细分方向，甚至每一个关键词都可以作为一个方向考虑。随着大数据的发展，我想在未来还会有更多各式各样的岗位等待着你。

总结

这一讲我们主要学习了大数据的发展过程。总的来说，大数据并不是一个特别的东西，而是在互联网时代必然的产物。从大数据概念的提出到现在有四十年的时间，但是我们可以预见，大数据的发展绝对不会止步于前，甚至可以说，大数据的发展才刚刚步入正常的轨道。

同时，根据我自己的经验，列举了在当前互联网公司中，大数据相关的工作方向，如果你对其中的内容感兴趣，抑或是想入行大数据，可以选择一个方向深入地了解和学习。在此过程中，有任何问题都可以在交流区留言。

希望通过这一讲的学习，你对大数据的了解又深入了一个层次。下一讲，我们将学习 “为了追赶当下趋势，我们要做什么思想准备”。

大数据思维

首先，我想讲一个叫庖丁解牛的故事，想必你应该听过。庖丁从开始杀牛，到他的故事被写下，操刀十九年，杀了数千头牛。也正是由于丰富的实践经验，他总结出了解杀牛的方法论：依照牛生理上的天然结构，砍入牛体筋骨相接的缝隙，顺着骨节间的空处进刀。依照牛体本来的构造，筋脉经络相连的地方和筋骨结合的地方，都不曾被刀碰到过，更何况大骨呢！这样，能够顺利地把牛解开，还不会对刀造成损害。所以，他明白了最核心的思维，即顺应天然结构，这种思维成就了他的大厨身份。反之，如果对于一个没有这种思维的人，即便是拿着最锋利的刀，面对一头完整的牛也会手足无措。

每个行业都有每个行业的思维方式，这些思维暗示着行业运转背后的规律。当我最初了解到这些思维方法，我还是一个行业新人，对其中所讲的内容一知半解，不置可否，而今天，当我再次回顾这些方法的时候，感到醍醐灌顶，无比认同。这些思维方式往往经过很多对这个行业的深入研究，并且能够通过现象看到本质的大师结合自己的经验总结而成的。

那么接下来，就让我们看一下，在大数据时代，有哪些思维方式可以帮助我们快速进入工作状态。

全量思维

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

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

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

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

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

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

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

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

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

容错思维

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

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

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

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

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

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

高可复用

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

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

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

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

这些还都仅仅是在公司内部的复用，这里给你留一个小小的思考，打车数据是否还可以用来做一些 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 ）不完善

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

总结

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

在案例后面，我根据案例的情况总结了大数据体系的发展趋势，当然，不管是模块化、平台化还是实时化，其实都是对效率提升和降低成本的追求。

你可以根据我们这讲所学分析下你所在的公司的大数据框架，或者其他一些比较庞大的大数据体系，有什么问题，可以在评论区留言。

我觉得，虽然大数据体系已经有了很大的发展，但是仍然是不完善的，在以后的时间里仍然可能发生很大的变化。当然，这些都是依据我自己的一些经验，并不一定是最正确的。

下一讲，我们来看一下提到过很多次的 Hadoop 框架是如何构建的。

Hadoop 体系

在前面的章节里，我们多次提到了 Hadoop 这个名称，想必你也大概知道了 Hadoop 是一个用于大数据的架构解决方案。关于 Hadoop 的理论基础以及是如何诞生的，我们在《02 | 从萌芽到爆发，大数据经历了哪些发展》中做了简要的介绍。那么，这一讲我们就从整体上来看一下 Hadoop 到底是怎样的。

Hadoop 的整体架构

经过了这么多年的开发与演进，Hadoop 早已成为一个庞大的系统，它的内部工作机制非常复杂，是一个结合了分布式理论与具体的工程开发的整体架构。对于没有什么经验的人来说，Hadoop 是极其难理解的。不过，我们这一专栏并不是要把 Hadoop 的运行机理讲清楚，而是明白 Hadoop 为我们提供了什么样的功能，在我们整个大数据流转的过程中可以发挥哪些作用就可以了。

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

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

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

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

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

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

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

思考一下我们刚刚进行过的人口普查，先把这个大任务按照地区划分成若干个小任务，每个地区找一名负责人，确保地区的划分不重不漏。然后由这个地区的负责人负责统计自己区域内的人员数量等信息，然后把所有人的统计结果汇总起来，就能得到全国的人口普查数据。如果说其中一个负责人有事情，不能完成，就可以换一个人继续进行这个地区的统计，而不会明显地影响全国的人口普查进度，这其实就是最朴素的 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 在经过不断的发展之后也已经形成了自己的生态圈，很多不同的组件都可以与 Hadoop 搭配使用。很多公司都基于 Hadoop 框架搭建起了自己的大数据处理体系。目前，免费的 Hadoop 版本主要有三个：

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

当然，所有的版本都是基于 Apache 版本进行改进的，而 CDH 版和 HDP 版则附加了很多新的特性，解决了一些工业级应用时的痛点。如果你所在的公司需要做一些这方面的建设，不妨再对几个不同版本进行一下比较。在该过程中有任何问题或者心得，都可以在留言区和我一起探讨。

下一讲我们还会对 Hadoop 生态圈中的一些常用组件进行更加深入的介绍，到时见。

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、小程序为数据源，通过用户的访问日志进行数据的收集。在收集数据的时候，有很多方法，也有很多困难，但是我的建议是尽量选择那些能够保障数据一致性的方法，这样在后续的数据处理、数据应用环节才能够更加快速有效。如果你的日志收集工作没有做好，后面的数据就会一团乱麻，那么大数据体系将无从提起。

在这一讲中，希望你已经了解了数据获取的基本方式以及与埋点有关的信息。当然，在实际的工作中，关于数据获取还有很多细节的事情需要处理，那还需要你不断地摸索，不断地学习。在此过程中，有任何问题或者心得，欢迎在评论区和我交流。

下一讲，我将与你一起讲解 Hadoop 体系中的文件系统 HDFS，到时见。

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

上一讲中，我们了解了在互联网公司中，数据一般都是从哪里来，以及如何进行数据的采集。而数据采集完成后需要进行长期的保存，以备我们在日后的生产活动中进行各种分析和使用，这就涉及了文件系统的问题，所以在这一讲中，我们就来讲解一下在 Hadoop 体系中的文件系统 HDFS 是如何运转的，同时，我们要动动手，搭建一个简单的 Hadoop 系统，并使用简单的命令感受一下 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 的基本构成，下面进入我们的动手环节。因为 HDFS 已经集成在了 Hadoop 系统中，所以我们来尝试安装一个单节点的 Hadoop 系统，然后就可以进行 HDFS 操作了。

动手安装 Hadoop

首先介绍一下，我使用的机器操作系统是 Windows 10。因为 Hadoop 需要 Java 的支持，我们先看一下电脑上是否已经安装了 JDK，并且配置好了环境变量。

进入 CMD 命令提示符中，使用下面这个命令查看 Java 版本，如果显示正常，说明已经安装了 Java，并且配置了环境变量。

C:\Users\userxxx>java -versionjava version "1.8.0_231"Java(TM) SE Runtime Environment (build 1.8.0_231-b11)Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)

在 Windows 8 及以上版本，如果你的 Java JDK 安装在了 Program Files 路径下面，需要注意使用下面的方式来调整你的环境变量路径，否则我们的 Hadoop 配置会无法识别。

用 “Progra~1” 替代 “Program Files”用 “Progra~2” 替代 “Program Files(x86)”

由于在 Windows 系统下支持得并不是很好，原生的 3.2.1 版本可能需要做一些调整，我这里把调整好的项目放到了云盘上（提取码：k132），你可以下载我已经打包好的。

下载完，把文件解压到自己的电脑上，比如我这里是放在 D:\，打开 CMD 命令提示符，然后进入 Hadoop 的 bin 路径，如下所示：

D:\hadoop-3.2.1\hadoop-3.2.1\bin>

使用命令 Hadoop Version，如果正常可以看到如下版本信息：

Hadoop 3.2.1Source code repository https:Compiled by rohithsharmaks on 2019-09-10T15:56ZCompiled with protoc 2.5.0From source with checksum 776eaf9eee9c0ffc370bcbc1888737This command was run using /D:/hadoop-3.2.1/hadoop-3.2.1/share/hadoop/common/hadoop-common-3.2.1.jar

接下来我们需要修改几个配置文件，让 Hadoop 进行最基本的启动。

（1）修改 D:\hadoop-3.2.1\hadoop-3.2.1\etc\hadoop\core-site.xml 为：

<configuration><property><name>fs.defaultFS</name><value>hdfs://localhost:9820</value></property></configuration>

（2）修改 D:\hadoop-3.2.1\hadoop-3.2.1\etc\hadoop\mapred-site.xml 为：

<configuration><property><name>mapreduce.framework.name</name><value>yarn</value></property></configuration>

（3）修改 D:\hadoop-3.2.1\hadoop-3.2.1\etc\hadoop\hdfs-site.xml 为：

<configuration><property><name>dfs.replication</name><value>1</value></property><property><name>dfs.namenode.name.dir</name><value>file:///d:/hadoop-3.2.1/hadoop-3.2.1/data/dfs/namenode</value></property><property><name>dfs.datanode.data.dir</name><value>file:///d:/hadoop-3.2.1/hadoop-3.2.1/data/dfs/datanode</value></property></configuration>

这里的 value 为 1 表明我们构建的系统只有一个节点，同时，定义了我们的 NameNode 根目录和 DataNode 根目录。

（4）修改 D:\hadoop-3.2.1\hadoop-3.2.1\etc\hadoop\yarn-site.xml 为：

<configuration><property><name>yarn.nodemanager.aux-services</name><value>mapreduce_shuffle</value><description>Yarn Node Manager Aux Service</description></property></configuration>

然后输入 hadoop namenode-format，应该能看到这样的结果：

选择 Y，可以看到执行成功，如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pGTVegaK-1657698673438)(https://s2.loli.net/2022/07/13/719fpLv5oEyuFwR.png)]

然后在 sbin 目录下输入 start-all，会有多个 CRM 窗口被创建，此时输入 jps，可以看到如下结果：

在浏览器中输入 http://localhost:9870/dfshealth.html，你可以看到如下界面：

输入 http://localhost:9864/datanode.html，你可以看到如下监控界面：

输入 http://localhost:8088/cluster，你可以看到如下管理界面：

当年看到这些界面，说明已经部署成功了，我们已经创建了有 1 个节点的 Hadoop 系统。在课后，你可以尝试使用虚拟机来创建具有多个节点的 Hadoop 系统，那么在配置上会有什么不同呢，这个留给你自行探索。

如果你要关闭 Hadoop 服务，记得在 sbin 路径下使用命令：

接下来，我们使用已经部署好的 Hadoop 系统来进行一些 HDFS 的文件操作。

HDFS 简单使用

根据部署的服务，我们的 HDFS 根目录是 hdfs://localhost:9820，下面我们尝试在根目录下面创建子目录 user，如下命令所示：

D:\hadoop-3.2.1\hadoop-3.2.1\bin>hadoop fs -mkdir  hdfs:

创建目录使用的是 mkdir，接着我们来列出根目录下面的详情，看是否创建成功了。详情如下所示：

D:\hadoop-3.2.1\hadoop-3.2.1\bin>hadoop fs -ls  hdfs:Found 1 itemsdrwxr-xr-x   - LonnyHirsi supergroup          0 2021-01-23 17:49 hdfs:

可以看到，这里显示根目录下有一个项，就是我们刚创建的 user 目录。从这两个命令可以了解，HDFS 的文件操作命令与 Linux 的文件操作命令基本相同。

不过要注意，HDFS 中的路径只能一层一层创建，如果我们尝试下面的命令，会得到一个错误信息。

D:\hadoop-3.2.1\hadoop-3.2.1\bin>hadoop fs -mkdir  hdfs:mkdir: `hdfs:

这是因为我们的根目录下面还没有 data 目录。

除了这些命令，HDFS 的操作还有：

显示文件内容的 cat 命令；
上传文件的 put 命令；
下载文件的 get 命令；
移动文件的 mv 命令；
删除文件的 rm 命令；
……

如果你需要学习这部分内容可以找一本相关的书籍进行更深入的学习，在这个课程中我们就不再过多地进行介绍了。

总结

这一讲我们讲解了 HDFS 文件系统，它是 Hadoop 体系两大核心基石之一，主要负责存储的部分。另外一部分解决计算问题的 MapReduce 我们会在《11 | MapReduce 处理大数据的基本思想有哪些》详细介绍。

在介绍了 HDFS 的基础架构之后，我们安排了一个实践环节，也就是动手安装 Hadoop 系统，当然我们这里安装的是单机单节点，希望你也能够亲自去尝试一下，甚至是用虚拟机搭建一个小型的多机环境以熟悉 Hadoop 的实际情况，在此过程中有任何问题，都欢迎与我进行交流。

课程的最后，简单介绍了 HDFS 的一些使用命令，可以看到跟我们平时在 Linux 系统中使用的文件处理命令基本相同，HDFS 帮我们屏蔽了后端存储的细节，让我们能够顺畅地使用。

下一讲，我们将讲解在 Hadoop 体系中与存储相关的两个项目：数据库 HBase 和数仓工具 Hive，让我们下一讲再见吧。

doop-3.2.1\bin>hadoop fs -mkdir hdfs:


创建目录使用的是 mkdir，接着我们来列出根目录下面的详情，看是否创建成功了。详情如下所示：

D:\hadoop-3.2.1\hadoop-3.2.1\bin>hadoop fs -ls hdfs:

Found 1 items

drwxr-xr-x - LonnyHirsi supergroup 0 2021-01-23 17:49 hdfs:


可以看到，这里显示根目录下有一个项，就是我们刚创建的 user 目录。从这两个命令可以了解，HDFS 的文件操作命令与 Linux 的文件操作命令基本相同。不过要注意，HDFS 中的路径只能一层一层创建，如果我们尝试下面的命令，会得到一个错误信息。

D:\hadoop-3.2.1\hadoop-3.2.1\bin>hadoop fs -mkdir hdfs:

mkdir: `hdfs:


这是因为我们的根目录下面还没有 data 目录。除了这些命令，HDFS 的操作还有：*   显示文件内容的 cat 命令；*   上传文件的 put 命令；*   下载文件的 get 命令；*   移动文件的 mv 命令；*   删除文件的 rm 命令；*   ……如果你需要学习这部分内容可以找一本相关的书籍进行更深入的学习，在这个课程中我们就不再过多地进行介绍了。### 总结这一讲我们讲解了 HDFS 文件系统，它是 Hadoop 体系两大核心基石之一，主要负责存储的部分。另外一部分解决计算问题的 MapReduce 我们会在《11 | MapReduce 处理大数据的基本思想有哪些》详细介绍。在介绍了 HDFS 的基础架构之后，我们安排了一个实践环节，也就是动手安装 Hadoop 系统，当然我们这里安装的是**单机单节点**，希望你也能够亲自去尝试一下，甚至是用虚拟机搭建一个小型的多机环境以熟悉 Hadoop 的实际情况，在此过程中有任何问题，都欢迎与我进行交流。课程的最后，简单介绍了 HDFS 的一些使用命令，可以看到跟我们平时在 Linux 系统中使用的文件处理命令基本相同，HDFS 帮我们屏蔽了后端存储的细节，让我们能够顺畅地使用。下一讲，我们将讲解在 Hadoop 体系中与存储相关的两个项目：数据库 HBase 和数仓工具 Hive，让我们下一讲再见吧。