Update(Stage5)：Kudu入门_项目介绍_ CDH搭建

Kudu

导读

1. 什么是 Kudu

2. 操做 Kudu

3. 如何设计 Kudu 的表

Table of Contents

• 1. 什么是 Kudu
  • 1.1. Kudu 的应用场景
  • 1.2. Kudu 和其它存储工具的对比
  • 1.3. Kudu 的设计和结构
• 2. Kudu 安装和操做
  • 2.1. 准备初始环境
  • 2.2. 配置 Yum 源
  • 2.. 使用 Java 操做 Kudu
  • 2.. 使用 Spark 操做 Kudu
• 4. Kudu 表和模式

1. 什么是 Kudu

导读

1. Kudu 的应用场景是什么?

2. Kudu 在大数据平台中的位置在哪?

3. Kudu 用什么样的设计, 才能知足其设计目标?

4. Kudu 中有什么集群角色?

1.1. Kudu 的应用场景

现代大数据的应用场景

例如如今要作一个相似物联网的项目, 多是对某个工厂的生产数据进行分析

项目特色

1. 数据量大

   有一个很是重大的挑战, 就是这些设备可能不少, 其所产生的事件记录可能也很大, 因此须要对设备进行数据收集和分析的话, 须要使用一些大数据的组件和功能

2. 流式处理

   由于数据是事件, 事件是一个一个来的, 而且若是快速查看结果的话, 必须使用流计算来处理这些数据

3. 数据须要存储

   最终须要对数据进行统计和分析, 因此数据要先有一个地方存, 后再经过可视化平台去分析和处理

对存储层的要求

这样的一个流计算系统, 须要对数据进行什么样的处理呢?

1. 要可以及时的看到最近的数据, 判断系统是否有异常

2. 要可以扫描历史数据, 从而改进设备和流程

因此对数据存储层就有可能进行以下的操做

1. 逐行插入, 由于数据是一行一行来的, 要想及时看到, 就须要来一行插入一行

2. 低延迟随机读取, 若是想分析某台设备的信息, 就须要在数据集中随机读取某一个设备的事件记录

3. 快速分析和扫描, 数据分析师须要快速的获得结论, 执行一行 SQL 等上十天是不行的

方案一: 使用  Spark Streaming 配合  HDFS 存储

总结一下需求

• 实时处理, Spark Streaming

• 大数据存储, HDFS

• 使用 Kafka 过渡数据

可是这样的方案有一个很是重大的问题, 就是速度机器之慢, 由于 HDFS 不擅长存储小文件, 而经过流处理直接写入 HDFS 的话, 会产生很是大量的小文件, 扫描性能十分的差

方案二:  HDFS +  compaction

上面方案的问题是大量小文件的查询是很是低效的, 因此能够将这些小文件压缩合并起来

可是这样的处理方案也有不少问题

• 一个文件只有再也不活跃时才能合并

• 不能将覆盖的结果放回原来的位置

因此通常在流式系统中进行小文件合并的话, 须要将数据放在一个新的目录中, 让 Hive/Impala 指向新的位置, 再清理老的位置

方案三:  HBase +  HDFS

前面的方案都不够舒服, 主要缘由是由于一直在强迫 HDFS 作它并不擅长的事情, 对于实时的数据存储, 谁更适合呢? HBase 好像更合适一些, 虽然 HBase 适合实时的低延迟的数据村醋, 可是对于历史的大规模数据的分析和扫描性能是比较差的, 因此还要结合 HDFS 和 Parquet 来作这件事

由于 HBase 不擅长离线数据分析, 因此在必定的条件触发下, 须要将 HBase 中的数据写入 HDFS 中的 Parquet 文件中, 以便支持离线数据分析, 可是这种方案又会产生新的问题

• 维护特别复杂, 由于须要在不一样的存储间复制数据

• 难以进行统一的查询, 由于实时数据和离线数据不在同一个地方

这种方案, 也称之为 Lambda, 分为实时层和批处理层, 经过这些这么复杂的方案, 其实想作的就是一件事, 流式数据的存储和快速查询

方案四:  Kudu

Kudu 声称在扫描性能上, 媲美 HDFS 上的 Parquet. 在随机读写性能上, 媲美 HBase. 因此将存储存替换为 Kudu, 理论上就能解决咱们的问题了.

总结

对于实时流式数据处理, Spark, Flink, Storm 等工具提供了计算上的支持, 可是它们都须要依赖外部的存储系统, 对存储系统的要求会比较高一些, 要知足以下的特色

