HDFS

本文源码： GitHub·点这里 || GitEE·点这里 一、MapReduce概述 1、基本概念 Hadoop核心组件之一：分布式计算的方案MapReduce，是一种编程模型，用于大规模数据集的并行运算，其中Map（映射）和Reduce（归约）。 MapReduce既是一个编程模型，也是一个计算组件，处理的过程分为两个阶段，Map阶段：负责把任务分解为多个小任务，Reduce负责把多个小任务的处理结果进行汇总。其中Map阶段主要输入是一对Key-Value，经过map计算后输出一对Key-Value值；然后将相同Key合并，形成Key-Value集合；再将这个Key-Value集合转入Reduce阶段，经过计算输出最终Key-Value结果集。 2、特点描述 MapReduce可以实现基于上千台服务器并发工作，提供很强大的数据处理能力，如果其中单台服务挂掉，计算任务会自动转义到另外节点执行，保证高容错性；但是MapReduce不适应于实时计算与流式计算，计算的数据是静态的。 二、操作案例 1、流程描述 数据文件一般以CSV格式居多，数据行通常以空格分隔，这里需要考虑数据内容特点； 文件经过切片分配在不同的MapTask任务中并发执行； MapTask任务执行完毕之后，执行ReduceTask任务，依赖Map阶段的数据； ReduceTask任务执行完毕后，输出文件结果。 2

大数据开发的学习，组件还是很多的，都需要掌握并多加练习。 最好的 参考文档 当然是官方的了。 因为Hadoop生态圈组件很多，所以，在建设之初一定要检查好各版本的兼容性。避免后期麻烦。 我的练习使用Hadoop-2.7.5 以及Hbase-1.4.2 看了Hbase 手册Chapter4 兼容性没有问题。 # 行存储 优点：写入一次性完成，保持数据完整性 缺点：数据读取过程中产生冗余数据，若有少量数据可以忽略 # 列存储 优点：读取过程，不会产生冗余数据，特别适合对数据完整性要求不高的大数据领域 缺点：写入效率差，保证数据完整性方面差 # Hbase优势: 海量数据存储 快速随机访问 大量写操作的应用 # Hbase应用场景 互联网搜索引擎数据存储 海量数据写入 消息中心 内容服务系统（schema - free ） 大表复杂 & 多维度索引 大批量数据读取 # Hbase 数据模型 # 行键 时间戳 列族contens 列族ahchor 列族mime " com.cn.www " t9 anchor:cnnsi.com= " CNN " t8 anchor:my.look.cn = " CNN.com " t6 contens:html = "" mime:type= " text/html " t5 contens:html = "" t3 contens:html = ""

导读：Flink 从 1.9.0 开始提供与 Hive 集成的功能，随着几个版本的迭代，在最新的 Flink 1.11 中，与 Hive 集成的功能进一步深化，并且开始尝试将流计算场景与Hive 进行整合。 本文主要分享在 Flink 1.11 中对接 Hive 的新特性，以及如何利用 Flink 对 Hive 数仓进行实时化改造，从而实现批流一体的目标。主要内容包括： · Flink 与 Hive 集成的背景介绍 · Flink 1.11中的新特性 · 打造 Hive 批流一体数仓 一、 Flink 与 Hive 集成背景 为什么要做 Flink 和 Hive 集成的功能呢？最早的初衷是我们希望挖掘 Flink 在批处理方面的能力。众所周知，Flink 在流计算方面已经是成功的引擎了，使用的用户也非常多。在 Flink 的设计理念当中，批计算是流处理中的一个特例。也就意味着，如果 Flink 在流计算方面做好，其实它的架构也能很好的支持批计算的场景。在批计算的场景中，SQL 是一个很重要的切入点。因为做数据分析的同学，他们更习惯使用SQL 进行开发，而不是去写 DataStream 或者 DataSet 这样的程序。 Hadoop 生态圈的 SQL 引擎，Hive 是一个事实上的标准。大部分的用户环境中都会使用到了 Hive 的一些功能，来搭建数仓。一些比较新的 SQL 的引擎

