HDFS

　　　　　　　　　　　　　 　　　Hadoop生态圈-Ranger数据安全管理框架 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰 版权声明：原创作品，谢绝转载！否则将追究法律责任。 　　 一.Ranger简介 　　Apache Ranger是一款被设计成全面掌握Hadoop生态系统的数据安全管理框架。它为Hadoop生态系统中众多的组件提供了一个统一的数据授权和管理界面。使得系统管理员只需面对Ranger一个系统，就能对Hadoop整个生态体系进行数据授权，数据管理与审计。详情请参考官网： http://ranger.apache.org/index.html 。 　　Ranger从架构上看主要由三大部分组成： 1>.User sync： 　　Ranger系统有自己的内部用户，从门户系统的登陆到权限策略的分配都是基于这些内部用户进行的。Ranger是一个统一Hadoop生态系统的安全管理框架，所以它面对的是Hadoop生态的众多组件。而这些组件使用的是服务器上的Linux用户，所以我们需要映射一份linux用户数据成为Ranger的内部用户。用户同步服务就是专门来做这件事情的，Ranger 通过用户同步服务实时的从Linux服务器中同步用户数据。 2>.Admin Portol： 　　管理员门户是一个Web UI控制台

1、理解State（状态） 1.1、State 对象的状态 Flink中的状态：一般指一个具体的task/operator某时刻在内存中的状态（例如某属性的值） 注意：State和Checkpointing 不要搞混 checkpoint则表示了一个Flink Job，在一个特定时刻的一份全状态快照，即包含一个job下所有task/operator 某时刻的状态 状态的作用 增量计算 聚合操作 机器学习训练模式 等等 容错 Job故障重启 升级 1.2、状态的分类 1、Operator State 绑定到特定operator并行实例，每个operator的并行实例维护一个状态 与key无关 例如：一个并行度为3的source，如果只考虑一个算子需要一个逻辑状态的情形，那么他就有3operator个状态 支持的数据类型 ListState 2、Keyed State 基于KeyedStream之上的状态，dataStream.keyBy()，只能在作用于KeyedStrem上的function/Operator里使用 KeyBy之后的Operator State，可理解为分区过的Operator State 每个并行keyed Operator的每个实例的每个key有一个Keyed State：即就是 一个唯一的状态，由于每个key属于一个keyed operator的并行实例

公司要将监控数据存入opentsdb，而opentsdb使用了hbase作为存储。所以想搭建一套高可用的分布式存储来供opentsdb使用。 因为机器有限，所以测试过程中将三台集群的环境安装在docker上。 一：宿主机版本和docker版本 　　宿主机：Centos7.2 3.10.0-862.14.4.el7.x86_64 　　docker：Docker version 1.13.1, build 94f4240/1.13.1 二：镜像版本 　　docker.io/centos 三：创建docker镜像 　　 mkdir -p /home/dockerfile/hbaseha 　　上传软件包至此目录 　　zookeeper-3.4.12.tar.gz 　　hbase-1.3.2.1-bin.tar.gz 　　hadoop-2.6.5.tar.gz 　　jdk8.tar.gz 　　创建Dockerfile。 　　vi Dockerfile # 选择一个已有的os镜像作为基础 FROM centos # 安装openssh - server和sudo软件包，并且将sshd的UsePAM参数设置成no RUN yum install -y openssh- server sudo RUN sed -i ' s/UsePAM yes/UsePAM no/g ' /etc/ssh/

1、KafkaUtils.createDstream 构造函数为KafkaUtils.createDstream(ssc, [zk], [consumer group id], [per-topic,partitions] ) 使用了receivers来接收数据，利用的是Kafka高层次的消费者api，对于所有的receivers接收到的数据将会保存在spark executors中，然后通过Spark Streaming启动job来处理这些数据，默认会丢失，可启用WAL日志，该日志存储在HDFS上 A、创建一个receiver来对kafka进行定时拉取数据，ssc的rdd分区和kafka的topic分区不是一个概念，故如果增加特定主体分区数仅仅是增加一个receiver中消费topic的线程数，并不增加spark的并行处理数据数量 B、对于不同的group和topic可以使用多个receivers创建不同的DStream C、如果启用了WAL，需要设置存储级别，即KafkaUtils.createStream(….,StorageLevel.MEMORY_AND_DISK_SER) 2.KafkaUtils.createDirectStream 区别Receiver接收数据，这种方式定期地从kafka的topic+partition中查询最新的偏移量

由于疫情原因在家办公，导致很长一段时间没有更新内容，这次终于带来一篇干货,是一篇关于 Hbase架构原理 的分享。 Hbase 作为实时存储框架在大数据业务下承担着举足轻重的地位，可以说目前绝大多数大数据场景都离不开Hbase。 今天就先从 Hbase 基础入手，来说说 Hbase 经常用到却容易疏忽的基础知识。 本文主要结构总结如下： Hbase 主从架构 Hbase 安装依靠 Hadoop 与 Zookeeper，网上有很多安装教程，安装比较简单，这里我们就着重看下 Habse 架构，如图： 可以从图中看出，Hbase 也是主从架构，其中 HMaster 为主，HRegionServer 为从。 Zookeeper 主要存储了Hbase中的元数据信息，如哪个表存储在哪个 HRegionServer 上； HLog 是作为 Hbase 写数据前的日志记录； BLockCache 作为读写数据的缓存； HMaster： 负责新Region分配到指定HRegionServer 管理HRegionServer 间负载均衡，迁移 region 当HRegionServer 宕机，负责 region 迁移 HRegionserver： 响应客户端读写请求 管理Region 切分变大的 Region Region： 一个 Region 对应一个 Table 表 Hbase 存储的最小单元

