大数据快速入门干货

大数据时代

“大数据”这个人造词汇其实很容易产生不少误解,尤其是这个“大”字,很容易让人感觉,数据量必须大,而且特别大,越大越能形成产业,也越有价值。

做个假设,假如现在给石油产业冠以“大石油”产业的名字,那么会影响石油行业本身对其他行业的服务样态吗?应该不会。

在“大石油”产业里,同样有人从事着这样的工作内容:石油勘探、石油开采、石油运输、石油提炼、石油产品销售等多个细分领域和环节。

试想如果没有石油,也就没有廉价汽车与航空动力,尤其是没有乙烯等重要化工原材料的来源,是否存在塑料这样一种廉价的工业制造材料都很难说,

类比一下“大数据”产业,数据收集、数据传输、数据存储、数据建模、数据分析、数据交易贯穿了大数据产业的完整产业链。

如上图所示,数据由各种软件进行收集,经过网络传输,在云数据中心进行存储,由数据科学家进行建模和加工,最后数据分析得到的是一种知识,是一种人们通过数据洞悉世界的能力。

大数据可以让错综复杂的孤立数据,产生内在联系,从而看到不相关的事情之间更多背后的因果。

这些因果联系的意义会让人们在各个方面能够推测未来趋势,减少试错的机会,减少成本,降低风险,解放劳动力

我认为这才是大数据产业本身的价值与意义所在。

大数据方向

大数据的方向有很多的,即使没有真正经历过,平时也会耳濡目染,在各大杂志公众号新闻上听说过,什么大数据人工智能,大数据分析挖掘,大数据架构师等职位。

我以我的两段从业经历来说明一下大数据的方向吧。

我的前公司是一家互联网企业,大数据部门是从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

在整个大数据体系里面,最宝贵、最难以替代的资源就是数据。
大量数据是以文件形式保存的,典型代表是行为日志数据(用户搜索日志、购买日志、点击日志以及机器操作日志等)。
这些文件形式的数据具有价值高、数据大、流式产生的特点,需要一个分布式文件系统存储它们,该文件系统应具有良好的容错性、扩展性和易用的 API。
而HDFS 就是一个理想的解决方案。

如果我们把大数据计算比作烹饪,那么数据就是食材,而分布式文件系统 HDFS 就是那口烧菜的大锅。

HDFS 作为最早的大数据存储系统,存储着宝贵的数据资产,各种新的算法、框架要想得到人们的广泛使用,必须支持 HDFS 才能获取已经存储在里面的数据。
所以大数据技术越发展,新技术越多,HDFS 得到的支持越多,我们越离不开 HDFS。
HDFS 也许不是最好的大数据存储技术,但依然最重要的大数据存储技术。

存储大数据的挑战在哪里

首先就是每天新增的数据量特别多,可多达 GB 级别,甚至是 TB 级别,新增的文件数量可能多达 10 万 级别。
为了应对数据扩容的问题,存在两种解决方案:纵向扩展(scala-up)和横向扩展(scale-out)。
纵向扩展利用现有的存储系统,通过不断增加存储容量来满足数据日益增长的需求;但是价格昂贵、升级困难、存在物理瓶颈
横向扩展则是增加节点来扩大存储容量,一般分布式文件系统都会选择横向扩展。

横向扩展的挑战在哪里

因故障丢失数据 
横向扩展集群中采用的节点通常是普通的商用服务器,可能出故障地方又非常多,内存、CPU、主板、磁盘会损坏,服务器会宕机,网络会中断,机房会停电,所有这些都可能会引起软件系统的不可用,甚至数据永久丢失。
文件通常较大
在大数据场景中,GB 级别的文件是很常见的,且这样的文件数量极多,这与传统文件系统的使用场景是很不同的,这就要求分布式文件系统在 IO 操作以及块大小方面进行重新设计。
一次写入多次读取
一部分文件是通过追加方式产生的,且一旦产生之后不会再随机修改,实际有很多场景会是这样的,包括应用程序流式产生的数据、历史归档数据等。

HDFS的主要架构

上面是 HDFS 文件系统的架构图。
HDFS 使用主从架构,主节点是 NameNode,从节点被称为 DataNode。
NameNode 是 HDFS 集群的管理者,负责管理文件系统元数据和所有的 DataNode。
DataNode 是存储实际的数据块,并周期性通过心跳向 NameNode 汇报自己的状态信息。
Client 是客户端,用户通过客户端和 NameNode 以及 DataNode 交互,完成 HDFS 管理(比如服务的启动和停止)和数据读写的操作。
为了解决单个文件过大的问题,HDFS 对文件分块之后存储。而分块操作也是在客户端完成的。

HDFS高可用设计思路

文件分块存储

数据被分块存储在集群任意的 DataNode 上,所以 HDFS 存储的文件可以非常大,实现了大容量的存储。
DataNode上存储的数据块会复制多个副本,保证了数据的高可靠性,并通过一系列手段保证 HDFS 系统的主要组件高可用,进而保证数据和整个系统的高可用。

数据存储故障容错

磁盘介质在存储过程中受环境或者老化影响,其存储的数据可能会出现错乱。
HDFS 的应对措施是,对于存储在 DataNode 上的数据块,计算并存储校验和(CheckSum)。
在读取数据的时候,重新计算读取出来的数据的校验和,如果校验不正确就抛出异常,应用程序捕获异常后就到其他 DataNode 上读取备份数据。

磁盘故障容错

