引入
面试题
1. 有一个很大的(4T)的文件, 文件中存储的是ip, 每行存储一个, 要求求出出现此处最多的那个ip
1 | 如果这个文件是小文件: |
2. 有两个很大的文件, 两个文件中存储的都是url, 求出两个文件中相同的url
1 | 如果文件是小文件: |
3. 有一个很小的文件, 存储的都是url, 每行一个, 怎样快速判断给定的一个url是否在这个文件中
小文件: IO + 集合(set)
- 创建io 和 集合
- 进行文件读取放在 set集合中
- set.contains(url) ==> true:存在, false: 不存在
大文件:
思路1: 用hashCode() 进行分区, 然后用要查找的 url 取模定位
- 但是这样定位到了还是要一个个找
思路2:
- 数组的查询性能比较高, 数组可以通过下标
基数排序
- 数组的索引代表的是数据的原始值, 数组中存储的值, 是原始值出现的次数
- 放到对应下标的位置, 值只存出现的次数
- 如果数组中对应的下表存储的值为0, 代表此下标的值没有出现过, 就不需要输出
- 缺点:
- 数据范围过大时, 数组长度不好创建
- 数组的类型不好确定
- 如果数据比较分散时, 会造成资源浪费
- 练习: 写一个基数排序, 随机生成的20个数, 运用基数排序排序
对于本题
- 不需要统计次数, 存在标记为1, 不存在就是0
- 所以存的时候最好用boolean存, 用位数组
bit[]
- 可以设计多个hash算法, 用来校验某一种hashCode相同的情况
- 影响误判率3要素: hash算法个数 k - 数据量n - 数组长度 m
- 布隆过滤器 公式: k = 0.7*(m/n), 此时的误判率最小
大数据基本介绍
数据
- 数据就是数值,也就是我们通过观察、实验或计算得出的结果。数据有很多种,最简单的就是数字。
- 数据也可以是文字、图像、声音等。数据可以用于科学研究、设计、查证等。
结构划分:
- 结构化
- 半结构化
- 非结构化
大数据特点: 4V
数据量大
1 Byte =8 bit
1 KB = 1,024 Bytes = 8192 bit
1 MB = 1,024 KB = 1,048,576 Bytes
1 GB = 1,024 MB = 1,048,576 KB
1 TB = 1,024 GB = 1,048,576 MB (普通用户数据级别)
1 PB = 1,024 TB = 1,048,576 GB(企业级数据级别)
1 EB = 1,024 PB = 1,048,576 TB
1 ZB = 1,024 EB = 1,048,576 PB(全球数据总量级别)数据增长速度快
数据种类多
- 文字 图片 音频 视频..
- 数据的价值密度低 整体价值高
数据来源
- 公司中的自己的业务数据 淘宝 京东
- 第三方
- 爬虫 爬数据
数据处理
- 缺失数据的处理
- 考虑缺失数据是否影响整体的业务逻辑 不影响 删除
- 如果是和钱相关的数据 —-慎重 不能轻易删除
- 敏感数据
- 脱敏处理 – 加密
数据价值
- 人物画像
- 根据根据用户数据给用户做一个全方位的分析画像 属性: 人脉 消费水平 性格特点
- ….
- 根据根据用户数据给用户做一个全方位的分析画像 属性: 人脉 消费水平 性格特点
几个概念
集群:
- 多个机器共同协作完成同一个任务, 每一个机器叫做节点, 多个机器共同组成的群体叫做集群
- 集群中的每个节点之间通过局域网或其他方式通讯
分布式:
- 分而治之 , 一个任务呗分成多个子任务模块, 每个任务跑在不同的节点上
- 原来一个人干的事情, 现在大家分工劳动
- 分布式的文件系统 , 分布式数据库, 分布式计算系统
负载均衡: Nginx
- 每个节点分配到的任务基本均衡
- 负载均衡是跟每个节点自身的配置等匹配的
- 不存在绝对的均衡
Hadoop
概念
- 一个分布式的开源框架
- 支持成千上万的节点, 每个节点依靠本地的计算和存储
- 在应用层面提供高可用性
- 将硬件错误看成一个常态
Hadoop的模块
- Common
- 支持其他 Hadoop 模块的公共实用程序
- 封装: 工具类, RPC框架
- HDFS
- Hadoop的分布式文件系统, 负责海量数据的存储
- 将文件切分成指定大小的数据块并以多副本的存储形式存储在多个机器上
- 数据切分, 多副本, 容错等操作对用户是透明的
- 架构: 主从架构 ( Java进程)
- 主: namenode 一个
- 从: datenode 多个
- 助理: SecondaryNamenode 分担主进程的压力
- YARN
- 集群的资源调度框架, 负责集群的资源管理
- 架构: 主从架构
- 主: ResourceManager – 负责统筹资源
- 从: NodeManager
- MapReduce
- 分布式计算框架, 有计算任务的时候才会有响应的进程
Hadoop的搭建
搭建前的准备
1 | 搭建准备: |
方式1: 伪分布式
所有进程全部运行在同一个节点上
1 | 1)上传 |
方式2: 完全分布式
各个节点的安装的普通用户名必须相同 密码也得相同, 每个节点都需要操作
1 | 搭建准备: |
可能遇到的错误
搭建过程中
- 主机找不到
- /etc/sysconfig/network /etc/hosts
- 重启机器
- 何时化的时候报错
- 配置文件错误, 根据错误去相应文件进行调整, 修改完毕后, 重新格式化直到格式化成功
启动过程中
某些进程启动不了
措辞1: 暴力
- 全部关闭集群重新启动
- stop-dfs.sh 在任意节点执行
- stop-yarn.sh 在yarn的主节点启动
- 重新启动, 直接启动就可以了
- start-dfs.sh
- start-yarn.sh
措施2: 单独启动某些进程
单独启动hdfs
的相关进程
- hadoop-daemon.sh start hdfs 过程
- hadoop-daemon.sh start namenode
- hadoop-daemon.sh start secondarynamenode
单独启动yarn
的相关命令
- yarn-daemon.sh start yarn 的相关过程
- yarn-daemon.sh start resourcemanager
==搭建过程中的注意事项==
集群的只能成功的格式化一次, 不成功的要一直到格式化成功, 成功后就不能再次格式化
格式化的过程中: 创建出来namenode存储的相关目录
version文件: 记录仪集群的版本信息的, 每格式化一次, 就会产生一个新的版本信息
1
2
3
4
5
6namespaceID=1163449973
clusterID=CID-47f10077-2aef-4df6-a364-1a735515a100 #记录集群的版本信息的
cTime=0
storageType=NAME_NODE
blockpoolID=BP-1527239677-192.168.75.162-1527817150436
layoutVersion=-63
启动hdfs的时候: 生成datanode的相关数据信息
version: 记录datanode 相关版本的信息
1
clusterID=CID-47f10077-2aef-4df6-a364-1a735515a100
- 两个文件中的
clusterID
相同的时候, datanode 才会认为是同一个集群的
想要重复格式化, 分3步走
停止所有服务
删除 namenode 的数据目录
rm -rf /home/ap/data/hadoopdata/name
删除 datanode 的数据目录
rm -rf /home/ap/data/hadoopdata/data
此时才可以重新格式化, 否则会造成 datanode 启动不了, 注意, 关闭防火墙, 关闭vpn
也可以一步到位
rm -rf /home/ap/data
再重新格式化
集群搭建过程中环境变量的配置(jdk. hadoop…)
- 在Linux中修改环境变量的地方有3个
- /etc/profile 系统环境变量, 针对所有用户的
- ~/.bashrc 用户环境变量
- ~/.bash_profile 用户环境变量
- 这3个配置文件的加载顺序
- /etc/profile > .bashrc > .bash_profile
- 生效: 最后一次加载的生效
- 在Linux中修改环境变量的地方有3个
时间同步问题
- 只要是完全分布式的, 多个节点之间一定要做时间同步,
- 目的:
- 要和 北京/上海 时间保持一致? no
- 集群背部各个节点之间时间保持一致 yes
- why ?
- 集群内部各个节点之间需要通信, 尤其是datanode 和 namenode之间, 他们之间的通信依靠心跳机制, 他们之间的心跳存在一个时间控制, 这个时间是 630s, 他们之前需要做时间同步
集群的安装模式
1. 单机模式
- 直接解压的方式, 什么都不配置, 并且在一个节点上
- 没有分布式文件系统, 所有的文件都是来自本地, 只能对本地的文件进行读写
- 几乎没人用, 测试时偶尔会用
2. 伪分布式
- 可以看做跑在一个节点上的完全分布式
- 有分布式文件系统, 只不过这个文件系统只有一个节点
==3. 完全分布式==
规划
目前疑点: NodeManager是根据什么配置到每台机器上的??
根据表征, 可能是根据 slave文件
主机名 / IP | HDFS | YARN |
---|---|---|
cts1 / 192.168.56.131 | NameNode | 空的 |
cts2 / 192.168.56.132 | DataNode | NodeManager |
cts3 / 192.168.56.133 | DataNode + Secondary NameNode | NodeManager |
cts4 / 192.168.56.134 | DataNode | NodeManager +ResourceManager |
- hdfs 为例 : 在宏观看就是一个大的节点, 后台采用的硬件配置是三天机器的硬件配置之和, 但是对用户来讲完全感觉不到
- 在完全分布式中, 有主节点, 有从节点
- 主节点 namenode只有一个, 从节点有多个, 真实生产中, namenode会单独做一个节点
- 如果集群中namenode宕机, 整个集群还可以使用吗? 不可以
- namenode: 主要作用存储元数据 (管理数据的数据, 存储的就是datanode存储数据的描述)
- datanode: 负责集群中真正处理数据存存储的
- 如果namenode 宕机, 集群无法使用, 这也是完全分布式的一大缺点, 存在单点故障问题
- 一般生产中不太使用, 学习, 测试, 节点个数比较少的时候, 有时候也会使用这种模式
- 节点数目越多, namenode宕机的可能性越大, 压力太大
- 助理secondarynamenode: 只是一个助理, 只是分担namenode的压力, 但是不能代替
- 架构:
- 一主多从
==4. 高可用==
- 概念: 集群可以持续对外提供服务, 做到 7*24 小时不间断
- 依赖于zookeeper, 搭建放在 zookeeper课程之后
- 集群架构:
- 双主多从
- 有2个 namenode, 但是在同一时间只能有一个是 活跃的 namenode, 我们把这个活跃的namenode 成为 active 的, 另外一个是处理热备份状态, 我们将这个节点叫
standby
, 但是2个主节点存储的元数据是一模一样的, 当active namenode
宕机的时候, standby的namenode 可以立马切换为 active 的namenode, 对外提供服务, 就可以做到 集群持续对外提供服务的功能 - 如果过一段时间, 宕机的 namenode 又活过来了, 宕机的 namenode 只能是变成 standby 的
- 缺陷: 在同一时间中, 集群中只有一个active 的 namenode, 也就是说 集群中有主节点能力的节点 只有一个, 如果集群中, 节点个数过多(1000) 的时候, 会造成namenode的崩溃, namenode存储的是元数据, 元数据过多的时候, 会造成namenode的崩溃(两个都崩溃), 没有真正的分担namenode 的压力
- 实际生产多使用高可用
5. 联邦机制
- 同一个集群中可以有多个主节点, 这些主节点的地位是一样的.
- 同一时间, 可以有多个活跃的 namenode
- 这些 namenode 共同使用集群中所有的 datanode, 每个namenode 只负责管理集群中的 datanode上的一部分数据
- 一般超大集群搭建的时候: 联邦 + 高可用
- 超大集群使用
- 每个namenode进行数据管理靠的Block Pool ID相同
- 不同的namenode管理的数据Block Pool ID 不同