数据分析之Hadoop详解

您所在的位置:网站首页 hadoop的框架最核心的设计 数据分析之Hadoop详解

数据分析之Hadoop详解

2023-08-06 02:33| 来源: 网络整理| 查看: 265

1.1 什么是Hadoop

在这里插入图片描述

- Hadoop的概念:

Apache™ Hadoop® 是一个开源的, 可靠的(reliable), 可扩展的(scalable)分布式计算框架 允许使用简单的编程模型跨计算机集群分布式处理大型数据集可扩展: 从单个服务器扩展到数千台计算机,每台计算机都提供本地计算和存储可靠的: 不依靠硬件来提供高可用性(high-availability),而是在应用层检测和处理故障,从而在计算机集群之上提供高可用服务

- Hadoop能做什么?

搭建大型数据仓库PB级数据的存储 处理 分析 统计等业务

搜索引擎

日志分析

数据挖掘

商业智能(Business Intelligence,简称:BI)

商业智能通常被理解为将企业中现有的数据(订单、库存、交易账目、客户和供应商等数据)转化为知识,帮助企业做出明智的业务经营决策的工具。从技术层面上讲,是数据仓库、数据挖掘等技术的综合运用。

Hadoop发展史 2003-2004年 Google发表了三篇论文 GFS:Google的分布式文件系统Google File SystemMapReduce: Simplified Data Processing on Large ClustersBigTable:一个大型的分布式数据库 2006年2月Hadoop成为Apache的独立开源项目( Doug Cutting等人实现了DFS和MapReduce机制)。2006年4月— 标准排序(10 GB每个节点)在188个节点上运行47.9个小时。2008年4月— 赢得世界最快1TB数据排序在900个节点上用时209秒。2008年— 淘宝开始投入研究基于Hadoop的系统–云梯。云梯总容量约9.3PB,共有1100台机器,每天处理18000道作业,扫描500TB数据。2009年3月— Cloudera推出CDH(Cloudera’s Dsitribution Including Apache Hadoop)2009年5月— Yahoo的团队使用Hadoop对1 TB的数据进行排序只花了62秒时间。2009年7月— Hadoop Core项目更名为Hadoop Common;2009年7月— MapReduce和Hadoop Distributed File System (HDFS)成为Hadoop项目的独立子项目。2012年11月— Apache Hadoop 1.0 Available2018年4月— Apache Hadoop 3.1 Available搜索引擎时代 有保存大量网页的需求(单机 集群)词频统计 word count PageRank 数据仓库时代 FaceBook推出Hive曾经进行数分析与统计时, 仅限于数据库,受数据量和计算能力的限制, 我们只能对最重要的数据进行统计和分析(决策数据,财务相关)Hive可以在Hadoop上运行SQL操作, 可以把运行日志, 应用采集数据,数据库数据放到一起分析 数据挖掘时代 啤酒尿不湿关联分析用户画像/物品画像 机器学习时代 广义大数据 大数据提高数据存储能力, 为机器学习提供燃料alpha gosiri 小爱 天猫精灵 1.2 Hadoop核心组件

Hadoop是所有搜索引擎的共性问题的廉价解决方案

如何存储持续增长的海量网页: 单节点 V.S. 分布式存储如何对持续增长的海量网页进行排序: 超算 V.S. 分布式计算HDFS 解决分布式存储问题MapReduce 解决分布式计算问题

Hadoop Common: The common utilities that support the other Hadoop modules.(hadoop的核心组件)

Hadoop Distributed File System (HDFS™): A distributed file system that provides high-throughput access to application data.(分布式文件系统)

源自于Google的GFS论文, 论文发表于2003年10月HDFS是GFS的开源实现HDFS的特点:扩展性&容错性&海量数量存储将文件切分成指定大小的数据块, 并在多台机器上保存多个副本数据切分、多副本、容错等操作对用户是透明的

下面这张图是数据块多份复制存储的示意

图中对于文件 /users/sameerp/data/part-0,其复制备份数设置为2, 存储的BlockID分别为1、3。Block1的两个备份存储在DataNode0和DataNode2两个服务器上Block3的两个备份存储在DataNode4和DataNode6两个服务器上 在这里插入图片描述

Hadoop MapReduce: A YARN-based system for parallel processing of large data sets.

分布式计算框架源于Google的MapReduce论文,论文发表于2004年12月MapReduce是GoogleMapReduce的开源实现MapReduce特点:扩展性&容错性&海量数据离线处理

在这里插入图片描述 Hadoop YARN: A framework for job scheduling and cluster resource management.(资源调度系统)

