尚硅谷大数据技术之数仓开发规范
数据仓库开发设计流程
数据仓库开发设计流程
数据仓库开发设计流程如下：
１．分析业务需求，确定数据仓库主题：需要全面了解企业业务和数据。
２，构建逻辑模型：通常使用维度建模技术，包括维度表和事实表来描述数据。
３．数据仓库技术选型。
４．逻辑模型转换为物理模型。
５．数据源分析：识别和分析所有可用的数据源，包括内部和外部系统。
６．数据抽取、转换和加载（ETL）：确定如何从不同的数据源中提取数据，并将其转换为适合数据仓库的格式。
包括数据清洗、数据集成和数据转换等过程。
７．数据仓库架构设计：确定数据仓库的整体架构，考虑到数据仓库的可伸缩性、性能和可用性等方面。
８．数据仓库实施：根据设计的数据模型和架构来实施数据仓库。
包括创建数据库表、索引、视图等。
９．数据质量管理。
１０．开发数据仓库的分析应用。
１１．数据仓库管理和维护。
尚硅谷大数据之hive
尚硅谷大数据之hive尚硅谷大数据之hive》是一本关于Hive技术的书籍。
它旨在全面介绍Hive的主要内容和应用，并针对不同的读者群体提供有用的信息和指导。
Hive是一个开源的数据仓库基础设施工具，它构建在Hadoop 之上，用于处理大规模数据集。
通过使用Hive，用户可以使用类似于SQL的查询语言来访问和分析存储在Hadoop分布式文件系统中的数据。
这使得非技术背景的用户也能够利用Hive进行数据分析和查询。
本书主要包括以下内容：Hive基础知识：介绍Hive的基本概念、架构和组件。
读者将了解Hive如何与Hadoop生态系统中的其他工具集成，并研究如何安装和配置Hive。
Hive数据模型：详细解释Hive的数据模型，包括数据表、分区和桶等概念。
读者将研究如何创建、修改和管理Hive数据表，并了解如何利用分区和桶来提高查询性能。
Hive查询语言：深入介绍HiveQL，这是Hive的查询语言。
读者将研究如何编写各种类型的查询，包括基本的选择、过滤和聚合查询，以及复杂的连接和子查询。
Hive优化和性能调优：提供有关如何优化Hive查询性能的实用技巧和建议。
读者将研究如何使用索引、分区和桶来改善查询速度，以及如何使用适当的配置参数来优化Hive性能。
Hive高级特性：介绍Hive的一些高级特性和扩展，例如动态分区、外部表、UDF和UDAF等。
读者将了解如何利用这些功能来处理具有更复杂需求的数据分析场景。
本书适合各种读者群体，包括数据分析师、数据工程师、数据库管理员和对Hive技术感兴趣的研究者。
无论您是初学者还是有一定经验的专业人士，本书都将为您提供全面且易于理解的Hive研究资源。
2.简要介绍HiveHive是一个基于Hadoop的数据仓库基础架构，用于处理和分析大数据。
它提供了一个类似于SQL的查询语言，称为HiveQL，使用户能够对存储在Hadoop集群中的大规模数据进行查询和分析。
Hive的重要性在于它简化了大数据处理和分析的过程。
数据仓库开发规范
01数据层次的划分具体仓库的分层情况需要结合业务场景、数据场景、系统场景进行综合考虑，下面我们看一下常见的分层•ODS：Operational Data Store，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。
它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。
其主要作用是把基础数据引入到数仓。
•CDM：Common Data Model，公共维度模型层，又细分为DWD和DWS。
它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标。
▪DWD：Data Warehouse Detail，明细数据层。
▪DWS：Data Warehouse Summary，汇总数据层。
•ADS：Application Data Service，应用数据层。
02数据分类架构该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。
在进入到CDM层后，由以下几部分组成：•公共维度层：基于维度建模理念思想，建立整个企业的一致性维度。
•明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。
您可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化处理。
•公共汇总粒度事实层：以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段来物理化模型。
03数据划分及命名约定请根据业务划分数据并约定命名，建议针对业务名称结合数据层次约定相关命名的英文缩写，这样可以给后续数据开发过程中，对项目空间、表、字段等命名做为重要参照。
数据划分•按业务划分：命名时按主要的业务划分，以指导物理模型的划分原则、命名原则及使用的ODS project。
•按数据域划分：命名时按照CDM层的数据进行数据域划分，以便有效地对数据进行管理，以及指导数据表的命名。
数据库开发规范
数据库开发规范数据库开发规范指的是在进行数据库开发工作时，要遵循的一系列规范和准则，以确保数据库的设计合理性、效率和稳定性。
以下是一个包括约1000字的数据库开发规范：一、命名规范1. 表名、字段名、视图名、存储过程名、函数名、触发器名等应该使用有意义的英文单词或词组来命名，且使用下划线作为单词之间的分隔符。
例如，表名可以命名为“students”，字段名可以命名为“student_id”。
2. 表名应该使用单数形式，例如“student”而不是“students”。
二、数据类型规范1. 在选择数据类型时，应尽量使用最简单的数据类型，避免使用过于复杂的数据类型。
2. 需要存储精确浮点数时应使用 DECIMAL 或 NUMERIC 数据类型，避免使用浮点型数据类型，例如 FLOAT 或DOUBLE。
3. 需要存储日期和时间时应分别使用 DATE 和 TIMESTAMP数据类型。
三、主键规范1. 每个表都应该有一个主键，用于唯一标识每一条记录。
2. 主键应该是简单、稳定和不可更改的。
一般情况下，可以使用自增长的整数作为主键。
3. 主键的命名应该统一，并且在命名时应遵循表名加上“_id”的规则。
四、索引规范1. 对于经常被查询或用于连接的字段，应该添加索引，以提高查询性能。
2. 除非有特殊需要，不要在较小的表上创建索引，因为索引会增加查询和更新的开销。
3. 在创建索引时，应该根据具体的查询需求选择合适的索引类型，包括唯一索引、非唯一索引、聚集索引、非聚集索引等。
五、约束规范1. 应该使用外键约束来确保数据的完整性和一致性。
2. 外键约束应该定义在子表上，并且应该指向主表的主键。
3. 在删除或更新主表的数据时，应该采取合适的措施来处理与之相关的子表数据，例如设置级联删除或级联更新。
六、存储过程和函数规范1. 存储过程和函数应该使用有意义的名称，以描述其功能。
2. 存储过程和函数应该尽量简短，并且只处理一个具体的业务逻辑。
数据仓库规范
数据仓库规范一．数据仓库层次结构规范1.1 基本分层结构系统的信息模型从存储的内容方面可以分为，STAGE接口信息模型、ODS/DWD信息模型，MID信息模型、DM信息模型、元数据信息模型。
在各个信息模型中存储的内容如下描述：1) SRC接口层信息模型：提供业务系统数据文件的临时存储，数据稽核，数据质量保证，屏蔽对业务系统的干扰，对于主动数据采集方式，以文件的方式描述系统与各个专业子系统之间数据接口的内容、格式等信息。
与该模型对应的数据是各个专业系统按照该模型的定义传送来的数据文件。
STAGE是生产系统数据源的直接拷贝，由ETL过程对数据源进行直接抽取，在格式和数据定义上不作任何改变。
与生产系统数据的唯一不同是，STAGE层数据具有时间戳。
STAGE层存在的意义在于两点：（1）对数据源作统一的一次性获取，数据仓库中其他部分都依赖于STAGE层的数据，不再重复进行抽取，也不在生产系统上作运算，减小生产系统的压力；（2）在生产系统数据已经刷新的情况下，保存一定量的生产系统的历史数据，以便在二次抽取过程中运算出错的情况下可以进行回溯。
2) ODS/DWD层（对应原模型的ODS和DW层）信息模型：简称DWD层是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中。
为企业进行经营数据的分析，系统将数据按分析的主题的形式存放，跟STAGE层的粒度一致，属于分析的公共资源。
3) MID 信息模型：轻度综合层是新模型增加的数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计。
轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并为满足一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀。
4) DM信息模型：为专题经营分析服务，系统将数据按分析的专题组织成多维库表的形式存放，属于分析目标范畴的数据组织与汇总，属于分析的专有资源。
03_尚硅谷大数据之Kafka工作流程分析
第3章Kafka工作流程分析Kafka核心组成Producer A Producer BTopic APartition 0Topic APartition 1Broker1Leader FollowerReplicationA/0ReplicationA/1Topic APartition 0Topic APartition 1Broker2LeaderFollowerConsumer AConsumer BKafka ClusterBroker3Partition0message0message1Consumer CZookeeperConsumer groupmessage to A-0 message to A-1 message to B-0message from A-0 message from A-1message from B-0生产者生产消息Kafka集群管理消息消费者消费消息Zookeeper注册消息3.1 Kafka生产过程分析3.1.1 写入方式producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。
3.1.2 分区（Partition）消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成，其组织结构如下图所示：我们可以看到，每个Partition中的消息都是有序的，生产的消息被不断追加到Partition log上，其中的每一个消息都被赋予了一个唯一的offset值。
1）分区的原因（1）方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；（2）可以提高并发，因为可以以Partition为单位读写了。
数据仓库开发规范
数据仓库设计与开发规范1概述2数据仓库设计规范2.1命名规范数据仓库库表的命名规范命名规范➢RAW表：RAW+源表名称➢中间表：MID+源表名称➢如果表名字符长度超过32位，则在源表名称中英文字母缩写替换英文单词表字段命名规范命名规范数据库字段的命名必须遵循以下规范：➢采用有意义的字段名。
字段的名称必须是易于理解，能表达字段功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。
➢系统中属于是业务范围内的编号的字段，其代表一定的业务信息，这样的字段建议命名为：代表当前这字段含意的英文单词+ “ID”➢尽量遵守第三范式的标准（3NF）。
✧表内的每一个值只能被表达一次✧表内的每一行都应当被唯一的标示✧表内不应该存储依赖于其他键的非键信息存储过程命名规范命名规范➢存贮过程的命名请遵循以下命名规范：P_ MID_+ 业务逻辑（英文单词或缩写）如：P_MID_PUB_TRADE_BUY设计规范在存贮过程中必须说明以下内容：➢名称：存贮过程。
➢描述：描述存储过程的作用➢创建者：首次创建此存贮过程的人的姓名。
在此请使用中文全名，不允许使用英文简称。
➢修改者、修改日期、修改原因：如果有人对此存贮过程进行了修改，则必须在此存贮过程的前面加注修改者姓名、修改日期及修改原因。
➢对存贮过程各参数及变量的中文注解。
示例如下：-- =============================================-- procedurename: P_MID_PUB_TRADE_BUY-- description : 公募交易表-- author : 张三-- create date : 2015-07-17--source_table : raw_tp_dis_trade_app_rec--target_table : MID_PUB_TRADE_BUY--modified ：修改日期：2015-07-20 修改原因及内容-- =============================================视图命名规范命名规范➢视图的命名请遵循以下命名规范：V_ +_操作的表名（不带前缀）或功能的英文单词或英文单词缩写。
08_尚硅谷大数据之压缩和存储
第8章压缩和存储8.1 Hadoop源码编译支持Snappy压缩8.1.1 资源准备1）CentOS联网配置CentOS能连接外网。
Linux虚拟机ping 是畅通的注意：采用root角色编译，减少文件夹权限出现问题2）jar包准备(hadoop源码、JDK8 、maven、protobuf)（1）hadoop-2.7.2-src.tar.gz（2）jdk-8u144-linux-x64.tar.gz（3）snappy-1.1.3.tar.gz（4）apache-maven-3.0.5-bin.tar.gz（5）protobuf-2.5.0.tar.gz8.1.2 jar包安装0）注意：所有操作必须在root用户下完成1）JDK解压、配置环境变量JAVA_HOME和PATH，验证java-version(如下都需要验证是否配置成功)[root@hadoop101 software] # tar -zxf jdk-8u144-linux-x64.tar.gz -C /opt/module/ [root@hadoop101 software]# vi /etc/profile[root@hadoop101 software]#source /etc/profile验证命令：java -version2）Maven解压、配置 MAVEN_HOME和PATH。
[root@hadoop101 software]# tar -zxvf apache-maven-3.0.5-bin.tar.gz -C /opt/module/[root@hadoop101 apache-maven-3.0.5]# vi /etc/profile[root@hadoop101 software]#source /etc/profile验证命令：mvn -version8.1.3 编译源码1）准备编译环境[root@hadoop101 software]# yum install svn[root@hadoop101 software]# yum install autoconf automake libtool cmake[root@hadoop101 software]# yum install ncurses-devel[root@hadoop101 software]# yum install openssl-devel[root@hadoop101 software]# yum install gcc*2）编译安装snappy[root@hadoop101 software]# tar -zxvf snappy-1.1.3.tar.gz -C /opt/module/[root@hadoop101 module]# cd snappy-1.1.3/[root@hadoop101 snappy-1.1.3]# ./configure[root@hadoop101 snappy-1.1.3]# make[root@hadoop101 snappy-1.1.3]# make install# 查看snappy库文件[root@hadoop101 snappy-1.1.3]# ls -lh /usr/local/lib |grep snappy3）编译安装protobuf[root@hadoop101 software]# tar -zxvf protobuf-2.5.0.tar.gz -C /opt/module/[root@hadoop101 module]# cd protobuf-2.5.0/[root@hadoop101 protobuf-2.5.0]# ./configure[root@hadoop101 protobuf-2.5.0]# make[root@hadoop101 protobuf-2.5.0]# make install# 查看protobuf版本以测试是否安装成功[root@hadoop101 protobuf-2.5.0]# protoc --version4）编译hadoop native[root@hadoop101 software]# tar -zxvf hadoop-2.7.2-src.tar.gz[root@hadoop101 software]# cd hadoop-2.7.2-src/[root@hadoop101 software]# mvn clean package -DskipTests -Pdist,native -Dtar -Dsnappy.lib=/usr/local/lib -Dbundle.snappy执行成功后，/opt/software/hadoop-2.7.2-src/hadoop-dist/target/hadoop-2.7.2.tar.gz即为新生成的支持snappy压缩的二进制安装包。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.背景
为了避免底层业务变动对上层需求影响过大，屏蔽底层复杂的业务逻辑，尽可能简单、完整的在接口层呈现业务数据，建设高内聚松耦合的数据组织，使数据从业务角度可分割，显得尤为重要。
从整个集团业务条线出发，形成数据仓库总体概念框架，并对整个系统所需要的功能模块进行划分，明确各模块技术细节，建设一套完整的开发规范。
2.分层规范
ODS（原始数据层）：ODS层是数据仓库准备区，为DWD层提供基础原始数据。
DWD（明细数据层）：和ODS粒度一致的明细数据，对数据进行去重，脏数据过滤，空处理，保证数据质量。
DWS（服务数据层）：轻度汇总数据及建宽表(按主题)存放数据。
ADS（应用数据层）：存放应用类表数据。
3.表规范
3.1 命名
维表命名形式：dim_描述
事实表命名形式：fact_描述_[AB]
临时表命名形式：tmp_ 正式表名_ [C自定义序号]
宽表命名形式：dws_主题_描述_[AB]
备份表命名形式：正式表名_bak_yyyymmdd
表命名解释：
1）表名使用英文小写字母，单词之间用下划线分开，长度不超过40个字符，命名一般控制在小于等于6级。
2）其中ABC第一位"A"时间粒度：使用"c"代表当前数据，"h"代表小时数据，"d"代表天
数据，"w"代表周数据，"m"代表月数据，"q"代表季度数据， "y"代表年数据。
3）其中ABC的第二位"B"表示对象属性，用"t"表示表，用"v"表示视图。
4）其中ABC的第三位"C"自定义序号用于标识多个临时表的跑数顺序。
3.2 注释
注释要结合表的英文名，要求注释简洁明了，体现出表的业务出处、主题和用途。
3.3 存储格式
所谓的存储格式就是在Hive建表的时候指定的将表中的数据按照什么样子的存储方式，如果指定了方式，那么在向表中插入数据的时候，将会使用该方式向HDFS中添加相应的数据类型。
在数仓中建表默认用的都是PARQUET存储格式，相关语句如下所示：STORED AS INPUTFORMAT
‘org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat’
OUTPUTFORMAT
‘org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat’
3.5 字符集
Hadoop和hive 都是用utf-8编码的，在建表时可能涉及到中文乱码问题，所以导入的文件的字符编码统一为utf-8格式。
3.6 约定
理论上在数仓落地的表不应该出现null未知类型，对于可能出现null的字段，如果为字符型统一为空字符串，如果是数值则给0。
4.字段规范
4.1 命名
1）使用英文小写字母，单词之间用下划线分开，长度不超过30个字符，命名一般控制在小于等于4级；
2）和源数据ods层表字段名一致，如为新增字段，尽量言简意赅；
3）英文名尽量专业，符合业界要求，不得使用汉语拼音；
4）尽量避免使用关键字。
如无法避免，使用”`”转义；
5）指标字段能使用缩写的尽量使用统一的缩写，如申请金额统计apply_amt_sum。
4.2 注释
注释本着简洁、详实、完整的原则，对于有业务含义的字段，在注释中需要枚举并解释其业务含义，如ods_loan_apidata_order_info.order_status 订单状态：1待支付，2支付不成功，3支付成功；
4.3 类型
日期时间等格式统一用string类型，字符串也是用string，数值的话，会根据字段定义来确定，对于有小数点要求的，比如某些金额、利率，需要用到decimal类型，无小数点要求的用浮点类型double和整数类型（int，bigint）。
5.代码规范
5.1 sql编码
1）关键字右对齐，代码注释详尽，查询字段时每行不超过三个字段，缩进时空四格等相关书写规范。
2）明细数据层依赖于ods层，应用数据层依赖于服务数据层，原则上，不允许跨层查询。
3）如果SQL语句连接多表时，应使用表的别名来引用列。
4）WHERE条件中参数与参数值使用的类型应当匹配，避免进行隐式类型转化。
5）在SELECT语句中只获取实际需要的字段。
5.2 shell脚本
调度脚本主要是通过跑shell脚本，shell脚本的注意点：
1）命名与所跑的目标表名相同，注释要完善，后缀以.sh结尾。
2）脚本头需要加上分割线、作者、日期、目的、描述等信息。