之前做过一个大数据离线数仓项目，然后写下了一篇总结????大数据实战【千亿级数仓】项目总结。那一篇博客主要针对方向是项目本身，那如果我们把眼光放远，讨论的方向放到数仓设计上面，那该如何总结呢？
不用担心，本篇博客将告诉你答案！
文章目录
① 构建数据仓库的基础 (前提)
稳定：数据的生产稳定、有保障；
数据仓库底层有三个系统（a\b\c）
保证ABC能够稳定生产数据。
高质量：数据质量要足够高；
尽量保证数据是高质量的。在确定100%没有意义的数据的情况下，将数据剔除掉。
覆盖广：数据涵盖的业务面要尽可能多；
以解决业务问题为目标：企业需要提供解决业务问题所需要的所有数据。【理想情况下】
实际上企业内：已有数据能够解决哪些问题就优先解决哪些问题。能支撑是什么业务就做着什么业务。
透明：数据的构成流程要透明，用户使用放心。
② 基于大数据平台构建数仓
为什么基于大数据平台构建数据仓库？[数仓与大数据的结合点]
- 存储计算能力强，分布式存储，存储空间大，使空间换时间成为可能，使扁平化数据处理流程成为可能（简化计算过程，计算难度）
- 数仓会使计算流程变多，但是每一步和计算的难度都会降低。
- 组件多，编程接口丰富，增加了数据处理的方式方法。
- 大数据平台组件众多，每个组件都有自己的特点和用法。
- 同一个问题可以有多种方式方法解决
数据同步：自己写代码/sqoop/kettle。
数据预计算：MR/hive/spark。
实时计算：sparkStreanig/structStreaming/flink/storm
- 多种数据采集，能够实现实时数据、离线数据，非结构化数据和半结构化数据的采集；
- 得益于大数据内的组件众多，实时数据，离线数据都能够同步都能够计算。
- 结构化数据（结合数据库），非结构化数据采集(flume)
③ 仓库架构设计原则
1、自下而上与自上而下相结合
自下而上：数据的清洗、过滤、填充、汇总、计算自下而上分步骤计算。
自上而下：数据的查询、异常追踪，数据价值密度自上而下。
2、高容错性
构建数仓的任何一个系统出现故障，都会对数仓服务产生一定的影响，所以在构建数仓时，需保证数仓具备高容错性。（hive-mysql-kettle-kylin）
3、数据质量监控
数仓最终的结果直接受数据质量的影响。生产中数据质量管理需要贯穿整个数据处理流程
④ 数仓构建步骤
第一步：模型设计
建模方式：维度建模或实体关系建模
1. 维度建模相对实施比较简单，便于事实数据分析，适用于业务分析报表和BI；
2. 实体关系建模结构相对较复杂，它便于主体与主体之间的数据打通，比较适合复杂数据的深入分析。
模型分类: 星型模型和雪花模型
两种模型没必要绝对分开，事实上应该是并存的。星型也属于雪花模型。
星型模型结构相对简单，有利于计算，所以若表结构为雪花型可以在将雪花模型转换成星型模型，以达到降低计算难度的目的。
第二步：数据分层
数据分层可以使数据构建体系更加清晰，便于数据使用者快速对数据进行定位；同时数据分层也可以简化数据加工处理流程，降低计算复杂度。
常用的分层为：集市层（ADS）、中间层(DW)、基础数据层(ODS)，上下三层结构。
其中：
数据基础层(ODS)
数据采集：把多种数据源的数据统一采集到一个平台上；
数据归类：按照来源系统和业务领域进行分类（目录）；
数据规范化：包括规范维度标识、统一计量单位等规范化操作。
数据清洗：删除不符合要求的数据，避免脏数据参与后续数据计算（也可在DW层）；
数据结构化：对于半结构化和非结构化的数据，进行结构化【目前还不在数仓中实现】；
数据中间层（DW）
目标就是把同一实体/主题，不同来源/不同数据表的数据打通（拉宽到一个报表），已方便后续计算业务数据的使用。
用户行为数据可以抽象出来一些有用的数据，例如兴趣、偏好、习惯等。这些数据可以支撑上层的部分应用（推荐）。
当有一个实事数据和两个主题相关时
需将该数据放在两个主题库中（冗余两份或多分）这样能保证主题的完整性和提高数据的易用性，两个主题之间相互不影响（单表数据的复用性比较低）。为了提高单数据表的复用性和减少计算关联，会在事实表中冗余部分维度信息。
数据集市层（ADS）
数据集市由需求场景驱动建设，方便需求快速查询，快速计算。
⑤ 数据架构
数据架构包括数据整合、数据体系、数据服务三部分。
数据整合
数据类型可分为结构化、半结构化、非结构化三类。
数据整合可分为全量数据、增量数据、实时数据三类。
| 结构 | 半结构 | 非结构 | |
|---|---|---|---|
| 全量 | 结构全量 | 半结构全量 | 非结构全量 |
| 增量 | 结构增量 | 半结构增量 | 非结构增量 |
| 实时 | 结构实时 | 半结构实时 | 半结构实时 |
半结构化数据/非结构化数据需要经过结构化计算后才能使用。
例如：
微博 - - 博主，时间、状态、评论数。
图片 - - 文件名、大小、创建时间、格式。
语音 - - 文件名、时常、大小、格式，创建时间。
视频 - - 文件名、时长、分类等。
目前数仓架构体系中并不包含非结构化数据特征提取操作（其他系统提取好后才寄过来）。
数据体系
即数据的计算从入库开始到写入数据集市的全部过程。
数据服务化
数据服务化包括统计服务、分析服务、标签服务：
ADS数据集市包含统计服务、分析服务、标签服务。
统计服务（用户）：
主要是偏传统的报表服务，将计算后的结果存储到关系型数据库中，供前端的报表系统或业务系统查询。
分析服务（分析师）：
用来提供明细数据的即席查询(即席查询【想怎么查就怎么查】:操作人员可以自主灵活的进行各种维度的交叉组合查询)。分析服务的能力类似于传统cube提供的内容。
一个查询有10个维度。（group by 后面的字段有1-10个）
10个维度任意组合的可能性有多少？？ 2的十次方-1个可能（1023）
用户的所有查询可能都在这1023种情况内
标签服务（推荐）：
在大数据的应用中，经常会对主体进行特征刻画。例如：客户的年龄段、消费性别、消费能力、兴趣习惯等。这些数据通过打标签转换成KV的数据服务，用于前端应用查询。
经验分享
1、采用强制分区，在所有的表都上都加上时间分区。通过分区，保证每个任务都能够独立重跑，而不产生数据质量问题，降低了数据修复成本；此外通过分区裁剪，还可以降低计算成本。
2、应用计算框架完成日志结构化、同类数据计算过程等操作，减轻了开发人员的负担，同时更容易维护。
3、优化关键路径。优化关键路径中耗时最长的任务是最有效的保障数据产出时间的手段。
⑥ 数据治理
适用场景：
计算量很大，生产中数据质量管理所需要的资源需要与数仓的计算资源对顶或相匹配。
数据治理贯穿在数仓架构内部和数据处理的流程之中。
保障数据质量，可以从事前、事中、事后入手。
事前，可以通过制定每份数据的数据质量监控规则，越重要的数据对应的监控规则应该越多。
事中，通过监控和影响数据生产过程，对不符合质量要求的数据进行干预（删除/填充/归0等），使其不影响下流数据的质量。
事后，通过对数据质量情况进行分析和打分，将一些不足和改进反馈数据监控体系，推动整体的数据质量提升。
例如：数据进入ODS层之前数据量是多少条，根据规则删除掉多少条，剩余多少条。进入之前=删除的+剩余的
数据进入DW层之前多少条，出DW多少条。进入的-输出的是否是未join上的数据。
编写质量检测程序，逐一检查数据是否符合规则。统计出符合的有多少条，不符合的有多少条（符合的+不符合的=所有的）。
⑦ 数据生命周期
虽然大数据集群空间大，但不要过量使用空间。出于成本等因素的考虑，在大数据平台上依然需要对数据生命周期进行管理。
根据使用频率将数据分为冰、冷、温、热四类。保证数据的生命周期尽量合理（保证温热数据占整个数据体系大部分）。
对于数据中间计算过程数据，在保障满足绝大部分应用访问历史数据需要的前提下，缩短数据保留周期，有助于降低存储成本。
热（近1-7天）：存储在kylin的cube (hbase+预计算)或redis或mysql
温（近8-14天）：存贮在mysql或oracle或MongoDB
冷（近15-45天）：存储在hive表(SSD硬盘中)
冰（45+）：冰数据存储在HDFS的机械硬盘中
结语
关于【大数据】数仓设计的干货内容分享就到这里，后续会为大家带来其他类型的项目分析，敬请期待????
如果以上过程中出现了任何的纰漏错误，烦请大佬们指正????
受益的朋友或对大数据技术感兴趣的伙伴记得点赞关注支持一波????
标签：数仓,结构化,步带,深入,计算,构建,数据,结构 来源： https://blog.51cto.com/u_15105906/2844420
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。