HDFS

环境：ubuntu 16.0 需要软件：jdk ssh https://mirrors.tuna.tsinghua.edu.cn/apache/hadoop/common/ 2.8.3 安装 jdk并配置环境变量 安装ssh和rshync，主要设置免密登录 sudo apt-get install ssh sudo apt-get install rshync sh-keygen -t dsa - P '' -f ~ /.ssh/id_dsa cat ~ /.ssh/id_dsa.pub >> ~ /.ssh/authorized_keys ssh 安装hadoop root@hett-virtual-machine:/usr/local/hadoop# tar -xzvf /home/hett/Downloads/hadoop-2.8.3.tar.gz root@hett-virtual-machine:/usr/local/hadoop# mv hadoop-2.8.3 hadoop root@hett-virtual-machine:/usr/local# cd hadoop/ root@hett-virtual-machine:/usr/local/hadoop# mkdir tmp root@hett-virtual-machine:/usr/local/hadoop#

版本说明： 通过 HDP 3.0.1 安装的 HBase 2.0.0 一、概述 HBase 本身提供了很多种数据导入的方式，目前常用的有三种常用方式： 使用 HBase 原生 Client API 使用 HBase 提供的 TableOutputFormat，原理是通过一个 Mapreduce 作业将数据导入 HBase 使用 Bulk Load 方式：原理是使用 MapReduce 作业以 HBase 的内部数据格式输出表数据，然后直接将生成的 HFile 加载到正在运行的 HBase 中。 <!--more--> 二、方式对比 **前两种方式：**需要频繁的与数据所存储的 RegionServer 通信，一次性导入大量数据时，可能占用大量 Regionserver 资源，影响存储在该 Regionserver 上其他表的查询。 **第三种方式：**了解过 HBase 底层原理的应该都知道，HBase 在 HDFS 中是以 HFile 文件结构存储的，一个比较高效便捷的方法就是先生成 HFile，再将生成的 HFile 加载到正在运行的 HBase 中。即使用 HBase 提供的 HFileOutputFormat2 类或者 importtsv 工具来完成上述操作。 经过对比得知：如果数据量很大的情况下，使用第三种方式（Bulk Load）更好。占用更少的 CPU

版本说明： 通过 HDP 3.0.1 安装的 HBase 2.0.0 一、概述 Apache HBase 是基于 Hadoop 构建的一个分布式的、可伸缩的海量数据存储系统。常被用来存放一些海量的(通常在TB级别以上)、结构比较简单的数据，如历史订单记录，日志数据，监控 Metris 数据等等， HBase 提供了简单的基于 Key 值的快速查询能力。 <!--more--> HBase 实际上更像是“数据存储”而不是“数据库”，因为它 缺少 RDBMS 中找到的许多功能，例如二级索引，触发器和高级查询语言等。 但是 HBase 具备许多 RDBMS 没有的功能： 通过 RegionServer 扩展存储。如果 HBase 集群从10个 RegionServer 扩展到20个 RegionServer ，那么在存储和处理能力方面都会翻倍。 强大的读写能力。 自动分片。 HBase 表通过 Region 分布在 HBase 上，并且随着数据的增长， Region 会自动分割和重新分配。 RegionServer 自动故障转移。如果一个 RegionServer 宕机或进程故障，由 Master 负责将它原来所负责的 Regions 转移到其它正常的 RegionServer 上继续提供服务。 Hadoop/HDFS 集成： HBase 使用 HDFS 作为其分布式文件系统。

