HDFS

桔妹导读： Presto在滴滴内部发展三年，已经成为滴滴内部Ad-Hoc和Hive SQL加速的首选引擎。目前服务6K+用户，每天读取2PB ~ 3PB HDFS数据，处理30万亿~35万亿条记录，为了承接业务及丰富使用场景，滴滴Presto需要解决稳定性、易用性、性能、成本等诸多问题。我们在3年多的时间里，做了大量优化和二次开发，积攒了非常丰富的经验。本文分享了滴滴对Presto引擎的改进和优化，同时也提供了大量稳定性建设经验。 1. Presto简介 ▍ 1.1 简介 Presto是Facebook开源的MPP（Massive Parallel Processing）SQL引擎，其理念来源于一个叫Volcano的并行数据库，该数据库提出了一个并行执行SQL的模型，它被设计为用来专门进行高速、实时的数据分析。Presto是一个SQL计算引擎，分离计算层和存储层，其不存储数据，通过Connector SPI实现对各种数据源（Storage）的访问。 ▍ 1.2 架构 Presto沿用了通用的Master-Slave架构，一个Coordinator，多个Worker。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行；Worker节点负责实际执行查询任务。Presto提供了一套Connector接口，用于读取元信息和原始数据，Presto

小编在去年的时候，写过一篇轰动全网的文章 《你需要的不是实时数仓 | 你需要的是一款强大的OLAP数据库》 ，这篇文章当时被各大门户网站和自媒体疯狂转载，保守阅读量也在50万+UV，在这篇文章中提到过Preto，Presto作为OLAP计算领域的一员有着独特的优势和特点。 本篇文章是作者作为Presto小白时期，经过调研、线上调试、生产环境稳定运行这个过程中大量的实践经验和资料检索，沉淀下来的一个读书笔记。本文从原理入门、线上调优、典型应用等几个方面为读者全面剖析Presto，希望对大家有帮助。 我是谁？我从哪里来？要到哪里去？ Presto is an open source distributed SQL query engine for running interactive analytic queries against data sources of all sizes ranging from gigabytes to petabytes. Presto allows querying data where it lives, including Hive, Cassandra, relational databases or even proprietary data stores. A single Presto query can combine data

介绍Hadoop 大数据胜于好算法 如果数据足够多，可能产生意想之外的应用 无论算法好坏，更多的数据总能带来更好的推荐效果 大数据存储和分析遇到的问题 磁盘容量的增长远远大于磁盘读取速度 1TB的磁盘，数据传输速度100MB/s，读一遍2.5H 写数据就更慢了 解决之道 磁盘数据并行读写 分布式文件系统，冗余 MapReduce Hadoop Hadoop是一个由Apache基金会所开发的分布式系统基础架构。Hadoop提供了一个可靠的共享存储和分析系统。HDFS实现存储，MapReduce实现分析处理。 传统关系型数据库 vs MapReduce Hadoop生态圈 Hadoop支持多种语言，包括Java/C/Python/Ruby HDFS Hadoop Distributed File System HDFS是Hadoop的首选分布式文件系统，同时Hadoop也可以支持其他文件系统，例如本地文件和其他分布式系统。 超大文件->1024G->1T->1024T->1P HDFS是为大数据吞吐设计的，这可能会以时间延迟为代价 HDFS的block默认为64M,Map任务通常一次处理一个块的任务 nodename存储文件的元数据，nodename是放在内存中的，所以文件存储的节点受限于namenode的内存大小 显示分布式系统的数据块结构： # DEPRECATED hadoop

