离线数仓项目, 数仓理论(概要, 建模方法, 数仓分层, 模型介绍,元数据), 数仓设计(需求分析, 数据埋点, 指标体系, 架构设计(方案选型,逻辑架构, 物理环境, 命名规范))

1991年Bill Inmon（比尔·恩门）出版了他的第一本关于数据仓库的书《Building the Data Warehouse》，标志着数据仓库概念的确立。书中指出，数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合，用于支持管理决策(Decision-Making Support)。该书还提供了建立数据仓库的指导意见和基本原则。凭借着这本书，Bill Inmon被称为数据仓库之父。

1.2 数据仓库四大特征

面向主题的
集成的
稳定的
反映历史变化的

面向主题的
与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。

什么是主题呢？

主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象
在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象

面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整、一致的描述，能完整、统一地刻划各个分析对象所涉及的企业的各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进
行数据组织的方式具有更高的数据抽象级别。

例如销售情况分析就是一个分析领域，那么数据仓库的分析主题可以是“销售分析”。

集成的

数据仓库的数据是从原有的分散的多个数据库、数据文件、用户日志中抽取来的，数据来源可能既有内部数据又有外部数据。操作型数据与分析型数据之间差别很大：

数据仓库的每一个主题所对应的源数据，在原有的各分散数据库中有重复和不一致的地方，且来源于不同的联机系统的数据与不同的应用逻辑捆绑在一起
数据仓库中的数据很难从原有数据库系统直接得到。数据在进入数据仓库之前，需要经过统一与综合

数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，数据仓库中的数据会从多个数据源中获取，这些数据源包括多种类型数据库、文件系统以及Internet网上数据等，它们通过数据集成而形成数据仓库中的数据。

稳定的

数据仓库数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。

数据稳定主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。

反映历史变化的

数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。虽然数据仓库不会修改数据，但并不是说数据仓库的数据是永远不变的。数据仓库的数据也需要更新，以适应决策的需要。

数据仓库的数据随时间的变化表现在以下几个方面：

数据仓库的数据时限一般要远远长于操作型数据的数据时限
业务系统存储的是当前数据，而数据仓库中的数据是历史数据
数据仓库中的数据是按照时间顺序追加的，都带有时间属性

1.3 数据仓库作用

整合企业业务数据，建立统一的数据中心；
产生业务报表，了解企业的经营状况；
为企业运营、决策提供数据支持；
可以作为各个业务的数据源，形成业务数据互相反馈的良性循环；
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；
开发数据产品，直接或间接地为企业盈利；

1.4 数据仓库与数据库的区别

数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。

OLTP（On-Line Transaction Processing 联机事务处理），也称面向交易的处理系统。主要针对具体业务在数据库系统的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。

OLAP（On-Line Analytical Processing 联机分析处理），一般针对某些主题的历史数据进行分析，支持管理决策。

数据仓库的出现，并不是要取代数据库：

数据仓库主要用于解决企业级的数据分析问题或者说管理和决策
数据仓库是为分析数据而设计，数据库是为捕获和存储数据而设计
数据仓库是面向分析，面向主题设计的，即信息是按主题进行组织的，属于分析型；数据库是面向事务设计的，属于操作型
数据仓库在设计是有意引入数据冗余（目的是为了提高查询的效率），采用反范式的方式来设计；数据库设计是尽量避免冗余（第三范式），一般采用符合范式的规则来设计
数据仓库较大，数据仓库中的数据来源于多个异构的数据源，而且保留了企业的历史数据；数据库存储有限期限、单一领域的业务数据

数据仓库的出现，并不是要取代数据库：

数据库是面向事务的设计，数据仓库是面向主题设计的
数据库存储有限期限的业务数据，数据仓库存储的是企业历史数据
数据库设计尽量避免冗余，数据存储设计满足第三范式，但是便于进行数据分析。数据仓库在设计时有意引入冗余，依照分析需求，分析维度、分析指标进行设计
数据库是为捕获数据而设计，数据仓库是为分析数据而设计

以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记账。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存取款多，消费交易多，那么该地区就有必要设立ATM了。

银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的大型数据库。

