刘逸云的论坛回复_云社区-华为云

华为云账号：h76b2f02525941892279微信账号：TigerDAY03学习笔记-DAY03Kimball维度建模技术概述（2）1.主要内容:缓慢变化维、高级事实表技术、高级维度表技术1.1. 如图： 1.2. 如图：2.缓慢变化维2.1. 如图： 2.2.缓慢变化维捕捉：2.2.1.例如：通过历史报表，统计出销售人员在历史上某个早期的时候，在某个特定的区域的销售业务量。所以，需要把销售人员的历史变化记录通过某种方式保存下来。2.2.2.历史信息要采取合理的手段进行保存。否则，这种对历史数据的某个时间点产生的报表统计分析就是不准确的。或者是无法做出统计分析的。2.2.3.举例：如外币兑换的汇率，不同币种的汇率基本上每天都在变化。要看前天的100元人民币在当前能兑换多少美元？就要找到前天的人民币兑换美元的汇率来进行计算。这种情况往往在信用卡账单计算的时候就会碰到。【还款金额】需要根据入账日的那天汇率来计算刷卡金额，而不能够根据账单日的汇率来进行兑换的结算。这种要记录维度属性值、发送变化的历史情况，就叫做缓慢变化维捕捉。它的处理方法有很多种类型。从简单到复杂逐一介绍。2.3.Type0、保留原值2.3.1.实际上是属性它不会发生变化，一致保持静止不变。直白的讲它不应该算缓慢变化维，因为它静止不动了。根本就不会发生变化。不过老外就是喜欢把各种情况就纳入到一个整体里面（老师又吐槽了，嘿嘿……）然后说某些情况是这种一般情况的特例！所以针对这种不会发生属性值变化的情况，2.3.2.反应到现实里面就是维度表它不会变化，从它创建之初起就是这样。总结：这种维度只要一开始建立固定的维度表就好不会有变化，最常见的例子是：在数据里的很多地方都会内置一个万年历。它就是一个静止不动的Type0的维度表。2.4.Type1、覆盖2.4.1.如图 2.4.2.直接用新值覆盖了原有额旧值，所以Type1维度表的熟悉永远是当前最新的取值状态。这种情况本质上也没有能保持历史，历史数据被新值给破坏了；这种方式简单但是破坏力比较大。对于需要做历史数据分析的BI应用来说，其实也是一种灾难性的。因为它没有办法恢复历史场景。2.4.3.例如：商品销售领域用来区分单品的自然主键、商品发布的例子。Sku库存保有单位用于区分单品的自然主键。Sku取决于对应的商品有多少种参数。我们假设某手机品牌TT的手机的颜色包括：白色、黑色和金色；存储容量有64GB、128GB还有256GB。那么对应的商品的SKU会有9种组合，哪种商品库存缺货了？直接对应的SKU就可以查询的到。2.4.4.关于覆盖的例子：产品的负责部门从教育部转变为了战略部。那么使用Type1方式的部门信息就被覆盖了。对于SQL语句来说就是非常简单的一个update的语句。但是在update之后，所有的数据分析的部门指向就都到了战略部门。那么引发的问题就是：教育部门在历史上的数据都丢失了，无法再统计到了。因为再事实表里面只会存储这个产品的主键信息。2.5.Type2、增加新行2.5.1. 如图：2.5.2.我们建设DWBI系统的出发点，是能够正确的反应历史、能够统计历史、分析历史的变化趋势。在这种情况下，Type1肯定是没有办法实现的。这就需要采用Type2的技术：增加新行。它是缓慢变化维，最实际最实用的主要的处理方法。Type2的方法是在维度表中增加新行来记录修改后的属性值。但是，这种方式会导致原有的自然键或者持久键出现重复。为了避免这种重复情况的出现，也就是保持维度表中这种情况不会发生一般会采用两种方法：一种是分配新的代理主键，就是前面的产品编号，必须把它产生一个新的产品编号、或者新的代理键来区分变化前和变化后的产品描述。然后在事实表中把代理键作为事实表的外键存放。直到下次会产生新的维度键更新这个代理键。另外一种方式：是在原有的主键基础上，增加产生变化的日期；那么就是原有的自然键+变化日期，通过这种复合主键的方式来避免主键重复性问题；那么不管是哪种方式，都需要在维度行里面增加两到三个额外连。第一个，行记录有效的开始日期的时间戳。第二列，行记录的有效的截止日期和时间戳。第三个，当前行的有效标志、状态标志。2.5.3.图中1行是产品的初始信息。2、从第二行是如果发生变化的时候，当部门有变化的时候，使用Type2的方法，增加一条记录。新生成的记录主键它会新生成一个产品编号（新生成的代理主键）。3、从第三行我们可以观察到三个字段：生效日期、截止日期和当前状态字段的变化。我们可以看到，当属性变化的时候，它都会自动增加一行。增加完一行以后，把原来上一条历史记录的截止日期，把它设定为失效的当天。截止日期跟新为下一条新纪录生效日期的上一天。这种方式的好处是：使得每条记录的截止日期和生效日期，在记录的前一条记录和后一条记录环环相扣起来了。对于同一个数据的历史对象的时间轴上，它就仿佛构成了一条完整的链条。所以我们在实际项目中，通常把物理上的这种类型的，Type2的类型的表，我们通俗的把它称为历史拉链表。那么实现Type2的算法就叫拉链表算法。在实际项目中，要考虑大表的结构，以及在实际项目中高效SQL以及物理结构。比如对于容量很大的维度历史表，需要进一步的考虑增加分区、索引等技术。而拉链表算法也要考虑检查拉链的效果；避免出现交叉链、断链的情况发生。甚至有时候因为原业务系统的数据有一些不可避免的数据质量，或者是错误需要重新处理数据的时候，要能够实现拉链回退的算法。在拉链表中我怎么能够获取任意点和任意时间点，当时有效的维度属性呢？我们要做的方法就是在SQL的Where语句条件里面。在Where语句里面制定查询条件：取当前最新快照的方法，如图：凡是数据状态等于“Current”的记录都可以查询出来。另外一种方式是我们取截止日期是“MAX_DATE”的记录。我们可以看出当前状态和截止日期是有很强的相关性的。凡是等于“MAX_DATE ”的都是当前有效的数据。我们称之为“开链数据”我们通过截止日期增加分区，这样可以更好的让我们提升查询效率。另外是根据当前状况的查询条件，这里当前字段增加索引的查询效果不明显。往往在一些项目里就把这个字段给去掉了。上图，是错误拉链表使用的情况，因为查询语句有断链的情况。数据最大的相差日期是1天。那么相差数据大于1天就等于数据断开了。交叉链：是指后面数据的生效日期，小于上一条数据的而截至日期；两个区间发生了重叠。有交叉所以起名为交叉链。最后的例子是重复链：它既可以是生效日期的重复，也可以截止日期的重复。断链、交叉链、重复链都是非正常情况，应该是人为操作后，拉链数据失误后所引起的。对于重要的维度数据历史表来说，我们要建立定期检查机制保证数据的准确性。2.6.Type3、增加新列（属性）2.6.1.如图：2.6.2.类型3是在原来的表上加上新的属性列字段。在某些场合下，用户想看到直观的比对。支持我们一些常见的分析手段，上期比、环比等这一类的分析。图中增加一列：变更前部门名称。每次变更部门记录的时候就把，前一次变更的内容保持到变成部门名称中。当前最新的值放在部门名称中。2.6.3.Type3带来作用：进一步扩展的方法是，我们可以增加多个列；记录多个历史记录。因为这种方法可以把更新之前和更新之后的数据都保留到同一行，这样对于BI工具在使用分析的时候就能够快速的查询展现。性能是有保证的。但是另外一方面，如果要保留更多的历史资源、增加更多的列。2.6.4.如果记录列变化比较多的时候，每个表都要增加多列记录；这样就会导致数据表变的很宽，而且很稀疏。所以，这种方式一般对于特定的表有这种对比分析需求的时候。而且对于性能要求很高的时候才用。一般场合下增加一个列就够了，增加多个列的应用场景不多见。2.7.Type4、增加mini维2.7.1.如图：2.7.2.大型维度表会面对性能的调战。微型维度或者mini维是解决这种变化维度高的场景的技术。它的出发点就是采用不同的维度。消除频繁分析或者频繁变化的属性。进行降频，把高变化率的数据改变为低频数据。从而减少数据变化量。这种低频的维度我们称为mini维，或者叫微型维度。2.7.3.我们来看个例子：一般在客户维度中，生日、姓名的维度发生的变化。地址、通信这些变化维度变化非常低，而年龄，购买习惯、收入水平相对于其他维度属性来说，变化的就比较频繁。可能按照月的维度它就会发生变化。那么我们把这种变化维度较多的人口统计特征拿出来构建新的mini维，原来的维度表中保留哪些更稳定的属性。这就是增加mini维的处理手段。2.7.4.mini维也需要维护自己的主键。这就是图中人口统计mini维中，就要使用自己的Demographics Key(PK)。这样在mini维的行记录中明显就减少了。另外，在构建mini维的时候。不断变化的属性可以转化为值，这样就能极大减少nimi维中值的数量。2.7.5.不过这种区域划分的情况，也有一种潜在的问题。如果未来我们想变更区域范围，如表里面的收入我们把它变成小于三万。从三万到四万之间这种区域，如我们想以后给它划分的更明显的话。那么这种变更就会出现一定的困难。所以，如果可以在预先设定的区间范围内，我们相对设的比较细一些。如果确实记录动态变化的情况，本书在第十章有讨论：动态可变带宽，也就是区间划分的这种事实表。2.8.Type5、增加mini维和Type1支架2.8.1.如图：2.8.2.多种Type的混合体。支架表每次取当前更新的。mini表是动态记录的一张表，我们通过Type1支架表内容覆盖的方式，进行数据的更新。把人口统计维度的主键放入到客户维度表里面作为一个外键存在。2.8.3.这种方法对于BI工具不想访问事实表的情况下，把主维度表进行数据上卷或进行数据汇总操作。在这之前，如果我们只采用Type4的技术手段的话。这种mini维和主维度不会发生关联。需要通过事实表将mini表和主维度表进行关联；而Type5通过支架的这种方式，我们就直接把当前状态下的维度进行上卷的时候，就减少了这种主维度通过事实表维度去关联mini维的这种操作。直接就通过主维度和mini维发生了一个主外键的关联关系。所以它减少了通过事实表关联的操作，从而大幅的可以提高BI的查询性能。2.9.Type6、增加Type1属性和Type2维度2.9.1.如图：2.9.2.类型6是建立在类型2的基础上，类型2是通过拉链表来进行维度记录的。这里我们增加三类数据：生效日期、截止日期还有当前状态字段。然后通过历史部门名称来记录部门变化的情况和信息。那么每次部门发送变化，就会增加一行记录。然后闭链、开链。2.9.3.我们在类型6中还要增加一列，就是当前部门名称；来记录当前最新的部门名称。这种增加列的方法是之前介绍的Type3;注意对于这个新增列来说，每次发生变化的时候都会把历史所有的相关记录都更新到当前的部门名称。所以这个当前部门名称这个字段，它是采用type1的覆盖方式来进行更新的。2.9.4.所以我们总结一下，Type6就是Type1+Type2+Type3的综合体。也可以说是Type1*Type2*Type3的综合体。再总结一下：历史部门字段+部门拉链就是Type2，新增当前部门的名称就是Type3，覆盖新增字段的方式就是Type1。最终所得的结果就是Type6。2.10.Type7、双Type1和Type2维度2.10.1.如图： 2.10.2.当获取信息超过100个表的时候，性能维度就会受到挑战。这就是Type7所处理的场景。2.10.3.在类型2的维度表中使用代理键来跟踪变化，维度自然键为当做事实表的外键。如果自然键使用不便，或者会有重分配的情况。那么应该使用不同的持续性超自然键来替代。在记录发生的事实表中，类型2维度的外键、可以用来过滤和分组历史的属性变化。而持久键可以和当前维度表进行关联。这样就加速不同场景下的BI工具的访问。2.10.4.Type7实际上是Type6的加速变形。把历史和当前拆分后，来应对大量属性的维度变化的3.缓慢变化维总结3.1.如图：3.2.高级事实表的技术3.2.1.如图：3.3.事实表的代理键：代理键常用作维度表的主键。但在事实表里面有时也可以生成代理键。主要是考虑其唯一性。另外，在一条过程中可以不用查询多个维度。3.4.蜈蚣事实表：这种情况应该尽量避免出现，蜈蚣事实表是把多怼一层次的维度进行规范化，并把规范化多层次表的主外键都包含在了事实表中。结果就形成了多脚蜈蚣的样子。3.4.1.如日期维度：有人会在正则表达式后生成日维度、月维度和年维度；并且将这些时间维度都会放在事实表中。这种方法是不可取的。正确的方法是应该采用最低粒度维度，例如日期。3.5.多货币场景和多种度量单位场景，出现在企业有跨国业务的时候。或者特定行业里面特定度量的场景。对于货币来说，事实表应该建两个列。一个记录本币，一个记录外币。两者之间用当时的汇率进行折算。而对于多种度量标准的事实表：同样应该一个列记录标准单位，另外一列记录特殊度量记录的值。3.6.事实表时间跟踪：针对事实表时间跟踪的情况，对于事实表来说如果有需要跟踪时间变化等情况。那么可以增加Type2的拉链表技术；对缓慢变化平衡库存场景具有可能使用到这种拉链表技术。3.7.如图： 3.8.多指维度与桥接表：这种技术指的是两个表多对多关系，通常会使用桥接表来解除这种直接的多对多关系。把多对多关系转换成两个维度表，分别对桥接表的一对多关系；这样可以使用SQL方便进行查询操作。例如：在金融领域里面分析家庭客户的时候，可能多个家庭会拥有多个独立不同的银行账户。而这些家庭账户是这些多个家庭所共同持有的，所以就把它通过桥接表的方式把多对多关系，拆分成两个多对一的关系。3.9.随时间变化的多值桥接表：在上面表的基础上，增加了Type2的历史信息捕捉，形成了桥接表的历史拉链表。3.10.对于聚集事实作为维度属性：是用户通常对于客户分组的行为标志敢兴趣。可以把度量聚集成带状范围。比如通过交易的资产额度，来划分不同的客户分组。3.11.多时区维度：类似前面提过的多币种维度一样。应当在受到多时区影响的事实表中增加双外键；链接两种或者多个时区的场景下的日期。4.本节回顾4.1.如图4.2.课后作业，如图： PS：附件是我整理的DAY03的学习思维导图，请大家点赞下载，谢谢。

