全量、增量、流水、拉链、快照、代理键、缓慢变化维…
这是我的第68篇原创
今天是一篇很枯燥的数据仓库名词和使用场景的解释。适合对数仓感兴趣的同学食用。
数仓建设的时候，我们会有非常多的名词，很多数据分析师经常接触数仓，但又不太了解，往往会被数仓工程师的一堆名字给打晕了。别怕，有我在！
今天给你把这些名词都给解释清楚：全量表、增量表、流水表、拉链表、快照表、代理键、业务主键、自增主键、维度、缓慢变化维、分区、分桶、分表、分库、位图、颗粒度。
上面都是常用的一些名词，我们把他们分个类：
表的设计模式：分区、分桶、分表、分库。
我们知道一张表中的数据超过一定数量之后，查询的速度会变慢，MySQL大概是2000W左右。但是业务数据不断累积，超过这个限制怎么办？
在结构化数据库中，采用的方法就是表分区。将一个表按照某个规则（比如按年，或者hash散列等），将大量存储在不同的分区中，起到分而治之的效果。对A表进行分区，A表仍然是一张表，但是不同年份的数据会存在不同的物理文件中，查询时我们只需要查找对应的某个分区表即可，速度可以得到保障。但是分区表有一些弊端，比如只能横向分，对主键和索引有要求等。优点是仍然是一张表，对使用非常友好。
所以我们会有其他的方法，比如分表。分表有两种分法：1、把一张大表进行纵向切割，分成若干个小表，适合很多列的表；2、把一张大表进行横向切分，分成若干个小表，适合数据量特别巨大的表。在大型互联网公司，一般横向直接切成1024个小表。分表的扩展性非常好，隔离性也很好。但是一张表会分出N张表，对使用很不友好。
如果一个数据库中的数据表很多，每张表的数据也非常多，那咋弄？除了分表，那就是分库了。我们把关系相近的表归好类，形成若干个表的集合。每个关系比较紧密的表的集合放在一个数据库中，这样就形成了一个一个的子集表的数据库，这就是分库。
在大数据环境中，表的关联代价很大，效率比较低。研究过MapReduce、Spark原理的同学应该知道其原因，核心就是shuffle过程会导致数据的不均匀。这时候我们可以进行分桶操作，即把A、B关联用的ID进行分桶操作，之后关联的时候，MapReduce时，会把两个表相同id的数据分在一个桶中进行join，这样效率就非常高了。
表的更新模式：全量表、增量表、流水表、快照表、拉链表。
其实叫更新模式不完全对，姑且这么叫吧。我们知道数据仓库是面向历史的，里面的数据原则上是不允许变更的数据。但是业务数据是变化的啊，我们用不变的数据仓库数据反应业务的变化呢？
方法1：每天都把所有数据都复制一遍，放在数仓里，就像找个照片一样不就好了吗？对，这就是快照表。
方法2：我们把每条数据的每次变化都记录下来，形成数据变化流水账，放在数仓里，也可以对吗？对，这就是流水表。
方法3：我们不必把所有的变化都记录下来，只需要记录关键信息的变化就可以了，每条数据的关键信息变化了，就记录到数仓里，这就是拉链表。
如果一张表含有该业务从诞生开始到现在的所有数据，那这张表就叫全量表。全量更新也是这个意思，如果更新数据的时候，直接覆盖这张表里的所有数据，就叫全量更新。一般我们都直接truncate，然后insert。优点是出错少，好维护，缺点是数据处理量大。
如果一张表只含有某个更新周期内的数据，那就叫增量表。增量更新也是这个意思，从上次的更新截止点开始，抽取这次新增加的数据，放在目标表里，这就是增量更新。增量更新的时候我们需要注意增量字段，还得小心更新失败、漏更新等，需要进行数据更新的校核，比较费劲。优点是数据处理量小，速度快；缺点是事儿多。
快12点了，来不及写字段和概念了，明天继续哈~~~
配合以下资料享受更佳
资料包 | 数据仓库建设全套资料包
资料包 | 数据中台产品资料包
资料包 | 数据产品选型资料包
