1.1 理解大数据（1）

目录

1.1 理解大数据

【注】自问自答是咱们的博客的写作风格：因为我接触的很多小伙伴基础都比较拉跨，于是就尝试用白话让知识和技术更容易被人理解和接受，希望大家习惯这样的表述风格。

1.1.1 核心问题

step_0   生活中数据无处不在，且有的时候体量巨大。

举例子：
金融：证券交易、股票、期货
社交：微信、QQ、微博、Facebook
搜索引擎
电商平台
科学实验数据 …
【Q0】人们不禁要问：这些数据有什么用？
【A0】可以分析这些数据、尝试找规律，进而给出类似问题的预测、或是应对策略。
==> 其实这就是大数据的核心工作，简单明了。

step_1   很多资料中常常提及“海量数据”一词，这又是一个什么概念？

首先需要了解描述数据体量的单位：
（1）bit < Byte < KB < MB < GB < TB < PB < EB < … 这个可以自行百度，不用记忆。
（2）仅在TB之后才勉强算是“海量数据”，也就是人们常说的“大”数据。
（3）别忘了单位换算：1 Byte = 8 bit，其余都是1024（即1k）

接着要顺着Linux的设计哲学去理解文件和数据之间的关系：
（1）一切数据皆可以文件的形式存在，即：文件可以指代数据。
（2）若用文件表述海量数据，那么可以具象为两种形式，即：文件体积大 or 文件数量多
【注】这个表述第一次看或许不能理解，但等学完HDFS之后就豁然开朗了！

接下来咱们据几个例子（均摘自《大数据算法设计分析》）

e.g1：美国国防部高级研究计划局（DARPA）建立的实时地面监测系统每年产生19ZB（1ZB≈1021B）的检测数据。

e.g2： 欧洲原子能研究机构（CERN）于2008年再位于法国与瑞士边界的日内瓦近郊建成了大型电子对撞器（Large Hadron Collider，LHC），LHC每年产生10ZB实验数据。

e.g3： 中国航空公司拥有的波音737飞机远超160架，如果每架飞机每天飞行10h，每年产生的发动机检测数据就可以超过283.5EB（1EB≈1018B）。

e.g4：北京市市区配置的电子眼超过40万个，每天工作24h，每年产生大于1.4EB的检测数据。

e.g5：北京市出租车超过6.7万辆，每年这些出租车生产大于48PB的GPS数据。

e.g6：全国铁路5T系统每天采集90.3TB（1TB≈1021B）的图片、2.1TB温度数据、15.6TB的音频数据、3.8TB的运行状态数据，每年产生总计40.8PB的数据。

e.g7：中国电信用户上网日志数据和通话记录数据每年大于29.2PB。

step_2 核心问题：海量数据的存储 与 海量数据的运算

为什么说：“海量数据的存储 与 海量数据的运算” 是大数据的核心问题呢？咱们可以举几个例子引导大家思考：

（1）海量数据的存储

e.g1：个人电脑硬盘扩容，服务器硬盘扩容？

==>这例子告诉我们：磁盘空间有上限，叠硬件不是好的解决方案，这是一个人们普遍接受的事实。

（2）海量数据的运算

e.g2：用Excel查询/筛选/核算 1万条数据 VS 1000万条数据？

e.g3：海量数据中快速查询目标信息？

e.g4：面对海量数据文件或者大体量的单个文件，如何高效读写，将I/O时间挤出来让给计算？

==>以上3个例子告诉我们：很多问题在数据体量不大的时候，往往被人忽视；一旦数据体量上来，反而成为了瓶颈。

【结论】面对海量数据的存储和计算，以往的处理手段不再有效，需要重新思考解决问题的方案，甚至整理出一套的理论去指导如何进行可靠的大数据存储和高校的大数据计算。

1.1.2 研究目标

step_0  讨论存储解决方案

咱们沿着之前单机存储空间有限的话题继续往下聊：

【Q1】若不愿意通过堆叠硬件以解决存储空间有限的问题应该怎么办？
【A1】可以使用多台计算机（服务器）一起参与数据的存储，让它们联网。

【Q2】若文件体量很大，一台设备存储不了怎么办？
【A2】考虑把文件数据拆分成合适的大小，如A1中的描述分开存储在多个设备中。

【Q3】若此种拆分操作是可行的，那么应该遵循什么样的拆分策略呢？
【A3】暂时没有具体的思路，但应该保证被拆分的数据最后能恢复成原来的样子。

以上三个Q&A的示意图如下：

【Q4】既然希望分开存储的多个部分数据最后能够恢复出完整的数据，逆向思考：若其中一台设备挂掉了，拿不到完整的数据或者导致部分数据丢失应该怎么处理？
【A4】可以设计一些冗余存储策略，即每台设备都多留一部分其他设备存储数据的备份。

