HDFS

1 HDFS写数据流程 1.1 剖析文件写入 HDFS写数据流程，如下图 1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。 2）NameNode返回是否可以上传。 3）客户端请求第一个 Block上传到哪几个DataNode服务器上。 4）NameNode返回3个DataNode节点，分别为DN1、DN2、DN3。 5）客户端通过FSDataOutputStream模块请求DN1上传数据，DN1收到请求会继续调用DN2，然后DN2调用DN3，将这个通信管道建立完成。 6）DN1、DN2、DN3逐级应答客户端。 7）客户端开始往DN1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，DN1收到一个Packet就会传给DN2，DN2传给DN3；DN1每传一个packet会放入一个应答队列等待应答。 8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。 1.2 网络拓扑-节点距离计算 在HDFS写数据的过程中，NameNode会选择距离待上传数据最近距离的DataNode接收数据。那么这个最近距离怎么计算呢？ 节点距离：两个节点到达最近的共同祖先的距离总和。 1.3 机架感知

1. 环境准备 在一台linux机器上，安装好hadoop运行环境，安装方式请查看： HADOOP运行环境搭建 2. 启动HDFS并运行MapReduce程序 2.1. 配置集群 1. 配置：hadoop-env.sh Linux系统中获取JDK的安装路径： [root@ hadoop101 ~]# echo $JAVA_HOME /opt/module/jdk1.8.0_144 编辑hadoop-env.sh，修改hadoop-env.sh中的JAVA_HOME 路径： export JAVA_HOME=/opt/module/jdk1.8.0_144 2. 配置：core-site.xml 首先文件的存取目录不能停留在本地，要用HDFS上的文件，就需要配置HDFS的NameNode的地址。 所以需要在core-site.xml中增加以下配置 <!-- 指定HDFS中NameNode的地址 --> <property> <name>fs.defaultFS</name> <value>hdfs://hadoop101:9000</value> </property> <!-- 指定Hadoop运行时产生文件的存储目录 --> <property> <name>hadoop.tmp.dir</name> <value>/opt/module/hadoop-2.7.2/data

Windows 端 Hdfs 客户端实现文件上传、下载等操作 文章目录 1. 先在 Centos 上开启 Hdfs 2. 在 Windows 上配置 Hadoop 2.1 下载 Hadoop 包 2.2 解压配置 2.3 可能的错误 3. 配置 winutil 和 hadoop.ddl 3.1 下载 winutil 和 hadoop.ddl 3.2 拷问至 .\hadoop-2.9.2\etc\hadoop\bin 目录 4. 创建 maven 工程， 运行读写程序 4.1 pom 文件 4.2 运行上传文件 4.3 查看结果 1. 先在 Centos 上开启 Hdfs 具体可参考： Hadoop环境搭建-1. 安装VMware及Centos7 Hadoop环境搭建-2. Hadoop单机版 Hadoop环境搭建-3. Hadoop集群版 2. 在 Windows 上配置 Hadoop 2.1 下载 Hadoop 包 地址：https://archive.apache.org/dist/hadoop/common/hadoop-2.9.2/ 2.2 解压配置 解压到目录下，在高级系统设置中设置环境变量 配置完成，在 cmd 输入"hadoop version" 验证成功 2.3 可能的错误 出现下面错误, 但是 java 却是正常的 Error: JAVA_HOME is