YARN: Yet Another Resource Negotiator

负责整个集群资源的管理和调度

YARN特点:扩展性&容错性&多框架资源统一调度

在这里插入图片描述

1.3 Hadoop优势 高可靠 数据存储: 数据块多副本数据计算: 某个节点崩溃, 会自动重新调度作业计算 高扩展性 存储/计算资源不够时,可以横向的线性扩展机器一个集群中可以包含数以千计的节点集群可以使用廉价机器,成本低 Hadoop生态系统成熟 hadoop概念扩展 Hadoop生态系统

狭义的Hadoop VS 广义的Hadoop

广义的Hadoop:指的是Hadoop生态系统,Hadoop生态系统是一个很庞大的概念,hadoop是其中最重要最基础的一个部分,生态系统中每一子系统只解决某一个特定的问题域(甚至可能更窄),不搞统一型的全能系统,而是小而精的多个小系统; 在这里插入图片描述 Hive:数据仓库

R:数据分析

Mahout:机器学习库

pig:脚本语言,跟Hive类似

Oozie:工作流引擎,管理作业执行顺序

Zookeeper:用户无感知,主节点挂掉选择从节点作为主的

Flume:日志收集框架

Sqoop:数据交换框架,例如:关系型数据库与HDFS之间的数据交换

Hbase : 海量数据中的查询,相当于分布式文件系统中的数据库

Spark: 分布式的计算框架基于内存

spark corespark sqlspark streaming 准实时 不算是一个标准的流式计算spark ML spark MLlib

Kafka: 消息队列

Storm: 分布式的流式计算框架 python操作storm

Flink: 分布式的流式计算框架

Hadoop生态系统的特点

开源、社区活跃

囊括了大数据处理的方方面面

成熟的生态圈

HDFS 读写流程& 高可用

HDFS读写流程 在这里插入图片描述

客户端向NameNode发出写文件请求。

检查是否已存在文件、检查权限。若通过检查,直接先将操作写入EditLog,并返回输出流对象。 (注:WAL,write ahead log,先写Log,再写内存,因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了,由于在真实写操作之前,操作就被写入EditLog中了,故EditLog中仍会有记录,我们不用担心后续client读不到相应的数据块,因为在第5步中DataNode收到块后会有一返回确认信息,若没写成功,发送端没收到确认信息,会一直重试,直到成功)

client端按128MB的块切分文件。

client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点,此后client端和NameNode分配的多个DataNode构成pipeline管道,client端向输出流对象中写数据。client每向第一个DataNode写入一个packet,这个packet便会直接在pipeline里传给第二个、第三个…DataNode。 (注:并不是写好一个块或一整个文件后才向后分发)

每个DataNode写完一个块后,会返回确认信息。 (注:并不是每写完一个packet后就返回确认信息,个人觉得因为packet中的每个chunk都携带校验信息,没必要每写一个就汇报一下,这样效率太慢。正确的做法是写完一个block块后,对校验信息进行汇总分析,就能得出是否有块写错的情况发生)

写完数据,关闭输输出流。

发送完成信号给NameNode。

(注:发送完成信号的时机取决于集群是强一致性还是最终一致性,强一致性则需要所有DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向NameNode汇报,HDFS一般情况下都是强调强一致性)

HDFS如何实现高可用(HA)

数据存储故障容错 磁盘介质在存储过程中受环境或者老化影响,数据可能错乱对于存储在 DataNode 上的数据块,计算并存储校验和(CheckSum)读取数据的时候, 重新计算读取出来的数据校验和, 校验不正确抛出异常, 从其它DataNode上读取备份数据 磁盘故障容错 DataNode 监测到本机的某块磁盘损坏将该块磁盘上存储的所有 BlockID 报告给 NameNodeNameNode 检查这些数据块在哪些DataNode上有备份,通知相应DataNode, 将数据复制到其他服务器上 DataNode故障容错 通过心跳和NameNode保持通讯超时未发送心跳, NameNode会认为这个DataNode已经宕机NameNode查找这个DataNode上有哪些数据块, 以及这些数据在其它DataNode服务器上的存储情况从其它DataNode服务器上复制数据 NameNode故障容错 主从热备 secondary namenodezookeeper配合 master节点选举 Hadoop发行版的选择 Apache Hadoop 开源社区版最新的Hadoop版本都是从Apache Hadoop发布的Hadoop Hive Flume 版本不兼容的问题 jar包 spark scala Java->.class->.jar ->JVM CDH: Cloudera Distributed Hadoop