• 支持逐行插入

• 支持更新

• 低延迟随机读取

• 快速分析和扫描

1.2. Kudu 和其它存储工具的对比

导读

1. OLAP 和 OLTP

2. 行式存储和列式存储

3. Kudu 和 MySQL 的区别

4. Kudu 和 HBase 的区别

OLAP 和  OLTP

广义来说, 数据库分为 OLTP 和 OLAP。

数据处理大体能够分红两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、平常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操做，侧重决策支持，而且提供直观易懂的查询结果。 

OLTP 系统强调数据库内存效率，强调内存各类指标的命令率，强调绑定变量，强调并发操做；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

• OLTP

  先举个栗子, 在电商网站中, 常常见到一个功能 - "个人订单", 这个功能再查询数据的时候, 是查询的某一个用户的数据, 并非批量的数据

  OLTP 须要作的事情是

  1. 快速插入和更新

  2. 精确查询

  因此 OLTP 并不须要对数据进行大规模的扫描和分析, 因此它的扫描性能并很差, 它主要是用于对响应速度和数据完整性很高的在线服务应用中

• OLAP

  OLAP 和 OLTP 的场景不一样, OLAP 主要服务于分析型应用, 其通常是批量加载数据, 若是出错了, 从新查询便可

• 总结

  • OLTP 随机访问能力比较强, 批量扫描比较差

  • OLAP 擅长大规模批量数据加载, 对于随机访问的能力则比较差

  • 大数据系统中, 每每从 OLTP 数据库中 ETL 放入 OLAP 数据库中, 而后作分析和处理

行式存储和列式存储

行式和列式是不一样的存储方式, 其大体以下

• 行式存储

  行式通常用作于 OLTP, 例如个人订单, 那不只要看到订单, 还要看到收货地址, 付款信息, 派送信息等, 因此 OLTP 通常是倾向于获取整行全部列的信息

• 列式存储

  而分析平台就不太同样了, 例如分析销售额, 那可能只对销售额这一列感兴趣, 因此按照列存储, 只获取须要的列, 这样能减小数据的读取量

存储模型

结构

• Kudu 的存储模型是有结构的表

• OLTP 中表明性的 MySQL, Oracle 模型是有结构的表

• HBase 是看起来像是表同样的 Key-Value 型数据, Key 是 RowKey 和列簇的组合, Value 是具体的值

主键

• Kudu 采用了 Raft 协议, 因此 Kudu 的表中有惟一主键

• 关系型数据库也有惟一主键

• HBase 的 RowKey 并非惟一主键

事务支持

1. Kudu 缺乏跨行的 ACID 事务

2. 关系型数据库大多在单机上是能够支持 ACID 事务的

性能

• Kudu 的随机读写速度目标是和 HBase 类似, 可是这个目标创建在使用 SSD 基础之上

• Kudu 的批量查询性能目标是比 HDFS 上的 Parquet 慢两倍之内

硬件需求

• Hadoop 的设计理念是尽量的减小硬件依赖, 使用更廉价的机器, 配置机械硬盘

• Kudu 的时代 SSD 已经比较常见了, 可以作更多的磁盘操做和内存操做

• Hadoop 不太能发挥比较好的硬件的能力, 而 Kudu 为了大内存和 SSD 而设计, 因此 Kudu 对硬件的需求会更大一些

1.3. Kudu 的设计和结构

导读

1. Kudu 是什么

2. Kudu 的总体设计

3. Kudu 的角色

4. Kudu 的概念

Kudu 是什么

HDFS 上的数据分析

HDFS 是一种可以很是高效的进行数据分析的存储引擎

• HDFS 有不少支持压缩的列式存储的文件格式, 性能很好, 例如 Parquet 和 ORC

• HDFS 自己支持并行

HBase 能够进行高效的数据插入和读取

HBase 主要用于完成一些对实时性要求比较高的场景

• HBase 可以以极高的吞吐量来进行数据存储, 不管是批量加载, 仍是大量 put

• HBase 可以对主键进行很是高效的扫描, 由于其根据主键进行排序和维护

• 可是对于主键之外的列进行扫描则性能会比较差

Kudu 的设计目标

Kudu 最初的目标是成为一个新的存储引擎, 能够进行快速的数据分析, 又能够进行高效的数据随机插入, 这样就能简化数据从源端到 Hadoop 中能够用于被分析的过程, 因此有以下的一些设计目标

• 尽量快速的扫描, 达到 HDFS 中 Parquet 的二分之一速度