HDFS 定义 HDFS(Hadoop Distributed File System) ，它是一个文件系统，用于储存文件，通过目录树来定位文件；其次，它是 分布式 的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。    HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。 HDFS 优缺点 优点： 1）高容错性 数据自动保存多个副本,某个副本丢失以后，它可以自动恢复 2）适合处理大数据 能够处理数据规模大的数据；能够处理百万规模以上的文件数量 3）可构建在廉价机器上，通过多副本机制，提高可靠性 缺点： 1）不适合低延时数据访问 2）无法高效的对大量小文件进行存储 存储大量小文件会占用namenode大量的内存来存储文件目录和块信息，并且小文件存储的寻址时间会超过读取时间 3）不支持并发写入，不支持文件随机修改 HDFS组成架构 1) NameNode(NN)：就是Master，是一个主管者 （1）管理HDFS名称空间 （2）配置副本信息 （3）管理数据块映射空间 （4）处理客户端读写请求 2）DataNode(DN)：就是Slave,NameNode下达命令，DataNode执行实际操作 （1）存储实际的数据块 （2）执行数据块的读写操作 3）Client:就是客户端 （1）文件切分，文件上传HDFS的时候，Client将文件切分成Block

Hive 开发指南 三个主要组件： Serializers/Deserializers，用户可以自定义来解析自有的数据格式。 MetaStore Query Processor 一些其它组件： 命令行组件 Hive Server：提供被客户端使用的api，用于操作hive。 通用组件： Ant相关： 脚本组件： Hive SerDe （Serializer Deserializer）: Hive 使用SerDe结合FileFormat来读写表中的行。 hive并不能识别HDFS中的文件格式，用户可以使用其他工具把hdfs上的文件读取到hive表中，或者把信息按照hive能识别的格式写到hdfs上，这些格式化过的文件可以通过create external table 或者load data inpath 加载到hive中，这样仅仅是把这些文件移动到hive的表存储目录中。 Hive读写hdfs文件的FileFormat类： TextInputFormat/HiveIgnoreKeyTextOutputFormat：读写纯文本格式的文件。 SequenceFileInputFormat/SequenceFileOutputFormat：读写序列化格式的文件（SequenceFile）。 Hive序列化和反序列化的SerDe类： MetadataTypedColumnsetSerDe

作为推送行业领导者，截止目前个推SDK累计安装覆盖量达100亿（含海外），接入应用超过43万，独立终端覆盖超过10亿 （含海外）。个推系统每天会产生大量的日志和数据，面临许多数据处理方面的挑战。 首先数据存储方面，个推每天产生10TB以上的数据，并且累积数据已在PB级别。其次，作为推送技术服务商，个推有很多来自客户和公司各部门的数据分析和统计需求，例如：消息推送和数据报表。虽然部分数据分析工作是离线模式，但开源数据处理系统稳定性并不很高，保障数据分析服务的高可用性也是一个挑战。另外，推送业务并不是单纯的消息下发，它需帮助客户通过数据分析把合适的内容在合适的场景送达给合适的人,这要求系统支持数据挖掘，并保证数据实时性。最后，个推要求快速响应数据分析需求。因此，个推大数据系统面临着数据存储、日志传输、日志分析处理、大量任务调度和管理、数据分析处理服务高可用、海量多维度报表和快速响应分析和取数需求等方面的挑战。 大数据系统演进之路 面临诸多挑战，个推大数据系统在逐步发展中不断完善。其发展可分为三个阶段。一是统计报表，即传统意义的BI；二是大数据系统的基础建设阶段；三是工具、服务和产品化。 个推大数据系统演进第一阶段：统计报表计算 早期由于数据处理无太复杂的需求，个推选择几台高性能的机器，把所有数据分别放在这些机器上计算。只需在机器上多进程运行PHP或Shell脚本即可完成处理和统计

Mac 下编译 Hadoop-2.8 系统基本环境准备 1. maven：Apache Maven 3.5.4 2. jdk：1.8.0_201 3. brew：Homebrew 2.2.6 编译环境准备 1.cmake： 2.openssl： 3.snappy： 4.zlib： 5.protobuf： 编译hadoop 下载hadoop源码 开始编译 编译完成 系统基本环境准备 由于下面列的东西都比较常规，具体的安装过程就不详细列举的，有问题可以自行百度 1. maven：Apache Maven 3.5.4 2. jdk：1.8.0_201 3. brew：Homebrew 2.2.6 编译环境准备 1.cmake： 安装命令 brew install cmake 2.openssl： 安装命令 brew install openssl 3.snappy： 安装命令 brew install snappy 4.zlib： 安装命令 brew install zlib 5.protobuf： 由于必须使用2.5.0版本需要自行下载安装https://github.com/protocolbuffers/protobuf/releases/tag/v2.5.0 下载后解压后进入protobuf目录 执行命令列表，进行编译 $ cd /Users/wx2514/tool

