mysql 数据仓库 元数据_002.hive数据仓库建模和元数据备份

1.数据建模

装逼的解释：

是指 对现实世界各类数据的抽象组合，确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。

通俗的说：

1.概念建模阶段： 就是对业务的梳理和理解(1.客户交流 2.需求理解 3.形成实体)

2.逻辑建模阶段： 对实体进行细化，细化成具体的表，同时丰富表结构(表／列／索引／约束／视图／存储过程 等等)

3.物理建模阶段： 对逻辑建模建模阶段的各种数据库对象 生成 相应的SQL代码，运行来创建相应具体数据库对象。

2.多维数据模型的模式

这个的确需要很丰富的经验，对于我来说这个仅仅只是局限在大致了解。

1.星型

一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。

8a14c8da66222aae2c12bd0c2a108b9b.png

2.雪花型

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表，通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

d487bdefc49bd6844bb0e359609c33e6.png

3.事实星座

又称星系模式，复杂的应用可能需要多个事实表共享维表。这种模式可以看作星形模式集。

bba7745ae5daef6ed7bb96785ef24eea.png

3.元数据：MetaStore

1.相关概念

元数据服务组件，这个组件存储hive的元数据，hive的元数据存储在关系数据库里，hive支持的关系数据库有derby、mysql。元数据对于hive十分重要，因此hive支持把metastore服务独立出来，安装到远程的服务器集群里，从而解耦hive服务和metastore服务，保证hive运行的健壮性。

2.表介绍

dcff6fad28cef24779b8ce80a24a8d14.png

其中主要涉及到的表如下：

表名

说明

关联键

TBLS

所有hive表的基本信息(表名，创建时间，所属者等)

TBL_ID,SD_ID

TABLE_PARAM

表级属性，(如是否外部表，表注释，最后修改时间等)

TBL_ID

COLUMNS

Hive表字段信息(字段注释，字段名，字段类型，字段序号)

SD_ID

SDS

所有hive表、表分区所对应的hdfs数据目录和数据格式

SD_ID,SERDE_ID

SERDE_PARAM

序列化反序列化信息，如行分隔符、列分隔符、NULL的表示字符等

SERDE_ID

PARTITIONS

Hive表分区信息(所属表，分区值)

PART_ID,SD_ID,TBL_ID

PARTITION_KEYS

Hive分区表分区键(即分区字段)

TBL_ID

PARTITION_KEY_VALS

Hive表分区名(键值)

PART_ID

3.Hive 将元数据存储在 RDBMS 中，有三种模式可以连接到数据库

1.Single User Mode： 此模式连接到一个 In-memory 的数据库 Derby，一般用于 Unit Test。

edb74351bb986be92b597bdeadca68bd.png

2.Multi User Mode：通过网络连接到一个数据库中，是最经常使用到的模式。

a0a3b7f6d78339048f9e0868335f0151.png

3.Remote Server Mode：用于非 Java 客户端访问元数据库，在服务器端启动一个 MetaStoreServer，客户端利用 Thrift 协议通过 MetaStoreServer 访问元数据库。

7c9dc7084e0e650d8f286034eb96ace8.png

4.元数据MetaStore的备份机制

节点数据误删恢复问题:

1.按照时间:

mysqlbinlog --start-datetime="2010-04-16 00:00:00" --stop-datetime="2010-04-16 01:00:00" /usr/local/mysql/var/mysql-bin.0000001 > test.sql

2.按照position恢复(show slave status\G;这里能看到position值是多少)

mysqlbinlog --start-position=001 --stop-position=006 /usr/local/mysql/var/mysql-bin.0000001 > test.sql

注意，以上都是重定向，而非真正的恢复，如果需要恢复，那么可以去掉>test.sql.

mysql主从同步常见异常及恢复方法

1. 一般的异常只需要跳过一步即可恢复

>slave stop;

>SET GLOBAL sql_slave_skip_counter = 1;

>slave start;

2.断电导致主从不能同步时，通主库的最后一个bin-log日志进行恢复

在主库服务器上，mysqlbinlog mysql-bin.xxxx > binxxxx.txt

tail -n 100000  binxxxx.txt > tail-binxxxx.txt

vim tail-binxxxx.txt 打开tail-binxxxx.txt文件找到最后一个postion值

然后在从库上，change host to 相应正确的值

>slave stop;

>change master to master_host='ip', master_user='username', master_password='password', master_log_file='mysql-bin.xxxx', master_log_pos=xxxx;

>slave start;

>show slave status\G;

3.主键冲突、表已存在等错误代码如1062,1032,1060等，可以在mysql主配置文件指定

略过此类异常并继续下条sql同步，这样也可以避免很多主从同步的异常中断

[mysqld]

slave-skip-errors = 1062,1032,1060

3.mysql主从同步: 主节点机器宕机，所有数据丢失，如何恢复？

知道的朋友，留言给一下解决方案。(dump这种方案，我总感觉不太靠谱，不知道是不是我想多咯)

刚刚朋友说： 主从交换身份，然后进行同步操作，感觉好像很有道理的样子。

你们觉得呢？

可以用mysqldump工具

简单用例说明：

1.导入、导出数据库

导出：mysqldump -uroot db1 > db1.sql  (注db1为database名)

导入：mysql -uroot test < db1.sql (注test为database名，将db1中所有的表及数据导入到test数据库)

2.导入、导出表

导出：mysqldump -uroot db1 tb1 tb2>tables.sql(注db1为database名，tb1 tb2为要导出的表列表，中间用空格隔开)

导入：mysql -uroot test < tables.sql(将db1数据库中的tb1和tb2表导入到test数据库)

主从架构

cc250b8b44587a2318a8a96179aa86b9.png

8b7703ed9e44725db7c7f0b7984e43bb.png

主主架构

aa6570311b9c2d58cbc7b49bfe14abb2.png

1146a3a42a346c327c2de84727fc1c99.png