参考文章： kudu介绍 文章内容来源于官网文档： http://kudu.apache.org/docs/index.html 一、kudu介绍 Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的成员之一(incubating)，专门为了对快速变化的数据进行快速的分析，填补了以往Hadoop存储层的空缺。 1 功能上的空白 Hadoop生态系统有很多组件，每一个组件有不同的功能。在现实场景中，用户往往需要同时部署很多Hadoop工具来解决同一个问题，这种架构称为混合架构 (hybrid architecture)。比如，用户需要利用Hbase的快速插入、快读random access的特性来导入数据，HBase也允许用户对数据进行修改，HBase对于大量小规模查询也非常迅速。同时，用户使用HDFS/Parquet + Impala/Hive来对超大的数据集进行查询分析，对于这类场景， Parquet这种列式存储文件格式具有极大的优势。 很多公司都成功地部署了HDFS/Parquet + HBase混合架构，然而这种架构较为复杂，而且在维护上也十分困难。首先，用户用Flume或Kafka等数据Ingest工具将数据导入HBase，用户可能在HBase上对数据做一些修改。然后每隔一段时间(每天或每周)将数据从Hbase中导入到Parquet文件

参考： kudu原理与使用 1、 kudu简介 1.1、kudu是什么 简单来说:dudu是一个与hbase类似的列式存储分布式数据库。 官方给kudu的定位是:在更新更及时的基础上实现更快的数据分析 1.2、为什么需要kudu 1.2.1、hdfs与hbase数据存储的缺点 目前数据存储有了HDFS与hbase，为什么还要额外的弄一个kudu呢? HDFS:使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条纪录级别的update操作，随机读写性能差。 HBASE:可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。 正因为HDFS与HBASE有上面这些缺点， KUDU较好的解决了HDFS与HBASE的这些缺点，它不及HDFS批处理快，也不及HBase随机读写能力强，但是反过来它比HBase批处理快（适用于OLAP的分析场景），而且比HDFS随机读写能力强（适用于实时写入或者更新的场景） ，这就是它能解决的问题。 2、架构介绍 2.1、基本架构 2.1.1、概念  Table（表） ：一张table是数据存储在kudu的位置。Table具有schema和全局有序的primary key(主键)。Table被分为很多段，也就是tablets.  Tablet (段)

目录 主要组件 数据模型 注意 ：Hbase是依赖zookeeper和hdfs的，需要启动zk和hdfs。 主要组件 Zookeeper： HBase 通过 Zookeeper 来做 Master 的高可用、RegionServer 的监控、元数据的入口以及集群配置的维护等工作。 HDFS： HDFS 为 HBase 提供最终的底层数据存储服务，同时为 HBase 提供高可用的支持。 Master：（是所有 Region Server 的管理者，其实现类为 HMaster） 对RegionServer的操作： 监控 RegionServer 处理RegionServer 故障转移 处理 元数据 的变更 处理region的 分配或转移 在空闲时间进行数据的 负载均衡 通过Zookeeper发布自己的位置给客户 对于表的操作（DDL） create, delete, alter RegionServer：（为 Region 的管理者，其实现类为 HRegionServer） 1．负责存储HBase的实际数据 2．处理分配给它的Region 3．刷新缓存到HDFS 4．维护Hlog 5．执行压缩 6．负责处理Region分片 对于数据的操作：（DML） get, put, delete； Region： Hbase表的分片

Serde是 Serializer/Deserializer的简写。hive使用Serde进行行对象的序列与反序列化。 What is a SerDe? SerDe is a short name for " Serializer and Deserializer. " Hive uses SerDe (and FileFormat) to read and write table rows. HDFS files --> InputFileFormat --> <key, value> --> Deserializer --> Row object Row object --> Serializer --> <key, value> --> OutputFileFormat --> HDFS files 当是读取hdfs文件时key部分将会被忽略，在写入hdfs时key总是一个常量，一般的行的数据是存储在value中的。 用户在建表的时候可以自定义 SerDe 或者使用自带的 SerDe。如果没有指定 ROW FORMAT 或者 ROW FORMAT DELIMITED，将会使用自带的 SerDe。 你可以创建表时使用用户自定义的Serde或者native Serde，如果 ROW FORMAT没有指定或者指定了 ROW FORMAT DELIMITED就会使用native

一、环境准备 已安装Apache Spark 2.2.0(此版本仅支持Apache Spark 2.2.0, 其他Spark 版本后续会兼容) 已安装MySQL并启动,且开启远程访问 各安装节点已经配置ssh免密登录 二、下载 moonbox-0.3.0-beta下载：https://github.com/edp963/moonbox/releases/tag/0.3.0-beta 三、解压 tar -zxvf moonbox-assembly_2. 11 - 0.3 . 0 -beta-dist.tar.gz 四、修改配置文件 配置文件位于conf目录下 step 1: 修改slaves mv slaves.example slaves vim slaves 将会看到如下内容: localhost 请根据实际情况修改为需要部署worker节点的地址, 每行一个地址 step 2: 修改moonbox-env.sh mv moonbox-env.sh.example moonbox- env.sh chmod u +x moonbox- env.sh vim moonbox -env.sh 将会看到如下内容: export JAVA_HOME=path/to/installed/ dir export SPARK_HOME =path/to/installed/ dir