在本系列的第三部分，我使用了一个示例来详细地介绍 Impala query profile 。在这一部分中，我将使用一个真实生产系统的 Impala Profile 文件，解释我在遇到问题时阅读 Profile 文件的步骤，并逐渐找到引起问题的真正原因。如果你错过了我的文章的前3个部分，你可以点击以下链接阅读一下： 一步一步理解Impala query profile（一） 一步一步理解Impala query profile（二） 一步一步理解Impala query profile（三） 好了，我们开始吧。由于 Profile 文件本身相当大，因为它涉及到多个 Impalad 进程，所以如果我将完整的内容在页面上显示出来，页面就会很难看。因此，请从这个 链接 下载，并在你本地电脑或浏览器上来查看这个文件。 这个查询的问题是，不知道出于什么原因，之前执行相同的查询几分钟内就可以完成，但现在要花1个多小时才能完成。这个 Profile 文件只是其中的一个例子，实际上，当时在这个集群中运行的所有查询都有相同的问题。所以请花点时间看一下这个 Profile ，看看你是否能获取什么有用的信息，并对问题产生的场景有一个大致的了解。 现在，让我们一起来看看排查该问题的步骤。 1、由于用户反馈查询时间比正常情况下长，我想知道的第一件事是到底花费了多长时间？所以首先，我在 Profile

前言 只有光头才能变强。 文本已收录至我的GitHub仓库，欢迎Star： https://github.com/ZhongFuCheng3y/3y 这篇文章主要是 入门 大数据，不涉及到高深的知识点和理论，我相信每个人都看得懂。如果文章有错误的地方，不妨在评论区友善指出~ 一、什么是大数据？ 1.1 前置知识 我有的时候给 外行人 讲解什么是数据库，就常常用Excel来举例子(因为大多数人认识什么是Excel)。在知乎有一个类似的题目《有excel了要数据库干啥？》，大家可以去看看： https://www.zhihu.com/question/26779236 其实很大一部分原因就是：Excel能处理的 数据量 远远没有数据库得多。由于我们互联网产生的数据是非常非常多的，所以我们一般选择数据库来存储数据。 Excel只有104w行，多了加载不进去的 ---- @知乎 EamonLiao 众所周知，我们能存多少数据，是取决于我们 硬盘 的大小的。比如，我的磁盘的大小就256GB(实际能存储的大小是没有256GB的，但这里我就不展开了)，这意味着我这电脑只能存储比256GB要小的数据。 硬盘的大小 为了能够更好地管理计算机的数据(访问和查找变得更加简单)，我们就有了 文件系统 。 文件系统 有了文件系统，已经可以存储数据了（很方便我们去获取），那为什么还会有数据库呢？

HDFS非常容易存储大数据文件，如果Hive中存在过多的小文件会给namecode带来巨大的性能压力。同时小文件过多会影响JOB的执行，hadoop会将一个job转换成多个task，即使对于每个小文件也需要一个task去单独处理，task作为一个独立的jvm实例，其开启和停止的开销可能会大大超过实际的任务处理时间。 同时我们知道hive输出最终是mr的输出，即reducer（或mapper）的输出，有多少个reducer（mapper）输出就会生成多少个输出文件，根据shuffle/sort的原理，每个文件按照某个值进行shuffle后的结果。 为了防止生成过多小文件，hive可以通过配置参数在mr过程中合并小文件。而且在执行sql之前将小文件都进行Merge，也会提高程序的性能。我们可以从两个方面进行优化，其一是map执行之前将小文件进行合并会提高性能，其二是输出的时候进行合并压缩，减少IO压力。 1、小文件带来的问题 HDFS的文件元信息，包括位置、大小、分块信息等，都是保存在NameNode的内存中的。每个对象大约占用150个字节，因此一千万个文件及分块就会占用约3G的内存空间，一旦接近这个量级，NameNode的性能就会开始下降了。此外，HDFS读写小文件时也会更加耗时，因为每次都需要从NameNode获取元信息，并与对应的DataNode建立连接

