本文分为两大节介绍，第一节是数仓建设，第二节是数据治理，内容较长，还请耐心阅读！
在谈数仓之前，先来看下面几个问题：
数仓为什么要分层？
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
数据仓库之父 Bill Inmon对数据仓库做了定义——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。从定义上来看，数据仓库的关键词为面向主题、集成、稳定、反映历史变化、支持管理决策，而这些关键词的实现就体现在分层架构内。
一个好的分层架构，有以下好处：
清晰数据结构
数据血缘追踪
减少重复开发
数据关系条理化
屏蔽原始数据的影响
数仓分几层最好？
不能为了分层而分层
分层是以解决当前业务快速的数据支撑为目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。
如何搭建一个好的数仓？
稳定
可信
丰富
透明
数仓设计
数仓设计的3个维度：
功能架构
数据架构
技术架构
数仓架构
源数据数据仓库数据应用
数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。
源数据
数据仓库
数据应用
抽取Extra, 转化Transfer, 装载Load
建设数据仓库犹如创造一条新的生命，分层架构只是这条生命的逻辑骨架而已。想要在骨架上长出血肉，就必须进行合适的数据建模，数据仓库的强壮还是孱弱，健美还是丑陋，就取决于建模的结果。
数仓建模方法
范式建模法、维度建模法、实体建模法
1. 范式建模法
范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :
每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
根据 Inmon 的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。
2. 实体建模法
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
实体，事件，说明
上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。
3. 维度建模法
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
典型的代表是我们比较熟知的星形模型（Star-schema），以及在一些特殊场景下适用的雪花模型（Snow-schema）。
维度建模中比较重要的概念就是 事实表（Fact table）和维度表（Dimension table）。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。
目前在互联网公司最常用的建模方法就是维度建模。
维度建模怎么建：
在实际业务中，给了我们一堆数据，我们怎么拿这些数据进行数仓建设呢，数仓工具箱作者根据自身60多年的实际业务经验，给我们总结了如下四步。
数仓工具箱中的维度建模四步走：
这四步是环环相扣，步步相连。下面详细拆解下每个步骤怎么做
1、选择业务过程
2、声明粒度
3、确认维度
4、确认事实
其中粒度是非常重要的
事实是整个维度建模的核心
实际业务中数仓分层
数仓分层要结合公司业务进行，并且需要清晰明确各层职责，要保证数据层的稳定又要屏蔽对下游影响，一般采用如下分层结构：
数据层具体实现
使用四张图说明每层的具体实现
数据源层主要将各个业务数据导入到大数据平台，作为业务数据的快照存储。
同一事实表中的所有度量必须具有相同的粒度
数据发散
最实用的事实就是数值类型和可加类事实
此层命名为轻汇总层，就代表这一层已经开始对数据进行汇总，但是不是完全汇总，只是对相同粒度的数据进行关联汇总，不同粒度但是有关系的数据也可进行汇总，此时需要将粒度通过聚合等操作进行统一。
数据应用层的表就是提供给用户使用的，数仓建设到此就接近尾声了，接下来就根据不同的需求进行不同的取数，如直接进行报表展示，或提供给数据分析的同事所需的数据，或其他的业务支撑。
一张图总结下数据仓库的构建整体流程
数据治理
数仓建设真正的难点不在于数仓设计，而在于后续业务发展起来，业务线变的庞大之后的数据治理
其实数据治理的范围很⼴，包含数据本⾝的管理、数据安全、数据质量、数据成本等。在DAMA 数据管理知识体系指南中，数据治理位于数据管理“车轮图”的正中央，是数据架构、数据建模、数据存储、数据安全、数据质量、元数据管理、主数据管理等10大数据管理领域的总纲，为各项数据管理活动提供总体指导策略。
数据治理之道是什么
1. 数据治理需要体系建设
合理的平台架构、完善的治理服务、体系化的运营手段
根据企业的规模、所属行业、数据量等情况选择合适的平台架构；治理服务需要贯穿数据全生命周期，保证数据在采集、加工、共享、存储、应用整个过程中的完整性、准确性、一致性和实效性；运营手段则应当包括规范的优化、组织的优化、平台的优化以及流程的优化等等方面。
2. 数据治理需要夯实基础
数据规范、数据质量、数据安全
3. 数据治理需要IT赋能
数据治理不是一堆规范文档的堆砌，而是需要将治理过程中所产生的的规范、流程、标准落地到IT平台上，在数据生产过程中通过“以终为始”前向的方式进行数据治理，避免事后稽核带来各种被动和运维成本的增加。
4. 数据治理需要聚焦数据
数据治理的本质是管理数据，因此需要加强元数据管理和主数据管理，从源头治理数据，补齐数据的相关属性和信息，比如：元数据、质量、安全、业务逻辑、血缘等，通过元数据驱动的方式管理数据生产、加工和使用。
5. 数据治理需要建管一体化
数据模型血缘与任务调度的一致性是建管一体化的关键，有助于解决数据管理与数据生产口径不一致的问题，避免出现两张皮的低效管理模式。
浅谈数据治理方式
数据产生->数据接入->数据存储->数据处理->数据输出->数据展示完整性、规范性、一致性、准确性、唯一性、关联性
在系统建设的各个阶段都应该根据标准进行数据质量检测和规范，及时进行治理，避免事后的清洗工作。
质量检测可参考以下维度：
下面是根据美团的技术文章总结的几点具体治理方式：
1. 规范治理
规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，统一按照最详细、可落地的方法进行规范建设。
词根
词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。
普通词根：描述事物的最小单元体，如：交易-trade。
专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。
表命名规范
通用规范
表名、字段名采用一个下划线分隔词根（示例：clienttype->client_type）。
每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。
表名、字段名需以字母为开头。
表名、字段名最长不超过64个英文字符。
优先使用词根中已有关键字（数仓标准配置中的词根管理），定期Review新增命名的不合理性。
在表名自定义部分禁止采用非标准的缩写。
表命名规则
指标命名规范
结合指标的特性以及词根管理规范，将指标进行结构化处理。
3.日期修饰词，用于修饰业务发生的时间区间。
4.聚合修饰词，对结果进行聚集操作。
5.基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额-trade_amt。
6.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt。
7.普通指标命名规范，与字段命名规范一致，由词汇转换即可以。
2. 架构治理
数据分层
优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长，一般的分层架构如下：
数据流向
稳定业务按照标准的数据流向进行开发，即ODS–>DWD–>DWA–>APP。非稳定业务或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP两个模型数据流。在保障了数据链路的合理性之后，又在此基础上确认了模型分层引用原则：
正常流向：ODS>DWD->DWT->DWA->APP，当出现ODS >DWD->DWA->APP这种关系时，说明主题域未覆盖全。应将DWD数据落到DWT中，对于使用频度非常低的表允许DWD->DWA。
尽量避免出现DWA宽表中使用DWD又使用（该DWD所归属主题域）DWT的表。
同一主题域内对于DWT生成DWT的表，原则上要尽量避免，否则会影响ETL的效率。
DWT、DWA和APP中禁止直接使用ODS的表， ODS的表只能被DWD引用。
禁止出现反向依赖，例如DWT的表依赖DWA的表。
3. 元数据治理
元数据可分为技术元数据和业务元数据：
技术元数据
常见的技术元数据有：
存储元数据：如表、字段、分区等信息。
运行元数据：如大数据平台上所有作业运行等信息：类似于 Hive Job 日志，包括作业类型、实例名称、输入输出、 SQL 、运行参数、执行时间，执行引擎等。
数据开发平台中数据同步、计算任务、任务调度等信息：包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
数据质量和运维相关元数据：如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。
业务元数据
元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体。
元数据治理主要解决三个问题
通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；
基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；
通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。
4. 安全治理
围绕数据安全标准，首先要有数据的分级、分类标准，确保数据在上线前有着准确的密级。第二，针对数据使用方，要有明确的角色授权标准，通过分级分类和角色授权，来保障重要数据拿不走。第三，针对敏感数据，要有隐私管理标准，保障敏感数据的安全存储，即使未授权用户绕过权限管理拿到敏感数据，也要确保其看不懂。第四，通过制定审计标准，为后续的审计提供审计依据，确保数据走不脱。
5. 数据生命周期治理
任何事物都具有一定的生命周期，数据也不例外。从数据的产生、加工、使用乃至消亡都应该有一个科学的管理办法，将极少或者不再使用的数据从系统中剥离出来，并通过核实的存储设备进行保留，不仅能够提高系统的运行效率，更好的服务客户，还能大幅度减少因为数据长期保存带来的储存成本。数据生命周期一般包含在线阶段、归档阶段（有时还会进一步划分为在线归档阶段和离线归档阶段）、销毁阶段三大阶段，管理内容包括建立合理的数据类别，针对不同类别的数据制定各个阶段的保留时间、存储介质、清理规则和方式、注意事项等。
从上图数据生命周期中各参数间的关系中我们可以了解到，数据生命周期管理可以使得高价值数据的查询效率大幅提升，而且高价格的存储介质的采购量也可以减少很多；但是随着数据的使用程度的下降，数据被逐渐归档，查询时间也慢慢的变长；最后随着数据的使用频率和价值基本没有了之后，就可以逐渐销毁了。
–END–
暂无评论内容