前言 在大规模的分布式集群节点中，出现机器损坏的现象是十分常见的。但为了保证数据的高可用性，系统在设计上往往采用多副本的形式来达到冗余的效果。对于那些“损坏”了的机器，正常的逻辑是走正常下线过程，即decommission流程。Decommission最为核心的一点是，它要保证节点内的数据完好无恙的复制到其它健康的节点上，然后最后将此节点标记为Decommissioned状态，随后就可以从集群中移除了。Decommission过程能够减小因为坏节点下线对于集群产生的不利影响。在我们所熟知的HDFS里面，就有相当完整的Decommission过程以及命令使用方式。本文笔者不聊HDFS的Decommission，而是聊聊新一代对象存储系统Ozone的Decommission原理过程。尽管Ozone在底层数据存储原理上与HDFS差异较大，但是在Decommission部分逻辑上还是有许多共通之处的，笔者会在下文中具体阐述其中的一些区别点。 Ozone Decommission原理过程 Ozone Decommission过程用更为具体清晰的解释：Ozone基于Container的Decommission过程。Ozone在数据replication是在Datanode的Container level来做的，那么Decommission过程也就自然同样是根据Container来做的。

在很多的流处理框架的介绍中，都会说kafka是一个可靠的数据源，并且推荐使用Kafka当作数据源来进行使用。这是因为与其他消息引擎系统相比，kafka提供了可靠的数据保存及备份机制。并且通过消费者位移这一概念，可以让消费者在因某些原因宕机而重启后，可以轻易得回到宕机前的位置。 但其实kafka的可靠性也只能说是相对的，在整条数据链条中，总有可以让数据出现丢失的情况，今天就来讨论如何避免kafka数据丢失，以及实现精确一致处理的语义。 kafka无消息丢失处理 在讨论如何实现kafka无消息丢失的时候，首先要先清楚大部分情况下消息丢失是在什么情况下发生的。为什么是大部分，因为总有一些非常特殊的情况会被人忽略，而我们只需要关注普遍的情况就足够了。接下来我们来讨论如何较为普遍的数据丢失情况。 1.1 生产者丢失 前面介绍Kafka分区和副本的时候，有提到过一个producer客户端有一个acks的配置，这个配置为0的时候，producer是发送之后不管的，这个时候就很有可能因为网络等原因造成数据丢失，所以应该尽量避免。但是将ack设置为1就没问题了吗，那也不一定，因为有可能在leader副本接收到数据，但还没同步给其他副本的时候就挂掉了，这时候数据也是丢失了。并且这种时候是客户端以为消息发送成功，但kafka丢失了数据。 要达到最严格的无消息丢失配置，应该是要将acks的参数设置为-1

HBase建表高级属性，hbase应用案例看行键设计，HBase和mapreduce结合，从Hbase中读取数据、分析，写入hdfs，从hdfs中读取数据写入Hbase，协处理器和二级索引 1. Hbase高级应用1.1建表高级属性下面几个shell 命令在hbase操作中可以起到很到的作用，且主要体现在建表的过程中，看下面几个create 属性1、 BLOOMFILTER 默认是NONE 是否使用布隆过虑及使用何种方式 布隆过滤可以每列族单独启用。 使用 HColumnDe... hbase系统架构图以及各部分的功能作用，物理存储，HBase寻址机制，读写过程，Regin管理，Master工作机制 1.1 hbase内部原理1.1.1 系统架构 Client 1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。Zookeeper 1 保证任何时候，集群中只有一个master 2 存贮所有Region的寻址入口—-roo... hbase的shell命令行方式操作 进入hbase命令行 cd /home/tuzq/software/hbase-1.3.1/bin ./hbase shell 查看帮助 显示hbase中的表 List（列出你有哪些表） 创建user表，包含info、data两个列族 create

）当 sink 到 hdfs 时： ) 需修改 flume-env.sh 配置，增添 hdfs 依赖库： 　　FLUME_CLASSPATH="/root/TDH-Client/hadoop/hadoop/*:/root/TDHClient/hadoop/hadoop-hdfs/*:/root/TDH-Client/hadoop/hadoop/lib/*" 实例： a1.sources=r1 a1.sinks=k2 a1.channels=c2 a1.sources.r1.type=avro a1.sources.r1.channels=c1 c2 a1.sources.r1.bind=172.20.237.105 a1.sources.r1.port=8888 #r1的数据通过c2发送给k2输出到HDFS中存储 a1.sinks.k2.channel = c2 a1.sinks.k2.type=hdfs a1.sinks.k2.hdfs.kerberosKeytab=/etc/hdfs1/conf/hdfs.keytab a1.sinks.k2.hdfs.kerberosPrincipal=hdfs/gz237-105@TDH #存储到hdfs上的位置 a1.sinks.k2.hdfs.path= hdfs://nameservice1/yang/flume/portal