【大数据系列】大数据导论

听说很多学java的都转到大数据了(java转大数据确实有点优势)，那不得多准备一条路？毕竟CRUD有什么好学的呢? （狗头）

说实话，大数据框架很多，很大，可能没有机会接触，就会望而生畏，任何事情，迈出第一步是最难的。别怕。

工作中需要，本篇记录学习中的知识点归纳整合，同时，希望我的大数据之旅，对后来者有一定的参考借鉴。共勉。

然后回归初心：请一条路走到黑吧。会点大数据的开发，比会点开发的大数据。我感觉后续上限高些。SQL boy泪目。

大数据学习导论

导论说的是大方向，心中有沟壑，到底自有乾坤

前置基础

• Java : 看Java篇，大数据也是需要编程的，不一定是java，但最好是java。
• Git :
• MySQL : 大家都戏称SQLBoy，实际上SQL确实是离不开的一项基础技能，MySQL用的人多，一通百通，其他库上手也快。
• Linux : 看Linux篇，主要是为了有基础的环境
• Zookeeper : 看Zookeeper篇，大数据生态大部分是动物，zookeeper戏称动物管理员，hadoop、kafka都需要依赖它。

在提交大数据作业到集群上运行时，通常需要先将项目打成 JAR 包。

• …… 反正就是java的那一套要会，生态体系可以不用会（springcloud什么的）
• Scala：如果你的时间有限，可以在了解 Spark 后再去学习 Scala 也不迟(spark源码中大量使用)

为什么学

可能是不那么卷吧，至少没有后端卷，薪资在算法和后端之间，岗位种类比较少。

怎么学 ★★★

永远要站在学习的制高点，心中有沟壑，何惧细节问题ABC。

如果脱离社招太久可以去BOSS上看看各方公司的招聘需求。

从流程分类

数据分析步骤（流程）的重要性体现在：对如何开展数据分析提供了强有力的逻辑支撑;

典型分析步骤:

张文霖在《数据分析六步曲》:

明确分析目的和思路->数据收集->数据处理->数据分析->数据展现->报告撰写

上图是一个简化的大数据处理流程图，大数据处理的主要流程包括数据收集、数据存储、数据处理、数据应用等主要环节

明确分析目的和思路

知道想要什么，要干什么，收集处理数据才有意义。通过思路让分析成体系，先分析什么，后分析什么，都有逻辑在里面。这样才能保证分析的结果有效，正确。

其实分析没那么容易，需要一套完善的数据分析方法论支撑。

方法论是一些营销管理类相关理论，比如用户行为理论，PEST分析法，5W2H分析法等。

数据采集 ☆

大数据处理的第一步是数据的收集。现在的中大型项目通常采用微服务架构进行分布式部署，所以数据的采集需要在多台服务器上进行，且采集过程不能影响正常业务的开展。基于这种需求，就衍生了多种日志收集工具，如 Flume 、Logstash、Kibana 等，它们都能通过简单的配置完成复杂的数据收集和数据聚合

数据处理 ☆

准确来说，应该叫数据预处理。一般数据没法直接用，需要对收集到的数据进行加工整理，形成适合数据分析的样式，保证数据的一致性和有效性，让数据变成干净规整的结构化数据。主要包括数据清洗、数据转化、数据提取、数据计算。

数据存储

收集到数据后，下一个问题就是：数据该如何进行存储？通常大家最为熟知是 MySQL、Oracle 等传统的关系型数据库，它们的优点是能够快速存储结构化的数据，并支持随机访问。但大数据的数据结构通常是半结构化（如日志数据）、甚至是非结构化的（如视频、音频数据），为了解决海量半结构化和非结构化数据的存储，衍生了 Hadoop HDFS 、KFS、GFS 等分布式文件系统，它们都能够支持结构化、半结构和非结构化数据的存储，并可以通过增加机器进行横向扩展。

分布式文件系统完美地解决了海量数据存储的问题，但是一个优秀的数据存储系统需要同时考虑数据存储和访问两方面的问题，比如你希望能够对数据进行随机访问，这是传统的关系型数据库所擅长的，但却不是分布式文件系统所擅长的，那么有没有一种存储方案能够同时兼具分布式文件系统和关系型数据库的优点，基于这种需求，就产生了 HBase、MongoDB。

数据分析 ☆

大数据处理最重要的环节就是数据分析，数据分析通常分为两种：批处理和流处理。

• 批处理：对一段时间内海量的离线数据进行统一的处理，对应的处理框架有 Hadoop MapReduce、Spark、Flink 等；
• 流处理：对运动中的数据进行处理，即在接收数据的同时就对其进行处理，对应的处理框架有 Storm、Spark Streaming、Flink Streaming 等。

批处理和流处理各有其适用的场景，时间不敏感或者硬件资源有限，可以采用批处理；时间敏感和及时性要求高就可以采用流处理。随着服务器硬件的价格越来越低和大家对及时性的要求越来越高，流处理越来越普遍，如股票价格预测和电商运营数据分析等。

上面的框架都是需要通过编程来进行数据分析，那么如果你不是一个后台工程师，是不是就不能进行数据的分析了？当然不是，大数据是一个非常完善的生态圈，有需求就有解决方案。为了能够让熟悉 SQL 的人员也能够进行数据的分析，查询分析框架应运而生，常用的有 Hive 、Spark SQL 、Flink SQL、 Pig、Phoenix 等。这些框架都能够使用标准的 SQL 或者 类 SQL 语法灵活地进行数据的查询分析。这些 SQL 经过解析优化后转换为对应的作业程序来运行，如

• Hive 本质上就是将 SQL 转换为 MapReduce 作业，
• Spark SQL 将 SQL 转换为一系列的 RDDs 和转换关系（transformations），
• Phoenix 将 SQL 查询转换为一个或多个 HBase Scan。

数据应用 ☆

数据分析完成后，接下来就是数据应用的范畴，这取决于你实际的业务需求。比如你可以将数据进行可视化展现，或者将数据用于优化你的推荐算法，这种运用现在很普遍，比如短视频个性化推荐、电商商品推荐、头条新闻推荐等。当然你也可以将数据用于训练你的机器学习模型，这些都属于其他领域的范畴，都有着对应的框架和技术栈进行处理，这里就不一一赘述。

• Data Report:数据报表，用表格、图型等格式来动态显示数据。

• Data Visualization:数据可视化主要旨在借助于图形化手段，清晰有效地传达与沟通信息。

• Ad Hoc:即席查询。是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

• Data Mining:数据挖掘。是指从大量的数据中通过算法搜索隐藏于其中信息的过程。数据挖掘通常与计算机科学有关，并通过统计、在线分析处理、情报检索、机器学习、专家系统（依靠过去的经验法则）和模式识别等诸多方法来实现上述目标。

数据分析的结果不是只有可视化展示，还可以继续数据挖掘（Data Mining）、即席查询（Ad Hoc）等

数据撰写

• 数据分析报告是对整个数据分析过程的一个总结与呈现
• 把数据分析的起因、过程、结果及建议完整地呈现出来，供决策者参考
• 需要有明确的结论，最好有建议或解决方案

其他框架

上面是一个标准的大数据处理流程所用到的技术框架。但是实际的大数据处理流程比上面复杂很多，针对大数据处理中的各种复杂问题分别衍生了各类框架：

• 单机的处理能力都是存在瓶颈的，所以大数据框架都是采用集群模式进行部署，为了更方便的进行集群的部署、监控和管理，衍生了 Ambari、Cloudera Manager 等集群管理工具；
• 想要保证集群高可用，需要用到 ZooKeeper ，ZooKeeper 是最常用的分布式协调服务，它能够解决大多数集群问题，包括首领选举、失败恢复、元数据存储及其一致性保证。同时针对集群资源管理的需求，又衍生了 Hadoop YARN ;
• 复杂大数据处理的另外一个显著的问题是，如何调度多个复杂的并且彼此之间存在依赖关系的作业？基于这种需求，产生了 Azkaban 和 Oozie 等工作流调度框架；
• 大数据流处理中使用的比较多的另外一个框架是 Kafka，它可以用于消峰，避免在秒杀等场景下并发数据对流处理程序造成冲击；
• 另一个常用的框架是 Sqoop ，主要是解决了数据迁移的问题，它能够通过简单的命令将关系型数据库中的数据导入到 HDFS 、Hive 或 HBase 中，或者从 HDFS 、Hive 导出到关系型数据库上。

从框架分类

数据采集框架

• Sqoop：离线数据库采集
• Logstash：全场景数据库采集工具
• DataX: 离线数据库采集
• Flume： 实时数据流采集
• Canal: 实时数据库采集
• Filebeat

