Lambda 架构 Batch Layer & Serving Layer 详解

前文链接: https://blog.csdn.net/rav009/article/details/85690985

继续介绍 Lambda结构 一些理念:

fact-based model

在关系型数据库的时代，我们通过维度表和事实表来组成数据仓库。但是到了大数据时代，由于数据的容量不再受到限制，我们可以大胆的使用事实表来作为数据仓库的基础。这并不是说要取消维度表，而是说维度表用的少了，Normalization用的少了。

Normalizaion和维度表的作用是节省空间, 比如用户维度表里存放了用户的各种属性, 这些属性不必在事实表里重复存放. 节省了空间. 同时当用户的属性发生变化时, 只需要更新维度表, 所有与维度表 有关联关系 的事实表都能得到相应的更新. 这是Normalizaion的好处。

但是在大数据时代，Normalizaion和维度表的存在导致当我们需要用维度的属性来对数据进行统计时(group by), 事实表和维度表的Join不可避免。一旦Join发生, 大数据的Join导致性能低下就不可避免. 

所以Lambda框架建议在Batch Layer的维度数据是Normalized, 而在Serving Layer的Batch View是denormalized。

fact-based model 除了上述的 大胆使用denormalized 外，另一个体现叫"immutable data"（不变数据，不update数据）。比如用户的职业或住址发生了变化, 我们不是过update记录这样的变化, 而是通过事实表的方式, 记录用户的变化, 比如在什么时间, 用户的某个属性变成了一个 new value。这样对于人为误操作也有很好的保护作用，我们不会轻易去update以前的数据，而是通过insert 新数据来取代以前的值。当我们发现insert的新数据有误时，可以把错误的值删除，就能退回原来的值。试想如果我们做了update操作, 就无法回退原来的old value. 像Hive这样的大数据数据库在默认的配置下, 本身就是不支持 update 和 delete 操作的。

 

除了fact-based model外, 其他的一些概念比如预计算, 分布式存储都是老生常谈不再赘述.