1.5 数据集市

数据仓库（DW）是一种反映主题的全局性数据组织。但全局性数据仓库往往太大，在实际应用中将它们按部门或业务分别建立反映各个子主题的局部性数据组织，即数据集市（Data Mart），有时也称它为部门数据仓库。

数据集市：是按照主题域组织的数据集合，用于支持部门级的数据分析与决策。如在商品销售的数据仓库中可以建立多个不同主题的数据集市：

商品采购数据集市
商品库存数据集市
商品销售数据集市

数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足企业内部部分业务部门的迫切需求，在初期获得了较大成功。但随着数据集市的不断增多，这种架构的缺陷也逐步显现。企业内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致，形成众多的数据孤岛

企业发展到一定阶段，出现多个事业部，每个事业部都有各自数据，事业部之间的数据往往都各自存储，各自定义。每个事业部的数据就像一个个孤岛一样无法(或者极其困难)和企业内部的其他数据进行连接互动。这样的情况称为数据孤岛，简单说就是数据间缺乏关联性，彼此无法兼容。

第2节数据仓库建模方法

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。有了适合业务和基础数据存储环境的模型，能获得以下好处：

性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐
成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本
效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率
质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性

大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

2.1 ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计一个3NF模型，用实体关系(Entity Relationship, ER)模型描述企业业务，在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF 的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点：

需要全面了解整个企业业务和数据
实施周期非常长
对建模人员的能力要求非常高

釆用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。其建模步骤分为三个阶段：

高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况
中层模型：在高层模型的基础上，细化主题的数据项
物理模型(也叫底层模型)：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等

2.2 维度模型

维度模型是数据仓库领域的Ralph Kimball大师所倡导的，他的《数据仓库工具箱》是数据仓库工程领域最流行的数据仓库建模经典。

维度建模从分析决策的需求出发构建模型，为分析需求服务，重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星型模型，以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤：

选择需要进行分析决策的业务过程。业务过程可以是：

单个业务事件，比如交易的支付、退款等
某个事件的状态，比如当前的账户余额等
一系列相关业务事件组成的业务流程

选择数据的粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度

识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选

选择事实。确定分析需要衡量的指标

现代企业业务变化快、人员流动频繁、业务知识功底的不够全面，导致ER模型设计产出周期长。大多数企业实施数据仓库的经验说明：在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。而维度建模对技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能。

第3节数据仓库分层(重点难点)

数据仓库更多代表的是一种对数据的管理和使用的方式，它是一整套包括了数据建模、ETL（数据抽取、转换、加载）、作用调度等在内的完整的理论体系流程。数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。

分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控。详细来讲，主要有下面几个原因：

清晰的数据结构: 每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。
将复杂的问题简单化: 将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的问题，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的地方开始修复。
减少重复开发: 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
屏蔽原始数据的异常: 屏蔽业务的影响，不必改一次业务就需要重新接入数据。
数据血缘的追踪: 最终给业务呈现的是一个能直接使用业务表，但是它的来源很多，如果有一张来源表出问题了，借助血缘最终能够快速准确地定位到问题，并清楚它的危害范围。

数仓的常见分层一般为3层，分别为：数据操作层、数据仓库层和应用数据层（数据集市层）。当然根据研发人员经验或者业务，可以分为更多不同的层，只要能达到流程清晰、方便查数即可。

ODS（Operation Data Store 数据准备区）

数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，也称为准备区。它们是后续数据仓库层加工数据的来源。ODS层数据的主要来源包括：

业务数据库。可使用DataX、Sqoop等工具来抽取，每天定时抽取一次；在实时应用中，可用Canal监听MySQL的 Binlog，实时接入变更的数据；
埋点日志。线上系统会打入各种日志，这些日志一般以文件的形式保存，可以用 Flume 定时抽取；
其他数据源。从第三方购买的数据、或是网络爬虫抓取的数据；

DW（Data Warehouse 数据仓库层）

包含DWD、DWS、DIM层，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