分布式文件存储系统

• Hadoop HDFS

数据库系统

• Mongodb、HBase、redis、kafka、ElasticSearch

分布式计算框架

• 批处理框架：Hadoop MapReduce
• 流处理框架：Storm
• 混合处理框架：Spark、Flink

数据分析框架

• MapReduce: 离线批处理系统，第一代计算引擎

• Hive ：基于SQL的MapReduce/Tez/Spark引擎

• Spark ：分布式技术栈

  • SQL：类似于hive
  • Streamming:流式实时计算
  • Structured Streaming: 结构化流，实时计算

• Flink SQL： 实时计算工具，流批一体

• Impala、Presto、Kylin: OLAP分析工具 查询数据快

• Pig、Phoenix

集群资源管理器

• Hadoop YARN

分布式协调服务

• Zookeeper

数据迁移工具

• Sqoop

统一可视化终端UI

• Hue

任务调度框架

• Azkaban、Oozie、AirFlow、DS

集群部署和监控管理

• Ambari、Cloudera Manager

元数据管理和血缘管理

• Atlas

学习顺序

上面列出的都是比较主流的大数据框架，社区都很活跃，学习资源也比较丰富。

• 建议从 Hadoop 开始入门学习，因为它是整个大数据生态圈的基石，其它框架都直接或者间接依赖于 Hadoop 。
• 接着就可以学习计算框架，Spark 和 Flink 都是比较主流的混合处理框架，

Spark 出现得较早，所以其应用也比较广泛。 Flink 是当下最火热的新一代的混合处理框架，其凭借众多优异的特性得到了众多公司的青睐。两者可以按照你个人喜好或者实际工作需要进行学习。

其实吧，如果时间都都学

具体看项目，有的项目可能就学个hdfs，hsql就行了

左耳归纳的顺序

• java、python基础语法
• mysql、Linux基础知识
• hadoop（hdfs、mapreduce、yarn）
• sqoop
• cdh（oozie）
• hive(presto)
• kafka、redis
• hbase(phoenix)

常用的开发工具

• IDE tools

IDEA YYDS!!、PyCharm、DataSpell

• virtual tools

VMware(颜控)

• ssh tools

xshell/xftp(习惯)，mobaXterm(推荐)

当前行业的大数据平台架构

• Lambda架构：离线和实时是两套架构

Lambda 架构（Lambda Architecture）是由 Twitter（推特） 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

Lambda架构总共由三层系统组成：
	批处理层（Batch Layer）
	速度处理层（Speed Layer）
	用于响应查询的服务层（Serving Layer）
	
=批处理层存储管理主数据集（不可变的数据集）和预先批处理计算好的，用于离线分析
  拿到已经发生过数据，对数据的多少有提前的预知，不能对数据进行修改
=速度处理层会实时处理新来的大数据。速度层通过提供最新数据的实时视图来最小化延迟，用于实时分析
  处理的是还没有发生和即将发生的数据，未来的数据什么样子及数据量有多少没有提前的预知，不能对数据进行修改
  
=所有在批处理层和速度层处理完的结果都输出存储在服务层中，服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询，批处理层和速度层分析后的结果可以存放在访问速度非常快的系统中，用于同一的查询和应用

虽然 Lambda 架构使用起来十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。

使用Lambda架构时，架构师需要维护两个复杂的分布式系统，并且保证他们逻辑上产生相同的结果输出到服务层中。

优点：分工明确，可以满足所有的分析需求
缺点：需要维护两套框架，运维麻烦

• Kappa架构：流批一体架构

  

Kappa 架构是由 LinkedIn（领英） 的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。克雷普斯是几个著名开源项目（包括 Apache Kafka 和 Apache Samza 这样的流处理系统）的作者之一，也是现在 Confluent 大数据公司的 CEO。

Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层。你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。

因为 Kappa 架构只保留了速度层而缺少批处理层，在速度层上处理大规模数据可能会数据丢失的的情况发生，这就需要我们花费更多的时间在处理这些错误异常上面。

优点：流批一体，只需维护一套框架，即可完成分析工作
缺点：门槛高，而且对于离线分析来讲，可能会造成数据丢失

大数据生态体系

推荐系统框架图

十万个为什么-小白入坑

HDFS、YARN、MapReduce三者关系

Hadoop、Hbase、Hive三者的关系

最开始是hadoop ，yarn+hdfs+mr全套的大数据处理系统，

后来mr写起来太费事了，能不能简单点完成数据分析工作，就有了hive, sql化方式完成数据处理过程。

再后来觉得觉得需要一个低延时查询东西，就有了hbase.

企业中数据分析文本和图片哪个多

当下的企业中用于分析的数据是侧重于文本数据多一些，还是侧重于图片、视频数据多一些？

文本多些，各种报表。

分布式和集群有什么区别

经常混淆，是因为混淆概念的时候，大多是口语中相对于单机说的。

• 分布式：多台机器部署不同组件
• 集群：多台机器部署相同组件

大数据的核心问题是什么

单机有瓶颈

• 海量数据存储问题（多台）： 分布式存储
• 海量数据计算问题（多台）： 分布式计算
• 人和人的沟通问题 —— 2023年8月22日 增

工作中的大数据工程师一般在干嘛

• 0 划水
• 1 写 SQL （很多入职一两年的大数据工程师主要的工作就是写 SQL ）
• 2 为集群搭大数据环境（一般公司招大数据工程师环境都已经搭好了，公司内部会有现成的大数据平台，但我这边会私下搞一套测试环境，毕竟公司内部的大数据系统权限限制很多，严重影响开发效率）
• 3 维护大数据平台（这个应该是每个大数据工程师都做过的工作，或多或少会承担“运维”的工作）
• 4 数据迁移（有部分公司需要把数据从传统的数据库 Oracle、MySQL 等数据迁移到大数据集群中，这个是比较繁琐的工作，吃力不讨好）
• 5 应用迁移（有部分公司需要把应用从传统的数据库 Oracle、MySQL 等数据库的存储过程程序或者SQL脚本迁移到大数据平台上，这个过程也是非常繁琐的工作，无聊，高度重复且麻烦，吃力不讨好）
• 6 数据采集（采集日志数据、文件数据、接口数据，这个涉及到各种格式的转换，一般用得比较多的是 Flume 和 Logstash）
• 7 数据处理
  • 7.1 离线数据处理（这个一般就是写写 SQL 然后扔到 Hive 中跑，其实和第一点有点重复了）
  • 7.2 实时数据处理（这个涉及到消息队列，Kafka，Spark，Flink 这些，组件，一般就是 Flume 采集到数据发给 Kafka 然后 Spark 消费 Kafka 的数据进行处理）
• 8 数据可视化（这个我司是用 Spring Boot 连接后台数据与前端，前端用自己魔改的 echarts）
• 9 大数据平台开发（偏Java方向的，大概就是把开源的组件整合起来整成一个可用的大数据平台这样，常见的是各种难用的 PaaS 平台）
• 10 数据中台开发（中台需要支持接入各种数据源，把各种数据源清洗转换为可用的数据，然后再基于原始数据搭建起宽表层，一般为了节省开发成本和服务器资源，都是基于宽表层查询出业务数据）
• 11 搭建数据仓库（这里的数据仓库的搭建不是指 Hive ，Hive 是搭建数仓的工具，数仓搭建一般会分为三层 ODS、DW、DM 层，其中DW是最重要的，它又可以分为DWD,DWM,DWS，这个层级只是逻辑上的概念，类似于把表名按照层级区分开来的操作，分层的目的是防止开发数据应用的时候直接访问底层数据，可以减少资源(注意，减少资源开销是减少 内存 和 CPU)的开销，分层后磁盘占用会大大增加，磁盘不值钱所以没什么关系，分层可以使数据表的逻辑更加清晰，方便进一步的开发操作，如果分层没有做好会导致逻辑混乱，新来的员工难以接手业务，提高公司的运营成本，还有这个建数仓也分为建离线和实时的）

总之就是离不开写 SQL …

大数据工程师的日常工作详细篇【摘抄】

面试造火箭，工作拧螺丝，你千万不能以日常工作内容去准备你的面试，不然你会找不到工作的，因为大数据的日常工作和你面试完全不是一个等级，先说说我的日常工作吧

现在是上午十点零一分，我在公司吃着早餐，就一杯黑芝麻糊，听说能改善脱发，所以我先提前预防着

公司是九点半上班，来了之后先去厕所待个二十分钟，然后吃早饭，顺便刷刷知乎，再写写问答，就像这条回答一样

十点半正式开始工作，上午的时间是非常短暂的，一般十一点半就开始吃饭了，所以上午基本干不了活，开开会时间基本就没了。

