ODS层搭建
原始数据层，ODS层是原始数据的完整备份，不做任何修改。为了方便DWD层使用，一般会在ODS层增加抽取数据的日期字段。
1,列式存储和行式存储
行存储的特点： 查询满足条件的一整行（所有列）数据的时候，列存储则需要去每个聚集的字段找到对应的每个列的值，行存储只需要找到其中一个值，其余的值都在相邻地方，所以此时行存储查询的速度更快。
列存储的特点： 因为每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量；每个字段的数据类型一定是相同的，列式存储可以针对性的设计更好的设计压缩算法。
1,TEXTFILE
默认格式，行式存储。可结合Gzip、Bzip2使用(系统自动检查，执行查询时自动解压)，但使用这种方式，hive不会对数据进行切分，从而无法对数据进行并行操作。并且反序列化过程中，必须逐个字符判断是不是分隔符和行结束符，性能较差。
2, ORCFILE
使用ORC文件格式可以提高hive读、写和处理数据的能力。ORCFile是RCFile的升级版。
在ORC格式的hive表中，数据按行分块，每块按列存储。结合了行存储和列存储的优点。记录首先会被横向的切分为多个stripes，然后在每一个stripe内数据以列为单位进行存储，所有列的内容都保存在同一个文件中。
每个stripe的默认大小为256MB，相对于RCFile每个4MB的stripe而言，更大的stripe使ORC可以支持索引，数据读取更加高效。
3,zlib压缩
优点：压缩率比较高；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样。
缺点：压缩性能一般。
4, snappy压缩
优点：高速压缩速度和合理的压缩率。
缺点：压缩率比zlib要低；hadoop本身不支持，需要安装（CDH版本已自动支持，可忽略）。
5,系统采用的格式
因为ORCFILE的压缩快、存取快，而且拥有特有的查询优化机制，所以系统采用ORCFILE存储格式（RCFILE升级版），压缩算法采用orc支持的ZLIB和SNAPPY。
在ODS数据源层，因为数据量较大，可以采用orcfile+ZLIB的方式，以节省磁盘空间；
而在计算的过程中（DWD、DWM、DWS、APP），为了不影响执行的速度，采用orcfile+SNAPPY的方式，提升hive和presto的执行速度。
存储空间足够的情况下，推荐采用SNAPPY压缩。
2, 数据同步方式
1, 全量覆盖
不需要分区，每次同步都是先删后写，直接覆盖。
适用于数据不会有任何新增和变化的情况。比如地区、时间、性别等维度数据，不会变更或很少会有变更，可以只保留最新值。
2, 仅新增同步
每天新增一个日期分区，同步并存储当天的新增数据。比如登录记录表、访问日志表、交易记录表、商品评价表等。
3,新增及更新同步
每天新增一个日期分区，同步并存储当天的新增和更新数据。
适用于既有新增又有更新的数据，比如用户表、订单表、商品表等。
4,全量同步
每天新增一个日期分区，同步所有数据，历史数据定期删除。
适用于数据会有新增和更新，但是数据量较少，且历史快照不用保存很久的情况。
DWD层搭建
DWD明细层，数据粒度和ODS层一致，主要对数据进行清洗转换等操作。
1,维度建模流程
掌握了数仓的相关概念和分层后，便可着手开始实际建设数仓。由于ODS层的数据是保持原貌从业务数据库中直接拉取，因此重点考虑DW层和APP层的事实表建设。
Kimball对于维度模型设计提出了四个步骤：选择业务过程、声明粒度、确定维度和确定事实，但是由于目前业务和技术的发展，不可避免地需要把一些维度冗余进事实表中，因此在建设事实表的过程中还需要考虑把哪些通用的维度冗余进去。
1、选择业务过程
与其说选择业务过程，不如说理解清楚需求(事实表)。当从零开始构建数仓时，需要在熟悉业务流程的基础上选择最重要、易实现、对下游数据影响大的业务过程。而当数仓的具备一些最基础的中间表后，无论是业务方从业务需要的角度，还是数仓同学基于整体规划的角度，或者是在建表的过程中发现了某些坑需要去填，其本质都是一个个对数仓的需求(事实表)，需要在理清需要的事实表后不断完善和丰富数仓的内容。
2、声明粒度
即每行是什么含义。在DWD层，其粒度往往是最小粒度，如表中每一行是不可再细分的订单维度、用户的每次操作记录等。而在DWS层，由于会进行一定程度的聚合，因此其粒度要较DWD层大，如每个品类、每个店铺、每一天的相关聚合信息。
3、确定维度
即表中所需要包括的环境信息，如类型、地区、日期、时间等维度。
4、确定事实
表中需要度量的属性(字段)，如订单事实表中的金额、数量等，事实与维度共同构成了表中的所有列。一些不可加事实，如比率，记得要拆成可加事实，方便下游了解计算过程以及进行二次加工。
5、冗余维度
完全把事实表和维度表拆开，这是不现实也不符合效率的，因此建设过程中需要把一些通用高频的维度冗余进事实表中，以空间换时间的方法提升效率。
拉链表的应用
一，,应用场景
当数据存在有变更的情况时，可以采用渐变维（SCD）模型来解决。这里推荐使用SCD2拉链表。拉链表既可以反应数据的历史状态，又能在最大程度上节省存储。
拉链表的实现需要在原始字段基础上增加两个新字段：
start_date(表示该条记录的生命周期开始时间——周期快照时的状态)
end_date(该条记录的生命周期结束时间)
