原题：大数据仓库技术方案(文字) ) )。
来源：网络选集：感悟计划网https://www.518 doc.com/p-5216.html
大数据数据仓库建设方案
互联网行业不仅数据量大，而且对业务时效性要求高，大多要求实时。 另外，互联网行业的业务变化非常快，不能像传统行业那样以自上而下的方式构建数据仓库，要求一次将新业务整合到数据仓库中，过时的离线业务，是现有的数据仓库
整体体系结构：
数据仓库逻辑分层体系结构：
1 .数据源
数据源顾名思义就是数据的来源，互联网公司的数据源随着公司规模的扩大呈增长趋势，同时来自各种业务来源，如嵌入点收集、客户上报等。
2.ODS层
数据仓库源系统中的数据表通常称为操作数据(ODS )层，而ODS层通常称为准备区域。 它们是后续数据仓库层(即基于Kimball维建模生成的事实表和维表层以及基于这些事实表和明细表加工的聚集层的数据)
3.DW层
仓库详细级别(数据仓库详细信息，DWD )和数据仓库摘要级别(数据仓库摘要，DWS )是数据仓库的主题内容。 DWD层和DWS层的数据是ODS层通过ETL清洗、转换和加载生成的，通常基于Kimball维建模理论构建，维和数据总线的完整性确保了每个子主题的维的完整性。
4.DWS层
APP应用层聚集层主要在hadoop平台上聚集DWD和DWS详细数据，并将结果同步到DWS数据库并提供给每个APP应用。
数据收集：
数据收集的任务是从各种数据源收集数据并存储在数据存储中，在这期间可能会进行简单的清洗。
常见的是用户行为数据的收集，首先做好sdk的嵌入点，通过kafka实时收集用户的访问数据，在spark上进行简单的清洗，存储在hdfs中作为数据仓库的数据源之一
数据存储：
随着企业规模的扩大，生成的数据也在增加。 像大型企业一样，如果每天生成的数据量达到Pb，传统的数据库将无法满足存储要求。 目前，hdfs是大数据环境中数据仓库/数据平台的理想数据存储解决方案。
在离线计算(即实时性要求不高的部分)中，Hive是第一个选择，它是丰富的数据类型、嵌入式函数压缩率非常高的ORC/PARQUET文件存储格式； 借助非常有用的SQL支持，基于结构化数据的Hive统计分析比MapReduce高效得多。 一句SQL可能完成的需求可能需要数百行代码才能开发MR。 flink最适合用于实时计算，但目前仅支持java和scala开发。
数据同步：
数据同步是指在不同的数据存储系统之间迁移数据。 例如，hdfs无法直接从hdfs检索数据以提高业务和APP应用程序的效率，因此需要将hdfs数据集中到其他存储系统(如mysql )中。 sqoop可以做到这一点，但sqoop太重，所以无论数据量如何，都必须启动和运行MapReduce。 此外，所有需要Hadoop群集的计算机都必须能够访问业务数据库。 蚂蚁开源的dataX是一个好的解决方案。
维度建模
维度建模的基本概念
“维建模”(dimensionalmodeling )是一种专门用于分析数据库、数据仓库和数据集市建模的方法。 这里缠绕着两个基本名词：维度、事实。
1、维度
维度是维度建模的基础和灵魂，在维度建模中，以测量为事实，以环境为维度进行描述，维度是分析事实所需的多种环境。 例如，在分析交易的过程中，可以在买方、卖方、商品、时间等维度描述交易发生的环境。
2、事实
事实表作为数据仓库维度建模的核心，紧紧围绕业务流程进行设计。 通过获取描述业务流程的度量来表示业务流程，其中包括要引用的维和与业务流程相关的度量。 事实表中的一个记录所表现的业务细节称为粒度。 粒度通常可以用两种方法来表示。 一个是维度属性组合表示的细节程度。一个是表示具体业务的意义。
维度建模中使用的专业术语
1、数据域
面向业务分析，是指将业务流程的活动维度抽象化后的集合。 其中，业务过程可以归纳为一个个不可分割的行为事件，在业务过程中可以定义指标的维度是指购买者的订单事件等被测量的环境，购买者是维度。 为了保障整个系统的生命力，数据域需要抽象提取并长期维护更新，但不会轻易改变。 在划分数据域时，必须扩展新的数据域，包括现有数据，而不影响新业务进入时的所有业务需求。
2、业务流程
价值企业活动事件，以下单证、支付、退款都是业务过程。 业务流程是不可分割的行为事件。
3、时间周期
用于澄清数据统计的时间或时间点，如自然月、过去30天、自然周等。
4、修饰类型
是对抽象词的抽象划分。 修饰型依赖于某个数
据域，如日志域的访问终端涵盖无线端，PC端等修饰词。
5、修饰词
指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于某一个修饰类型。
6、度量/原子指标
基于某一业务事件行为下的度量，是业务定义中不可在分割的指标，具有明确的业务含义名词，如支付金额。
7、维度
上述已经做了介绍，不必重述
8、维度属性
维度属性隶属于某一个维度，如地理维度里面的国家名称，国建id，省份名称等。
9、事实
上述已经做了介绍，不必重述
10、派生指标
派生指标=一个原子指标+多个修饰词+时间周期。可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近一天海外买家支付金额为派生指标(最近一天为时间周期，海外为修饰词，买家为维度)。
11、钻取
钻取是改变维的层次，变换分析的粒度。它包括向上钻取(rollup)和向下钻取(drilldown)。rollup是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；是指自动生成汇总行的分析方法。通过向导的方式，用户可以定义分析因素的汇总行，例如对于各地区各年度的销售情况，可以生成地区与年度的合计行，也可以生成地区或者年度的合计行。
而drilldown则相反，它从汇总数据深入到细节数据进行观察或增加新维。例如，用户分析“各地区、城市的销售情况”时，可以对某一个城市的销售额细分为各个年度的销售额，对某一年度的销售额，可以继续细分为各个季度的销售额。通过钻取的功能，使用户对数据能更深入了解，更容易发现问题，做出正确的决策。
维度建模的三种模式
1、星形模式
星形模式(StarSchema)是最常用的维度建模方式，可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a.维表只和事实表关联，维表之间没有关联；
b.每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
c.以事实表为核心，维表围绕核心呈星形分布；
2、雪花模式
雪花模式(SnowflakeSchema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
3、星座模式
星座模式(FactConstellationsSchema)也是星型模式的扩展。基于这种思想就有了星座模式：
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
4、三种模式对比
雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。
维度表设计
维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成维度属性的优劣，决定了维度是用的方便性，成为数据仓库易用性的关键。数据仓库的能力直接与维度属性的质量和深度成正比。
维度表基本设计方法
以商品维度为例对维度设计放发进行详细说明。
第一步：选择维度或者新建维度。作为维度建模的核心，在企业级数据仓库中，必须保证维度的唯一性。以商品维度为例，有且只有一个维度定义。
第二步：确定主维表。此处的主维表一般是ODS表，直接与业务系统同步。
第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性，根据业务系统的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据业务逻辑的梳理，可以得到商品与类目、sku、买家、卖家、店铺等维度存在的关联关系。
第四步：确定维度属性。本步骤主要包括两个阶段，其中一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或者生成新的维度属性。以商品维度为例，从主维表和类目、sku、卖家、店铺等相关维表中选择维度属性或者生成新的维度属性。
确定维度属性的几点提示：
a、尽可能生成丰富的维度属性；
b、尽可能多的给出包括一些富有意义的文字描述；
c、区分数值型属性和事实；
d、尽可能沉淀出通用的维度属性。
规范化的商品维度表现形式：
该模式属于雪花模式。
注意：采用雪花模式，用户在统计分析的过程中需要大量的关联操作，是用复杂度高，同时查询性能很差，如果数据量巨大，那就更差了；因此需要将维度的属性层次合并到单个维度中，该操作称之为反规范化，采用反规范化处理，方便，易用且性能好。
对于商品维度，如果采用反规范化，将表现为：
采用雪花模式，除了可以节约一部分存储之外，对于OLAP系统来说没有其他的效用。而现阶段存储的成本非常低。出于易用性和性能的考虑，维表一般设计成不规范化的。在实际应用中，几乎总是使用维表的空间来换取简明性和查询性能。
缓慢变化维
数据仓库的特征之一就是反应历史变化，所以如何处理维度的变化是设计的工作之一。缓慢变化维的提出是因为在现实世界中，维度的属性不是静态的，它会随着时间的流逝缓慢的变化，与数据增长较快的事实表相比，维度变化相对缓慢。
以下介绍几种处理这种情况的三种方式：
第一种方式：重写维度值。采用此种方式，不保留历史数据(简单来说就是更新相关的维度字段)。比如商品所属类目与2019年5月20日由类目1变成类目2，采用第一种处理方式。
第二种方式：插入新的维度行。采用此种方式，保留历史数据，维度值变化前后的事实和过去的维度关联，纬度值变化前后的事实和当前的维度值关联。同上面的例子采用第二种方式。
第三种方式：添加维度列。采用第二种方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。比如根据业务需求，需要将5月份的交易金额全部统计到类目2上，采用第二种方式无法实现。针对此问题，采用第三种处理方式，保留历史数据，可以使用任何一个属性列。同上面的例子，采用第三种方式。对于采用哪种方式解决缓慢变化维，只能根据业务需求去选择。
事实表设计
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和业务过程有关的度量。相对维表来说，事实表要细长的多，行的增加速度也比维表快很多。事实表分为三种类型：事务事实表，周期快照事实表，累计快照事实表。
1、事务事实表
用来描述业务过程，跟踪时间或者空间上某点的度量事件，保存的是最原子的数据，也成为“原子事实表”。
2、周期快照事实表
以具有规律的，可预见的时间间隔记录事实如每天、每月、每年等。
3、累计快照事实表
用来表述开始和结束之间的关键步骤事件，覆盖整个生命周期，通常具有多个时间字段来记录关键时间点，当过程随着时间变化时，记录也会跟着修改。
本文主要讨论事务事实表，其他的两种会在以后的文章中说明。
事实表设计原则
a、尽可能包括所有业务过程相关的事实
b、只选择与业务过程相关的事实
c、分解不可加事实为可加的组件
d、选择维度和事实之前必须先声明粒度
e、在同一个事实表中不可以有多重不同粒度的事实
f、事实的单位要保持一致
g、对事实的null值要处理
h、使用退化维提高事实表的易用性
事务事实表的基本设计方法
任何类型的事件都可以被理解成一种事务。比如交易过程中的创建订单，买家付款，物流中的发货，签收，付款等。事务事实表针对这些过程创建的一种事实表。下面店铺交易事务为例，阐述事务事实表的一般设计过程。
1、选择业务过程
交易的过程分为：创建订单、买家付款、卖家发货、买家确认收货，即下单、支付、发货和成功完结四个业务过程。
Kimball维度建模理论认为，为了便于进行独立的分析研究，应该为每一个业务过程建立一个事实表。
2、确定粒度
业务过程选定之后，就要对每个业务过程确定一个粒度，即确定事实表每一行所表达的细节层次。需要为四个业务过程确定粒度，其中下单、支付和成功完结选择交易子订单粒度，即每个子订单为事实表的一行，买家收货的粒度为物流单。
3、确定维度
选定好业务过程并且确定粒度后，就可以确定维度信息了。在店铺交易事实表设计过程中，按照经常用于统计分析的场景，确定维度包含：买家、卖家、商品、商品类目、发货地区、收货地址、父订单维度以及杂项维度。
4、确定事实
作为过程度量的核心，事实表应该包含与其描述过程有关的所有事实。以店铺交易事实表为例，选定三个业务过程:下单、支付、成功完结，不同的业务过程有不同的事实。比如在下单业务过程中，需要包含下单金额、下单数量、下单分摊金额；
在确定维度时，包含了买卖家维度，商品维度，类目维度，收发货等。Kimball维度建模理论建议在事实表中只保留这个维度表的外键，但是在实际的应用中，可以将店铺名称、商品类型、商品属性、类目属性冗余到事实表中，提高对事实表的过滤查询，减少表之间的关联次数，加快查询速度，该操作称之为退化维。
经过以上的操作，基本完成了店铺交易事务事实表的设计工作。
元数据管理
元数据通常定义为”关于数据的数据”,在数据仓库中是定义和描述DW/BI系统的结构，操作和内容的所有信息。元数据贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。
按照不同的用途将元数据分为两类：技术元数据和业务元数据。
技术元数据指描述系统中技术细节相关的概念、关系和规则的数据，包括对数据结构、数据处理方面的描述，以及数据仓库、ETL、前端展现等技术细节方面的信息。常见的技术元数据有：
1、分布式计算存储元数据，如表、列、分区等信息。记录表的表名、分区信息、责任人信息、文件大小、表类型、生命周期、列的字段、字段类型、字段备注等。
2、分布式计算系统运行元数据，集群上所有任务的运行信息；类似hive的运行日志，包括作业类型、实例名称、输入输出、运行参数、运行时间等。
3、调度任务中的调度信息，包括输入输出字段、依赖类型、依赖关系等。
4、数据质量跟运维相关元数据，如任务监控、运维报警、数据质量、故障等。
业务元数据指从业务角度描述业务领域相关的概念、关系和规则的数据，包括业务术语和业务规则等信息。常用的技术元数据有：
如维度和属性、业务过程、指标等规范化定义，用于更好的管理和使用数据。
数据应用元数据，数据报表、数据产品等配置和运行元数据。
注意：
关于元数据的建设这块想要做好，非常复杂，我觉得目前对我们公司来说是价值小于成本，因此我们暂不考虑这块。
任务调度与监控
在数据仓库建设中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据清洗任务、数据分析任务等；这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；这就需要一个非常完善的任务调度与监控系统，它作为数据仓库的中枢，负责调度和监控所有任务的分配与运行。
具体采用哪种工具，请根据自己公司的本身现状去做定夺。
综上所述，数据仓库建设是一个综合性技术。若企业的业务复杂，更是需要专门团队与业务方共同合作来完成。因此，一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。此外，架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好返回搜狐，查看更多
责任编辑：