下午两点正式进入紧张的工作中，大部分时间都是在思考，理解需求，考虑架构，这个时间占整个项目周期的70%，剩下时间是在开发，我离线和实时都做，离线的项目好做点，直接在公司的数据中台上做，写写sql即可，实时稍微复杂点，sql有时完成不了需求，需要写写代码

目前离线开发主要是hive，实时开发基本全部是flink了

如果让我招大数据工程师，我第一看中的不是技术，而是你有没有独立思考的能力，给你一个你毫不熟悉的项目，能不能快速理清业务逻辑，能不能将需求完整的复述一遍，因为这太重要了，我司目前招进来两个大数据初级，不知道是跨行业的原因，还是笨，需求始终理解的差那么一点，也可能是我们的业务比较复杂。但是需求理解不到位，技术在厉害也是没用

但是话又说回来，需求这东西你没办法提前复习啊，只有需求来了才知道要干什么，所以面试时只能考察技术及你的过往项目经历，通过你之前做的项目看你对这个项目的理解情况，这主要看和面试官有没有眼缘，没有具体标准，，因为每个人做的项目可能不一样，你项目中会的地方多说一点，不会的少说一点或者干脆不说，面试官感觉你说得好，你就有希望

但是技术是有标准的，问你某个技术点，你会就是会，不会就是不会

但是在学技术的时候要多思考，这个技术点为什么这样实现，有什么好处，多思考会让大脑越来越灵活，就比如Flink支持精准一次处理语义，但是大家深入思考下flink的精准处理是怎么实现的，有人说是通过两阶段提交协议实现的，对，是通过这个协议，那再深入思考下，这个协议的主要内容是什么，底层的算法是怎么实现的，这样一步步的向下思考，你就会发现一个新世界

以上都是随便扯扯，大家随便看看就好，接下来说说大数据怎么学习，怎么面试

想学大数据或者说想入门大数据，技术肯定是第一重要的，不会大数据的技术谈什么大数据。那么大数据的技术怎么学，要知道大数据是依赖Java的，首先要保证Java得会

咱们从业务来说，一个项目一般包含：前端，后端，后后端，大数据属于后后端，是在项目开发完成之后有了数据之后才到大数据这一步

从上帝视角看张图：

大数据工作分为图上这几种，和后端接触的是ETL工程师，负责将数据拿到大数据平台，然后供数仓开发工程师使用，大数据开发负责大数据平台的建设，后面还有数据分析师，AI工程师等

1、数仓工程师 (全称：数据仓库工程师)

数仓工程师日常工作一般是不写代码的，主要以写 SQL 为主！
数仓工程师是大数据领域公司招聘较多的岗位，薪资也较高，需要重点关注！
数据仓库分为离线数仓和实时数仓，但是企业在招聘时大多要求两者都会，进入公司之后可能会专注于离线或实时其中之一。就目前来说，大多数的企业还是以离线数仓为主，不过未来趋势肯定是实时数仓为主，所以学习时，为了现在能找到工作，需要学习离线数仓，为了以后的发展，需要学习实时数仓。所以，离线和实时都是我们重点掌握的！

需要掌握的技能：不管离线还是实时，重中之重就是：SQL

SQL 语法及调优一定要掌握，这里说的 SQL 包括 mysql 中的 sql，hive中的 hive sql，spark 中的 spark sql，flink 中 的 flink sql。

在企业招聘的笔记及面试中，一般问的关于 sql 的问题主要是以 hive sql 为主，所以请重点关注！

除 sql 外，还需要重点掌握以下技能，分为离线和实时
离线数仓需要重点掌握的技能：

• Hadoop（HDFS，MapReduce，YARN）
• Hive（重点，包括hive底层原理，hive SQL及调优）
• Spark（Spark 会用及了解底层原理）
• Oozie（调度工具，会用即可）
• 离线数仓建设（搭建数仓，数仓建模规范）
• 维度建模（建模方式常用的有范式建模和维度建模，重点关注维度建模）

实时数仓需要重点掌握的技能：

• Hadoop（这是大数据基础，不管离线和实时都必须掌握）
• Kafka（重点，大数据领域中算是唯一的消息队列）
• Flink（重中之重，这个不用说了，实时计算框架中绝对王者）
• HBase（会使用，了解底层原理）
• Druid（会用，了解底层原理）
• 实时数仓架构（两种数仓架构：Lambda架构和Kappa架构）

2. 大数据开发工程师

数据开发工程师一般是以写代码为主，以 Java 和 Scala 为主。大数据开发分两类，第一类是编写Hadoop、Spark、Flink 的应用程序，第二类是对大数据处理系统本身进行开发，如对开源框架的扩展开发，数据中台的开发等！需要重点掌握的技能：

• 语言：Java 和 Scala（语言以这两种为主，需要重点掌握）
• Linux（需要对Linux有一定的理解）
• Hadoop（需理解底层，能看懂源码）
• Hive（会使用，能进行二次开发）
• Spark（能进行开发。对源码有了解）
• Kafka（会使用，理解底层原理）
• Flink（能进行开发。对源码有了解）
• HBase（理解底层原理）

通过以上技能，我们也能看出，数据开发和数仓开发的技能重复率较高，所以很多公司招聘时 大数据开发 和 数仓建设 分的没有这么细，数据开发包含了数仓的工作！

3. ETL工程师

ETL是三个单词的首字母，中文意思是抽取、转换、加载
从开始的图中也能看出，ETL工程师是对接业务和数据的交接点，所以需要处理上下游的关系
对于上游，需要经常跟业务系统的人打交道，所以要对业务系统比较熟悉。比如它们存在各种接口，不管是API级别还是数据库接口，这都需要ETL工程师非常了解。

其次是其下游，这意味着你要跟许多数据开发工程师师、数据科学家打交道。比如将准备好的数据（数据的清洗、整理、融合），交给下游的数据开发和数据科学家。

需要重点掌握的技能

• 语言：Java/Python（会基础）
• Shell脚本（需要对shell较为熟悉）
• Linux（会用基本命令）
• Kettle（需要掌握）
• Sqoop（会用）
• Flume（会用）
• MySQL（熟悉）
• Hive（熟悉）
• HDFS（熟悉）
• Oozie（任务调度框架会用其中一个即可，其他如 azkaban，airflow）

4. 数据分析工程师

在数据工程师准备好数据维护好数仓后，数据分析师就上场了。
分析师们会根据数据和业务情况，分析得出结论、制定业务策略或者建立模型，创造新的业务价值并支持业务高效运转。
同时数据分析师在后期还有数据爬虫、数据挖掘和算法工程师三个分

需要重点掌握的技能：

• 数学知识（数学知识是数据分析师的基础知识，需要掌握统计学、线性代数等课程）
• 编程语言（需要掌握Python、R语言）
• 分析工具（Excel是必须的，还需要掌握 Tableau 等可视化工具）
• 数据敏感性（对数据要有一定的敏感性，看见数据就能想到它的用处，能带来哪些价值）

大数据学习路线

系统的学习大数据相关的课程，可按照如下顺序学习

需要先掌握 Java SE 阶段，Linux 基础命令，MySQL数据库

如果上述基础技能没有掌握，可网上搜索相关课程进行学习（这类基础课程网上免费的特别多）

Java只需要学习 Java SE 阶段即可

会在虚拟机中安装Linux发行版本（建议安装 CentOS），学完Linux基础即可。

MySQL需要学习 sql 语法，范式，事务等。

如果以上技能你都掌握的话，接下来就进入大数据框架

可按照如下顺序进行学习（涵盖ETL、数仓、开发等岗位）

hadoop -> zookeeper -> hive -> flume && sqoop -> azkaban && oozie -> 数仓建模理论+实践 -> hbase -> redis -> kafka -> elk -> scala -> spark -> kylin -> flink -> 实时数仓项目

以上为大数据学习必备知识！！！

学完以上技能后，有时间还需要学习比较流行的 OLAP 查询引擎
Impala 、 Presto、Druid 、 Kudu 、 ClickHouse 、 Doris

如果还有时间，可以学习数据治理相关的内容，如元数据管理，数据湖等
Atlas 、 Hudi

大数据的部门内部组织结构

大数据基本介绍

大数据主要解决海量存储和海量计算的问题

大数据概念

大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

最小的基本单位是bit，按顺序给出所有单位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。

1Byte = 8bit 1K = 1024Byte 1MB = 1024K 1G = 1024M

1T = 1024G 1P = 1024T 1E = 1024P 1Z = 1024E

1Y = 1024Z 1B = 1024Y 1N = 1024B 1D = 1024N

