大数据快速入门干货
大数据时代
“大数据”这个人造词汇其实很容易产生不少误解，尤其是这个“大”字，很容易让人感觉，数据量必须大，而且特别大，越大越能形成产业，也越有价值。
做个假设，假如现在给石油产业冠以“大石油”产业的名字，那么会影响石油行业本身对其他行业的服务样态吗？应该不会。
在“大石油”产业里，同样有人从事着这样的工作内容：石油勘探、石油开采、石油运输、石油提炼、石油产品销售等多个细分领域和环节。
试想如果没有石油，也就没有廉价汽车与航空动力，尤其是没有乙烯等重要化工原材料的来源，是否存在塑料这样一种廉价的工业制造材料都很难说，
类比一下“大数据”产业，数据收集、数据传输、数据存储、数据建模、数据分析、数据交易贯穿了大数据产业的完整产业链。
如上图所示，数据由各种软件进行收集，经过网络传输，在云数据中心进行存储，由数据科学家进行建模和加工，最后数据分析得到的是一种知识，是一种人们通过数据洞悉世界的能力。
大数据可以让错综复杂的孤立数据，产生内在联系，从而看到不相关的事情之间更多背后的因果。
这些因果联系的意义会让人们在各个方面能够推测未来趋势，减少试错的机会，减少成本，降低风险，解放劳动力。
我认为这才是大数据产业本身的价值与意义所在。
大数据方向
大数据的方向有很多的，即使没有真正经历过，平时也会耳濡目染，在各大杂志公众号新闻上听说过，什么大数据人工智能，大数据分析挖掘，大数据架构师等职位。
我以我的两段从业经历来说明一下大数据的方向吧。
我的前公司是一家互联网企业，大数据部门是从0开始起步的。
我们的数据总监是来自百度的资深专家。
一开始是从0开始搭建 CDH 集群，接着采集服务器日志，采集关系型数据库数据到 hadoop 上。
等数据渐渐多了起来，我们开始着手做一个企业数据仓库，整合各个业务线的数据，最终产出各种报表和分析数据给老板和各个业务线的产品经理。此时产生了第一个小组，数据仓库组。
然后数据越来越多，需求也越来越多，我们便开始招数据分析人员，去接第三方的数据分析需求，并产出各条业务线生产运营分析报告。此时产生了第二个小组，数据分析组。
当时我们也有社交的场景，会员在平台上会发文章，写评论，当然必不可少的会打广告。打广告的方式也是五花八门，玩文字梗的，谐音梗的，图片上打广告的。此时需要专门从事 NLP 和图形识别的小组，去拦截平台广告。由此成立了第三个小组，AI组。
随着社交场景的持续发展，平台内容也在逐渐增多，此时需要做一个推荐系统去构建用户的画像，给用户推荐他们喜欢的内容，维持用户的黏性。此时产生了第四个小组，推荐组。
后面数据越来越多，老板也看到了其中的价值，需要从海量的数据中挖掘有意义的东西，比如从海量的球赛数据，赔率数据中去分析球赛结果，提高平台的整体返奖率。由此有了第五个小组，数据挖掘组。
这便是我的第一份大数据经历，可以大致看到大数据的几个大方向，数据开发，数据分析和挖掘，人工智能和机器学习，推荐系统。
第二份工作，是做一个大数据平台，供大数据开发在平台上开发大数据任务。这个大数据平台一方面对接底层的离线计算组件，实时计算组件，离线同步组件，一方面对接调度系统，另一方面还要提供基本的开发功能。相当于第一段经历中，最后要做的事情，就是做一个平台。
所以也算圆满了。
如果你真的要从事大数据，那么大概有下面几个方向，你可以去选择
大数据架构方向
大数据架构方向，更多注重的是Hadoop、Spark、Flink 等大数据框架的实现原理、部署、调优和稳定性问题，以及它们与Flume、Kafka、DataX等数据流工具以及可视化工具的结合技巧。
再有就是一些工具的商业应用问题，如Hive、Cassandra、HBase、Elasticsearch、ClickHouse等。
能够将这些概念理解清楚，并能够用辩证的技术观点进行组合使用，达到软/硬件资源利用的最大化，服务提供的稳定化，这是大数据架构人才的目标。
以下是大数据架构方向研究的主要方面。
（1）架构理论：关键词有高并发、高可用、并行计算、MapReduce、Spark 等。
（2）数据流应用：关键词有Flume、Kafka、Flink，Druid等。
（3）存储应用：关键词有HDFS、ES，ClickHouse等。
（4）软件应用：关键词有Hive、HBase、Spark等。
（5）微服务应用：构建平台各种业务系统，如平台系统，调度系统，数据权限系统，api 系统等
大数据分析方向
大数据分析方向的人才更多注重的是数据指标的建立，数据的统计，数据之间的联系，数据的深度挖掘和机器学习，并利用探索性数据分析的方式得到更多的规律、知识，或者对未来事物预测和预判的手段。
以下是大数据分析方向研究的主要方面。
（1）数据库应用：关键词有RDBMS、NoSQL、MySQL、Hive等。
（2）数据加工：关键词有ETL、Python等。
（3）数据统计：关键词有统计、概率等。
（4）数据分析：关键词有数据建模、数据挖掘、机器学习、回归分析、聚类、分类、协同过滤等。
此外还有一个方面是业务知识。
其中，数据库应用、数据加工是通用的技术技巧或者工具性的能力，主要是为了帮助分析师调用或提取自己需要的数据，毕竟这些技巧的学习成本相对较低，而且在工作场景中不可或缺，而每次都求人去取数据很可能会消耗过多的时间成本。
数据统计、数据分析是分析师的重头戏，一般来说这两个部分是分析师的主业，要有比较好的数学素养或者思维方式，而且一般来说数学专业出身的人会有相当的优势。
最后的业务知识方面就是千姿百态了，毕竟每家行业甚至每家公司的业务形态都是千差万别的，只有对这些业务形态和业务流程有了充分的理解才能对数据分析做到融会贯通，才有可能正确地建立模型和解读数据。
大数据开发方向
大数据开发方向的人才更多注重的是服务器端开发，数据库开发，呈现与可视化，人机交互等衔接数据载体和数据加工各个单元以及用户的功能落地与实现。
以下是大数据开发研究的主要方面。
（1）数据仓库开发：关键词有RDBMS、NoSQL、MySQL、Hive等。
（2）数据流工具开发：关键词有Flume、Heka、Fluentd、Kafka、ZMQ等。
（3）数据前端开发：关键词有HightCharts、ECharts、JavaScript、D3、HTML5、CSS3等。
（4）数据获取开发：关键词有爬虫、分词、自然语言学习、文本分类等。
那么有没有对未来的方向更加明确一点？
种一棵树最好的时间是十年前，其次是现在。
存储之王HDFS
如果我们把大数据计算比作烹饪，那么数据就是食材，而分布式文件系统 HDFS 就是那口烧菜的大锅。
存储大数据的挑战在哪里
横向扩展的挑战在哪里
HDFS的主要架构
HDFS高可用设计思路
文件分块存储
数据存储故障容错
磁盘故障容错
DataNode 故障容错
NameNode 故障容错
资源调度框架 YARN
第一代资源管理器为什么会被淘汰掉
我们知道，hadoop 主要是由三部分组成，HDFS （hadoop 分布式文件系统），MapReduce（分布式计算框架），还有一个就是分布式集群资源调度框架 YARN。
但是 YARN 并不是随 HADOOP 的推出一开始就有的。
YARN 是在 Mapreduce 基础上演化而来的，它克服了 MapReduce 架构中的各种局限性，主要可概括为以下几个方面：
可靠性差
MRv1采用了master/slave结构，其中，master存在单点故障问题，一旦它出现故障将导致整个集群不可用。
扩展性差 在MRv1中，JobTracker（master）同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了Hadoop集群扩展性。
资源利用率低
MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些的空闲资源。
此外，Hadoop将槽位分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置）。
无法支持多种计算框架
随着互联网高速发展，MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而MRv1不能支持多种计算框架并存。
在 Hadoop 早期的时候，大数据技术就只有 Hadoop 一家，这个缺点并不明显。
但随着大数据技术的发展，各种新的计算框架不断出现，我们不可能为每一种计算框架部署一个服务器集群，而且就算能部署新集群，数据还是在原来集群的 HDFS 上。
所以我们需要把 MapReduce 的资源管理和计算框架分开，这也是 Hadoop 2 最主要的变化，就是将 Yarn 从 MapReduce 中分离出来，成为一个独立的资源调度框架。
Yarn 的设计思想
基本设计思想是将 JobTracker 的两个主要功能，即资源管理和作业控制（包括作业监控、容错等），分拆成两个独立的进程。
资源管理进程和具体的应用程序无关，它负责整个集群的资源（内存，CPU，磁盘等）管理，而作业控制进程则是直接与应用程序相关的模块，且每个作业控制进程只负责管理一个作业。
这样，通过将原有JobTracker中与应用程序相关和无关的模块分开，不仅减轻了JobTracker的负载，也使得Hadoop支持更多的计算框架。
从资源管理的角度看，下一代MapReduce框架衍生出了一个资源统一管理平台，它使得Hadoop不再局限于仅支持MapReduce一种计算模型，而是可无限融入多种计算框架，并且对这些框架进行统一管理和调度。
Yarn 的架构
从图上看，Yarn 包括两个部分：一个是资源管理器（ResourceManager），一个是节点管理器（NodeManager）。
ResourceManager 进程负责整个集群的资源调度管理，通常部署在独立的服务器上；
NodeManager 进程负责具体服务器上的资源和任务管理，在集群的每一台计算服务器上都会启动。基本上跟 HDFS 的 DataNode 进程一起出现。
资源管理器
调度器
调度器主要功能是根据资源容量，队列等方面的限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个应用程序。
YARN中的调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（ResourceContainer，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
在YARN中，资源调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler。
应用程序管理器
应用程序管理器负责应用程序的提交、监控应用程序运行状态等。
应用程序启动后需要在集群中运行一个 ApplicationMaster，ApplicationMaster 也需要运行在容器里面。
每个应用程序启动后都会先启动自己的 ApplicationMaster，由 ApplicationMaster 根据应用程序的资源需求进一步向 ResourceManager 进程申请容器资源，得到容器以后就会分发自己的应用程序代码到容器上启动，进而开始分布式计算。
以一个 MapReduce 为例介绍 Yarn 的工作流程
当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：第一个阶段是启动ApplicationMaster；第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。
YARN的工作流程分为以下几个步骤：
步骤1 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
步骤2 ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
步骤3 ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
步骤5 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。
步骤6 NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。
步骤8 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
总结
在云计算的时代，一切资源都是动态管理的，理解这种动态管理的原理对于理解云计算也非常重要。
Yarn 作为一个大数据平台的资源管理框架，简化了应用场景，对于帮助我们理解云计算的资源管理很有帮助。
数据仓库神器Hive
数据分析人员用的最多的就是 SQL 了，有没有大数据工具，可以像 MYSQL 那样，直接执行一个 SQL 就能跑出结果？
Hive 本质上，还是把 SQL 变成 MapReduce 程序，然后提交的，所以在介绍 Hive 之前，还想介绍下 MapReduce 是怎么跑一些简单 SQL 任务的。
MapReduce如何实现SQL
SELECT pageid, age, count(1)
FROM pv_users GROUP BY pageid, age;
Hive架构
基于计算引擎
基于 MPP 架构
那么下面重点介绍一下 Hive 引擎