数仓为何物数仓的本质和数据库一样，是用来保存组织数据的。但是区别也很明显：从使用上，数据库服务于OLTP，对响应速度要求很高，有频繁的增删改查需求，而数仓服务于OLAP，对响应的实时性要求不高，入库的数据是以分析为目的，基本不会再做修改。从数据上来看，数据仓库的数据体量和数据的繁杂程度较数据库不是高了一点点。
数仓何以用数仓的主要目的是为了合理的组织保存数据，保证数据的完整、准确、及时。其实数据仓库可以看成是BI的基础版本、数据库的升级版本，我们可以把公司里的数据都想象成一个个文件夹，数据库就是这一个个文件柜，这个文件柜存放着非常多的数据，无论这个数据是什么、或者是如何组织的。而当我们的文件非常多、种类非常复杂的时候，我们的就想要寻找某个文件夹的时候，如果每个文件柜每个文件柜的去找，实际上是非常耗费成本的，因此我们不妨建立一个档案室，对不同的文件柜进行编号、归类、分组，方便我们快速定位数据源，这个档案室就是数据仓库。所以这时候我们需要更为庞大的数据仓库，帮助我们去对多个数据源的数据库数据进行抓取，而抓取数据源的过程就可以理解为ETL的工作，这样去理解一个企业的数据架构就会简单很多。数仓的最终目标是为了挖掘数据价值。
数仓建设基本流程建立数据仓库的第一个步骤就是通过与业务部门的充分交流，了解建立数据仓库所要解决的问题的真正含义，确定各个主题下的查询分析要求。业务人员往往会罗列出很多想解决的问题，信息部门的人员应该对这些问题进行分类汇总，确定数据仓库所实现的业务功能。一旦确定问题以后，信息部门的人员还需要确定一下几个因素：·操作出现的频率，即业务部门每隔多长时间做一次查询分析。·在系统中需要保存多久的数据，是一年、两年还是五年、十年。·用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。·用户所能接受的响应时间是多长、是几秒钟，还是几小时。指标库是前期准备工作的重要阶段性成果。它定义数仓的服务范围，是主题的实质性体现，对后面数据治理有非常重大的意义。指标库是维度和度量的集合。常用报表涉及的字段应是指标库的子集。
数仓建设基本流程
比数据域更高维度的业务划分方法，适用于庞大的业务系统。维度：维度建模由RalphKimball提出。维度模型主张从分析决策的需求出发构建模型，为分析需求服务。维度是度量的环境，是我们观察业务的角度，用来反映业务的一类属性。属性的集合构成维度，维度也可以称为实体对象。例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。属性（维度属性）：维度所包含的表示维度的列称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。度量：在维度建模中，将度量称为事实，将环境描述为维度，维度是用于分析事实所需要的多样环境。度量通常为数值型数据，作为事实逻辑表的事实。指标：指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词，体现明确的业务统计口径和计算逻辑，例如支付金额。原子指标=业务过程+度量。派生指标=时间周期+修饰词+原子指标，派生指标可以理解为对原子指标业务统计范围的圈定。业务限定：统计的业务范围，筛选出符合业务规则的记录（类似于SQL中where后的条件，不包括时间区间）。统计周期：统计的时间范围，例如最近一天，最近30天等（类似于SQL中where后的时间条件）。统计粒度：统计分析的对象或视角，定义数据需要汇总的程度，可理解为聚合运算时的分组条件（类似于SQL中的groupby的对象）。粒度是维度的一个组合，指明您的统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、地区这两个维度的组合。如果您需要统计全表的数据，则粒度为全表。在指定粒度时，您需要充分考虑到业务和维度的关系。统计粒度常作为派生指标的修饰词而存在。基本概念
闻第一需求调研在构建数据仓库之前，首先需要确定构建数据仓库的目标与需求，并进行全面的业务调研。您需要了解真实的业务需求，以及确定数据仓库要解决的问题。业务调研充分的业务调研和需求分析是数据仓库建设的基石，直接决定数据仓库能否建设成功。在数仓建设项目启动前，您需要请相关的业务人员介绍具体的业务，以便明确各个团队的分析员和运营人员的需求，沉淀出相关文档。您可以通过调查表和访谈等形式详细了解以下信息：1.用户的组织架构和分工界面。例如，用户可能分为数据分析、运营和维护部门人员，各个部门对数据仓库的需求不同，您需要对不同部门分别进行调研。2.用户的整体业务架构，各个业务板块之间的联系和信息流动的流程。您需要梳理出整体的业务数据框架。3.各个已有的业务板块的主要功能及获取的数据。
闻第壹需求调研需求分析在未考虑数据分析师和业务运营人员的数据需求的情况下，单纯根据业务调研结果构建的数据仓库可用性差。完成业务调研后，您需要进一步收集数据使用者的需求，进而对需求进行深度的思考和分析。需求分析的途径有两种：1.根据与分析师和业务运营人员的沟通获知需求。2.对报表系统中现有的报表进行研究分析。在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：1.业务数据是根据什么（维度、粒度）汇总的，衡量标准是什么？例如，成交量是维度，订单数是成交量的度量。2.明细数据层和汇总数据层应该如何设计？公共维度层该如何设计？是否有公共的指标？3.数据是否需要冗余或沉淀到汇总数据层中？举例：数据分析师需要了解A公司电商业务中厨具类目的成交金额。当获知这个需求后，您需要分析：根据什么（维度）汇总、汇总什么（度量）以及汇总的范围多大（粒度）。例如，类目是维度，金额是度量，范围是全表。此外，还需要思考明细数据和汇总数据应该如何设计、是否是公共层的报表及数据是否需要沉淀到汇总表中等因素。需求调研的分析产出通常是记录原子与派生指标的文档。
矩第贰数仓标准建设数仓标准主要包括编码规范和设计规范：设计规范设计规范主要包括数据架构规范、数据流规范、数据模型规范。开发规范开发规范主要包括编码规范和命名规范
矩第贰数仓标准建设设计规范1.模型架构规范模型架构规范一般采用分层架构：1.ODS：OperationalDataStore，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到数仓。2.CDM：CommonDataModel，公共维度模型层，又细分为DWD和DWS。它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标1.DWD：DataWarehouseDetail，明细数据层2.DWS：DataWarehouseSummary，汇总数据层。3.ADS：ApplicationDataService，应用数据层。
矩第贰数仓标准建设设计规范2.数据流规范
矩第贰数仓标准建设设计规范3.数据模型规范模型是对现实事物的反映和抽象，能帮助我们更好地了解客观世界。数据模型定义了数据之间关系和结构，使得我们可以有规律地获取想要的数据。例如，在一个超市里，商品的布局都有特定的规范，商品摆放的位置是按照消费者的购买习惯以及人流走向进行摆放的。1.数据模型的作用数据模型是在业务需求分析之后，数据仓库工作开始时的第一步。良好的数据模型可以帮助我们更好地存储数据，更有效率地获取数据，保证数据间的一致性。2.模型设计的基本原则1.高内聚和低耦合一个逻辑和物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论中的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。2.核心模型与扩展模型分离建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要。在必须让核心模型与扩展模型做关联时，不能让扩展字段过度侵入核心模型，以免破坏了核心模型的架构简洁性与可维护性。3.公共处理逻辑下沉及单一底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。4.成本与性能平衡适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。5.数据可回滚处理逻辑不变，在不同时间多次运行数据的结果需确定不变。6.一致性相同的字段在不同表中的字段名必须相同。7.命名清晰可理解表命名规范需清晰、一致，表命名需易于下游的理解和使用。
矩第贰数仓标准建设开发规范1.编码规范代码规范主要包括开发语言范围的确定，开发工程目录结构的统一，脚本或源文件的格式化约定，常用函数使用的一般性规定及版本管理的一般性规定。2.命名规范命名规范规定了库、表、字段、工程目录、脚本、源文件命名的强制性约定。
行第叁过程控制过程控制主要包括元数据管理、安全管理、运维管理、数据质量管理。1.元数据管理元数据是数据的数据，元数据保证了数据和管理的便宜性，降低了数据使用成本，同时也是其他过程管理的基石，可以说没有完整准确的元数据，是不可能建设出一个合格的数仓的。2.安全管理数据泄露对公司的威胁不言而喻。安全管理是以规避数据泄露、保证数据安全的管理过程。数据安全应从流程、软件、硬件上多方面考虑。3.运维管理运维管理是保证数仓是否能够正常运行的基础。资源监控、作业监控、作业诊断是基础的服务功能。4.数据质量管理数据质量管理是对数据完整、准确、及时的控制过程。它保证了数据的价值的，是数仓建设的重中之重。
元数据管理元数据是描述数据的数据。元数据主要由四部分组成：1.业务元数据，与业务规则、流程相关的描述性数据2.技术元数据，与存储、访问等技术底层的描述性数据，包括分区数量、分区增长率、分区大小、表对应的ETL任务运行时段、运行时长、表累计调用次数等等3.操作元数据，与数据操作相关的描述性数据4.管理元数据，与数据管理相关的描述性数据元数据除了以上传统组成，还应包括血缘元数据，血缘关系应精确到字段。
安全管理1.物理环境安全主要从容灾机房和备份入手,备份数据一般是3个月内的全量数据，不应根据数据量大小及重要程度进行划分，应一视同仁。备份的数据应归档压缩加密。2.软件环境安全1.网络安全2.权限管理3.开发环境3.数据流出管理1.数据脱敏2.严格控制单次数据导出体量，一般单次导出数据量不应大于条3.明细数据不应提供导出功能4.反爬虫4.法律风险控制
运维管理1.资源监控资源监控除了保证作业的正常运行外，也是资源扩充，作业运行时段规划的基础2.作业监控作业的正常运行时数据准确性、完整性和及时性的基础。作业监控的主要目的是快速恢复。针对作业失败应有一整套应对措施。3.作业诊断作业诊断也就是作业日志的入库和分析，是作业优化和错误追踪的基础。
数据质量管理数据质量保障原则1.完整性完整性是指数据的记录和信息是否完整，是否存在数据缺失情况。数据缺失主要包括记录的缺失和具体某个字段信息的缺失，两者都会造成统计结果不准确。完整性是数据质量最基础的保障。例如，某个稳定业务的数据量每天约为万条记录，某天突然下降了1万条，则可能是出现了记录缺失。例如，某科高考成绩表中，每个考卷分数都对应一个准考证号，当准考证号字段的空值数大于0时，则可能是出现了信息缺失。2.准确性准确性是指数据中记录的信息和数据是否准确、是否存在异常或者错误的信息。例如，成绩单中分数出现负数或订单中出现错误的买家信息等，这些数据都是问题数据。确保记录的准确性也是保证数据质量必不可少的一部分。3.一致性一致性通常体现在跨度很大的数据仓库中。例如，某公司有很多业务数仓分支，对于同一份数据，在不同的数仓分支中必须保证一致性。例如，从在线业务库加工到数据仓库，再到各个数据应用节点，用户ID必须保持同一种类型，且长度也要保持一致。因此，您需要设计数仓的公共层以确保数据的一致性，详情请参见CDM公共维度层设计规范。4.及时性保障数据的及时产出才能体现数据的价值。例如，决策分析师通常希望当天就可以看到前一天的数据。若等待时间过长，数据失去了及时性的价值，数据分析工作将失去意义。
数据质量管理数据质量管理是通过划分数据资产等级和分析元数据的应用链路，对不同资产等级的数据采取相对应的质量管理方式。数据质量管理流程图如下。数据管理流程说明如下：1.分析业务场景，根据应用的影响程度，确定当前以及生产链路上的数据资产等级。2.在各个加工环节上根据不同资产等级对数据采取不同的质量管理方式。3.对数据风险点进行监控，包括数据质量风险和数据及时性监控。4.根据业务过程中出现的问题，对监控方案进行汇总分析和改进。
数据质量管理数据资产等级定义根据数据质量不满足完整性、准确性、一致性、及时性时，对业务的影响程度划分数据的资产等级。通常，划分为5个性质的等级：1.毁灭性质：数据一旦出错，将会引起重大资产损失，面临重大收益损失等。标记为S+。2.全局性质：数据直接或间接用于企业级业务、效果评估和重要决策等。标记为S。3.局部性质：数据直接或间接用于某些业务线的运营、报告等，如果出现问题会给业务线造成一定的影响或造成工作效率降低。标记为A。4.一般性质：数据主要用于日常数据分析，出现问题带来的影响极小。标记为B。5.未知性质：无法明确数据的应用场景。标记为C。这些性质的重要性依次降低，即重要程度为S+SABC。如果一份数据出现在多个应用场景汇总，则根据其最重要程度进行标记。
数据质量管理数据加工过程卡点校验离线业务系统生成的数据，通过同步工具进入数据仓库系统。数据在数据仓库中进行清洗、加工、整合、算法和建模等一系列运算后，再通过同步工具输出到数据产品中进行消费。整个流程中，先有数据加工，才有数据仓库模型和数据仓库代码的建设。因此，保障数据加工过程中的质量是保障离线数据仓库整体数据质量的重要环节。1.代码提交时的卡点校验。即在SQL提交前进行相关规则校验。规则分类如下：1.代码规范类规则。例如，表命名规范、生命周期设置及表注释等。2.代码质量类规则。例如，分母为0提醒、NULL值参与计算影响结果提醒及插入字段顺序错误等。3.代码性能类规则。例如，分区裁剪失效、扫描大表提醒及重复计算检测等。2.任务发布上线时的卡点校验。为保障线上数据的准确性，每次变更都需要经过测试再发布到线上生产环境，且生产环境测试通过后才算发布成功。3.任务变更或数据重跑。在进行更新操作前，需要通知下游变更原因、变更逻辑、变更时间等信息。下游对此次变更没有异议后，再按照约定时间执行发布变更，这样可以将变更对下游的影响降到最低。
省第肆迭代1.经验积累当需求有新增或者变更时，应维护到专门的文档中。当前版本与上个版本区别应一目了然，业务逻辑记录应完整详实。踩坑说明应记录前因后果，解决方案应详实各种自研或非自研工具应说明大致原理和使用方法。使用方法必须带有案例。各种自定义的UDF方法应说明大致原理和使用方法。使用方法必须带有案例。文档应有专人监督。2.优化优化可能是脚本性能的优化、健壮性的优化，也可能是模型的优化，依赖关系的优化。优化是数仓建设中必不可少的一部分，但也要警惕优化成为日常工作。优化的目的应明确，优化前后对比数在文档中应给出。
举个例子需求统计昨天所有汽车的里程第一步：从业务系统抽取数据1.确定抽取的mysql中的源数据表run_info2.确定抽取形式为增量抽取，创建ods层表ods.bis1_run_info_d_inr第二步：公共业务逻辑编写1.建立dwd.bis1_run_info_d表，书写ETL脚本，去除重复行、处理脏数据、确实数据填补，完善维度信息2.建立dws.bis1_car_trip_d表，书写ETL脚本,里程计算逻辑实现，按汽车型号、汽车vid、行程维度统计里程、开始点信息、结束点信息、行程时间、最大速度、最低速度、平均速度等等指标聚合计算。第三步：需求业务逻辑编写1.在rpt.bis1_car_info_d表中新增里程字段,书写ETL脚本,按型号、汽车vid统计每辆汽车每天的里程等信息。第四步：将表输出到BI等其他外部系统。