学习还是得系统_2

读《数据仓库工具箱》，笔记：
1、半可加事实：对某些维度来说是可加的，但不是所有维度。如 库存水平对产品或商店来说是可加的，对日期来说是非可加的。

2、
inventory dollar value at cost 按成本计价的存货美元价值
inventory dollar value at latest selling price 按最新售价计算的存货美元价值

3、周期快照是最常见的库存模式。建模库存业务过程的第二种方式是记录影响库存的每个事务，即事务事实表。
尽管事务事实表比较简单，但它包含了反应每个库存操作的详细信息。事务事实表可方便地度量频繁发生的特定时间事务类型，用于回答那些周期快照由于粒度问题不能回答的问题。即使如此，将事务事实表作为分析库存性能的唯一依据是不切实际的。尽管通过回滚所有可能发生的事务到某一已知库存位置，重新构建任何时间准确的库存形势，从理论上讲是可行的，但实现起来太困难，因为分析问题涉及日期、产品、仓库、供应商等多种因素。如果性能度量包含不同的自然粒度或维度，则可能需要为不同过程建立不同的事实表。
最后一种库存模型是累积快照。累积快照事实表用于定义过程开始、结束以及期间的可区分的里程碑。在库存模型中，当仓库接受某个特定产品时，将在事实表中建立一行表示。被处理的产品用单一事实行跟踪，直到它离开仓库。包含多个日期和事实的库存累积快照事实表看起来一点也不像事务或周期快照模式。

4、事实表主要包含三种基本类型：事务、周期快照、累积快照，这一简单模型无论在哪个行业都适用。所有三种类型都可以使用，结合两个辅助事实表就可以获取整个业务全景，同时应用三个事实表将会使管理工作非常困难。

4.1、事务–每个事务或事务线一行
事务数据与多维框架非常贴合。原子事务数据是最自然的多维数据，它能够实现您对细节行为的分析。但不能仅仅只有事务，有一些商业问题的回答仅用这些细节数据难以实现。

4.2、周期快照–每个快照周期加上其他维度一行
在本例中，快照表的设计与其相关的事务表紧密相关。事实表共享多个维度表，快照通常不涉及维度。相反，与事务表比较，汇总周期快照表中通常包含更多的事实，因为在周期内发生的所有活动是周期快照中有效的度量。
在许多业务中，用于表示管理性能矩阵的事务细节不易汇总。正如在库存案例研究中所看到的那样，仔细分析事务时非常耗时的，增加需要的逻辑来解释不同类型事务对库存水平的影响会极其复杂，而且还需要假定您能够访问需要的历史数据。周期快照能够为库存水平提供快速、灵活的管理。快照模式的数据直接来自处理这些复杂计算的操作型系统。如果不是这样，ETL系统也必须实现这些复杂的逻辑以正确地解释每个事务类型的影响。

4.3、累积快照事实表–粒度：每次管道事件一行；管道活动发生时更新。
与其他两种事实表相比，尽管累计快照不太常见，但具有深刻含义。累积快照表示具有确定的开始和结束以及在此期间所有中间过程步骤的过程，累计快照最适合处理业务用户开展对工作流或流水线的分析。
对OLAP多维数据库来说，累积快照通常是存在问题的。因为对累积快照的更新需要同时改变事实和维度外键，多数多维数据库需要重新处理这些快照的更新，除非事实行是在流水线发生后加载的。

5、价值链集成
无论业务组织还是信息技术组织，通常都对价值链集成感兴趣。业务管理需要审视业务过程以更好地对性能进行评估。
IT管理人员意识到要实现有关数据仓库和BI的承诺需要集成。许多人将集成看成是他们管理企业信息财富的责任。他们知道，如果允许存在独立的、非集成的数据库，则难以表名他们完成了这样的责任。除了解决商业需求，信息技术还能从集成中获益，因为集成允许组织更好地利用稀缺资源并通过重用赢得效益。
使用共享公共维度对设计可以被集成的维度模型时至关重要的。