DWD（Data Warehouse Detail 细节数据层），是业务层与数据仓库的隔离层。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，也即宽表化处理；
DWS（Data Warehouse Service 服务数据层），基于DWD的基础数据，整合汇总成分析某一个主题域的服务数据。以分析的主题为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表；
公共维度层（DIM）：基于维度建模理念思想，建立一致性维度；
TMP层：临时层，存放计算过程中临时产生的数据；

ADS（Application Data Store 应用数据层）

基于DW数据，整合汇总成主题域的服务数据，用于提供后续的业务查询等。

数据仓库层次的划分不是固定不变的，可以根据实际需求进行适当裁剪或者是添加。如果业务相对简单和独立，可以将DWD、DWS进行合并。

第4节数据仓库模型

4.1 事实表与维度表

在数据仓库中，保存度量值的详细值或事实的表称为事实表。

事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据。事实表的粒度决定了数据仓库中数据的详细程度。

常见事实表：订单事实表

事实表的特点：表多（各种各样的事实表）；数据量大

事实表根据数据的粒度可以分为：事务事实表、周期快照事实表、累计快照事实表

维度表（维表）可以看作是用来分析数据的角度，纬度表中包含事实数据表中事实记录的特性。有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。

常见维度表：时间维度、地域维度、商品维度

小结：

事实表是关注的内容（如：销售额、销售量）
维表是观察事务的角度

4.2 事实表分类

1、事务事实表

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。用户可以通过事务事实表对事务行为进行特别详细的分析。

如：订单表

通过事务事实表，还可以建立聚集事实表，为用户提供高性能的分析。

2、周期快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。它统计的是间隔周期内的度量统计，如历史至今、自然年至今、季度至今等等。

周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。周期快照事实表的维度个数比事务事实表要少，但是记录的事实要比事务事实表多。

如：商家日销售表（无论当天是否有销售发生，都记录一行）日期、商家名称、销售量、销售额

3、累积快照事实表

累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

如：订货日期、预定交货日期、实际发货日期、实际交货日期、数量、金额、运费
如：商家本周、本月、本年累计销售表

4.3 星型模型

星型模是一种多维的数据关系，它由一个事实表和一组维表组成；
事实表在中心，周围围绕地连接着维表；
事实表中包含了大量数据，没有数据冗余；
维表是逆规范化的，包含一定的数据冗余；

4.4 雪花模型

雪花模式是星型模型的变种，维表是规范化的，模型类似雪花的形状；
特点：雪花型结构去除了数据冗余。
星型模型存在数据冗余，所以在查询统计时只需要做少量的表连接，查询效率高；
星型模型不考虑维表正规化的因素，设计、实现容易；
在数据冗余可接受的情况下，实际上使用星型模型比较多；

4.5 事实星座

数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。
特点：公用维表

第5节元数据

元数据（Metadata）是关于数据的数据。元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。元数据就相当于所有数据的地图，有了这张地图就能知道数据仓库中：

有哪些数据
数据的分布情况
数据类型
数据之间有什么关系
哪些数据经常被使用，哪些数据很少有人光顾

在大数据平台中，元数据贯穿大数据平台数据流动的全过程，主要包括数据源元数据、数据加工处理过程元数据、数据主题库专题库元数据、服务层元数据、应用层元数据等。

业内通常把元数据分为以下类型：

技术元数据：库表结构、数据模型、ETL程序、SQL程序等
业务元数据：业务指标、业务代码、业务术语等
管理元数据：数据所有者、数据质量、数据安全等

第二部分电商离线数仓设计

第1节需求分析

近年来，中国的电子商务快速发展，交易额连创新高，电子商务在各领域的应用不断拓展和深化、相关服务业蓬勃发展、支撑体系不断健全完善、创新的动力和能力不断增强。电子商务正在与实体经济深度融合，进入规模性发展阶段，对经济社会生活的影响不断增大，正成为我国经济发展的新引擎。

中国电子商务研究中心数据显示，截止到 2012 年底，中国电子商务市场交易规模达7.85万亿人民币，同比增长 30.83%。其中，B2B 电子商务交易额达 6.25 万亿，同比增长 27%。而 2011 年全年，中国电子商务市场交易额达 6 万亿人民币，同比增长 33%，占 GDP 比重上升到 13%；2012 年，电子商务占 GDP 的比重已经高达15%。

