关于作者：大圣归来，一个有数据信仰的sql工程师，积极进取、喜欢思考，期待与大家一起交流学习~
数据仓库中很多理论都源于生活，深入研究你会发现不光是数据仓库，包括Kafka数据写入流程、数据结构、MySQL事务一致性等一些技术的核心部分都可以在实际生活中找到他们的影子。今天，我们就从餐厅就餐的场景切入，来探讨数据仓库工作流。
首先，让我们来看下面这幅图，图中的快递小哥一大早就送菜到餐厅，很早就要送去，1是为了保证菜新鲜，2是餐厅要早早的准备一系列的前奏工作，包括清洗、分类、加工等操作，请看下图：
这就好比数仓中的数据接入层，通常离线场景中会借助Sqoop、DataX、Kettle等工具以JDBC的方式把数据原生不动的从关系型数据库比如MySQL中的数据抽取到数据接入层，数仓中这一层通常称为ODS层，在这一层尽可能的保留数据原貌，不对其进行加工（除非你一眼发现小哥送过来的菜中有坏掉的），以便出现问题时可以溯源。
对上一层有了实际的理解之后，我们开始进入下一环节：洗菜，请看下图：
在餐厅的后厨中通常有专门负责洗菜的伙计或阿姨，他们负责对菜品进行清洗工作，然后放置在指定区域，这一区域在数仓中叫数据明细层，通常称作DWD层，这一层尽量保证跟ODS层一致的粒度，不对其做多维的聚合操作，也不做过多的过滤工作，只是简单地清洗，为了给后续操作保证数据的质量。
完成了以上这两层的工作后，开始进入切菜配菜环节，请看下图：
切菜配菜工作由非常熟悉菜品，或者至少熟悉饭店中一个系列的菜品的伙计完成，不然厨师会不满导致返工。数仓中这一层叫数据集市层，一般称作DWS层，完成这一层的开发一样要交由熟悉业务的同学开发，一道菜需要由一份主食材配合些许作料和配菜完成，这个过程其实就是星型建模的过程。
上一步骤完成后，紧接着需要把搭配好的菜品分门别类的放置在对应的地方：
想要摆放的合理也是一门手艺活，冷热菜分离，调味料单独处理摆放在特殊区域。数仓中就需要对不同应用场景的数据放置于不同存储系统中，有离线有实时，有历史趋势分析，有近三个月的流量转化，不同的需求可能会把数据放入到Redis、HBase、HDFS、MySQL等关系或非关系数据库中。
接下来到了关键的一个步骤：下厨，见图：
这个步骤的产出，直接关系到客户的满意度，但也是基于面前所有步骤的高质量完成，才能最终交付一道好菜。数仓中这一层就叫应用层，通常称为APP层，直接决定了报表数据的精准，再配合一份漂亮的菜单，nice！
让我们再从上至下的串一遍，见下图：
我们来构造一个场景：中午客户三五成群走进饭店，首先客户会根据菜单中琳琅满目的菜品选择中意的菜下单，这时饭店服务员把消息传递到后厨，这时对于后厨来说，大部分菜品可以直接下锅甚至直接呈上，因为一早就已经准备好了常规菜，即便有些特殊的需求，通过其他层也能快速获取到。这里还有很多环节部分没有细化，大家先对维度建模的模型分层有个大概的认识。