45亿数据迁移记录后续-日数据量千万级别到clickhouse 相关文档地址 flume 参考地址 waterdrop 参考地址 clickhouse 参考地址 kafka 参考地址 环境 日志在一个服务器，clickhouse集群在另一个服务器。 思路 之前迁移数据的时候，没考虑这块，等数据整个迁移完了以后，才开始考虑，做准备的。 思路1 ： flume 读取 日志文件，然后使用flume 的avro模式传递日志(这里使用avro传递日志，是因为，日志服务器没有hadoop 环境，而且也是为了保持日志服务器的稳定)，将读取到的日志落在hdfs,写入的规则，按照天进行分割，一天一个数据文件。然后使用waterdrop 动态传递参数日期，写一个linux 的crontab 任务，每天调用一次，每次传递昨天的日期，拉取昨天的数据，从hdfs 到 clickhouse。 整个方案是可行的，初步测试，已经走通，但是与我们的场景不符合，因为我这边的数据，相对而言，都是实时数据，不允许出现一天的这么长时间的间隔。 思路2 ： 扔掉flume,使用waterdrop直接读取日志，清洗处理，然后直接到clickhous。关于waterdrop处理日志，之前博客，可翻阅进行参考。 这个方案是错误的，因为我之前并没有正确了解waterdrop，waterdrop并不支持实时数据处理，所有针对日志文件

集群机器和配置文件配置 机器配置 hadoop001 hadoop002 hadoop003 HDFS NameNode DataNode DataNode SecondaryNameNode DataNode YARN NodeManager ResourceManager NodeManager NodeManager 配置文件修改 核心配置文件 core-site.xml <!-- 指定HDFS中NameNode的地址 --> <property> <name>fs.defaultFS</name> <value>hdfs://hadoop001:9000</value> </property> <!-- 指定Hadoop运行时产生文件的存储目录 --> <property> <name>hadoop.tmp.dir</name> <value>/opt/module/hadoop-2.7.2/data/tmp</value> </property> HDFS配置文件 hadoop-env.sh export JAVA_HOME=/opt/module/jdk1.8.0_144 hdfs-site.xml <property> <name>dfs.replication</name> <value>3</value> </property> <!--

HBase的数据备份 1.1 基于HBase提供的类对表进行备份 使用HBase提供的类把HBase中某张表的数据导出到HDFS，之后再导出到测试hbase表中。 (1) ==从hbase表导出到HDFS== [hadoop@node01 shells]$ hbase org.apache.hadoop.hbase.mapreduce.Export myuser /hbase_data/myuser_bak (2) ==文件导入hbase表== hbase shell中创建备份目标表 create 'myuser_bak','f1','f2' 将HDFS上的数据导入到备份目标表中 hbase org.apache.hadoop.hbase.mapreduce.Driver import myuser_bak /hbase_data/myuser_bak/* 补充说明 以上都是对数据进行了全量备份，后期也可以实现表的 增量数据备份 ，增量备份跟全量备份操作差不多，只不过要在后面加上时间戳。 例如： HBase数据导出到HDFS hbase org.apache.hadoop.hbase.mapreduce.Export test /hbase_data/test_bak_increment 开始时间戳 结束时间戳 1.2 基于snapshot快照对表进行备份

spark 环境安装 spark的存储需要使用hdfs,所以这里先安装hadoop2.7,安装配置完成之后再安装spark 1. hadoop2.7安装 为了防止网速过慢,这里推荐一个网址 hadoop2.7.7 1.1 获取安装包 wget http://archive.apache.org/dist/hadoop/common/hadoop-2.7.5/hadoop-2.7.5.tar.gz 1.2 解压到自己想放的目录 tar -zxvf hadoop-2.7.7.tar.gz -C /export/servers/ 1.3 配置hadoop环境变量 export HADOOP_HOME=/export/servers/hadoop-2.7.7 export PATH=:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH 1.4 使配置生效 source /etc/profile 1.5 创建目录用于hadoop配置 mkdir /mnt/hadoop mkdir /mnt/hadoop/tmp mkdir /mnt/hadoop/var mkdir /mnt/hadoop/dfs mkdir /mnt/hadoop/dfs/name mkdir /mnt/hadoop/dfs/data 1.6 修改hadoop配置文件 1.6.1 core