电商行业技术特点

技术新
技术范围广
分布式
高并发、集群、负载均衡
海量数据
业务复杂
系统安全

电商业务简介

类似X东商城、X猫商城。电商网站采用商家入驻的模式，商家入驻平台提交申请，有平台进行资质审核，审核通过后，商家拥有独立的管理后台录入商品信息。商品经过平台审核后即可发布。网上商城主要分为：

网站前台。网站首页、商家首页、商品详细页、搜索页、会员中心、订单与支付相关页面、秒杀频道等；
运营商后台。运营人员的管理平台，主要功能包括：商家审核、品牌管理、规格管理、模板管理、商品分类管理、商品审核、广告类型管理、广告管理、订单查询、商家结算等；
商家管理后台。入驻的商家进行管理的平台，主要功能包括：商品管理、订单查询统计、资金结算等功能；

数据仓库项目主要分析以下数据：

日志数据：启动日志、点击日志（广告点击日志）
业务数据库的交易数据：用户下单、提交订单、支付、退款等核心交易数据的分析

数据仓库项目分析任务：

会员活跃度分析主题: 每日新增会员数；每日、周、月活跃会员数；留存会员数、留存会员率
广告业务分析主题: 广告点击次数、广告点击购买率、广告曝光次数
核心交易分析主题: 订单数、成交商品数、支付金额

第2节数据埋点

数据埋点，将用户的浏览、点击事件采集上报的一套数据采集的方法。

通过这套方法，能够记录到用户在App、网页的一些行为，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑，包括访问数、访客数、停留时长、浏览数、跳出率。这样的信息收集可以大致分为两种：页面统计、统计操作行为。

在企业经营中，数据分析辅助决策是非常重要的一环，而埋点采集用户行为数据的工作则是基础中的基础。如果没有用户行为数据，经营分析将无从说起。埋点为数据分析提供基础数据，埋点工作流程可分为：

根据埋点需求完成开发（前端开发工程师 js）
App或网页采用用户数据
数据上报服务器
数据的清洗、加工、存储（大数据工程师）
进行数据分析等到相应的指标（大数据工程师）

在以上过程中，涉及的相关人员可分以下几类：

埋点需求：数据产品经理，负责撰写需求文档，规定哪些区域、用户操作需要埋点
埋点采集：前端工程师，负责通过一套前端 js 代码对用户的请求事件上送至服务器
数据清洗、加工及存储：对埋点中数据缺失、误报等情况需要进行清洗，并通过一定的计算加工，输出业务分析所需要的结构化数据，最后将数据存储在数据仓库中
数据分析：在数据仓库中对数据进行整理，成业务关注的指标
前端展示：Java 开发

主流的埋点实现方法如下，主要区别是前端开发的工作量：

手动埋点

开发需要手动写代码实现埋点，比如页面ID、区域ID、按钮ID、按钮位置、事件类型（曝光、浏览、点击）等，一般需要公司自主研发的一套埋点框架

优点：埋点数据更加精准
缺点：工作量大，容易出错

无痕埋点

不用开发写代码实现的，自动将设备号、浏览器型号、设备类型等数据采集。主要使用第三方统计工具，如友盟、百度移动、魔方等

优点：简单便捷
缺点：埋点数据统一，不够个性化和精准

日志举例

启动日志：

{
	"app_active": {
		"name": "app_active",
		"json": {
			"entry": "3",
			"action": "0",
			"error_code": "0"
		},
		"time": 1593553936325
	},
	"attr": {
		"area": "葫芦岛",
		"uid": "2F10092A192",
		"app_v": "1.1.12",
		"event_type": "common",
		"device_id": "1FB872-9A100192",
		"os_type": "0.7.0",
		"channel": "MA",
		"language": "chinese",
		"brand": "Huawei-4"
	}
}

事件日志（广告点击、收藏、点赞、消息通知、商品评论、商品详情页加载等事件）：