• 尽量的支持随机读写, 达到 1ms 的响应时间

• 列式存储

• 支持 NoSQL 样式的 API, 例如 put, get, delete, scan

整体设计

• Kudu 不支持 SQL

  Kudu 和 Impala 都是 Cloudera 的项目, 因此 Kudu 不打算本身实现 SQL 的解析和执行计划, 而是选择放在 Impala 中实现, 这两个东西配合来完成任务

  Kudu 的底层是一个基于表的引擎, 可是提供了 NoSQL 的 API

• Kudu 中存储两类的数据

  • Kudu 存储本身的元信息, 例如表名, 列名, 列类型

  • Kudu 固然也有存放表中的数据

  这两种数据都存储在 tablet 中

• Master server

  存储元数据的 tablet 由 Master server 管理

• Tablet server

  存储表中数据的 tablet 由不一样的 Tablet server 管理

• tablet

  Master server 和 Tablet server 都是以 tablet 做为存储形式来存储数据的, 一个 tablet 一般由一个 Leader 和两个 Follower 组成, 这些角色分布的不一样的服务器中

Master server

• Master server 中存储的其实也就是一个 tablet, 这个 tablet 中存储系统的元数据, 因此 Kudu 无需依赖 Hive

• 客户端访问某一张表的某一部分数据时, 会先询问 Master server, 获取这个数据的位置, 去对应位置获取或者存储数据

• 虽然 Master 比较重要, 可是其承担的职责并很少, 数据量也不大, 因此为了增进效率, 这个 tablet 会存储在内存中

• 生产环境中一般会使用多个 Master server 来保证可用性

Tablet server

• Tablet server 中也是 tablet, 可是其中存储的是表数据

• Tablet server 的任务很是繁重, 其负责和数据相关的全部操做, 包括存储, 访问, 压缩, 其还负责将数据复制到其它机器

• 由于 Tablet server 特殊的结构, 其任务过于繁重, 因此有以下的限制

  • Kudu 最多支持 300 个服务器, 建议 Tablet server 最多不超过 100 个

  • 建议每一个 Tablet server 至多包含 2000 个 tablet (包含 Follower)

  • 建议每一个表在每一个 Tablet server 中至多包含 60 个 tablet (包含 Follower)

  • 每一个 Tablet server 至多管理 8TB 数据

  • 理想环境下, 一个 tablet leader 应该对应一个 CPU 核心, 以保证最优的扫描性能

tablet 的存储结构

在 Kudu 中, 为了同时支持批量分析和随机访问, 在总体上的设计一边参考了 Parquet 这样的文件格式的设计, 一边参考了 HBase 的设计

• MemRowSet

  这个组件就很像 HBase 中的 MemoryStore, 是一个缓冲区, 数据来了先放缓冲区, 保证响应速度

• DiskRowSet

  列存储的好处不只仅只是分析的时候只 I/O 对应的列, 还有一个好处, 就是同类型的数据放在一块儿, 更容易压缩和编码

  DiskRowSet 中的数据以列式组织, 相似 Parquet 中的方式, 对其中的列进行编码, 经过布隆过滤器增进查询速度

tablet 的  Insert 流程

• 使用 MemRowSet 做为缓冲, 特定条件下写为多个 DiskRowSet

• 在插入以前, 为了保证主键惟一性, 会已有的 DiskRowSet 和 MemRowSet 进行验证, 若是主键已经存在则报错

tablet 的  Update 流程

1. 查找要更新的数据在哪一个 DiskRowSet 中

2. 数据放入 DiskRowSet 所持有的 DeltaMemStore 中, 这一步也是暂存

3. 特定时机下, DeltaMemStore 会将数据溢写到磁盘, 生成 RedoDeltaFile, 记录数据的变化

4. 定时合并 RedoDeltaFile

   • 合并策略有三种, 常见的有两种, 一种是 major, 会将数据合并到基线数据中, 一种是 minor, 只合并 RedoDeltaFile

2. Kudu 安装和操做

导读

由于 Kudu 常常和 Impala 配合使用, 因此咱们也要安装 Impala, 可是又由于 Impala 强依赖于 CDH, 因此咱们连 CDH 一块儿安装一下, 作一个完整的 CDH 集群, 搭建一套新的虚拟机

1. 建立虚拟机准备初始环境

2. 安装 Zookeeper

3. 安装 Hadoop

4. 安装 MySQL

5. 安装 Hive

6. 安装 Kudu

7. 安装 Impala