Kilobyte(KB)=1024B相当于一则短篇故事的内容。
Megabyte(MB)=l024KB相当于一则短篇小说的文字内容。
Gigabyte(GB)=1024MB相当于贝多芬第五乐章交响曲的乐谱内容。
Terabyte(TB)=1024GB相当于一家大型医院中所有的X光图片资讯量。
Petabyte(PB)=l024TB相当于50%的全美学术研究图书馆藏书资讯内容。
Exabyte (EB)=1024PB；5EB相当于至今全世界人类所讲过的话语。
Zettabyte(ZB)=1024EB如同全世界海滩上的沙子数量总和。
Yottabyte(YB)=1024ZB相当于7000位人类体内的微细胞总和。

如上图所示，1986年，全球只有0.02EB也就是约21000TB的数据量，而到了2007年，全球就是280EB也就是约300000000TB的数据量，翻了14000倍。
而最近，由于移动互联网及物联网的出现，各种终端设备的接入，各种业务形式的普及，平均每40个月，全球的数据量就会翻倍！如果这样说还没有什么印象，可以再举个简单的例子，在2012年，每天会产生2.5EB的数据量。基于IDC的报告预测，从2013年到2020年，全球数据量会从4.4ZB猛增到44ZB！而到了2025年，全球会有163ZB的数据量！

由此可见，截至目前，全球的数据量已经大到爆了！而传统的关系型数据库根本处理不了如此海量的数据！

大数据特点

1）Volume（大量）：

• 采集数据量大
• 存储数据量大
• 计算数据量大

截至目前，人类生产的所有印刷材料的数据量是200PB，而历史上全人类总共说过的话的数据量大约是5EB。当前，典型个人计算机硬盘的容量为TB量级，而一些大企业的数据量已经接近EB量级。

2）Velocity（高速）：

• 数据增长速度快
• 获取数据速度快
• 数据处理速度快

这是大数据区分于传统数据挖掘的最显著特征。根据IDC的“数字宇宙”的报告，预计到2020年，全球数据使用量将达到35.2ZB。在如此海量的数据面前，处理数据的效率就是企业的生命。

天猫双十一：2016年6分58秒，天猫交易额超过100亿

3）Variety（多样）：

这种类型的多样性也让数据被分为结构化数据和非结构化数据。相对于以往便于存储的以数据库/文本为主的结构化数据，非结构化数据越来越多，包括网络日志、音频、视频、图片、地理位置信息等，这些多类型的数据对数据的处理能力提出了更高要求。

4）Value（低价值密度）：

价值密度的高低与数据总量的大小成反比。比如，在一天监控视频中，我们只关心宋老师在健身那一分钟，如何快速对有价值数据“提纯”成为目前大数据背景下待解决的难题。

5）Veracity（数据质量）：

• 数据的准确性
• 数据的可信赖度

大数据能干啥

1）O2O：百度大数据+平台通过先进的线上线下打通技术和客流分析能力，助力商家精细化运营，提升销量。

2）零售：探索用户价值，提供个性化服务解决方案；贯穿网络与实体零售，携手创造极致体验。经典案例，子尿布+啤酒。

3）电商：精准广告位、个性化推荐、大数据杀熟。

以前是今天搜索明天推送（离线），现在想搜索后直接推送（实时）方向靠。

4）传媒：精准营销、猜你喜欢、交互推荐。

通过对受众人群机型大数据分析，结合对应算法，对受众喜欢的进行交互推荐

5）房产：大数据全面助力房地产行业，打造精准投策与营销，选出更合适的地，建造更合适的楼，卖给更合适的人。

6）保险：海量数据挖掘及风险预测，助力保险行业精准营销，提升精细化定价能力。

7）金融：多维度体现用户特征，帮助金融机构推荐优质客户，防范欺诈风险。

理财投资，通过对个人的信用评估，风险承担能力评估（是否有能力偿还），集合众多理财产品、推荐响应的投资理财产品。用户画像。

8）物流：拥堵预测、智能红绿灯、导航最优规划。

目前，交通的大数据应用主要在两个方面:一方面通过对车流量等海量数据的收集，估算，预测该路段一定时间内的车流量情况，给用户提供便利，合理进行道路规划；另一方面可以利用大数据来实现即时信号灯调度，提高已有线路通行能力。（交通国家在推，还比较薄弱）

9）人工智能

10）电信：基站选址优化，舆情监控，客户用户画像。

智慧营业厅，通过对用户当前的行为习惯、偏好，节假日的相应数据变化，调节自身业务结构，做到按需分配。

11）安防：犯罪预防、天网监控。

人脸识别，通过人脸识别，–匹配，存储用户数据，结合人工智能，分析及甄别用户行为，预防犯罪行为发生。

12）医疗：智慧医疗、疾病预防、病源追踪。

通过对海量病例大数据的存储，匹配、检索、结合用户的饮食、行为等习惯，搭建智慧医疗体系。

大数据发展前景

1）党的十八届五中全会提出“实施国家大数据战略”，国务院印发《促进大数据发展行动纲要》，大数据技术和应用处于创新突破期，国内市场需求处于爆发期，我国大数据产业面临重要的发展机遇。

2）国际数据公司IDC预测，到2020年，企业基于大数据计算分析平台的支出将突破5000亿美元。目前，我国大数据人才只有46万，未来3到5年人才缺口达150万之多。

3）党十九大提出“推动互联网、大数据、人工智能和实体经济深度融合”。

4）2020年初，中央推出34万亿“新基建”投资计划

5）下一个风口：2020年时5G的元年，2021年大数据爆发年

6）人才紧缺、竞争压力大

从政策来说，国家是重视的，至少不愁没饭吃

大数据业务需求

• 需求本质

通过对相关数据的处理和分析，提取隐藏在数据中的价值，为公司==赚更多的钱==。

这也是公司为什么愿意花钱招人、买装备投入大数据的核心原因。

• 数据分析

对公司中的业务数据进行分析处理，根据业务需求计算出各种指标，实现运营支撑。
赚取的实现途径：买卖产品或服务。

#1、需要更多新客户
	方式：推广拉新
	指标：广告播放量、点击量、注册量、推广渠道成本占比、转化比等

#2、让新用户消费
	方式：优惠券、现金券等优惠活动(首单优惠30%、满100减20)
	指标：登录次数、收藏次数、加入购物车次数、首单转化率
	
	推荐系统：基于对用户数据的分析，构建用户画像，精准把握用户需求，实现精准推荐。
	#兴趣爱好：颜色、品牌、价格区间、之前购买信息、当前搜索浏览信息

#3、让老用户留存
	方式：解决用户痛点、迎合用户兴趣点
	指标：退款次数、好评数、差评数、留存率、不同终端成交占比

#4、降低运营成本
	指标：销售收入、成交额、退款额，再细分为不同维度不同粒度（不同渠道、不同终端、不同地区、不同日期）
	
	风控系统：安全领域、金融领域
	#统计分析一个恶意访问，拦截和屏蔽恶意访问
	#信用风控

企业数据的业务流程分析

企业中数据分析的基本方向：

把隐藏在数据背后的信息集中和提炼出来，总结出所研究对象的内在规律，帮助管理者进行有效的判断和决策。

• 现状分析（分析当下的数据）：现阶段的整体情况，各个部分的构成占比、发展、变动；
  • 实时分析（Real Time Processing |Streaming）: 指从数据产生到数据分析到数据应用的时间间隔很短，可细分秒级、毫秒级
• 原因分析（分析过去的数据）：某一现状为什么发生，确定原因，做出调整优化；
  • 离线分析（Batch Processing）: 时间维度明显成批次性变化。一周一分析(T+7)，一天一分析（T+1），所以也叫做批处理。
• 预测分析（结合数据预测未来）：结合已有数据预测未来发展趋势。
  • 机器学习（Machine Learning）: 基于历史数据和当下产生的实时数据预测未来发生的事情；侧重于数学算法的运用，如分类、聚类、关联、预测。

服务器基本介绍

服务器，也称伺服器，是提供计算服务的设备。由于服务器需要响应服务请求，并进行处理，因此一般来说服务器应具备承担服务并且保障服务的能力。

在网络环境下，根据服务器提供的服务类型不同，分为文件服务器、数据库服务器、应用程序服务器、WEB服务器等

服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

可以简单的理解为服务器就是一台电脑，只不过硬盘比普通的PC机更大，CPU比普通的PC机处理速度更快，网卡比普通的PC机更快。。。

​

存储磁盘基本介绍

服务器需要存储数据，免不了得要磁盘的支持，磁盘就是一类存储介质，专门用于存储我们各种类型的数据，其中磁盘按照接口类型又可以有好多种分类，接下来我们来简单看一下不同接口的各类磁盘的基本特性吧