{
	"lagou_event": [{
		"name": "goods_detail_loading",
		"json": {
			"entry": "2",
			"goodsid": "0",
			"loading_time": "71",
			"action": "3",
			"staytime": "119",
			"showtype": "5"
		},
		"time": 1594804466872
	}, {
		"name": "notification",
		"json": {
			"action": "3",
			"type": "4"
		},
		"time": 1594775458428
	}, {
		"name": "ad",
		"json": {
			"duration": "19",
			"ad_action": "0",
			"shop_id": "46",
			"event_type": "ad",
			"ad_type": "2",
			"show_style": "1",
			"product_id": "9022",
			"place": "placeindex_right",
			"sort": "4"
		},
		"time": 1594779518872
	}, {
		"name": "favorites",
		"json": {
			"course_id": 2,
			"id": 0,
			"userid": 0
		},
		"time": 1594812897271
	}],
	"attr": {
		"area": "清远",
		"uid": "2F10092A77",
		"app_v": "1.1.7",
		"event_type": "common",
		"device_id": "1FB872-9A10077",
		"os_type": "0.8.4",
		"channel": "PQ",
		"language": "chinese",
		"brand": "iphone-2"
	}
}

第3节数据指标体系

指标：对数据的统计值。如：会员数、活跃会员数、会员留存数；广告点击量；订单金额、订单数都是指标；

指标体系：将各种指标系统的组织起来，按照业务模型、标准对指标进行分类和分层；

没有数据指标体系的团队内数据需求经常表现为需求膨胀以及非常多的需求变更。每个人都有看数据的视角和诉求，然后以非专业的方式创造维度/指标的数据口径。数据分析人员被海量的数据需求缠住，很难抽离出业务规则设计好的解决方案，最
终滚雪球似的搭建难以维护的数据仓库。

建立指标体系实际上是与需求方达成一致。能有效遏制不靠谱的需求，让需求变得有条例和体系化；
指标体系是知道数据仓库建设的基石。稳定而且体系化的需求，有利于数据仓库方案的优化，和效率提升；

由产品经理牵头、与业务、IT方协助，制定的一套能从维度反应业务状况的一套待实施框架。在建立指标体系时，要注重三个选取原则：准确、可解释、结构性。

准确：核心数据一定要理解到位和准确，不能选错；
可解释：所有指标都要配上明确、详细的业务解释。如日活的定义是什么，是使用了App、还是在App中停留了一段时间、或是收藏或购买购买了商品；
结构性：能够充分对业务进行解读。如新增用户只是一个大数，还需要知道每个渠道的新增用户，每个渠道的新增转化率，每个渠道的新增用户价值等。

在建立指标体系之前，先了解一下指标的构成，在工作过程中遇见的指标多为派生性指标。指标的构成如下所示：

基础指标 + [ 修饰词 ] + 时间段
修饰词是可选的；基础指标和时间段是必须的
基础指标是不可拆分的指标，如：交易额、支付金额、下单数
修饰词多是某种场景的表现，如：通过搜索带来的交易等
时间段即为一个时间周期，如：双十一期间，618活动期间等

三者叠加在一起就形成业务上常用的指标（这些指标也是派生指标），如：双11这一天通过搜索带来的交易额、双11这一天的交易额。同样，像此类日活、月活、次
日留存、日转化率等都属于派生指标。

在筛选完合理指标后，就要着手建立对应的指标体系。主要分为四个步骤：理清业务阶段和需求、确定核心指标、对指标进行维度的拆解、指标的落地；

1、厘清业务阶段及需求

企业的发展往往分为三个阶段：创业期、上升期、成熟发展期，不同的阶段关注的核心指标也是不同的。

业务前期，最关注用户量，此时的指标体系应该紧密围绕用户量的提升来做各种维度的拆解
业务中期，除了关注用户量的走势大小，更加重要的是优化当前的用户量结构，比如看用户留存，如果留存偏低，那就需要进一步分析查找原因
成熟发展期，更多关注的就是产品变现能力和市场份额，要关注收入指标、各种商业化模式的的收入，同时做好市场份额和竞品的监控，以防止新起势力抢占份额等

2、确定核心指标

这个阶段最重要的是找到正确的核心指标。

