数仓思想==预制菜

在目前的数据开发工作核心中是分为两种的

        第一种为数仓开发部分，第二部分为数据分析部分，而两者的区别在个人愚见以为是数仓的结果更细，更精准，数分是一种可能，两者的关系更像是导航导弹中导航和炸弹的关系，数仓的作用更像是导航，需要精准查找目标所在位置，然后就由炸弹登场，无论这个人会不会躲避，炸弹，你在这一定位范围内，炸弹总能达到杀伤效果

        在目前的工作中，数仓开发中对数仓的作用-----记录和治理，总结和管理。而数仓的核心思想就是空间换时间，第二核心思想应该就是数据管理和数据治理，现实中我认为最能反映数仓思想的就是我们目前所唾弃的-----预制菜。

            数据开发就很想饭店里厨房的厨师，之前饭店的规模比较小，厨师兼顾管理食材和饭怎么做，客人没这么多，食材也不用准备这么多，无论怎么放，一眼就能找到，厨师做饭就很方遍，。但是当饭店做大做强后，客人很多的时候，老板说我们仍然要想以前一样能够高效率做饭,而且把饭做成米其林标准，客户想要什么口味，就上什么口味，为每位客户单独定制，那么我们就要对饭菜进行预制化-----我们就提前把饭做成半成品，等客人需要上菜的时候我们直接热一下就可以就可以达到很快出餐了，

这时候我们要做的就是数仓第一步--------业务调研，为了提前做好菜品半成本，我们需要先和厨师调研这种菜品的做饭流程，比如我做糖醋里脊的时候，需要那些食材。

下一步就是确认粒度------就是菜品的咸淡或者口味，那些菜品是特别咸的，菜是微咸，那些是甜的，包括于菜品的下锅时间，要煮多久，和那里的菜。这个要根据客人口味进行变化和食谱变化

第三步就是确认维度-----根据我们前面的整理，开始确认我们做菜的调味品，这些是我们整体做饭的灵魂，咸和淡，烂和硬（时间），所谓维度就是我么做菜的环境，菜是咸淡甜，口味，时间，可以把这里放的是我们食谱上会影响菜口味的环境（在数据里是可以确认精准度的环境）

第四步确认事实---就是确认我们所需要的食材（这里再数据里是度量，一般都是可以计算的部分例如：数量金额）

这里举例说明：什么是数据域和业务域这部分怎么理解

数据域呢就是大家可以就比做是我们做菜所需要的，比如可以分为蔬菜，水果，肉类，酱料

业务域可以分为八大菜系，比如浙菜，鲁菜。。。

两者之前区别是什么：数据域是方便数据人员的处理的，业务域是为了方便业务人员

数据域是自下而上，以业务数据视角来划分数据，一般进行完业务系统数据调研之后就可以进行数据域的划分。

主题域则自上而下，以业务分析视角来划分数据，一般进行完业务需求调研之后才可以进行主题域的划分。

既然我们不对数据分数据域的话们就好像买菜不对菜进行分类，这样当我们的需要的时候我们需要花费大量时间寻找，同时在后续发展中也不方便我们维护存储。业务域的划分就像是我们根据不同的节日、顾客群体和市场趋势来设计促销活动。例如，针对浙江地区的顾客，我们可能会推出清淡口味的菜品促销，以符合当地人的饮食习惯。通过这种方式，我们能够更有针对性地满足市场需求，提高营销效率和顾客满意度。

而分域的好处有哪些呢

1. 数据隔离：不同的业务领域可能存在不同的数据权限和安全性需求。通过将数据仓库进行分域处理，可以根据不同的角色或用户对数据进行隔离，确保敏感数据只能被授权的人员访问。

2. 管理和维护：数据仓库中的数据通常来自于多个源系统，并经过清洗、转换等处理。如果将所有数据放在一个域中，会增加数据管理和维护的难度。通过分域处理，可以按照业务领域对数据进行分类和组织，简化数据的管理和维护工作。

3. 查询性能优化：数据仓库通常被用于复杂的分析查询和报表生成。如果数据仓库中包含大量的数据和多个业务领域的数据，查询性能可能会受到影响。通过将数据进行分域处理，可以针对不同的业务领域进行优化，提高查询性能。

假如我们要做糖醋里脊预制菜

第一步我们首先先调研：一家大师傅的糖醋里脊特别好吃，达到完美级别，然后我们就从他这里得到菜谱

他是这么写的

1.首先将买来的里脊肉长条，切好后，将里脊条放入大碗处理，分别加入料酒、味精、盐，进行腌制。腌制一段时间。
2.将番茄酱倒入另一碗中，加些水、糖、醋、淀粉进行搅拌均匀
3.把淀粉撒在盘子上铺满。点火，锅中倒入油，要多一点，要开始炸了。待油热的时候，就可以炸了，将里脊条裹满干淀粉，然后下锅即可。待里脊条炸至浮起，即可捞出待用
4.将锅内油倒出，留少许油。将番茄汁倒入锅内翻炒，待番茄汁变的粘稠时，将炸好的里脊条倒入锅内一起翻炒出锅即可。

业务部分就结束，

下一步就开始确认粒度

我们就要想厨师确认：

1.长条要切成多宽，多长大小

