数仓相关数据读后感
数据仓库工具书
主要讲维度建模和具体的业务场景例子，维度建模步骤：选择业务过程-声明粒度-确认维度-确认事实，星型模型&雪花模型，事实表&维度表怎么设计，事务-周期快照-累积快照-无事实事实表，其他印象深刻的：蜈蚣事实表，数据仓库总线矩阵
美团技术团队博客-美团数据平台及数仓建设实践
一、美团数仓架构的不同发展阶段
阶段1：团队规模小，要求快速响应，灵活多变，支持业务决策
分为数据源层、数据加工层、数据服务层，数据应用层。
我理解为ODS+DWD+DIM+WDS+ADS
问题：随着数据量、业务负责度和团队规模的增重，为了更好地完成业务需求，数据组团队按照应用划分了不同的团队：面向总部的团队、面向城市业务的团队。各个团队开发的时候都做面向自己的业务做一个数据模型、明细数据、指标、主题宽表，这就会导致重复计算和烟囱式开发。在团队规模还小的时候，大家彼此知道对方在做的事情，基本不会有太大的问题，但是团队规模增长到一定程度，团队之间的沟通障碍就越来越大，最终导致烟囱式开发。不同团队独立作战，烟囱式开发的主要问题：
- 开发效率低
- 大量重复计算、数据冗余，资源成本高
- 数据口径不统一
阶段2：为了解决这个问题（烟囱式开发），数据组做了架构上的调整，主要目标是：简化开发流程、明确分层分主题标准。
- 之前的数据组的团队被完全纵向切分，导致公用的部分明细数据重复开发，为了解决这一情况，将数据团队改为：数据建模组和数据应用组
- 数据建模组：负责基础事实表，基础维度表，原子指标的数据开发，自下而上，面向业务
- 数据应用组：负责应用指标，应用维度，应用模型的数据开发，自上而下，面向应用
- 分层规范：明确各层的职责
- 数据源层ODS：负责接入数据源，并做到多数据源整合
- 数据集成层IDL：业务主题的划分（商家、交易、用户），屏蔽底层影响，尽量欢迎业务，统一标准---类似DWD
- 数据组件层CDL：分析主题划分（商家交易、用户活动），针对同一个分析对象统一指标口径，避免重复计算---原子指标
- 数据集市层MDL：负责建设宽表模型，汇总表模型（商家宽表，商家时段汇总表），作用是支持数据分析查询以及支持应用所需的数据，围绕应用构建不同的数据集市（流量集市、城市经营集市）---派生指标
- 数据应用层ADL：主要职责是建设应用分析，支持多维分析应用，比如城市经营分析等。
- 主题标准：根据数仓的每层特性，使用不同的主题划分方式，总体原则是：主题内部高度内聚，不同主题间低耦合。比如明细层按照业务过程划分主题，汇总层按照“实体+活动”划分分析主题，应用层根据应用需求划分应用主题
问题：数据集成层和组件层，由数据基建组来统一标准；数据应用层由数据应用组来运维。这个索然分工明确，沉淀了公共数据，数仓底部做了收敛，但是在应用层和集市层缺发生了膨胀，缺乏管理。(我理解为存在很多临时性需求，导致有的应用层数据模型一段时间之后就没人使用了。）
阶段3：为了解决这个问题（数据应用膨胀），希望使用建模工具代替人工开发。
建模工具分为：基础建模工具、应用层建模工具
- 基础层建模工具：主要是在元数据中心记录维护业务过程、表的关联关系、实体对象、识别的分析对象，基于维护的信息构建数据组件以供应用层和数据层拼接。（搭建数仓的元数据管理平台）
- 自助查询工具：根据数据组件和用户选取的需要查询的指标维度信息构建逻辑宽表，根据逻辑宽表匹配最佳模型，从而产生查询语句，并将查询出来的数据反馈给用户，同时根据用户查询情况反过来指导建模，告诉我们哪些指标和那些维度经常会放在一起查询，根据用户常用的指标、维度组合建设数据组件
- 应用层建模工具：依赖数据组件，包括数据组件层的多维明细数据、轻度汇总数据以及集市层的宽表，构建数据应用。主要过程是获取需要的数据组件，进行数据裁剪、维度退化、按需上卷、复合指标计算，最终把获取到的多个小模型拼接起来构建数据应用。
总结：
阶段1数仓刚刚起步，很多时候都是面向需求开发，数据团队人也不多，很多时候都是要求快速，基本上就是一个人从数据源开始一路开发到应用层；随着业务需求量的增多，数仓体积增大，个人独立开发导致的烟囱式开发的缺点逐渐暴露，迎来了第二阶段。
阶段2主要目标就是公共计算逻辑下沉，这个交给了数据建模组来专门负责，也就是把数仓分层了上下两块，下面的数仓底层交给专门的人负责，上面还是面向需求，百花齐放；但是随着需求的增多，这朵花太大了，而且很多花瓣都干死了（就是开发一段时间之后就没人用了），而且需求多大家都忙不过来了，很多简单的需求能不能实现让他们自己搞？这就迎来了第三阶段。
阶段3主要目标是使用建模工具代替人工开发，解决一些简单的需求，典中典就是自助查询工具了，搞个数据自助平台，他们需要什么自己去查，查不了再来找我们开发，极大地减轻开发负担，而且很多临时需求也好管理。同时，开发一些元数据管理工具，建模工具，方便开发时捋清各个表的关联关系以及数据流转过程，用于提高开发效率。
二、数据治理
1、数据开发流程治理
数据开发流程：需求分析->技术方案设计->数据开发->报表/接口开发
- 需求分析：产品设计一个需求PRD，列出指标维度矩阵，然后与需求相关人员进行沟通，做一些数据探查，看数仓的数据能不能满足该需求的实现。
- 技术方案的设计：完成需求分析后，形成设计数据模型，同时将方案落地到文档进行技术方案评审。
- 数据开发：技术方案评审通过之后，正式进入数据开发以及测试阶段。
- 报表开发：数据开发完成后，进入具体的应用开发，如看板、报表、接口。
整个数据开发流程需遵循：数据标准化、标准系统化、系统一体化。即数据符合标准规范，同时将标准规范落地到系统里，最后系统要和周边应用打通，形成一体。
- 数据标准化：数据产品团队、数据开发团队、数据分析团队联合建立数据标准化委员会，指定《指标标准规范》、《维度标准规范》以及一些新增指标、维度的流程等一系列规范标准，这样做的好处是：指标维度管理有据可依、保障各方指标维度口径清晰统一。
- 标准系统化：明确了数据标准的各项规范，要将这些规范落地到系统上，也就是数据治理平台（美团自研）。主要有四层：数据生产工具、集团基础平台、元数据层、数据服务层。
- 数据生产工具：离线生产平台、实时生产平台、调度管理平台（主要依靠平台计算能力）
- 集团基础平台：数据资产管理、元数据管理、数据质量管理、资源管理、权限管理
- 元数据层：数据模型、表&字段、主题&层级、指标&维度、业务过程、词根&词库
- 数据服务层：数据标准化过程，如指标流程、维度流程、认证管理都是在这里落地；同时把业务管理起来，保留业务大盘、业务过程、数据域管理；还要管理数据模型包括维度矩阵、事实逻辑模型、维度逻辑模型；同时提供元数据服务，包括业务元数据、技术元数据、以及维度服务；还有一些在线建模工具。
-
系统一体化：主要是针对下游对接，通过与各个下游不同形式的对接，数据治理平台完成了整个下游数据应用的联通，以及支持数据使用与生产，形成了一体化的系统。
- 报表平台：保证展示所需的指标维度信息、模型信息来自数据治理平台
- 数据超市：数据超市的自助取数里根据指标、维度、数据组件构建数据查询
- 异常分析平台：对指标维度的波动进行检测分析
- CRM系统：面向一线城市团队的数据展示、
- 算法平台：面向算法平台提供标签、特征数据的管理
- 画像平台：管理画像平台的人群标签
- 数据API服务：对外提供的API接口
- 公司元数据平台：向公司元数据平台提供元数据信息
2、资源优化
3、数据安全
三、OneData建设探索
OneData的核心思想：从设计、开发、部署和使用层面，避免重复建设和指标冗余建设，从而保障数据口径的规范和统一，最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。
如何统一？：统一归口、统一出口
- 统一业务归口：构建业务知识库，保障对业务认知的一致性（业务流转+数据流转）
- 统一设计归口：模型分层规范，设定各层数据流向（ODS-DWD-DWA-APP/ODS-DWD-APP/ODS-DWD-DWT-APP），主题划分（面向业务、面向分析），规范建设（词根、表命名、指标命名、）
-
面向业务：按照业务进行聚焦，降低对业务理解的难度，并能解耦复杂的业务。我们将实体关系模型进行变种处理为实体与业务过程模型。实体定义为业务过程的参与体；业务过程定义是由多个实体作用的结果，实体与业务过程都带有自己特有的属性。根据业务的聚合性，我们把业务进行拆分，形成了七大核心主题。
-
面向分析：按照分析聚焦，提升数据易用性，提高数据的共享与一致性。按照分析主体对象不同及分析特征，形成分析域主题在 DWA 进行应用，例如销售分析域、组织分析域。
-
- 统一应用归口：构建知识库，同个应用的多次迭代维护在同一文档
- 统一数据出口：
- 交付标准化，完善交付细节，从根本上保证数据质量，如业务测试保证数据合理性一致性、技术测试保证数据唯一性准确性、数据平台的稳定性和后期人工维护保证数据的及时性。
- 数据资产管理，针对如何解决数据质量中维度和指标一致性的问题，以及如何提高数据易用性的问题，提出了数据资产的概念，借助公司内部平台工具实现数据资产管理。实现：统指标管理、统一维度管理、统一数据出口
数仓全景图：
