大数据基础课04 大数据开发必备工具和来源

在前面的章节里，我们多次提到了 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 生态圈中的一些常用组件进行更加深入的介绍，到时见。

精选评论

**一：

请问老师，现在都说要测试驱动开发和自动化测试，那大数据开发里怎么做测试驱动开发和自动化测试呢？需要哪些技术栈，谢谢

讲师回复：

测试方面我工作中接触的不是很多，据我了解一般也是会有公司自己的统计平台，进行数据处理，查看统计的正确性；共用框架一般有uiautomator，appium然后公司自己二次开发。

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

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

传感器

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

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

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

爬虫采集

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

日志采集

最重要的一种数据采集的方式就是日志采集。在这个移动互联网的时代，基本上每个互联网公司的输出都以手机 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，到时见。

精选评论

**超：

您好老师，关于自动埋点，现在有什么成熟的解决方案吗，最近在找相关的东西，但是没找到…

讲师回复：

你好，埋点的作用就是记录日志用于后面的数据分析和挖掘，埋点框架一般也是针对特定的需求，或者通用功能进行开发，我了解好像也没有特别常用的，可以看一下heap，mixpanel，growingIO，大公司一般会自己开发公司内的通用埋点框架，但是也只是管理最常用的埋点需求，比如网易Hubble。

**前：

老师您好：请问，大数据中的数据，一大部分应该是各业务系统产生的数据吧？文章中是不是缺少这一部分数据？

讲师回复：

您好，业务系统的数据其实也是来源于业务的用户。