6、企业数据仓库总线架构
DW/BI 的成功，需要使用一种架构化、增量式的方法构建企业数据仓库。我们提出的方法称为企业数据仓库总线架构。
矩阵行应该关注引用业务过程。总线矩阵的每个列应该表示最详细的粒度。矩阵行共享标准的一致性维度。

7、改进现存模型成为总线矩阵
建立不同维度模型而不考虑关联它们的框架是难以接受的。孤立的、独立的维度模型会失去许多分析机会。它们会导致企业视图的矛盾，进一步导致报表之间无法比较。独立的维度模型成为遗留的实现，它们的存在将妨碍开发一致的DW/BI 环境。
如果某个维度模型是基于良好的维度设计构建的，也许可以将已经存在的模型转换为标准版本。使用交叉引用映射方法重建原始维度表。同样，事实表也需要重新处理，使用一致性维度主键替换原始的多维主键。当然，如果原始的维度和一致性维度表包含不同的属性，则对先前存在的BI 应用及查询进行返工是不可避免的。

8、一致性维度
一致性维度共享跨企业过程的事实表。一致性维度也被称为公共维度、主维度、引用维度和共享维度。一致性维度首先在ETL系统建立，然后逻辑上或物理上复制到DW/BI 环境中。在构建时，非常重要的是确保 DW/BI 开发小组能够使用这些维度。
除了一致性和可用性外，一致性维度能够确保将来自不同业务过程的性能度量合并到单个报表中。
一致性维度来自不同风格：

• 相同的一致性维度，具有一致性的维度键、属性列名、属性定义和属性值。
• 包含属性子集的缩减上卷一致性维度。如，如果品牌表属性是原子产品表属性的严格子集，则产品和品牌维度仍然是一致的。
• 包含行子集的缩减一致性维度
• 总线矩阵的缩减一致性维度

9、为产品、客户或其他维度寻找公共定义的愿望是建立企业DW/BI 系统理论目标的试金石。如果没有建立公共定义的医院，组织就没有必要建立企业 DW/BI 环境。尽管机构可能会发现跨不同行业合并数据的困难性，但一定程度上的集成通常成为最终的目标。

