Kimball生命周期导论
原书是《数据仓库生命周期工具箱》，会写系列文章，用于记录读书笔记，同时写一点思考感悟。
最近开始回归数仓的文章，多读、多想、多思考。
|0x00 绪论
说起数据仓库，先说数仓诞生的初衷。
数据仓库的初衷，是为了商业智能（BI）而设计，在《数据仓库生命周期工具箱》一书中，把数仓系统称之为DW/BI系统，这样数据的主动权不再由技术人员掌握，而是由业务用户掌握，因此数仓的另一个重要目的是，让普通的业务用户能够看懂它。
数仓系统的最大特点，就是每个系统都是不断发展变化的，永远不会静止。新的商业催生了新的诉求，而新的管理者和执行官也会对数仓提出一些不可预知的要求，更多更新的数据源在接入到系统中，不断变化的动态机制使得数仓系统的稳定性变得极具挑战。这一点在传统技术时代并不明显，但是互联网时代特点就很明显了。因为过去的项目是有明确的起止时间的，而在互联网行业中，一个项目甚至是无限的，只有最细粒度的需求，是有起止时间的。
数仓有两个大的主题，一个是Kimball生命周期方法，另一个则是总线架构。Kimball与其他的数仓方法论有什么不同？最简单的答案是，Kimball是从业务用户的角度出发，找出他们完成工作需要什么，并以此建立数仓系统，随后开始逐步的向下探索报表、产品、存储系统和开发系统，进行统一的工作，最后深入到底层的数据架构之中。尽管二十年来我们在技术和认知上都有了巨大的进步，但Kimball生命周期的基本架构却没有显著的改变，这印证了Kimball团队的那句名言：“技术源于实践，结论来自验证”。
数仓早期的概念是：业务的生命周期，管理数据要有三个基本原则：
- 将关注点放在业务层面上；
- 按照维度组织数据，将这些数据以报表的形式呈现给业务用户；
- 开发过程应该是逐次迭代的方法，每次的生命周期增量都应该是可处理的，不要试图一次性完成所有的工作。
数仓是面向业务用户而设计的，因此数仓天然的应该围绕业务价值来展开设计，而不是单纯的炫技。
|0x01 生命周期
数仓系统的成功依赖于多项工作和多个部件的合理集成，仅仅拥有好的数据模型或者是好的数据架构是不够的的，还需要协调数仓项目中的很多方面。就像一个管弦乐队中的指挥一样，必须将多种乐器协调起来，任何一名独奏者都不能取代整个管弦乐队，Kimball生命周期就像乐队的总乐谱一样，确保了项目的每一个组成部分，都可以在正确的时间，按照正确的顺序，组合在一起。
第一个要介绍的概念便是项目/项目群规划。生命周期总要有个起点，而数仓的生命周期，则是从项目的规划开始。项目是指从开始到部署的一个单循环，它的起始和终止都是有限的，而项目群的概念则更为宽泛，包括了多个项目的资源运行协调、底层设施、开发进度与项目间的沟通等，一个项目群比一个项目所涵盖的内容更加广泛。
在项目规划过程中，比较突出的一致性问题，是数仓项目业务范围的界定。通常情况下，开发人员需要对业务需求有最基本的了解才能够对业务的范围进行恰当的定义，在图中，“项目/项目群规划”与“业务需求定义”两个方框间的双向箭头，就体现出了这种依赖关系。当项目规划确定后，工作就开始转向了资源的配置，以及项目任务的确定、分派、开发周期和优先级。
在互联网行业里，一个部门通常可以看作是整体的项目群，例如用户增长，每年有多少的增长指标，而细分下来的各种工作，就可以看作是一个个的项目。与过去概念不同的是，项目集是一个无法停下来的过程，它必然会催生各种各样新项目的诞生，但不论业务怎样规划，基础的逻辑都是不会变化的，也就是我们常说的公共层概念。可以说，一个设计良好的公共层，可以运行很多年不变，而应用层则随着新项目的不断诞生，进行无限的开发与应用。
第二个要介绍的概念是业务需求定义。如果我们能够对业务用户和他们的需求有彻底的了解，数仓项目成功的可能性就会大大增加。反之，如果缺乏深入的了解，那么数仓项目就会成为一次次的技能练习，对团队的发展没有什么助益。业务需求的分析通常会有一些技巧，比如GRASP、DDD领域驱动设计等。
在业务需求定义之后，是三条并行的路线，分别是技术、数据和BI三个方面，每一条平行的路线中都用箭头标明了各项活动中工作流的方向，也反映了各项工作之间的依赖关系。
第三个要介绍的是技术路线。这是业务需求确定之后，第一个并行的活动集合。数仓并不是单纯的建模，它所运行的环境，需要架构技术予以支持，包括业务需求、当前技术架构和方案设计的战略技术方向。例如我们是不是要支持实时，例如我们用怎样的OLAP引擎，等等。通常人们只会孤立的关注技术层面的工作，事实上技术是要有业务场景作为改进抓手的。
第四个要介绍的是数据路线。这是业务需求确定之后，第二个并行的活动集合。其目的是将源数据进行提取、转换和装载到目标模型的场所。数据路线有一个更通俗的解释，就是数据建模。第一个阶段便是ETL的设计与开发，包括；数据提取、数据清洗、数据一致性处理及数据传输和管理等过程开发，数据建模70%的风险都来自于这个阶段。ETL完成之后，就是维度建模的部分，在过去，就是要收集业务需求，将商业机构的数据需求确定下来并且保存在一个初步的“企业数据仓库总线矩阵”中，这个矩阵描述了商业机构的关键业务步骤及其相关维度。这个矩阵可以看作是数据架构的蓝图，确保了建模数据能够随着时间推移在整个商业机构中进行集成和扩散。
当然，今天的数据团队已经拆解成了数据架构、数据仓库、数据分析、算法四个组成部分，但ETL阶段依然是数据架构和数据仓库最重要的挑战，也决定了数据分析与算法的时效性价值能有多少。而不论是离线数仓的设计，还是实时数仓的设计，都离不开“企业数据仓库总线矩阵”的概念，无非是能做到多大的复杂性问题。
第五个要介绍的是BI路线。这是业务需求确定之后，第三个并行的活动集合。当业务需求定义完成后，BI团队便可以开始进行业务方面的工作，以确定数据的业务价值，并通过搭建报表平台的方式，来组织各种数据的展示，以满足用户的需求。对于大多数用户而言，会非常希望报表平台能够按照他们的需求和意愿随意定制，因此如何设计数据筛选和下钻的方式、提供易于理解的图表，就是提供有价值信息的关键方法。
让最懂的人，做最懂的事，而不是让专业的人，做专业的事。
|0x02 价值输出
当我们回顾刚才的整个流程，会发现，生命周期图并没有给出项目实现的绝对时间表，这涉及到了Kimball对于数仓技术的定位。
从传统意义上来说，Kimball集团将提供信息以支持商务决策的整个过程都叫作数据仓库技术，也就是说，提交端到端的完整解决方案是一项基本的原则。基于此，熟练的数据仓库人员，应该对于数据仓库技术架构中的各种工具都驾轻就熟，同时能够清晰的了解业务对方的诉求，配合BI来一起完成价值的输出。
商业智能这个术语从上世纪90年代才开始出现，主要是指对数据仓库中存储的数据进行记录和分析的过程。早期的数据仓库项目通常是失败的，但BI这样的工具却大获成功，因为BI承诺提供更多有业务价值的信息。
今天，这一类概念的定义已经有了比较明确的划分，即商业智能的重点，是使用相对简单的数学方法，来对历史数据进行展示和呈现，也就是“报表”；数据分析的重点，是采用更复杂的计算逻辑，并能够预测一些特定的问题、识别因果关系、确定最优解决方案的方法。可以说，商业智能“更广”，数据分析“更深”。
对于最近热门的数据科学，其定义存在争论，概念本身非常广泛，包含了整个“数据”相关的科学与实践。与数据分析不同的是，数据科学偏向于分析“宏观”问题，而数据分析偏向于分析特定行业或具体问题的挑战。数据科学最重要的方法在于，通过“自动化”对数据的分析，充分利用各类“工具”，来理解事物之间的真正本质。
人工智能是一门“让计算机做需要人类智能才能做的事情的科学”，领域非常广泛，包括了机器人、语言识别、图像识别、自然语言处理等方向。人工智能与机器学习的区别在于，人工智能是利用计算机完成模式的识别与探索的工作，而机器学习则是人工智能的子集，主要指利用计算机从数据中学习的概念，从堆积如山的数据中寻找出有用的知识。人类的学习是一个人根据过往的经验，对一类问题形成某种认识或总结出一定的规律，然后利用这些知识来对新的问题下判断的过程。人工智能，或者是机器学习，它们初始的设计思想并不复杂，仅仅是对人类学习过程的一个模拟。而在这整个过程中，最关键的是数据。
在大数据技术一统天下的时代里，数据仓库也分成了传统方向与新兴方向。传统方向因为受制于使用场景和业务诉求，原有的数仓+BI的方式已经能够很好的解决痛点，这种方式今天仍是数仓团队的主要工作，也就是通常所说的“茶树菇、SqlBoy”。而新兴的数仓更多的开始偏向数据科学、人工智能、数据化运营等算法场景，用于更加精细化的运营业务。
|0xFF 深入思考
维度建模是一套优化的设计原则，主要关注业务用户使用的便利性和BI查询性能这两个方面的目标。维度模型与那些规范化的数据库模型，虽然有着相同的数据内容和关系，但后者并不是那么通俗易懂，因此数仓相对于传统的数据库，最大的价值应该是易懂性，而不是仅仅能够满足报表需求。
维度模型的两个基本结构是事实表和维度表，事实表含有的度量源自于业务过程或者是度量事件，如销售订单处理或服务请求事件等。我们围绕着业务来进行模型建设，可以为所有的业务人员设计出相同、一致的数据视图，而不论他们是属于哪个部门，这对在业务会议中消除误解很有帮助。
不论我们如何设计数据仓库，是否采用维度建模，易懂性与通俗性，是共同的目标，而这些与技术无关，需要深入业务价值。
因此，数仓团队的使命，应该是同业务团队绑定在一起的，通过熟练的使用大数据工具，主打业务价值。
最后，大数据领域的数仓，业务场景一定要足够复杂，数据量一定要足够大，并且使用者一定要有足够多的实践经历，不然是无法深入理解维度建模的价值精髓的。