SCSI接口硬盘介绍

SCSi传统服务器老传输接口，转速为10kr 15kr。但是由于受到线缆及其阵列卡和传输协议的限制，该盘片有固定的插法，例如要顺着末端接口开始插第一块硬盘，没有插硬盘的地方要插硬盘终结器等。该盘现已经完全停止发售。该盘只有3.5寸版。常见转速：10000转/分。

SAS接口硬盘介绍

SAS 该盘分为两种协议，即SAS1.0及SAS 2.0接口，SAS1.0接口传输带宽为3.0GB/s转速有7.2kr 10kr 15kr。该盘现已被SAS2.0接口盘取代，该盘尺寸有2.5寸及3.5寸两种。SAS2.0接口传输带宽为6.0GB/s转速有10kr 15kr，常见容量为73.6G 146G 300G 600G 900G。常见转速：15000转/分。

FDE/SDE接口硬盘介绍

FDE/SDE 该盘体前者为IBM研发的SAS硬件加密硬盘，该盘体性能等同于SAS硬盘，但是由于本身有硬件加密系统，可以保证涉密单位数据不外泄，该盘主要用于高端2.5寸存储及2.5寸硬盘接口的机器上。SED盘雷同，厂家不一样。

SATA硬盘基本介绍

SATA硬盘：用SATA接口的硬盘又叫串口硬盘，是以后PC机的主流发展方向，因为其有较强的纠错能力，错误一经发现能自动纠正，这样就大大的提高了数据传输的安全性。新的SATA 使用了差动信号系统“differential-signal-amplified-system”。这种系统能有效的将噪声从正常讯号中滤除，良好的噪声滤除能力使得SATA只要使用低电压操作即可，和 Parallel ATA 高达5V的传输电压相比，SATA 只要0.5V(500mv) 的峰对峰值电压即可操作于更高的速度之上。“比较正确的说法是：峰对峰值‘差模电压’”。常见转速：7200转/分。

SSD硬盘介绍

SSD 该盘为固态硬盘，与个人PC不同的是该盘采用一类固态硬盘检测系统检测出场，并采用SAS2.0协议进行传输，该盘的性能也将近是个人零售SSD硬盘的数倍以上。

交换机基本介绍

基本介绍：交换机（Switch）意为“开关”是一种用于电（光）信号转发的网络设备。它可以为接入交换机的任意两个网络节点提供独享的电信号通路。最常见的交换机是以太网交换机。其他常见的还有电话语音交换机、光纤交换机等。

主要作用：交换机的主要功能包括物理编址、网络拓扑结构、错误校验、帧序列以及流控。交换机还具备了一些新的功能，如对VLAN（虚拟局域网）的支持、对链路汇聚的支持，甚至有的还具有防火墙的功能

网卡的介绍

网卡（Network Interface Card）是物理上连接计算机与网络的硬件设，是计算机与局域网通信介质间的直接接口。由于网络技术的不同，网卡的分类也有所不同，如大家所熟知的ATM网卡、令牌环网卡和以太网网卡等。据统计，目前约有80 ％的局域网采用以太网技术。  　　

接口方式 　

当前台式机和笔记本电脑中常见的总线接口方式都可以从主流网卡厂商那里找到适用的产品。但值得注意的是，市场上很难找到ISA接口的100M网卡。1994年以来，PCI总线架构日益成为网卡的首选总线，目前已牢固地确立了在服务器和高端桌面机中的地位。即将到来的转变是这种网卡将推广有的桌面机中。PCI以太网网卡的高性能、易用性和增强了的可靠性使其被标 准以太网网络所广泛采用，并得到了PC业界的支持。

技术方向 　

目前，以太网网卡有10M、100M、10M/100M及千兆网卡。对于大数据量网络 来说，服务器应该采用千兆以太网网卡，这种网卡多用于服务器与交换机之间的连接，以提高整体系统的响应速率.

对于通常的文件共享等应用来说，10M网卡就已经足够了，但对于将来可能的语音和视频等应用来说，100M 网卡将更利于实时应用的传输。

局域网基本介绍

局域网（Local Area Network，LAN）是指在某一区域内由多台计算机互联成的计算机组。一般是方圆几千米以内。局域网可以实现文件管理、应用软件共享、打印机共享、工作组内的日程安排、电子邮件和传真通信服务等功能。局域网是封闭型的，可以由办公室内的两台计算机组成，也可以由一个公司内的上千台计算机组成。

机架基本介绍

为了方便管理维护众多的服务器，以及在服务器出现问题时候快读的定位解决问题，我们可以使用机架的形式，将众多的服务器归纳到一个个的机架里面去。机架之间的通信问题可以使用交换机来组织成为局域网

网络拓扑-节点距离计算

在HDFS写数据的过程中，NameNode会选择距离待上传数据最近距离的DataNode接收数据。那么这个最近距离怎么计算呢？

节点距离：两个节点到达最近的共同祖先的距离总和。

例如，假设有数据中心d1机架r1中的节点n1。该节点可以表示为/d1/r1/n1。利用这种标记，这里给出四种距离描述。

大家算一算每两个节点之间的距离

IDC数据中心介绍

互联网数据中心（Internet Data Center）简称IDC，就是电信部门利用已有的互联网通信线路、带宽资源，建立标准化的电信专业级机房环境，为企业、政府提供服务器托管、租用以及相关增值等方面的全方位服务

IDC主机托管主要应用范围是网站发布、虚拟主机和电子商务等。比如网站发布，单位通过托管主机，从电信部门分配到互联网静态IP地址后，即可发布自己的www站点，将自己的产品或服务通过互联网广泛宣传；虚拟主机是单位通过托管主机，将自己主机的海量硬盘空间出租，为其他客户提供虚拟主机服务，使自己成为ICP服务提供商；电子商务是指单位通过托管主机，建立自己的电子商务系统，通过这个商业平台来为供应商、批发商、经销商和最终用户提供完善的服务。

IDC即互联网数据中心。它是伴随着互联网不断发展的需求而迅速发展起来的，成为了新世纪中国互联网产业中不可或缺的重要一环。它为互联网内容提供商（ICP）、企业、媒体和各类网站提供大规模、高质量、安全可靠的专业化服务器托管、空间租用、网络批发带宽以及ASP、EC等业务。

IDC是对入驻（Hosting）企业、商户或网站服务器群托管的场所；是各种模式电子商务赖以安全运作的基础设施，也是支持企业及其商业联盟其分销商、供应商、客户等实施价值链管理的平台。

IDC起源于ICP对网络高速互联的需求，而且美国仍然处于世界领导者位置。在美国，运营商为了维护自身利益，将网络互联带宽设得很低，用户不得不在每个服务商处都放一台服务器。为了解决这个问题，IDC应运而生，保证客户托管的服务器从各个网络访问速度都没有瓶颈。

IDC不仅是数据存储的中心，而且是数据流通的中心，它应该出现在Internet网络中数据交换最集中的地方。它是伴随着人们对主机托管和虚拟主机服务提出了更高要求的状况而产生的，从某种意义上说，它是由ISP的服务器托管机房演变而来的。具体而言，随着Internet的高速发展，网站系统对带宽、管理维护日益增长的高要求对很多企业构成了严峻的挑战。于是，企业开始将与网站托管服务相关的一切事物交给专门提供网络服务的IDC去做，而将精力集中在增强核心竞争力的业务中去。可见，IDC是Internet企业分工更加细化的产物。

目前我国比较大的机房主要在北京、上海、广州、唐山等地

磁盘阵列

单个硬盘的存储能力是有限的，如果要存储更多的数据，可以通过某种技术，将若干个硬盘连接在一起，提供能耗的存储能力。我们在服务器上插更多的磁盘来提高存储容量，而服务器上的插槽是有限的，我们无法无限地增加硬盘。所以，我们可以买RAID磁盘阵列来解决数据存储速度、容错问题

磁盘RAID的基本介绍：

1988 年美国加州大学伯克利分校的 D. A. Patterson 教授等首次在论文 “A Case of Redundant Array of Inexpensive Disks” 中提出了 RAID 概念 [1] ，即廉价冗余磁盘阵列（ Redundant Array of Inexpensive Disks ）。由于当时大容量磁盘比较昂贵， RAID 的基本思想是将多个容量较小、相对廉价的磁盘进行有机组合，从而以较低的成本获得与昂贵大容量磁盘相当的容量、性能、可靠性。随着磁盘成本和价格的不断降低， RAID 可以使用大部分的磁盘， “廉价” 已经毫无意义。因此， RAID 咨询委员会（ RAID Advisory Board, RAB ）决定用 “ 独立 ” 替代 “ 廉价 ” ，于时 RAID 变成了独立磁盘冗余阵列（ Redundant Array of Independent Disks ）。但这仅仅是名称的变化，实质内容没有改变.