10、缓慢变化维 SCD（slowly changing dimension）
类型0：保留原始值。持久性键始终是类型0属性。
类型1：重写。类型1响应是应对维度属性变化的最简单的方法。在维度表中，仅需以当前值重写先前存在的值。不需要触碰事实表。类型1存在的问题是将会失去属性变化的所有历史记录。因为重写删除了历史属性值，您仅保存了当前最新的属性值。如果对属性变化并不是很在意，那么采用类型1响应是比较合适的。如果不需要保存过去的描述，则也适合采用类型1响应。
请注意，同样的BI应用在类型1属性变化前与变化后可能会产生不同的结果。当维度属性类型1重写发生后，事实行将与新的描述性环境关联。如果维度模型通过OLAP 多维数据库部署，类型1 属性是一种层次上卷属性，那么类似于本例中产品的部门，当类型1 属性变化是，多维数据库可能需要重新处理。
即使类型1变化最易实现，也需要记住它们将会导致关系表或OLAP多维数据库在针对受影响属性的聚集时产生错误。
类型2：增加新行
与类型1不同，在使用类型2技术时，不需要再次考虑先前存在的聚集表。若需要正确地计算产品数量，需要使用产品统一编号-自然键属性作为不同计数的基础，而不要使用代理键。自然键列成为连接不同类型2行以产生单一产品的关键。
有效日期和失效日期支持对维度的精确时间分片。当新行增加到维度中以获取类型2属性变化时，先前的行过期了。通常建议旧行的结束日期刚好在新行的有效日期前，不要在这些有效日期与失效日期留下时间间隔。
在同一个维度中混合使用多种缓慢变化维度基数也是比较常见的。在维度中同时使用类型1和类型2时，有时类型1属性变化要求更新多个维度行。这种应该由业务数据管理员制定最终的决定。
类型3：增加新属性
类型3与类型2不同的是，类型3包含被认为 同时正确的当前 和 过去属性值对。当需要同时支持两个不同视图时，采用类型3时比较适当的。
对不可预测的属性变化，类型3无能为力。类型3最适合应用于当某个变化影响维度表中大量行的情况。
例子，更改产品维度表，增加一个“先前部门”属性，将已存在的部门值（教育）放入该列中。原先的部门属性按照类型1来对待，按照类型1技术重写以反映当前值（战略）。所有存在的报表和查询立刻转换到新的部门描述，但仍然可以按照旧部门值，通过查询先前部门属性建立报表。
如果类型3属性表示维度内层次化的上卷，如类型1一样，类型3更新和增加列可能导致需要重新处理OLAP多维数据库。
多类型3属性，如果维度属性的变化节奏可预测，我们通过归纳类型3方法到一系列类型3维度属性获得这些变化定期的、可预测的属性，即增加多列。
类型4：增加微型维度
场景：面对频繁变化的大型维表。采用不同的维度消除频繁分析或频繁变化的属性，这一维度技术称为微型维度。
例如，可以为一组不稳定的客户人口统计学属性（例如，年龄、购买频度积分和收入水平等）建立一个微型维度，认为这些属性中的这些列被用于扩展和变化对业务是非常重要的。对每个唯一的年龄、购买频度积分和收入水平的组合，在微型维度中采用一行表示，而不是采用每个客户一行的方式。利用该方法，微型维度变成人口统计学概要的集合。
在建立微型维度时，不断变化的属性被转换为带状范围值。即呈现相对小范围的离散值。
人口统计维度不能增长过大。如果维度包含5个统计属性，每个属性包含10个可能值，则理论上说最多存在10 0000行（10的5次方）。这一数量时微型维度行的上限。
demographic：人口统计学的

11、混合缓慢变化维度技术
场景：需要保存与事实事件关联的精确的历史维度属性，以支持按照当前属性值对历史事实构建报表。基本缓慢变化维度技术本身是不能保证实现这些需求的。
类型5：4+1。微型维度与类型1支架表
类型6：2+3+1。将类型1属性增加到类型2维度
类型7：双重类型1与类型2维度

12、当实体之间存在固定的、不随时间变化的、强关联的关系时，它们应该被建模到单一维度中。大多数情况下，当实体被划分为两个不同的维度时，设计将会更简单且方便管理。

13、维度表不应该与事实表以同样的速率增长。

---

yarn 探索：
preempted： 抢占;先占;抢占了;先发制人;取代
spark ui 有个 stages 选项卡，executors 数是动态分配的，可看到50个，tasks 数可看到有 360个，即一个executor 平均7个左右tasks。
一个任务占用了多少资源，怎么看？ 看代码，excutors数量memory ，这里是 5012g = 600g。yarn上看到集群总资源是 1.44T。而该任务使用的队列 queue 配置的容量 Configured Capacity 是 50.0%，即 0.72 T = 737 g。 说明该任务会占用集群 80% 以上的资源，因此，该任务的调度 pool 只能选择 最多同时调度一个任务 的pool。task数量会被 set hive.exec.reducers.bytes.per.reducer 影响，默认值是 256000000，即256MB，代码写了 64MB，如果用默认值 ，task数会变少为 90个。
小文件就是文件大小小于128M 的。下面两个参数影响Hdfs文件个数，set hive.merge.size.per.task=128000000; set hive.merge.smallfiles.avgsize=64000000; 是配置合并小文件的参数，即如果hdfs的文件小于 64MB 的话，就会自动合并。在hdfs上可以看到文件大小有为 75MB的，虽说也是小文件，但是也允许存在，因为 128MB不是个确定值，万一两个小文件合并为仅大于一点128M，那就会一个文件两个block, 一个block是128M，一个block是很小的文件，这样又变成小文件问题了。