实际生产环境当中，hadoop的环境搭建完成之后，第一件事情就是进行压力测试，测试我们的集群的读取和写入速度，测试我们网络带宽是否足够等一些基准测试 测试写入速度： 向HDFS文件系统中写入数据，10个文件，每个文件10MB，文件存放到/benchmarks/TestDFSIO中 hadoop jar /export/servers/hadoop-2.7.5/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.5.jar TestDFSIO -write -nrFiles 10 -fileSize 10MB 完成之后查看写入速度结果： hdfs dfs -text /benchmarks/TestDFSIO/io_write/part-00000 测试读取结果： 测试hdfs的读取文件性能 在HDFS文件系统中读入10个文件，每个文件10M hadoop jar /export/servers/hadoop-2.7.5/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.5.jar TestDFSIO -read -nrFiles 10 -fileSize 10MB 查看读取结果： hdfs dfs -text /benchmarks

Client发起文件上传请求，通过RPC与NameNode建立通讯，NameNode检查目标文件是否已经存在，父目录是否存在，返回是否可以上传。 Client请求第一个block该传输到哪些DataNode服务器上 NameNode根据配置文件中指定的备份数量以及机架感知原理进行文件分配，返回可用的DataNode的地址，如：A,B,C hadoop 在设计时考虑到数据的安全与高效，数据文件默认在HDFS上存放三份，存储策略为本地一份，同机架内其他一节点上一份，不同机架节点上一份。 Client请求3台DataNode中的一台A上传数据（本质上是一个RPC调用，建立pipeline）,A收到请求会继续调用B，然后B调用C，将整个pipeline建立完成，后逐级返回client。 Client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（默认64k）A收到一个packet就会传给B，B传给C，A每传一个packet会放入一个应答队列等待应答。 数据被分割成一个个packet数据包在pipeline上依次传输，在pipeline反方向上，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipelineack发送给Client。 当一个block传输完成之后

简介 压缩：原始数据通过压缩手段产生目标数据，要求输入和输出的内容是一样的（大部分），但体积是不一样的。 对于单机用户来说，磁盘空间的限制导致了文件压缩的需求；对于Hadoop用户来说，由于DataNode的限制，也要对HDFS上的数据进行压缩。压缩的目的是减少存储在HDFS上的数据所占用的空间（磁盘的角度），提升网络的传输效率（网络的角度）。对于分布式计算框架来说，Shuffle是一个主要的技术瓶颈。 大数据处理流程基本上是 输入==>处理==>输出 ，举例来说，在离线处理方面，Spark可以 HDFS==>Spark==>HDFS ，在实时处理方面，Spark Streaming可以 Kafka==>Spark Streaming==>RDBMS 。压缩可以使用在输入时，也可以使用在处理时（比如map作为中间状态，它的输出可以压缩以减少Shuffle的量），输出时。 MR在进行压缩数据处理时，不需要手工去处理。但是MR执行过程中，是需要一个动作进行数据压缩、解压的，MR根据后缀名进行处理。在处理压缩、解压的过程中，是有CPU资源的消耗的。如果集群本来CPU使用率很高，就会对其他作业产生影响，不建议使用压缩。 常见的压缩格式有 GZIP、BZIP2、LZO、SNAPPY 。选择压缩格式要从压缩比、压缩速度考虑。不同的压缩格式对应不同的codec。 BZip2Codec压缩：