RAID0基本介绍

RAID0 是一种简单的、无数据校验的数据条带化技术。实际上不是一种真正的 RAID ，因为它并不提供任何形式的冗余策略。 RAID0 将所在磁盘条带化后组成大容量的存储空间（如图 2 所示），将数据分散存储在所有磁盘中，以独立访问方式实现多块磁盘的并读访问。由于可以并发执行 I/O 操作，总线带宽得到充分利用。再加上不需要进行数据校验，RAID0 的性能在所有 RAID 等级中是最高的。理论上讲，一个由 n 块磁盘组成的 RAID0 ，它的读写性能是单个磁盘性能的 n 倍，但由于总线带宽等多种因素的限制，实际的性能提升低于理论值。

RAID0 具有低成本、高读写性能、 100% 的高存储空间利用率等优点，但是它不提供数据冗余保护，一旦数据损坏，将无法恢复。 因此， RAID0 一般适用于对性能要求严格但对数据安全性和可靠性不高的应用，如视频、音频存储、临时数据缓存空间等

将2个或者4个倍数的硬盘合二一，空间大小：2+2+2+2 = 8T

可以让硬盘的速度最快，空间利用率也很高，但是只要一个硬盘损坏，所有硬盘的数据玩完，特别不推荐，属于玩火的人才会用这个模式

RAID1基本介绍

RAID1 称为镜像，它将数据完全一致地分别写到工作磁盘和镜像 磁盘，它的磁盘空间利用率为 50% 。 RAID1 在数据写入时，响应时间会有所影响，但是读数据的时候没有影响。 RAID1 提供了最佳的数据保护，一旦工作磁盘发生故障，系统自动从镜像磁盘读取数据，不会影响用户工作。

RAID1 与 RAID0 刚好相反，是为了增强数据安全性使两块 磁盘数据呈现完全镜像，从而达到安全性好、技术简单、管理方便。 RAID1 拥有完全容错的能力，但实现成本高。 RAID1 应用于对顺序读写性能要求高以及对数据保护极为重视的应用，如对邮件系统的数据保护

这个模式是将2个或者4个，倍数的硬盘除以二，能保证数据拷贝的时候，有一个硬盘进行备份： 空间大小：2+2+2+2 = 4T

这个模式最安全，只要坏了硬盘，再换上一个即可，另外一个硬盘会进行备份，所以很多人用，但是空间利用率有点少，比如你买了2个8T硬盘组RAID1，那么只能用1个8T，就有点浪费了。

RAID2基本介绍

RAID2 称为纠错海明码磁盘阵列，其设计思想是利用海明码实现数据校验冗余。海明码是一种在原始数据中加入若干校验码来进行错误检测和纠正的编码技术，其中第 2n 位（ 1, 2, 4, 8, … ）是校验码，其他位置是数据码。因此在 RAID2 中，数据按位存储，每块磁盘存储一位数据编码，磁盘数量取决于所设定的数据存储宽度，可由用户设定。图 4 所示的为数据宽度为 4 的 RAID2 ，它需要 4 块数据磁盘和 3 块校验磁盘。如果是 64 位数据宽度，则需要 64 块 数据磁盘和 7 块校验磁盘。可见， RAID2 的数据宽度越大，存储空间利用率越高，但同时需要的磁盘数量也越多。

海明码自身具备纠错能力，因此 RAID2 可以在数据发生错误的情况下对纠正错误，保证数据的安全性。它的数据传输性能相当高，设计复杂性要低于后面介绍的 RAID3 、 RAID4 和 RAID5 。

但是，海明码的数据冗余开销太大，而且 RAID2 的数据输出性能受阵列中最慢磁盘驱动器的限制。再者，海明码是按位运算， RAID2 数据重建非常耗时。由于这些显著的缺陷，再加上大部分磁盘驱动器本身都具备了纠错功能，因此 RAID2 在实际中很少应用，没有形成商业产品，目前主流存储磁盘阵列均不提供 RAID2 支持。

RAID3基本介绍

RAID3 （图 5 ）是使用专用校验盘的并行访问阵列，它采用一个专用的磁盘作为校验盘，其余磁盘作为数据盘，数据按位可字节的方式交叉存储到各个数据盘中。RAID3 至少需要三块磁盘，不同磁盘上同一带区的数据作 XOR 校验，校验值写入校验盘中。 RAID3 完好时读性能与 RAID0 完全一致，并行从多个磁盘条带读取数据，性能非常高，同时还提供了数据容错能力。向 RAID3 写入数据时，必须计算与所有同条带的校验值，并将新校验值写入校验盘中。一次写操作包含了写数据块、读取同条带的数据块、计算校验值、写入校验值等多个操作，系统开销非常大，性能较低。

　　如果 RAID3 中某一磁盘出现故障，不会影响数据读取，可以借助校验数据和其他完好数据来重建数据。假如所要读取的数据块正好位于失效磁盘，则系统需要读取所有同一条带的数据块，并根据校验值重建丢失的数据，系统性能将受到影响。当故障磁盘被更换后，系统按相同的方式重建故障盘中的数据至新磁盘。

　　RAID3 只需要一个校验盘，阵列的存储空间利用率高，再加上并行访问的特征，能够为高带宽的大量读写提供高性能，适用大容量数据的顺序访问应用，如影像处理、流媒体服务等。目前， RAID5 算法不断改进，在大数据量读取时能够模拟 RAID3 ，而且 RAID3 在出现坏盘时性能会大幅下降，因此常使用 RAID5 替代 RAID3 来运行具有持续性、高带宽、大量读写特征的应用。

RAID4基本介绍

RAID4 与 RAID3 的原理大致相同，区别在于条带化的方式不同。 RAID4 （图 6 ）按照 块的方式来组织数据，写操作只涉及当前数据盘和校验盘两个盘，多个 I/O 请求可以同时得到处理，提高了系统性能。 RAID4 按块存储可以保证单块的完整性，可以避免受到其他磁盘上同条带产生的不利影响。

RAID4 在不同磁盘上的同级数据块同样使用 XOR 校验，结果存储在校验盘中。写入数据时， RAID4 按这种方式把各磁盘上的同级数据的校验值写入校验 盘，读取时进行即时校验。因此，当某块磁盘的数据块损坏， RAID4 可以通过校验值以及其他磁盘上的同级数据块进行数据重建。

RAID4 提供了 非常好的读性能，但单一的校验盘往往成为系统性能的瓶颈。对于写操作， RAID4 只能一个磁盘一个磁盘地写，并且还要写入校验数据，因此写性能比较差。而且随着成员磁盘数量的增加，校验盘的系统瓶颈将更加突出。正是如上这些限制和不足， RAID4 在实际应用中很少见，主流存储产品也很少使用 RAID4 保护。

RAID5基本介绍

RAID5 应该是目前最常见的 RAID 等级，它的原理与 RAID4 相似，区别在于校验数据分布在阵列中的所有磁盘上，而没有采用专门的校验磁盘。对于数据和校验数据，它们的写操作可以同时发生在完全不同的磁盘上。因此， RAID5 不存在 RAID4 中的并发写操作时的校验盘性能瓶颈问题。另外， RAID5 还具备很好的扩展性。当阵列磁盘 数量增加时，并行操作量的能力也随之增长，可比 RAID4 支持更多的磁盘，从而拥有更高的容量以及更高的性能。

RAID5 （图 7）的磁盘上同时存储数据和校验数据，数据块和对应的校验信息存保存在不同的磁盘上，当一个数据盘损坏时，系统可以根据同一条带的其他数据块和对应的校验数据来重建损坏的数据。与其他 RAID 等级一样，重建数据时， RAID5 的性能会受到较大的影响。

RAID5 兼顾存储性能、数据安全和存储成本等各方面因素，它可以理解为 RAID0 和 RAID1 的折中方案，是目前综合性能最佳的数据保护解决方案。 RAID5 基本上可以满足大部分的存储应用需求，数据中心大多采用它作为应用数据的保护方案。

这个模式最少得3块以上的硬盘，属于RAID1 和 RAID0 之间，比如有4块硬盘组RIAD5，那么只会用一块硬盘进行保护，其它的空间可以叠加： 空间大小：2+2+2+ 2 = 6T

这个模式，可以最大的利用磁盘空间，也能保护磁盘，而且如果用SSD的话，硬盘速度也有叠加，不过缺点就是硬盘在损坏以后，换上新的硬盘后，重建数据的时间非常长，而重建过程中，如果再损坏一块硬盘，就全部玩完。