例：某款产品的日活口径是打开APP，而且日活量不小，而且稳定上升。然而分析时发现，打开APP的用户中，5秒跳出率高达25%，这是非常不健康的，那么当前的核心指标日活实际上已经有了问题，更加好的核心指标应该是停留时长大于5秒的用户数。

每个APP的核心指标都不太一样，一定要花时间去考虑这件事。就像XX头条APP，它的日活和留存指标一定非常高，但仅关注这种指标肯定是不对的，它的真正核心指标绝对不是单纯的日活和留存。

3、核心指标维度拆解

核心指标的波动必然是某种维度的波动引起，要监控核心指标，本质上还是要监控维度核心指标。

在分析“进入APP用户数”指标时，要关注渠道转化率，分析用户从哪里来；同时用户通过哪种方式打开的，如通过点击桌面图标、点击通知栏、点击Push等；

在分析“停留时长大于5秒占比”指标时，要重点关注停留时长的分布，停留1秒 -- 5秒的用户各有多少，具体分布情况；停留大于5秒的用户特征和行为特性是怎么样的情况；停留小于5秒的用户特征等；

电商平台注重交易额，在真正达成交易之前，用户要打开APP、选择商品、确认订单、支付订单等整个交流漏斗模型。每一个环节的关键指标都可以通过公式的形式进行拆解，在根据拆解公式逐个分析对应的影响因素。

4、指标宣贯、存档、落地

在完成整个指标体系搭建后，要告知所有相关业务人员。一方面为下一步工作做铺垫，另一方面是为了让所有相关人员知晓已完成，以防甩锅；

对指标口径的业务逻辑进行详细的描述并存档，只有明确、清晰的定义才能明白指标的具体含义；

就是建立核心指标的相关报表，实际工作中，报表会在埋点前建好的，这样的话一旦版本上线就能立刻看到数据，而且也比较容易发现问题。

整个指标体系的搭建主要是由产品经理主导完成的，业务人员需要配合产品经理选择并确认指标，这也是在建立之初最重要的一点。

第4节总体架构设计

4.1、技术方案选型

框架选型
软件选型
服务器选型
集群规模的估算

4.1.1 框架选型

Apache / 第三方发行版（CDH / HDP / Fusion Insight）

Apache社区版本

优点：

完全开源免费
社区活跃
文档、资料详实

缺点：

复杂的版本管理
复杂的集群安装
复杂的集群运维
复杂的生态环境

第三方发行版本（CDH / HDP / Fusion Insight）

Hadoop遵从Apache开源协议，用户可以免费地任意使用和修改Hadoop。正因如此，市面上有很多厂家在Apache Hadoop的基础上开发自己的产品。如Cloudera的CDH，Hortonworks的HDP，华为的Fusion Insight等。

优点是：

主要功能与社区版一致
版本管理清晰。比如Cloudera，CDH1，CDH2，CDH3，CDH4等，后面加上补丁版本，如CDH4.1.0 patch level 923.142
比 Apache Hadoop 在兼容性、安全性、稳定性上有增强。第三方发行版通常都经过了大量的测试验证，有众多部署实例，大量的运用到各种生产环境
版本更新快。如CDH每个季度会有一个update，每一年会有一个release
基于稳定版本Apache Hadoop，并应用了最新Bug修复或Feature的patch
提供了部署、安装、配置工具，大大提高了集群部署的效率，可以在几个小时内部署好集群
运维简单。提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确，使运维工作简单，有效

CDH：最成型的发行版本，拥有最多的部署案例。提供强大的部署、管理和监控工具。国内使用最多的版本；拥有强大的社区支持，当遇到问题时，能够通过社区、论坛等网络资源快速获取解决方法；

HDP：100%开源，可以进行二次开发，但没有CDH稳定。国内使用相对较少；

Fusion Insight：华为基于hadoop2.7.2版开发的，坚持分层，解耦，开放的原则，得益于高可靠性，在全国各地政府、运营商、金融系统有较多案例。

4.1.2 软件选型