Hadoop基本介绍 hadoop 的组成部分 HDFS 辅助管理者：SecondaryNameNode 工作者：DataNode MapReduce Yarn HDFS 副本存放机制 第一份 第二份 第三个 Namenode作用 DataNode作用 RPC remote procedure call HDFS数据写入流程（重点） HDFS数据读取流程（重点） HDFS数据完整性 HDFS适用场景 hadoop 的组成部分 HDFS 管理者：NameNode 作用：负责管理，管理集群内各个节点。 负责管理整个文件系统的元数据（指的是数据的存放位置或存放路径）或名字空间 辅助管理者：SecondaryNameNode 作用：责辅助NameNode管理工作。 工作者：DataNode 作用：负责工作，进行读写数据。 周期向NameNode汇报。 负责管理用户的文件数据块(一个大的数据拆分成多个小的数据块) MapReduce Yarn 管理者：ResourceManager 工作者：NodeManager HDFS 副本存放机制 第一份 数据来源于客户端 第二份 存放的位置是与第一个副本在相同机架上，且不在同一个节点，按照一定的规则（cpu 内存 IO是用率，和硬盘剩余容量）找到一个节点存放 第三个 副本的存放位置是与第一第二份数据副本不在同一个机架上

一、HDFS读取文件流程： 详解读取流程： Client调用FileSystem.open()方法： 　　1 FileSystem通过 RPC 与NN通信，NN返回该文件的部分或全部block列表（含有block拷贝的DN地址）。 　　2 选取举栗客户端最近的DN建立连接，读取block，返回 FSDataInputStream 。 Client调用输入流的read()方法： 　　1 当读到block结尾时，FSDataInputStream关闭与当前DN的连接，并未读取下一个block寻找 最近DN 。 　　2 读取完一个block都会进行 checksum 验证 ，如果读取DN时出现错误，客户端会通知NN，然后再从下一个拥有该block拷贝的DN继续读。 　　3 如果block列表读完后，文件还未结束，FileSystem会继续从NN获取下一批block列表。 关闭FSDataInputStream 二、HDFS文件写入流程： 详细写入流程： Client调用FileSystem的create()方法： 　　1 FileSystem向NN发出请求，在NN的namespace里面创建一个新的文件，但是并 不关联任何块 。 　　2 NN检查文件是否 已经存在、操作权限 。如果检查通过，NN记录新文件信息，并在某一个DN上创建数据块。 　　3 返回FSDataOutputStream

HDFS的读写流程 一、写操作 前提：File大小为200M，block.size为128M，block分为两块block1和block2（块小于block.size的不会占用一个真个block大小，而是实际的大小）。 写操作的流程图 1. Client向NameNode发起写入请求。 2. NameNode返回可用的DataNode列表。 若client为DataNode节点，那存储block时，规则为：副本1，当前client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选。 若client不为DataNode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1，机架上；副本3，同副本2相同的另一个节点上；其他副本随机挑选。 3. client向DataNode发送block1，数据首先被写入FSDataOutputStream对象内部的Buffer中，然后数据被分割成一个个data package，每个Packet大小为64k字节，每个Packet又由一组chunk和这组chunk对应的checksum数据组成，默认chunk大小为512字节，每个checksum是对512字节数据计算的校验和数据。 当Client写入的字节流数据达到一个Packet的大小，这个Packet会被构建出来

1 文档编写目的 本文主要介绍HDFS Federation（联邦）相关知识，为后续文章《如何为CDH集群启用Federation（联邦）》做一个简单的铺垫。Federation即为“联邦”，该特性允许一个HDFS集群中存在多组Namenode同时对外提供服务，分管一部分目录（水平切分），彼此之间相互隔离，但共享底层的Datanode存储资源。 文章目录结构： 1. 文档编写目的 2. Federation 2.1 单组Namenode架构 2.2 单组Namenode局限性 2.3 为什么要引入Federation 3. Federation 介绍 3.1 Federation 架构 3.1.1 主要优点 3.1.3 主要缺点 3.2 Federation 局限性 4. 总结 2 Federation 背景 2.1 单组Namenode架构 HDFS 主要有两大模块： Namespace （命名空间）： 由目录、文件和块组成，它支持所有命名空间相关的文件操作，如创建、删除、修改，查看所有文件和目录。 Block Storage Service （块存储服务）：包括Block管理和存储两部分 Block 管理 通过控制注册以及阶段性的心跳，来保证Datanode的正常运行； 处理Block的报告信息和维护块的位置信息； 支持Block相关的操作，如创建、删除、修改