文件系统

概念

文件系统是一个软件，通过这个软件，用户不用关系具体的文件内容存储在磁盘的什么位置，直接就可以对文件操作

• 计算机的文件系统是一种存储和组织计算机数据的方法，它使得对其访问和查找变得容易
• 文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念，用户使用文件系统来保存数据不必关心数据实际保存在硬盘（或者光盘）的地址为多少的数据块上，只需要记住这个文件的所属目录和文件名。
• 在写入新数据之前，用户不必关心硬盘上的那个块地址没有被使用，硬盘上的存储空间管理（分配和释放）功能由文件系统自动完成，用户只需要记住数据被写入到了哪个文件中。
• 文件系统通常使用硬盘和光盘这样的存储设备，并维护文件在设备中的物理位置。但是，实际上文件系统也可能仅仅是一种访问资料的界面而已，实际的数据是通过网络协议（如NFS、SMB、9P等）提供的或者内存上，甚至可能根本没有对应的文件（如proc文件系统）。
• 严格地说，文件系统是一套实现了数据的存储、分级组织、访问和获取等操作的抽象数据类型（Abstract data type）。

重要概念

• 文件系统是一种用于向用户提供底层数据访问的机制。它将设备中的空间划分为特定大小的块（或者称为簇），一般每块512字节。数据存储在这些块中，大小被修正为占用整数个块。由文件系统软件来负责将这些块组织为文件和目录，并记录哪些块被分配给了哪个文件，以及哪些块没有被使用。

• 不过，文件系统并不一定只在特定存储设备上出现。它是数据的组织者和提供者，至于它的底层，可以是磁盘，也可以是其它动态生成数据的设备（比如网络设备）。

文件名

• 在文件系统中，文件名是用于定位存储位置。

• 大多数的文件系统对文件名的长度有限制。在一些文件系统中，文件名是大小写不敏感（如“AAA”和“aaa”指的是同一个文件）；在另一些文件系统中则大小写敏感。

• 大多现今的文件系统允许文件名包含非常多的Unicode字符集的字符。然而在大多数文件系统的界面中，会限制某些特殊字符出现在文件名中。（文件系统可能会用这些特殊字符来表示一个设备、设备类型、目录前缀、或文件类型），为方便起见，一般不建议在文件名中包含特殊字符。

元数据

• 其它文件保存信息常常伴随着文件自身保存在文件系统中。
• 文件长度可能是分配给这个文件的区块数，也可能是这个文件实际的字节数。文件最后修改时间也许记录在文件的时间戳中。有的文件系统还保存文件的创建时间，最后访问时间及属性修改时间。（不过大多数早期的文件系统不记录文件的时间信息）其它信息还包括文件设备类型（如：区块数，字符集，套接口，子目录等等），文件所有者的ID，组ID，还有访问权限（如：只读，可执行等等）。

文件系统的分类

• 本地磁盘文件系统

类Windows文件系统：盘符体系（D盘，E盘）NTFS
类Unix文件系统：    /目录

磁盘文件系统是一种设计用来利用数据存储设备来保存计算机文件的文件系统，最常用的数据存储设备是磁盘驱动器，可以直接或者间接地连接到计算机上。例如：FAT、exFAT、NTFS、HFS、HFS+、ext2、ext3、ext4、ODS-5、btrfs、XFS、UFS、ZFS。

Windows支持的文件系统

Windows	FAT12/FAT16	FAT32/VFAT	FAT64/exFAT	NTFS
Windows 3.x或更早 （MS-DOS 6.22） （PC-DOS 7.0）	可读/可写	不支持	不支持	不支持
Windows 95	可读/可写	不支持	不支持	不支持
Windows 95（OSR2以后） Windows 98（含SE） ME	可读/可写	可读/可写	不支持	不支持
Windows NT	可读/可写	不支持	不支持	可读/可写
2000 Windows XP Windows Vista Server 2003 Server 2008 (R2) Windows 7 Windows 8 Server 2012 (R2) Windows 8.1Windows 10	可读/可写	可读/可写	可读/可写	可读/可

Linux支持的文件系统

随着Linux的不断发展，它所支持的文件系统也在迅速扩充，Linux系统核心可以支持十多种文件系统类型：Btrfs、JFS、ReiserFS、exFAT、ext、ext2、ext3、ext4、XFS、ISO 9660、Minix、MSDOS、UMSDOS、VFAT、NTFS（Linux Kernel内置的NTFS驱动程序，写入功能不稳定）、HPFS、NFS、SMB、SysV、PROC等。

注意：部分Linux发行版的Kernel默认不编译Kernel内置的NTFS文件系统支持，常见的在Linux下读写NTFS的解决方法是安装NTFS-3G或ufsd等NTFS驱动程序。部分Linux发行版对NTFS的支持度并不高

UNIX及BSD操作系统下的文件系统

柏克莱加州大学开发早期的伯克利快速文件系统（Berkeley Fast File System），再由各UNIX厂商开发不同的文件系统，包括IRIX上的XFS、IBM AIX的JFS、HP HP-UNIX的VxFS及Solaris的ZFS。

macOS（Mac OS X）的文件系统

从1998年到2016年间使用HFS+，再早采用HFS。从2016年发布的macOS Sierra起，使用苹果文件系统（APFS）。

• 光盘文件系统

ISO镜像文件

• 网络文件系统

NFS: 使用网络来远程访问其他主机的文件，就像访问本机文件一样方便 （是一种将远程主机上的分区（目录）经网络挂载到本地系统的一种机制。）

• 分布式文件系统

1、分布式文件系统是由多态主机模拟出来的一个文件系统，文件是分散存储在不同的主机上
2、分布式文件系统有很多种：
1)、GFS
GFS（Google File System）是Google公司为满足公司需求而开发的基于Linux的可扩展的分布式文件系统，用于大型的、分布式的、对大数据进行访问和应用，成本低，应用于廉价的普通硬件上，但不开源，暂不考虑。

2)、TFS
TFS（Taobao File System）是阿里巴巴为满足了淘宝对小文件存储的需求而开发的一个可扩展、高可用、高性能、面向互联网服务、开源的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，这个也暂不考虑。

3)、HDFS
HDFS（Hadoop Distributed File System）。Hadoop分布式文件系统，适合运行在通用硬件上做分布式存储和计算，因为它具有高容错性和可扩展性的特点，可部署在廉价的机器上，适合大数据的处理，在离线批量处理大数据上有先天的优势。
Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapReduce算法的一种开源应用，是Google开创其帝国的重要基石。

4)、MooseFS
MooseFS 是来自波兰的开源且具备冗余容错功能的分布式 POSIX 文件系统，也是参照了 GFS 的架构，实现了绝大部分 POSIX 语义和 API，它支持通过FUSE方式将文件挂载操作，同时其提供的web管理界面非常方便查看当前的文件存储状态，对master服务器有单点依赖，用perl编写，用于中、大型文件应用，但性能相对较差，由于可能会实时访问所以暂不考虑。
备注：POSIX表示可移植操作系统接口(Portable Operating System Interface of UNIX,缩写为 POSIX )，POSIX标准定义了操作系统应该为应用程序提供的接口标准

5)、FastDFS
由淘宝的余庆先生所开发的一个开源分布式文件系统。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。适合以文件为载体的在线服务，如相册网站、视频网站等等。FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS搭建一套高性能的文件服务器集群提供文件上传、下载等服务。但是FastDFS部署有点麻烦，且它的SKD是不全的。

6)、MogileFS
MogileFS是一套高效开源的文件自动备份组件，由Six Apart开发，广泛应用在包括LiveJournal等web2.0站点上。支持多节点冗余，可实现自动的文件复制。不需要RAID，应用层可以直接实现RAID，不共享任何东西，通过集群接口提供服务工作于应用层，没有特殊的组件要求。使用HTTP方式通信。

7)、GridFS
MongoDB是一种知名的NoSql数据库，GridFS是MongoDB的一个内置功能，它用于存储和恢复那些超过16M（BSON文件限制）的文件(如：图片、音频、视频等)，是文件存储的一种方式，但是它是存储在MonoDB的集合中。它可以直接利用已建立的复制或分片机制，所以对于文件存储来说故障恢复和扩展都容易，且GridFS不产生磁盘碎片。

8)、MinIO
MinIO 是一个基于Apache License v2.0开源协议的对象存储服务。它兼容亚马逊S3云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。它也是一个非常轻量的服务,可以很简单的和其他应用的结合。MinIO的特色在于简单、轻量级，对开发者友好，学习成本低，安装运维简单，开箱即用。