数据采集：DataX、Flume、Sqoop、Logstash、Kafka
数据存储：HDFS、HBase
数据计算：Hive、MapReduce、Tez、Spark、Flink
调度系统：Airflow、azkaban、Oozie
元数据管理：Atlas
数据质量管理：Griffin
即席查询(快速)：Impala、Kylin、ClickHouse、Presto、Druid

其他：MySQL

框架、软件尽量不要选择最新的版本，选择半年前左右稳定的版本。

4.1.3 服务器选型

选择物理机还是云主机

机器成本考虑：物理机的价格 > 云主机的价格
运维成本考虑：物理机需要有专业的运维人员；云主机的运维工作由供应商完成，运维相对容易，成本相对较低；

4.1.4 集群规模规划

如何确认集群规模（假设：每台服务器20T硬盘，128G内存）

可以从计算能力(CPU、内存)、等方面着手考虑集群规模。

假设：

1、每天的日活用户500万，平均每人每天有100条日志信息
2、每条日志大小1K左右
3、不考虑历史数据，半年集群不扩容
4、数据3个副本
5、离线数据仓库应用

需要多大集群规模？

要分析的数据有两部分：日志数据+业务数据

每天日志数据量：500W * 100 * 1K / 1024 / 1024 = 500G

半年需要的存储量：500G * 3 * 180 / 1024 = 260T

通常要给磁盘预留20-30%的空间（这里取25%）： 260 * 1.25 = 325T

数据仓库应用有1-2倍的数据膨胀,因为数据分层（这里取1.5）：500T

需要大约25个节点

其他未考虑因素：数据压缩、业务数据

以上估算的生产环境。实际上除了生产环境以外，还需要开发测试环境，这也需要一定数据的机器。

4.2、系统逻辑架构

nginx集群, JtoE业务服务器, 数据库, 数据采集DataX , ODS,

nginx集群, 日志服务器, 数据采集FLUME集群, 汇总FLUME, HDFS, ODS,

Impala做即席查询

4.3、开发物理环境

5台物理机；500G数据盘；32G内存；8个core

关于数据集的说明：

1、在开发过程中使用小规模数据集

2、模块测试使用真实的数据集（数据量大）

3、在做项目期间根据自己实际情况使用不同的数据量（建议使用小规模的数据集）

4.4、数据仓库命名规范

1 数据库命名
     命名规则：数仓对应分层
     命名示例：ods / dwd / dws/ dim / temp / ads

2 数仓各层对应数据库
     ods层 -> ods_{业务线|业务项目}
     dw层 -> dwd_{业务线|业务项目} + dws_{业务线|业务项目}
     dim层 -> dim_维表
     ads层 -> ads_{业务线|业务项目} (统计指标等)
     临时数据 -> temp_{业务线|业务项目}
     备注：本项目未采用

3 表命名（数据库表命名规则）
     * ODS层：
     命名规则：ods_{业务线|业务项目}_[数据来源类型]_{业务}
     * DWD层：
     命名规则：dwd_{业务线|业务项目}_{主题域}_{子业务}
 
     * DWS层：
     命名规则：dws_{业务线|业务项目}_{主题域}_{汇总相关粒度}_{汇总时间周期}
   
     * ADS层：
     命名规则：ads_{业务线|业务项目}_{统计业务}_{报表form|热门排序topN}
     * DIM层：
     命名规则：dim_{业务线|业务项目|pub公共}_{维度}

创建数据库：

create database if not exists ods;
create database if not exists dwd;
create database if not exists dws;
create database if not exists ads;
create database if not exists dim;
create database if not exists tmp;

javastart

关注

5
点赞
踩
70

收藏

觉得还不错? 一键收藏
0
评论
离线数仓项目, 数仓理论(概要, 建模方法, 数仓分层, 模型介绍,元数据), 数仓设计(需求分析, 数据埋点, 指标体系, 架构设计(方案选型,逻辑架构, 物理环境, 命名规范))

离线数仓项目, 数仓理论(概要, 建模方法, 数仓分层, 模型介绍,元数据), 数仓设计(需求分析, 数据埋点, 指标体系, 架构设计(方案选型,逻辑架构, 物理环境, 命名规范
复制链接

扫一扫