华为云账号：h76b2f02525941892279微信昵称：Tiger 华为社区昵称：刘逸云DAY05 《大咖有话说：DevOps论道》四位讲师直播答疑，学习笔记。一、今天四位大佬：王立杰老师华为云MVP、资深敏捷创新专家、小米敏捷转型战略教练；许舟平华为云MVP、微服务与云计算技术专家、IBM敏捷专家；徐磊华为云MVP、英捷创软创世人兼首席架构师。汪珺（神秘大咖）华为云MVP、前惠普北美高级项目经理、EXIN DevOps Master全球导师认证、国内首批DevOps《凤凰项目》沙盘讲师。二、关于DevOps论道的问题及解答回顾：2.1、王立杰老师：看板流派。每个方法都是由人提出的，由人提出方法论。这个过程不是一朝一夕就可以完成的。任何方法论都是它具体的应用场景的。就像我们讲的看板方法论。它是基于客户现有的流程进行改进；对于团队来讲也不做特定的限制。在Scrum中，我们常讲7+-2小团队。在看板里面，我们5人、10人、30人都可以做看板。这里是一个复合型的，更简便的一个打法。它较于其他方法上手更容易。但是它背后的肌理和使用还是非常有难度的。目前国内的情况，真正可以把看板方法落到实处的团队，真的是少之又少。它是行进式的、渐进式的建设。注意：看板和回顾要有反馈环，这很关键。这样才可以实现持续的改进。王立杰老师总结：所有的方法后面都有一个PDCA环。2.2、姚冬老师：代徐磊老师（XP极限编程流派）。首先四个流派其实是可以相互融合，他们只是代表老师的特征，但并不是相互对立的；极限编程（Extreme Programming,简称XP）的来源是：2000年美国软件工程专家Kent Beck提出的敏捷软件开发方法的代表。XP是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方法。Kent Beck建议XP应用于规模小、进度紧、需求变化大、质量要去严格的项目。极限编程是价值而非实践驱动的高度迭代的开发过程，其价值体现在以下几个方面：第一，沟通（Communication）：即追求有效的沟通。XP强调项目开发人员、设计人员、客户之间等有效地、及时地沟通，确保各种信息的畅通。第二，简单（Simplicity）：即实现最简单的可行方案。XP认为应该尽量保持代码的简单，只要能够满足工作需要就行，这样有利于代码的重构和优化。第三，反馈（Feedback）：即快速有效的反馈。要求不断对当前系统状态进行反馈，通过反馈，达到迅速沟通、编码、测试、发布的目的。第四，用气（Courage）：即勇于放弃和重构。对于用户的反馈，XP程序员要勇于对自己的代码进行修改，即使有些修改可能会使得原来已经通过的测试又出现错误，但是经过团队的共同攻关，最终必然会取得满意的效果。第五、尊重（Respect）：让每个成员在团队中获得应有的尊重。姚老师总结：如果测试是好的，那么所有人都应该始终坚持测试。因为测试栈是需要左移的，如果集成测试很重要，那我们就应该更多的进行集成测试；如果迭代短些好，那我们就应该把迭代的时间变的非常的短。真的做到分钟级或者消失级的迭代。如果迭代版本做的好，持续提交的版本甚至可以用于线上发布；又例如代码评审是好的，我们就要始终坚持代码评审。关于XP里的结对编程：其实就是一个人在写，另外一个人在看。这也就是我们今天讲的四眼原则。就是四双眼睛一起去看。如果设计是好的，那我们应该把它当做一种必须的部分。设计肯定是要做不断的修正的，所以这里就引出的重构的概念。如果架构是好的，那么我们所有人都应该去一起去管理和完成架构。注意：架构不可以过度的设计，架构应该是根据技术的演进，以及团队的进步，根据细节的提炼逐渐的长出来的架构。它背后是有XP的概念的。2.3、姚冬老师：Scrum和技术工程维度，就会涉及到持续集成的问题。CI/CD,包括相关的测试管理。从开发环境、到测试环境、到类生产环境到生产环境。这里就会涉及持续的集成、持续的测试、持续的部署和持续的发布。这是一套完整的方法，底层会有DevOps Cloud相关的流水线的构建类、测试类的工具来进行一个整体的支撑。2.4、汪珺老师：DevOps的价值，这里介绍个行之有效（WAI MEN XI DAO）的办法，甲方提了问题，乙方的同事就不敢还嘴和顶嘴。然后我们就使用了大看板（冰山模型），对于传统企业来时候，它又监管、质量、全链路、技术的需求；我们具体例子：滴滴打车再早期的时候，它是业务需求；到了后面它有了监管需求。必须重视质量的，还有系统的耦合度、还有技术需求，那么我们在拆分的时候，往往看得到上面，而看不到下面，这个模型就是所谓的冰山模型。对于冰山的一角，汪老师是这么干的。把一块大看板拖到厕所门口。这是为什么呢？因为有的仙女可以不吃饭，但是她不可以不上厕所。所以这块看板所有人都会看到，那么之后我们就让PO或者是业务人员，分析师。把业务的流程迭代Story，按照他的理解写在上面。这是大家都不想去估的时候，假设登录我们需要4个小时，然后声明这个是客户需求，小额账户业务规则、业务流和相对的价值流；然后PO写完之后，他就走掉；那么下面是业务分析师过来：年末18岁和老外我额外需要两点规则，我进了输入框大于5万的，做一个交易，我们大于1万美金的我们做个交易。这样一来就完了了一个监管需求；那么这个时候测试同学的肚子可能不太舒服，过来看到登录模块，我要做个登录异常和密码异常，然后金额输入框我要做数字的校验和异常处理；到了研发和运维过来就会说：我们看到登录系统与系统的其他模块有交互。登录的程序，我们要灾备、加密，还有其他的一些协同的问题。总计一下：那么这样一个来的四个好处是。1、PO想不到的，团队所有人帮他想；2、如果做的事团队没有想到，那么第一责任不是开发，而是我们没有提出需求的问题。3、各项目为自己争取到了开会的视角，多元化，争取到了时间。比如：我18岁的需求需要2个小时额外去开发。但是看到整体迭代只有4个小时，那么肯定是不行了。4、每个点的需求，都是测试的一个检验点。我们输入的时候，就在客户上厕所过来过往的时候，而输出的时候，明确需求之后再跑。等到开会需要迭代沟通的时候，我们就来评估这个点有没有重复的、有没有浪费的、需不需要做？如果我们要在这里做，我们就要锁定这个需求，这样就等于是得到了一整块需求模板，这个是一个很好的方法。这是汪珺老师对于看板的灵活运作，我觉得非常受用。2.5、许舟平老师：故事点的评估。首先我们对于需求的优先级还有相应的需求理解是非常关键的。所以：过度的故事点的评估其实真的是一种浪费、同时也没有必要。用户故事地图和用户影响地图：首先，我们要知道我们为什么要这样去做？这里，从排优先级的角度来说，评估后的用户故事，我们应该知道应该是要体现在我们的用户故事地图里面的。也要通过优先级在做相关的排序的。所以它并不是一个简单的review的工具。总结：做用户故事地图点影响的评估，这是要取决于我们迭代的目标和大家在故事点的评估上能够达成一致。姚冬老师补充：从工程的角度来看，从持续集成的角度来看。每天至少要往主干上去提交一次代码。如果说我们的程序员做不到每天提交一次的，真的做不到？那么理论是实际上是一个倒逼。如果我么就是确定每天向主干上去合并，那么我们一定要把我们的需求也好，任务也好要拆分到具体的事项，实际上这个事项是一个以终为始的事情。另外，从解耦的角度上来讲。在粒度的解耦层面上来说，它是和需求的颗粒度大小、模块的大小；在解耦时要从入口就开始考虑。如果说需求非常大，那么后面的功能做的再好也没有办法进行解耦；这里一方面是为了评估工作量，为了增加团队间的沟通；从另一个层面来说，是为了更好的去控制后面的程序设计和相关的逻辑。三、王立杰老师讲敢死队：加里森敢死队（二战搅乱德国后方的特殊的队伍），这队伍的成员，很多人都是在监狱中去选择的，想小偷、爆破专家、酒吧女郎、酗酒的拳击手、善于开车的机械师，成员是多种多样的，是一个真正的跨职能的特殊的小队。每个小队成员的能力都是一个T形或者是派形、F形的技能；所以特别适合对于我们敏捷团队进行比喻。他们是端到端的把事情做好。