9)、SeaweedFS
SeaweedFS是基于go语言开发高度可扩展开源的分布式存储系统，能存储数十亿文件（最终受制于你的硬盘大小）、并且速度快，内存占用小。上手使用比fastDFS要简单很多，自带Rest API。对于中小型文件效率非常高，但是单卷最大容量被程序限制到30G，建议存储文件以100MB以内为主。

10)、Ceph
Ceph是Red Hat旗下一个成熟的分布式文件系统，而且还是一个有企业级功能的对象存储生态环境。该系统具备高性能、高可用性、高可扩展性、实时存储性等特点。虽然ceph很强大，但是学习成本高、安装运维复杂。Ceph用C++编写，存储容量可轻松达到PB级别。

11)、GlusterFS
GlusterFS 是由美国的 Gluster 公司开发的 POSIX 分布式文件系统（以 GPL 开源），它主要应用在集群系统中，具有高扩展性、高可用性、高性能、可横向扩展等特点，并且其没有元数据服务器的设计，让整个服务没有单点故障的隐患。该系统主要是为中大型文件设计的，存储容量可轻松达到PB。它存在扩容缩容影响服务器较多、遍历目录下文件耗时、小文件性能较差的缺点。

分布式技术

分布式：子模块1+子模块2+子模块3
集群：子模块1 * 3

分布式解决场景

计算问题

无论是我们在学校刚开始学编程，还是在刚参加工作开始处理实际问题，写出来的程序都是很简单的。因为面对的问题很简单。以处理数据为例，可能只是把一个几十K的文件解析下，然后生成一个词频分析的报告。很简单的程序，十几行甚至几行就搞定了。

直到有一天，给你扔过来1000个文件，有些还特别大，好几百M了。你用之前的程序一跑，发现跑的时间有点长。于是想要去优化下。1000 个文件，互相还没业务联系，用多线程呀，一个线程处理一个文件，结果再汇总就搞定了。如果多线程效果不够好，比如像 Python 的多线程，没法利用多核的威力，那就用多进程。

无论是线程、进程，本质上，目的都是为了计算的并行化，解决的是算的慢的问题。而如果计算量足够大，就算榨干了机器的计算能力，也算不过来，咋办？

一台机器不够，那就多搞几台机器嘛。所以就从多线程/进程的计算并行化，进化到计算的分布式化（当然，分布式一定程度上也是并行化）。

存储问题

另一方面，如果处理的数据有10T，而你手上的机器只有500G 的硬盘，怎么办？

一种办法是纵向扩展，搞一台几十T硬盘的机器；另一种是横向扩展，多搞几台机器，分散着放。前者很容易到瓶颈，毕竟数据无限，而一台机器的容量有限，所以在大数据量的情况下，只能选后者。把数据分散到多台机器，本质上解决的是存不下的问题。

同时，刚才提到计算分布式化后，总不能所以程序都去同一台机器读数据吧，这样效率必然会受到单台机器性能的拖累，比如磁盘 IO、网络带宽等，也就逼着数据存储也要分散到各个机器去了。基于这两个原因，数据存储也分布式起来了。

横向扩展可以解决纵向扩展的瓶颈，节省成本。但是引发新的问题：存储在多台机器后这么快速定位？

可以借助于元数据记录来解决这个问题。把文件和其存储的机器的位置信息记录下来，类似于图书馆查阅图书系统，这样就可以快速定位文件存储在哪一台机器上了。

文件系统元数据一般指文件大小、最后修改时间、底层存储位置、属性、所属用户、权限等信息。

元信息解决了找的问题，又有新的问题，大文件传输效率慢这么办？

大数据使用场景下，GB、TP级别的大文件是常见的。当单个文件过大的时候，如何提高传输效率？通常的做法是分块存储：把大文件拆分成若干个小块（block 简写blk），分别存储在不同机器上，并行操作提高效率。

此外分块存储还可以解决数据存储负载均衡问题。此时元数据记录信息也应该更加详细：文件分了几块，分别位于哪些机器上。

切片存储解决了传输问题，又有新的问题：如果切片丢了这么办？

机器、磁盘等硬件出现故障是难以避免的事情，如何保证数据存储的安全性。如果某台机器故障，数据块丢失，对于文件来说整体就是不完整的。冗余存储是个不错的选择。采用副本机制。副本越多，数据越安全，当然冗余也会越多。通过“不要把鸡蛋放在一个篮子里”的思想，可以把数据丢失的风险分散到各个机器上。

这样存储没问题了，但是用户用起来感觉很乱怎么办？

随着存储的进行，数据文件越来越多，与之对应元数据信息也越来越多，如何让用户视觉层面感觉不到元数据的凌乱，同时也与传统的文件系统操作体验保持一致？传统的文件系统拥有所谓的目录树结构，带有层次感的namespace（命名空间），因此可以把分布式文件系统的元数据记录这一块也抽象成统一的目录树结构。

通过上述场景式分析，可以得出要想实现一个分布式文件系统，是需要多方面综合考虑的。通常来说一个分布式文件系统需要具备：分布式特性、分块存储、副本机制、元数据记录、抽象目录树、统一namespace命名空间

分布式系统概述

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。
分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
从分布式系统的概念中我们知道，各个主机之间通信和协调主要通过网络进行，所以，分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中，对于大型的网站甚至可能分布在不同的国家和地区。

分布式实现方案

分布式系统

小明的公司又3个系统：系统A，系统B和系统C，这三个系统所做的业务不同，被部署在3个独立的机器上运行，他们之间互相调用（当然是跨域网络的），通力合作完成公司的业务流程。

将不同的业务分部在不同的地方，就构成了一个分布式的系统，现在问题来了，系统A是整个分布式系统的脸面，用户直接访问，用户访问量大的时候要么是速度巨慢，要么直接挂掉，怎么办？

由于系统A只有一份，所以会引起单点失败。

集群（Cluster）

小明的公司不差钱，就多买几台机器吧， 小明把系统A一下子部署了好几份（例如下图的3个服务器），每一份都是系统A的一个实例，对外提供同样的服务，这样，就不怕其中一个坏掉了，还有另外两个呢。

这三个服务器的系统就组成了一个集群。

可是对用户来说，一下子出现这么多系统A，每个系统的IP地址都不一样，到底访问哪一个呢？

如果所有人都访问服务器1.1，那服务器1.1会被累死，剩下两个闲死，成了浪费钱的摆设。

复杂均衡（Load Balancer）

小明要尽可能的让3个机器上的系统A工作均衡一些，比如有3万个请求，那就让3个服务器各处理1万个（理想情况），这叫负载均衡

很明显，这个负载均衡的工作最好独立出来，放到独立的服务器上（例如nginx）：

后来小明发现，这个负载均衡的服务器虽然工作内容简单，就是拿到请求，分发请求，但是它还是有可能挂掉，单点失败还是会出现。没办法，只好把负载均衡也搞成一个集群，这个集群和系统A的集群有两点不同：

1.我们可以用某种办法，让这个机器对外只提供一个IP地址，也就是用户看到的好像只有一个机器。

2.同一时刻，我们只让一个负载均衡的机器工作，另外一个原地待命，如果工作的那个拐到了，待命的那个就顶上去。

弹性(伸缩性)

如果3个系统A的实例还是满足不了大量请求，例如双十一，可以申请增加服务器，双十一过后，新增的服务器闲置，成了摆设，于是小明决定尝试云计算，在云端可以轻松的创建，删除虚拟的服务器，那样就可以轻松的随着用户的请求动图的增减服务器了。

故障转移

上面的系统看起来很美好，但是做了一个不切实际的假设：所有的服务都是无状态的，换句话说，假设用户的两次请求直接是没有关联的。但是现实是，大部分服务都是有状态的，例如购物车。

用户访问系统，在服务器上创建了一个购物车，并向其中加了几个商品，然后服务器1.1挂掉了，用户后续访问就找不到服务器1.1了，这时候就要做失效转移，让另外几个服务器去接管，去处理用户的请求。

可是问题来了，在服务器1.2,1.3上有用户的购物车吗？如果没有，用户就会抱怨，我刚创建的购物车哪里去了？还有更严重的，假设用户登录过得信息保存到了该服务器1.1上登录的，用户登录过的信息保存到了该服务器的session中，现在这个服务器挂了，用的session就不见了，会把用户踢到了登录界面，让用户再次登录！

处理不好状态的问题，集群的威力就大打折扣，无法完成真正的失效转移，甚至无法使用。

怎么办？

• 一种办法是把状态信息在集群的各个服务器之间复制，让集群的各个服务器达成一致。

• 还有一种办法， 就是把几种状态信息存储在一个地方，让集群服务器的各个服务器都能访问到。