2.1. 准备初始环境

导读

以前的环境中已经安装了太多环境, 因此换一个新的虚拟机, 从头开始安装

1. 建立虚拟机

2. 安装系统

3. 复制三台虚拟机

4. 配置时间同步服务

5. 配置主机名

6. 关闭 SELinux

7. 关闭防火墙

8. 重启

9. 配置免密登陆

10. 安装 JDK

Step 1: 建立虚拟机

1. 在 VmWare 中点击建立虚拟机

2. 打开向导

3. 设置硬件兼容性

4. 指定系统安装方式

5. 指定系统类型

6. 指定虚拟机位置

7. 处理器配置

8. 内存配置

9. 选择网络类型, 这一步很是重要, 必定要配置正确

10. 选择 I/O 类型

11. 选择虚拟磁盘类型

12. 选择磁盘建立方式

13. 建立新磁盘

14. 指定磁盘文件位置

15. 终于, 虚拟机建立好了, 复制图片差点没给我累挂

Step 2: 安装  CentOS 6

1. 为虚拟机挂载安装盘

2. 选择安装盘

3. 开启虚拟机

4. 进入 CentOS 6 的安装

5. 跳过磁盘选择

6. 选择语言

7. 选择键盘类型

8. 选择存储设备类型

9. 清除数据

10. 主机名

11. 选择时区, 这一步很重要, 必定要选

12. 设置 root 帐号, 密码最好是统一的, 就 hadoop 吧

13. 选择安装类型

14. 选择安装软件的类型

15. 安装完成, 终于不用复制图片了, 开心

Step 3: 集群规划

HostName	IP
cdh01.itcast.cn	192.168.169.101
cdh02.itcast.cn	192.168.169.102
cdh03.itcast.cn	192.168.169.103

已经安装好一台虚拟机了, 接下来经过复制的方式建立三台虚拟机

1. 复制虚拟机文件夹(Ps. 在建立虚拟机时候选择的路径)

2. 进入三个文件夹中, 点击 vmx 文件, 让 VmWare 加载

3. 为全部的虚拟机生成新的 MAC 地址

4. 确认 vmnet8 的网关地址, 以及这块虚拟网卡的地址

5. 修改网卡信息

   进入每台机器中, 修改 70-persistent-net.rules

   vi /etc/udev/rules.d/70-persistent-net.rules

6. 更改 IP 地址,  修改/etc/sysconfig/network-scripts/ifcfg-eth0 文件。     注意: 1. 网关地址要和 vmnet8 的网关地址一致, 2. IP 改成 192.168.169.101; 3.修改好后，重启系统！ 4.能够经过ifconfig  或者 ip addr这2个命令来查验IP地址是否正确。

Step 4: 配置时间同步服务

在几乎全部的分布式存储系统上, 都须要进行时钟同步, 避免出现旧的数据在同步过程当中变为新的数据, 包括 HBase, HDFS, Kudu都须要进行时钟同步, 因此在一切开始前, 先同步一下时钟, 保证没有问题

时钟同步比较简单, 只须要肯定时钟没有太大差别, 而后开启 ntp 的自动同步服务便可

yum install -y ntp
service ntpd start
chkconfig ntpd on  设置开机启动

同步大概须要 5 - 10 分钟, 而后查看是否已是同步状态便可

ntpstat

最后在其他两台节点也要如此配置一下

Step 5: 配置主机名

配置主机名是为了在网络内能够通讯

1. 修改 /etc/sysconfig/network 文件, 声明主机名

   # 在三个节点上使用不一样的主机名
   HOSTNAME=cdh01.itcast.cn

2. 修改 /etc/hosts 文件, 肯定 DNS 的主机名

   127.0.0.1 cdh01.itcast.cn localhost cdh01
   
   192.168.169.101 cdh01.itcast.cn cdh01
   192.168.169.102 cdh02.itcast.cn cdh02
   192.168.169.103 cdh03.itcast.cn cdh03

3. 在其他的两台机器中也要如此配置

Step 6: 关闭  SELinux

修改 /etc/selinus/config 将 SELinux 关闭

最后别忘了再其它节点也要如此配置

Step 7: 关闭防火墙

执行以下命令作两件事, 关闭防火墙, 关闭防火墙开机启动

service iptables stop
chkconfig iptables off

最后别忘了再其它节点也要如此配置

Step x: 重启

刚才有一些配置是没有及时生效的, 为了不麻烦, 在这里能够重启一下, 在三台节点上依次执行命令

reboot -h now