HDFS是分布式文件系统，它默认的存储单元是64M的数据块, 包括namenode,datanode,secondary namenode. namenode(元数据节点)： 1.namenode是用来管理文件系统的命名空间的，它将所有的文件和文件夹的元数据都保存在一个文件系统树中。 2.这些信息也会在硬盘上保存成命名空间镜像(namespace image)及修改日志(edit log)。 3.它还保存了一个文件里面包括哪些数据块，分布在哪些数据节点上，但是这些信息不存储在硬盘上，而是系统启动时从数据节点(datanode)收集的。 datanode(数据节点)：datanode是真正存储数据的地方。 1.client或者namenode可以向datanode请求写入或者读出数据块。 2.定时向namenode汇报存储数据块信息。 seccondary namenode(从元数据节点)：它并不是备用的namenode节点，它负责不同的事。 1.它会周期性地将namenode的namespace image和 editlog合并，以防日志文件过大。 2.合并之后的namespace image会在secondary namenode中保存一份，防止namenode节点失败时可以恢复 来源： oschina 链接： https://my.oschina.net/u/4085644

MapReduce详细工作流程之Map阶段 如上图所示 首先有一个200M的待处理文件 切片：在客户端提交之前，根据参数配置，进行任务规划，将文件按128M每块进行切片 提交：提交可以提交到本地工作环境或者Yarn工作环境，本地只需要提交切片信息和xml配置文件，Yarn环境还需要提交jar包；本地环境一般只作为测试用 提交时会将每个任务封装为一个job交给Yarn来处理（详细见后边的Yarn工作流程介绍），计算出MapTask数量（等于切片数量），每个MapTask并行执行 MapTask中执行Mapper的map方法，此方法需要k和v作为输入参数，所以会首先获取kv值； 首先调用InputFormat方法，默认为TextInputFormat方法，在此方法调用createRecoderReader方法，将每个块文件封装为k，v键值对，传递给map方法 map方法首先进行一系列的逻辑操作，执行完成后最后进行写操作 map方法如果直接写给reduce的话，相当于直接操作磁盘，太多的IO操作，使得效率太低，所以在map和reduce中间还有一个shuffle操作 map处理完成相关的逻辑操作之后，首先通过outputCollector向环形缓冲区写入数据，环形缓冲区主要两部分，一部分写入文件的元数据信息，另一部分写入文件的真实内容 环形缓冲区的默认大小是100M

Apache Flink提供了一种容错机制，可以持续恢复数据流应用程序的状态。该机制确保即使出现故障，程序的状态最终也会反映来自数据流的每条记录(只有一次)。 从容错和消息处理的语义上(at least once, exactly once)，Flink引入了state和checkpoint。 state 一般指一个具体的task/operator的状态。而 checkpoint 则表示了一个Flink Job，在一个特定时刻的一份全局状态快照，即包含了所有task/operator的状态。 Flink通过定期地做checkpoint来实现容错和恢复，容错机制连续绘制了分布式流数据流的快照。对于小状态的流应用程序，这些快照非常轻量级并且可以经常绘制，而不会对性能产生太大的影响。流应用程序的状态存储在一个可配置的地方(例如主节点或HDFS)。 如果出现程序故障(由于机器、网络或软件故障)，Flink将停止分布式流数据流。然后系统重新启动操作符并将其重新设置为最新成功的检查点。输入流被重置到状态快照的点。默认情况下，检查点是禁用的。 要使此机制实现其全部的保证，数据流源(如消息队列或代理)需要能够将流倒回到其定义的最近点。Apache Kafka可以做到，而Flink的Kafka连接器可以利用这些。 因为Flink通过分布式检查点实现快照，我们使用快照和检查点互换。