写此篇的原因是因为关于数据仓库这方面的单个书籍翻译不够友好，书写结构不够清晰以及当前现实环境的数据仓库搭建并非仅来自某个架构思想。
同时单单看一本书很难对数据仓库方面的知识进行全面的理解吸收。因此我想通过主动提问的方式从多本书籍结合自身经验以及与数仓专业人员的咨询请教中获取的知识进行理解、思考，最终得出结论来，并且一一回答数据仓库方面的知识内容。
此篇内容主要以数据仓库的介绍说明为主。也可以理解为语文中的说明文，几乎不涉及具体数据仓库搭建的方法论和技术细节。并且本篇文章为数据仓库方面知识的一个开始，后续遵循循序渐进，由浅入深的原则，对数据仓库进行深入了解和掌握。
此篇文章的撰写视角定位在对数据仓库客观的描述和说明，不涉及面向特定群体的说服而展开。
问题一： 数据仓库是什么？
数据仓库是对业务系统的数据进行同步接入、历史存储、清洗加工、关联打通、有效管理、分层建设、贴合需求；最终以提供满足业务场景数据使用需求的一种数据库。
参见数据仓库整个作业图便可进一步理解：
以下为每个环节的概述：
1. 同步接入
同步接入是指从各个业务系统抽取数据存入数仓。
一般分为离线抽取和实时抽取。抽取的数据来自多个业务系统和多种数据类型，关系型数据用sqoop来抽取，非关系型用kafka来抽取。
比如：一家金融公司的业务流程有 用户注册、贷款申请、风控审核、放款、贷后还款、催收等，这些业务环节的事务会在不同的系统完成；催收有催收系统，贷款申请有CRM系统等；这些围绕业务主线，涉及用户，内部员工，三方机构从而产生的业务数据，行为数据等都会通过每天定时或者实时存入数仓系统。
2. 历史存储
历史存储是指数仓会存储公司内所有保存的历史数据（前提是数据有接入数仓且之前有保存历史），可方便商业分析应用和其他业务诉求对历史数据的洞察。
比如：电商的物流数据，从下单到收货期间的运输状态可能每天都会不一样，那么数仓就会保存该订单物流每天的状态数据。
3. 清洗加工
清洗加工是指数仓会通过ETL（抽取、转换、加载）操作对业务系统的原始数据进行清洗，根据数据使用的便捷，干净，和业务诉求通过去重乱码，填补空值，维度拆分，行列转换等一系列操作。
比如：“地址”这个字段的值可能会拆分出多个维度来，国家、省、市、区、路、小区等等。 “身份证号”可以拆分出 出生年、月、日、性别等。
4. 关联打通
关联打通是指围绕业务主线及用户唯一识别，将不同业务系统的数据进行打通关联，将业务数据和行为数据进行关联打通；最终可形成完整的用户生命周期数据链路追踪。
5. 有效管理
有效管理是指对数据的在整个数仓内作业生命周期内的管理，包括对元数据的管理，对数据本身的作业管理，对数据关联角色人员的管理等。
比如：元数据管理这块，因为业务开发的人员流动，就会存在某些字段没有注释，没有明确的释义，当人员离开又加上需要了解该数据时就会遇到无人可问的情况，需要耗费较大的精力去想办法了解。
6. 分层建设
分层建设是指对进入数仓的数据进行层次划分（ODS 操作数据层、DWD明细数据层、DWS汇总数据层、ADS应用数据层），以满足数据使用便捷，高效，不耦合、符合业务需求等问题。（此处关于各个层次的细节介绍先不做说明，因为不在这个问题的讨论范围内）
7. 贴合需求
贴合需求是指所有的最终都需要业务化，为业务的分析决策，事务应用提供支持，而并非仅仅数据资产化；那么这就需要了解业务的数据需求来进行数据的加工开发，最终实现数据价值最大化。
问题二：数据仓库解决什么问题？
1. 数据打通提升数据价值
试想，现在某一电商产品做了一个版本迭代后，发现成交额有所下滑；目前知道成交额这种业务数据下滑，也知道都改了什么一系列功能，但并不清楚用户是在哪个环节流失的，他们操作了什么？停留了多少时间？ 是产品Bug还是用户不会用？在这种场景下如果没有行为数据做支撑，则很难定位到原因进行精准优化。
再试想下，同样是某一金融产品用户张三，其在该金融产品APP申请了一笔贷款，又在该金融产品的三方合作入口申请了一笔贷款；按照规定是不能进行单用户两笔贷款的，但因为系统数据没有打通，导致这样的风险问题存在。同时不得不说的是数据打通不是只有数据仓库可以解决，业务系统之间的数据交换也可以解决，只不过这种方式效率更低，更容易导致烟囱式开发。
2. 数据分层和维度建模提升数据使用效率
先说数据分层如何提升数据的使用效率；
如果我们不进行数据分层（直接ODS或源系统取）的情况下，在加工某一张报表，需要取一组数据的话，那么将会及其的复杂，繁琐。取一组数据需要关联N多表，并且还要了解清楚字段的意思，这种复杂的操作一般只能依赖BI开发，业务人员很难有能力提取，或者说即使有能力，也没有那些时间精力用来做这些事项；
如果我们进行数仓分层（ODS/DWD/DWS/ADS）的情况下，在加工一张应用层的表或者临时取一组数的话，仅仅是对两张报表进行关联；几乎不需要开发进行操作，直接在BI工具层即可实现。
用时间来量化衡量的话，没有数仓分层在对数据有所了解的情况下取数可能要1-2小时，有数仓分层分钟级即可搞定。
以下图为例，结合上边的论述和下边的图片可视化效果，以此来感受不分层与分层的区别：
再说维度建模提升数据使用效率；
由于维度模型的设计简单，基本遵照星型模型的设计规范，而大多数关系数据库的优化器是为星型模型设计的，这样就带来了维度建模的数据查询效率很高；此处待举例说明维度建模比雪花的能快多少；需要找开发求证
3. 降低运营成本
不搭建数仓（前提是企业业务验证成功，进入增长期有搭建数仓的必要）的情况下，数据报表的加工，临时数据的提取，数据接口封装对外输出都是需要不断的重复开发，并且耦合严重，这就导致了人力成本的上升；
比如： 数据报表的加工，每次类似需求都需要涉及业务人员，BI开发，测试，产品等，产品需要了解业务的数据需求目的，使用的场景，产生的价值，衡量的指标等针对这些问题与业务展开讨论，开发需要梳理数据来自哪些表，怎么取，怎么加工等。 一个报表的开发随便也要4个角色参与，7天+的工时；
而这些在数仓里可能只是根据业务通过BI进行表关联或者数仓开发根据业务应用数据从汇总层大宽表进行加工即可，人数缩减为2人参与，时间缩短为10分钟至1天。
问题三：数据仓库与业务源系统数据库有什么区别？
数据仓库主要是面向分析决策与业务应用支持的。
比如：从数据中分析用户为什么流失，交易量为什么下降，近些天的交易趋势是怎样的；从而满足分析性质的需求
比如：讲数仓的数据推给CRM系统供客服进行电话营销或者短信营销；趣头条那种根据用户激励模式，对用户的关键数据进行排名，展示等，也可从数仓输出原始数据，业务端再根据业务规则进行加工
源系统数据库是面向事务处理的，针对具体的业务操作进行数据的查询修改。
比如：电商用户选了一个衣服支付购买，那么订单系统就会插入一条该订单事务的数据。
更多区别如下所示：
问题四：数据仓库的架构都有哪些？它们之间的区别、优缺点、应用场景都是什么？
1. 数据仓库的架构目前主要分为
- 以Kimball集团为代表的一致性维度的企业总线架构
- 独立数据集市架构
- 以Inmon为代表的规范化建模Inmon架构
2. 它们之间的主要区别
Kimball
采用自下而上的建设思路；先选择业务主线需要使用的数据，再向上获取数据，形成数据集市，最终数据集市的合集形成了数据仓库。
独立数据集市
架构不需要考虑企业级别的信息共享和集成，只是为了满足部门的数据需求，针对部门的业务规则展开的数据建设；可以采用自上而下也可以采用自下而上。
Inmon
采用自上而下的建设思路；先从源业务系统获取数据进入数仓，然后再抽象数据主题，划分数据的层次，数据集市被包含在内，最终呈现给业务使用；
具体如下图所示：
3. 几种架构之间的优缺点
优点：
- Kimball：快速迭代，实施成本低，可快速响应业务需求。 因为Kimball采用的思路是自下而上的建设方法，它首先选取重要的业务一个业务单元进行切入，满足部分业务需求，后期还可以与数据仓库其他数据进行打通关联；比如： 金融业务现在最重要的是风控环节，风控环节的数据应用可以带来很大的商业价值，那么就可以先切入风控的去做，先随后根据调研评估，切入申请，贷后等环节。
- Inmon ：系统性的满足企业需求。 因为Inmon采用的思路是自上而下的的建设方法，统一接入系统元数据，统一根据业务部门需求建设数据集市；
- 数据集市 ：快速响应部门的数据需求。因为他只关注部门使用的数据，无需考虑公司内其他部门，因此使用的数据表、人、需求都会少。所以相对能快速响应。
缺点：
- Kimball： 造成重复建设，需求调研和满足各个业务需求时比较困难。 主要问题是根据某一环节的搭建，牵扯到对各个环节需求的调研，考虑多方的需求和真实能产生的价值。这里边会有博弈和真实需求的挖掘是否到位的难点。
- Inmon ：瀑布式建设，前期时间、人力等投入大。 由于它的思路是从数据源头进行系统性的全面建设，一次性接入所有数据，打通所有数据，建好所有模型，因此这样的代价不言而喻。
- 数据集市：只能适用于单部门，对公司是一种资源浪费，并且无法获取到其他部门数据，对自己业务补充也是一种缺失。 试想下公司有10个业务部门都各自搞一套数据集市，这样造成多大的人力浪费和其他资源浪费；在试想下自身可以拿到其他业务的数据，重叠用户可以对他们更全面的了解，非重叠用户可以进行拉新转化。
应用场景：
- Kimball：适用于企业高速成长，需要通过数据仓库减低成本，增强运营能力且内部可以达成建设迭代优先级共识的场景下。
- Inmon ：适用于企业稳定，业务模式比较固定的场景；比如： 银行，政府机构等。
- 数据集市：适用于企业内部没有达成共识，战略层面不关注数据打通的价值只需专注部门内部作业或者业务早期需要快速高效的获取数据，还没有建设数仓的必要。
但，就如万事没有非黑即白，非此即彼一样；数仓建设也不是一定要用Kimball还是Inmon ，两者是可以相结合的。
问题五：数据仓库搭建的整个流程是怎样的？
参照下图：
以下关于上述流程做简单说明：（该流程主要参照Kimball的架构思路）
1. 项目/项目群规划
在公司有众多业务领域的情况下，要搭建数仓就需要在顶层确认先切入哪个业务的优先级选择。 这个环节主要要针对业务高层关于他们的未来商业计划，目前的度量业务变化的指标以及确定数据建设对业务的影响价值进行探讨确定。
2. 业务需求调研
此环节主要是收集业务的数据需求，他们关注的业务过程，衡量指标以及数据建设带来的价值评估，以确定切入的具体业务环节。这个环节主要需要和具体的业务人员及业务小负责人进行沟通，因为他们属于执行层面，他们对数据的应用价值认识比较透彻。
3. 技术架构设计
根据需求的了解和数据量、类型的了解技术需要评估所有采用的服务器配置、数据接入技术、ETL技术、OLAP技术等。以完成数据仓库建设做好准备
4. 维度建模
维度建模是一种将数据结构化的逻辑设计方法。 数据被分为维度（分类型数据，一般以文字为主）和度量（连续型一般为数值为主），这样做能够提供较快的查询性能，以及对业务用户比较直观。
5. 物理设计
物理设计就是数据仓库的逻辑模型（即维度设计）在物理系统中的实现模式。其中包括逻辑模型中各种实体表的具体化，比如：表的数据结构类型，索引策略，存储位置，存放分配等
6. ETL设计与开发
此处主要的工作在于基于ETL 34 个子系统选择或搭建，并且根据各个源系统的数据类型、逻辑模型设计，数据需求进行ETL的设计。
7. 数据输出
数据输出是指数据对外的使用，当前常见的前端使用一般为 BI分析系统、画像系统、API接口等。
问题六：数据仓库与数据中台有什么区别？
绿色高亮的为区别之处。根据Kimball 自身撰写的数据仓库书籍描述，他对数据仓库的应用主要定义为BI；但根据当前的现实场景的应用来看，并不是数仓只是用做报表，它已经包含了画像，输出业务系统以及通过API网关的形式对外提供服务。比如：针对CRM营销系统需要的用户信息可以从数仓通过接口的形式进行输出。
因此，两者之间在实际层面几乎没有什么区别；只是概念层面前者具有较高的战略期望：
问题七：数据仓库分层是什么？都包含哪些层次？不同层次之间的区别与关联又是什么？
1. 模型分层是什么
数据仓库分层是通过对数据从无序到有序，从明细到汇总，从汇总到应用的设计。 主要是为了提升数据使用效率，方便问题定位，减少重复开发，统一数据口径等问题。
2. 包含哪些层次
- ODS层（Operational Data Store）：数据运营层；把操作系统的数据直接抽取存放到数仓系统中，基本不做什么加工；这样方便后续数据问题定位时，可以找到源数据。
- DWD层（Data Warehouse Detail）：数据明细层；该层的数据粒度与ODS层一致，都是原子级别的数据。 在基于维度建模方法的设计基础，讲维度退化至事实表，方便数据使用的效率。
- DWM层（Data WareHouse Middle）：数据中间层；该层的数据是基于DWD层的数据做轻度汇总，生成一系列公共指标，减少重复开发。也可以理解为对关键维度进行聚合。
- DWS层（Data WareHouse Servce）：数据服务层；又称做数据集市或者大宽表，比如：用户表、流量表、订单表、发货表等。一个表就会包含多个很多字段，涉及多个业务过程。
- ADS层：数据应用层；该层的数据主要是基于业务的个性化需求生成的数据表；上边几个层次更多的是基于业务过程的加工和聚合，而ADS层更多的关注的实际业务部门需要关注的个性化数据表的使用。数据来源一般也都是来自DWS层的再次加工。
3. 区别与关联主要为
ODS层没有进行ETL和维度建模结构化，后续分层都进行了这些操作；ODS和DWD是原子级数据而DWM和ADS是汇总数据；ADS是基于业务部门的个性需求产生的数据，而其他层是基于业务过程进行处理和主题划分。底层的数据支撑上层数据的建设，每个层次之间相互关联，相互依赖。
参见下图的数仓分层：
问题八：数据仓库分层都有什么价值？
1. 减少重复建设，提升数据应用效率
每个层次的粒度不同，需要新开发一个应用层的表直接根据现有的汇总层进行抽取即可。避免了一些数据重复的通过底层数据进行计算，浪费人力成本、时间成本和服务器资源成本。
试想下，要开发一个性化应用层的表，如果只有ODS层，数据分散，涉及表多，口径不一致，命名重复等问题都存在，这样开发出一张应用表，需要耗费多少时间周期，并且还不一定准确。 如果做了分层，直接通过汇总层根据需要进行连接即可。
2. 方便数据血缘追踪
当有应用层表的数据出现问题时，我们可以通过血缘追踪快速定位到其关联的表，因为层次结构清晰，所有很好追踪到；如果没有分层，则可能会想蜘蛛网一样。
问题九：数据仓库中的主题是什么？解决什么问题？
数据仓库主题是从较高层次上对数仓数据业务含义和需求的理解进行归类抽象划分的一种方式。最终会产生比如：订单主题、用户主题、营销主题、财务主题等。
举个超市的例子： 超市一般都有划分生鲜区、冻品区、食品区、粮油区、家电区、服饰区等，这些区域的分类也是根据商品的特有属性进行的区分，当我们有很明确的需求是要购买电视机，那么我们可以直接去家电区，而不用去生鲜区之类的；当我们的需求是在家做一顿丰盛的晚饭，那么我们可能会去 生鲜区、冻品区、食品区，但一定不用去服饰区。
反过来看数仓也是一样的，如果要看的是用户数据，直接拉用户主题的就可以，如果要分析用户的不同购买时段的购买情况及物流效率，那么数据加工时就可以很容易的确定出需要拉用户主题、事件主题、订单主题、物流主题的数据。
主要解决的问题是对数据分门别类的区分，方便业务使用数据以及方便数仓根据数据需求进行数据加工；
试想下，如果超市的东西放的乱七八糟的，家电区有食品，食品区与冻品等等，这样当我们要购买目标商品的时候要多麻烦；数仓如果我们有一个数据需求，却不知道数据都来自哪些表，并且会有很多表。这样的会多麻烦，做不做主题的效率差可能至少是5倍。
主题在物理上存在的形态会出现，数据耦合情况，具体如下所示：
问题十：产品经理在数仓建设中能发挥什么作用？
首先回到数据仓库建设的整个生命周期流程：项目/项目群规划—业务需求调研—技术架构设计—维度建模—物理设计—ETL设计与开发—数据输出。
产品经理发挥的作用也是围绕这个生命周期展开。主要为以下方面：
1. 项目/项目群规划
这个环节产品经理主要起到的作用是向上建设和立项调研。
数仓建设毕竟是一个需要投入较多人力成本，资源成本和多方面资源协调的事情，不是一个小需求，即时需求了解不透彻，错了也无关紧要。 数仓建设一旦确定要做，就标志着自上而下的影响面很广，那么就势必需要对数仓建设解决业务的问题，投入的成本，产生的价值，具体量化的数据和未来的潜在价值等等做一个立项调研，以说服领导层愿意投入资源进行建设，并且从战略上推动各个部门人员进行支持，否则很难推动建设。
比如： 我们输出结论产生多少的人力成本节省，折合多少金额；提升了多少的数据使用效率，折合多少金额；预计带来多少因数据打通而产生的增长机会，折合多少金额等。
2. 业务需求调研
这个环节产品经理主要起到的作用是业务数据需求挖掘。
这个环节需要通过刨根问底的方式深入业务了解他们的数据使用需求，关注的指标，数仓建设预计产生的价值。通过对各个业务关于数据使用的需求强烈程度和价值大小，进行综合评估，选择切入的业务环节顺序，以便实现价值尽早体现。
3. 维度建模
这个环节产品经理主要起到的作用是资源协调与推动。
这个环节的主要事项是数仓开发需要了解清楚业务，了解数据情况，字段释义，表之间的依赖关系，以便进行模型设计与主题划分。 这里边就存在着需要推动多个部门的相关人员进行配合协助，描述清楚业务的流程环节，字段的意义，依赖的关系。 如此消耗资源的事情，就需要产品进行协调推动各方输出信息给数仓。此部分更多是项目经理的工作。
4. ETL设计与开发
这个环节产品经理主要起到的作用是工具的搭建设计。
数仓关联的工具模块至少包含：元数据管理，数据接入，数据调度；在往细的拆又有 数据地图、数据血缘、数据预警、数据接入配置、可视化清洗的34个子系统等。 这些工具都是在帮助数仓建设提升效率，减少错误，方便管理等方面做努力。
5. 数据输出
这个环节产品经理主要起到的作用是业务应用数据需求分析和API网关产品设计。
产品收集日常业务提的各种数据应用需求，通过汇总抽象反馈至数仓用来完善ADS层；在业务系统需要使用的数据设计公共的API网关产品用来提供服务，避免数据重复输出，严重耦合带来效率问题。
总体来说，产品在数仓搭建的事情当中，一部分属于项目经理，比如维度建模过程中的多资源协调推动与项目推动；一部分属于产品经理，比如立项调研，管理工具设计规划等。