2.腌制一段时间是多久（一天？，如果是一天是24小时还是12小时，是24小时附近，还是要精确到分钟，还是要秒）（比如一天肯定就是24小时，精确到分可能就是11小时55分，到秒就是11小时55分55秒

3.加些水、糖、醋、淀粉是多少，油是什么油，那里的水最好，哪里的油最好

。。。。。（事于具细）相信到这里大家对粒度已经有点模糊的印象了，这里还有一点细节关于构建总线矩阵，总线矩阵讲的是业务过程和公共维度的关系。在工作时后我们就是比如做糖醋里脊，就要判断需不需要蔬菜，肉，料酒。

可以影响到我们食品口味的任何环境都是粒度，比如长条大小，腌制时间，如果厨师确认说比如长条大约切成手指大小，那粒度就是手指大小，假如厨师说0.5—1厘米宽，5cm高，那粒度就是0.5—1厘米宽，5cm，事务的描述最好以最细为主，因为粒度越细，描述的就越准确，影响口味的可能就越小，粒度是0.5—1厘米宽，5cm高时候，每一个糖醋里脊都是一样，口味越容易达到最完美。不会因为长条的大小而影响到口味。而我们就做到就是确认我们做的菜要像厨师一样做的一样完美。假如厨师说大小不会影响到口味，无论怎么切都无所谓，那这里长度在这里就不算粒度。

在数据里，我们可以把影响到我们查找数据的精准度的作为判断为粒度的依据，正如前文所说，我们数仓的核心保证数据的准确性，比较经典的就是年月日时分秒，地理位置国省市县，比如我们想查找一个名字叫张三的中国人，那这里的粒度中国，这些都是粒度，因为这些都是可能影响我们查找精确度的，因为这个粒度可以更细，比如中国浙江省杭州市余杭区。。。多少号的张三，这样就可以精确定位住，而我们在这一层做的就是确保我们要做业务的最细粒度，但是最细粒度所带来的影响会更麻烦，会影响我们厨师做饭的速度（粒度越细，数据就越复杂，处理就越缓慢，粒度可以到最细，但是我们只达到业务的最细，就是做菜的时候比如糖醋里脊中，某个省的里脊比较著名，某个省的某个市比较著名，对吧，然后我们做菜的时候大师傅就说这个市的所有里脊味道都差不多，不会影响口味，按照常理来说最细粒度是到县，镇，个人，但是这里的最细粒度就是市。

（粒度通常指的是数据被划分的程度，而维度则是描述数据的特征属性。这两者是不同的概念，粒度涉及到数据的详细程度，而维度则涉及到数据的分类和描述，这里是方便大家理解）

第三----确认维度，我相信大家经常会听说粒度是维度的灵魂，为什么是呢，因为维度中包含的是所有的粒度（就是在这一层，我们要保证所有影响我们环境的因素全部都被我们控制，在上一层中我们确认的是粒度最细的情况，那这一层我们要做的就是归类和总结所有的粒度）就拿上文来说某个省的里脊不错，市也可以，我们就要把市，省，国，，把最细粒度向上推到最大粒度，因为假如市粒度找不到，我可以用省粒度，省粒度不行再往上调，反过来同样，这一过程就称为下钻和上卷。找出我们前面业务调研的所有粒度，然后统计下来，比如国，省，市 调料维度-糖盐醋 ，酒类维度-香槟，啤酒（更细点可以专门建一张表记录酒和盐，糖。。。的种类，维度的维度还是维度）。。。。。。。。。。。。。三个注意点：第一尽可能生成丰富的维度属性（原因保证所有影响我们环境的因素全部都被我们控制）。。    第二尽量不使用编码（这个解释更明白（就是菜谱假如有个人上面写材料100000，假如一个人不懂邮政编码是不是会懵，所以为保证我们菜谱所有人都能明白 尽量把维度上面的的描述给描述明白 ，所以要尽量使用明确的文字说明 第三--尽量沉淀出通用的属性 （这个就很简单比如一个油，我们菜谱上我们需要的是它出场都是和醋一起使用的那这里我们完全就不用单独写油和醋的存在，直接就是油醋（个人杜撰），反之同理，且维度要唯一

第四-----确认事实  到这里我们的就是把我们做饭的主菜确认下来，比如糖醋里脊的里脊，那糖醋和中间的处理手段就是环境，对吧（对比取2018年用户花呗每月欠债金额，金额就是事实，而2018年，花呗，用户，欠债，每月就是环境，我们要做的就是拆解业务，然后把全部的都统计下来），之前统计的都是环境，现在就是核心部分就是我们想要的部分，当然事实也可以是我们食材的再处理，比如已经做好的糖醋里脊，客户想要更甜，我们可以直接在处理好的糖醋里脊上再加糖，假如说这种用户多了，不是一个两个用户，那么就可以把更甜的糖醋里脊作为作为一种单独处理的预制菜。在数仓中同样如此例如2018年的用户欠债金额，假如我们的需求者后期大量有这种需求，那么这个就可以作为一个单独的维度去处理，所以这一部分是很灵活的，这里也涉及到数仓分层的问题。谨记数仓核心而数仓的核心思想就是空间换时间，第二核心思想应该就是数据管理和数据治理，当然这里看我们的需求者的需求来变化----------业务驱动建设。