【Q5】若数据是可以拆分的，那么何时需要将数据重新组合在一起，并被取出？且如果有一些设备上的部分数据发生了变化，如何保证这些备份的数据一致性？如果考虑加入数据库那应该注意些什么呢？…

对以上问题，我们在讨论过程中并不要求给出一个非常精准的回答，虽然前4个问题基本上都能给出一个合适的解决思路，但面对Q5的连环提问已经有些吃力了；提问的逻辑链很清晰，若正面回复则需要思考很多细节实现，不过目前我们能得到两个阶段性的推论：
【推论1】我们或许需要一种新的文件系统去存储海量数据。
【推论2】同理，或许也需要一种新的数据库去存储海量数据。

如上图，考虑到我们的讨论是基于众多设备可以联网的前提下的，自然会联想到一个术语——“分布式”，且在后面的学习中我们可以看到分布式文件系统对应解决方案的就是HDFS，而分布式数据库则对应HBase。哈哈，Hadoop的两个重要组成部分就这样被空想出来了！

step_1  讨论计算解决方案

假设数据可拆分，基于此我们讨论一下计算任务拆分的可行性。

【Q6】如何拆分计算是比较合理的呢？
【A6】假设计算跟着被拆分的数据走，岂不是可以通过计算的本地化，节省网络传输数 据的带宽？每个设备仅计算一部分数据，效率也提升了嘛！
【但】上述设想有一个问题有待解决，即如何汇总每一部分的计算结果得到最后中的计算结果呢？

【Q7】若Q6的假设成立，接着畅享：因为计算是在多个设备上进行的，那么对拆分后相互独立的计算任务，完全可以采取并行策略提升计算效率。但也可能存在拆解后的计算任务必须顺序执行的情况，即等待某一部分数据的计算结果，或者某一步计算完成后才能继续下面的工作。则面对复杂的计算任务调度问题，我们应该怎办？
【A7】或许我们需要一个适应分布式场景的计算任务调度器。

【Q8】类似的，执行计算任务需要占用资源（CPU、内存、磁盘、带宽等），我们又应该调度这些资源呢？
【A8】或许我们需要一个适应分布式场景的资源调度器。

【Q9】继续思考，如果计算任务执行过程中，有的任务挂掉了，它们能否被检测到？若能检测到，是重新执行整个任务，还是从某一计算步骤开始重新执行？是由原来执行该
计算任务的设备去再次尝试完成，还是另选设备？…
【A9】综合Q7~Q9，我们需要实现一种调度软件，专门应对这种分布式存储和分布式计算框架在运行时可能出现的各种问题。

step_2  小结一下目前推演的成果

（1）面对海量数据存储和计算（分析），采用分布式框架是实现具体软件时的一个不错的选择。
（2）分布式框架存在短板，需要打补丁修补一些细节问题。

实际上，先辈们给出大数据问题解决方案和以上推演思路基本一致；且在计算问题部分的推演中，我们还引出了Hadoop的其他核心组件（MapReduce和YARN），如下图：

step_3  重拾大数据概论的课程内容，放飞自我畅享下大数据的一般业务流程

（1）数据采集：对结构化/半结构化/非结构化数据的采集方式各有不同。
（2）数据清洗：采集到的数据不一定是完全干净可靠的，要预处理一下。
（3）数据存储：将整理好的数据落盘备用。（以上三步为备菜环节）
（4）数据分析：大数据的灵魂。借助数学/统计学理论，将数据进行：分类、预测、挖掘内在规律和联系，为决策者提供参考。
（5）其他工作（报表、可视化…）
再借用一张他人的图：（侵删）

能够耐心看到这里的读者，想必对大数据产业链大致在做些什么？学习Hadoop到底在学习什么？学习的核心思路是什么？应该有了一定的了解，恭喜你！

step_4  总结

（1）大数据技术就是围绕着：数据存储和计算展开工作的。
（2）任何技术的出现和发展都有必然的场景需求和历史规律，而非凭空出现。
（3）我们在学习一门新技术时，应该静下心来，寻找内在演化规律，才能抓住本质，切莫人云亦云，仅看他人的读书笔记或者简化版教程往往会成为半吊子，也是典型的中式苏俄学习法的弊端。

推荐读物

[1] (美)Tom White，Hadoop 权威指南(中文版)，清华大学出版社
[2] (美)Lars George，HBase权威指南，人民邮电出版社
[3] (美)Edward Capriolo，Hive编程指南，人民邮电出版社
[4] 林意群，深度剖析Hadoop HDFS，机械工业出版社
[5] (美)Arun C Murthy，Hadoop YARN权威指南，机械工业出版社

书是常看常新的，没有必要强求自己一次弄懂，对Hadoop的学习最忌讳急功急利。
【注】有一些图是我直接从自己的PPT上贴过来的，清晰度不够，后面看情况替换吧。