Cloudera 在社区版的基础上做了一些修改

http://archive.cloudera.com/cdh5/cdh/5/ 在这里插入图片描述

hadoop-2.6.0-cdh-5.7.0 和 Flume*****-cdh5.7.0 cdh版本一致 的各个组件配合是有不会有兼容性问题CDH版本的这些组件 没有全部开源 HDP: Hortonworks Data Platform 大数据产品与互联网产品结合

分布式系统执行任务瓶颈: 延迟高 MapReduce 几分钟 Spark几秒钟

互联网产品要求

毫秒级响应(1秒以内完成)需要通过大数据实现 统计分析 数据挖掘 关联推荐 用户画像

大数据平台

整合网站应用和大数据系统之间的差异, 将应用产生的数据导入到大数据系统, 经过处理计算后再导出给应用程序使用

互联网大数据平台架构: 在这里插入图片描述

数据采集

App/Web 产生的数据&日志同步到大数据系统数据库同步:Sqoop 日志同步:Flume 打点: Kafka不同数据源产生的数据质量可能差别很大 数据库 也许可以直接用日志 爬虫 大量的清洗,转化处理

数据处理

大数据存储与计算的核心数据同步后导入HDFSMapReduce Hive Spark 读取数据进行计算 结果再保存到HDFSMapReduce Hive Spark 离线计算, HDFS 离线存储 离线计算通常针对(某一类别)全体数据, 比如 历史上所有订单离线计算特点: 数据规模大, 运行时间长 流式计算 淘宝双11 每秒产生订单数 监控宣传Storm(毫秒) SparkStreaming(秒)

数据输出与展示

HDFS需要把数据导出交给应用程序, 让用户实时展示 ECharts 淘宝卖家量子魔方 给运营和决策层提供各种统计报告, 数据需要写入数据库 很多运营管理人员, 上班后就会登陆后台数据系统

任务调度系统

将上面三个部分整合起来 大数据应用–数据分析

通过数据分析指标监控企业运营状态, 及时调整运营和产品策略,是大数据技术的关键价值之一

大数据平台(互联网企业)运行的绝大多数大数据计算都是关于数据分析的

统计指标关联分析,汇总报告,

运营数据是公司管理的基础

了解公司目前发展的状况数据驱动运营: 调节指标对公司进行管理

运营数据的获取需要大数据平台的支持

埋点采集数据数据库,日志 三方采集数据对数据清洗 转换 存储利用SQL进行数据统计 汇总 分析得到需要的运营数据报告

运营常用数据指标

新增用户数 UG user growth 用户增长

产品增长性的关键指标新增访问网站(新下载APP)的用户数

用户留存率

用户留存率 = 留存用户数 / 当期新增用户数3日留存 5日留存 7日留存

活跃用户数

打开使用产品的用户日活月活提升活跃是网站运营的重要目标

PV Page View

打开产品就算活跃打开以后是否频繁操作就用PV衡量, 每次点击, 页面跳转都记一次PV

GMV

成交总金额(Gross Merchandise Volume) 电商网站统计营业额, 反应网站应收能力的重要指标GMV相关的指标: 订单量 客单价

转化率

转化率 = 有购买行为的用户数 / 总访问用户数 数据分析案例

背景: 某电商网站, 垂直领域领头羊, 各项指标相对稳定

运营人员发现从 8 月 15 日开始,网站的订单量连续四天明显下跌

8 月 18 号早晨发现 8 月 17 号的订单量没有恢复正常,运营人员开始尝试寻找原因

是否有负面报道被扩散是否竞争对手在做活动是否某类商品缺货价格异常

没有找到原因, 将问题交给数据分析团队

在这里插入图片描述 数据分析师分析可能性

新增用户出现问题

查看日活数据, 发现日活没有明显下降

基本判断, 用户在访问网站的过程中,转化出了问题 在这里插入图片描述 转化过程:

打开APP

搜索关键词 浏览搜索结果列表

点击商品访问详情

有购买意向开始咨询

放入购物车

支付

在这里插入图片描述

订单活跃转化率 = 日订单量 / 打开用户数

搜索打开转化率 = 搜索用户数 / 打开用户数

有明显降幅的是咨询详情转化率

在这里插入图片描述

对咨询信息分类统计后发现,新用户的咨询量几乎为 0于是将问题提交给技术部门调查,工程师查看 8 月 15 日当天发布记录,发现有消息队列SDK更新

Hadoop企业应用案例之消费大数据

亚马逊提前发货系统

Hadoop企业案例之商业零售大数据

智能推荐



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3