如果 DataNode 监测到本机的某块磁盘损坏,就将该块磁盘上存储的所有 BlockID 报告给 NameNode。
NameNode 检查这些数据块还在哪些 DataNode 上有备份,通知相应的 DataNode 服务器将对应的数据块复制到其他服务器上,以保证数据块的备份数满足要求。

DataNode 故障容错

DataNode 会通过心跳和 NameNode 保持通信,如果 DataNode 超时未发送心跳,NameNode 就会认为这个 DataNode 已经宕机失效。
NameNode立即查找这个 DataNode 上存储的数据块有哪些,以及这些数据块还存储在哪些服务器上。
随后通知这些服务器再复制一份数据块到其他服务器上,保证 HDFS 存储的数据块备份数符合用户设置的数目,即使再出现服务器宕机,也不会丢失数据。

NameNode 故障容错

一个 HDFS 集群只存在一个对外服务的 NameNode,称为 Active NameNode,为了防止单个 NameNode 出现故障后导致整个集群不可用,用户可启动一个备用 NameNode,称为 Standby NameNode,为了实现 NameNode HA,需解决好两者的切换和状态同步问题。
HDFS 提供了手动方式和自动方式完成主备 NameNode 切换,手动方式是通过命令显式修改 NameNode 角色完成的,通常用于 NameNode 滚动升级;
自动模式是通过 zk 实现的,可在主 NameNode 不可用时,自动将备用 NameNode 提升为主 NameNode,以保障 HDFS 不间断对外提供服务。
主备的状态同步也很重要,主/备 NameNode 并不是通过强一致协议保证状态一致的,而是通过第三方的共享存储系统。
主 NameNode 将 EditLog (修改日志,比如创建和修改文件)写入共享存储系统,备用 NameNode 则从共享存储系统中读取这些修改日志,并重新执行这些操作,以保证与 主 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;
这是一条非常常见的 SQL,统计不同年龄段的用户访问不同网页的兴趣偏好,对于产品运营和设计很有价值。
“这个问题大体思路就是,把左边的表相同的行进行求和,就可以得到右边的表了。
我们都知道 MapReduce 有两个函数,Map 函数 和 Reduce 函数。
首先,看下 map 函数的输入 key 和 value,主要看 value,因为 key 默认是行号。
value 就是左边表的每一行数据,比如 <1,28> 。
map 函数的输出就是以输入的 value 作为 key,value 统一设置成 1,比如 <<1,28>,1> 这样。
map 函数的输出经过 shuffle 以后,相同的 key 及其对应的 value 被放在一起组成一个 <key,value 集合>,作为输入交给 reduce 处理。
比如<2,28> 被 map 函数处理了两次,到了 reduce 就是 <<2,28>,<1,1>> 这种,这里 key 是 <2,28> ,值是一个集合 <1,1>。
在 reduce 函数内部,value 的值会被累加,这里就是 2 。
那么这个 SQL 就被 MapReduce 处理了。”
“其实呢,MapReduce 在大数据产生之前就有了,而 hadoop 只是创造性的把 MapReduce 编程思想应用在大数据上,是一个很伟大的创举!”

Hive架构

“Hive 呢,就是直接可以把 SQL 变成 MapReduce 程序,跑在大数据集群上”。
为了让大家更高效的使用 MapReduce 和 Spark 等计算引擎,开源社区在计算引擎基础上构建了更高级的 SQL 引擎,其中典型代表就是 Hive 和 SparkSQL。
目前构建在 hadoop 之上的 SQL 引擎主要分为两类,基于计算引擎和基于 MPP 架构。

基于计算引擎

这些 SQL 引擎是在计算引擎基础上构建的,其基本原理是将 SQL 语句翻译成分布式应用程序,之后运行在集群中。典型的代表有构建在 MapReduce 之上的 Hive 和 构建在 Spark 之上的 SparkSQL。
这类 SQL 引擎的特点是具有良好的扩展性和容错性,能够应对海量数据。

基于 MPP 架构

这些 SQL 引擎是基于 MPP 架构构建的,其基本原理是将 SQL 翻译成可分布式执行的程序,采用 Volcano 风格的计算引擎并行处理这些任务,任务之间的数据流动和交换由专门的 Exchange 运算符完成。
典型的代表有 Presto 和 Impala 等。这些引擎具有良好的扩展性,但是容错性查。

那么下面重点介绍一下 Hive 引擎

如图,Hive 对外提供了三种访问方式,包括 Web UI,CLI 和 Thrift 协议(支持 JDBC/ODBC),而在 Hive 后端,主要由三个服务组成,主要有 Driver,Metastore 和 Hadoop 。
其中 Driver 实现了 SQL 解析,生成逻辑计划、物理计划、查询优化与执行等,它的输入是 SQL 语句,输出为一系列分布式执行程序。
Metastore。Hive Metastore 负责管理和存储元信息的服务,它保存了数据库的基本信息以及数据表的定义等,为了能够可靠的保存这些信息,Hive Metastore一般将它们持久化到关系型数据库中。
Hadoop。Hive依赖于Hadoop,包括分布式文件系统HDFS、分布式资源管理系统YARN以及分布式计算引擎MapReduce, Hive中的数据表对应的数据存放在HDFS上,计算资源由YARN分配,而计算任务则来自MapReduce引擎。

总结

其实 Hive 的架构并没有什么创新,SQL 解析优化相关的技术,以及数据库相关的技术和架构都非常成熟了。但是 把 Hive 和 MapReduce 这两种技术嫁接到一起,却是非常创新的,成就了 Hadoop 大数据仓库 Hive,也大大普及了大数据技术。
(0)

相关推荐