Step 8: 配置三台节点的免密登陆

SSH 有两种登陆方式

1. 输入密码从而验证登陆

2. 服务器生成随机字符串, 客户机使用私钥加密, 服务器使用预先指定的公钥解密, 从而验证登陆

因此配置免密登陆就可使用第二种方式, 大概步骤就是先在客户机生成密钥对, 而后复制给服务器

# 生成密钥对
ssh-keygen -t rsa

# 拷贝公钥到服务机
ssh-copy-id cdh01
ssh-copy-id cdh02
ssh-copy-id cdh03

而后在三台节点上依次执行这些命令

Step 9: 安装  JDK

安装 JDK 以前, 能够先卸载已经默认安装的 JDK, 这样能够避免一些诡异问题

1. 查看是否有存留的 JDK

   rpm -qa | grep java

2. 若是有, 则使用以下命令卸载

   rpm -e -nodeps xx

3. 上传 JDK 包到服务器中

4. 解压并拷贝到 /usr/java 中

   tar xzvf jdk-8u192-linux-x64.tar.gz
   mv jdk1.8.0_192 /usr/java/

5. 修改 /etc/hosts 配置环境变量

   export JAVA_HOME=/usr/java/jdk1.8.0_192
   export PATH=$PATH:$JAVA_HOME/bin

6. 在剩余两台主机上重复上述步骤

 

2.2. 建立本地 Yum 仓库

导读

建立本地 Yum 仓库的目的是由于从远端的 Yum 仓库下载东西的速度实在是太渣, 然而 CDH 的全部组件几乎都要从 Yum 安装, 因此搭建一个本地仓库会加快下载速度

1. 下载 CDH 的全部安装包

2. 生成 CDH 的 Yum 仓库

3. 配置服务器, 在局域网共享仓库

Step 1: 下载  CDH 的安装包

建立本地 Yum 仓库的原理是将 CDH 的安装包下载下来, 提供 Http 服务给局域网其它主机(或本机), 让其它主机的 Yum 可以经过 Http 服务下载 CDH 的安装包, 因此须要先下载对应的 CDH 安装包

须要注意的是, 这一步能够一点都不作, 由于已经为你们提供了对应的安装包, 在 DMP 的目录中, 就能找到 cloudera-cdh5 这个目录, 上传到服务器便可

1. 下载 CDH 的安装包须要使用 CDH 的一个工具, 要安装 CDH 的这个工具就要先导入 CDH 的 Yum 源

   wget https://archive.cloudera.com/cdh5/redhat/6/x86_64/cdh/cloudera-cdh5.repo
   mv cloudera-cdh5.repo /etc/yum.repos.d/

2. 安装 CDH 安装包同步工具

   yum install -y yum-utils createrepo

3. 同步 CDH 的安装包

   reposync -r cloudera-cdh5

Step 2: 建立本地  Yum 仓库服务器

建立本地 Yum 仓库的原理是将 CDH 的安装包下载下来, 提供 Http 服务给局域网其它主机(或本机), 让其它主机的 Yum 可以经过 Http 服务下载 CDH 的安装包, 因此须要提供 Http 服务, 让本机或者其它节点能够经过 Http 下载文件, Yum 本质也就是帮助咱们从 Yum 的软件仓库下载软件

1. 安装 Http 服务器软件

   yum install -y httpd
   service httpd start

2. 建立 Yum 仓库的 Http 目录

   mkdir -p /var/www/html/cdh/5
   cp -r cloudera-cdh5/RPMS /var/www/html/cdh/5/
   cd /var/www/html/cdh/5
   createrepo .

3. 在三台主机上配置 Yum 源

   最后一步即是向 Yum 增长一个新的源, 指向咱们在 cdh01 上建立的 Yum 仓库, 可是在这个环节的第一步中, 已经下载了一个 Yum 的源, 只须要修改这个源的文件, 把 URL 替换为 cdh01 的地址便可

   因此在 cdh01 上修改文件 /etc/yum.repos.d/cloudera-cdh5.repo 为

   baseurl=http://cdh01/cdh/5/

   在 cdh02 和 cdh03 上下载这个文件

   wget https://archive.cloudera.com/cdh5/redhat/7/x86_64/cdh/cloudera-cdh5.repo
   mv cloudera-cdh5.repo /etc/yum.repos.d/

   而后在 cdh02 和 cdh03 上修改文件 /etc/yum.repos.d/cloudera-cdh5.repo

   baseurl=http://cdh01/cdh/5/