导读：随着互联网规模的扩大，数据也呈爆炸式增长，产生了各种结构化、半结构化、非结构化数据，越来越多的企业开始在大数据平台下进行数据处理本文主要从总体思路、模型设计、数据结构、数据管理四个方面介绍如何利用大数据平台的特性构建更适合大数据应用的数据仓库。
总体思路
随着互联网规模的扩大，数据也呈爆炸式增长，各种结构化、半结构化、非结构化数据层出不穷。 新环境下的数据应用呈现出业务变化快、数据源多、系统耦合多、应用深度深等特点。
那么，根据这些特点，该如何构建数据仓库呢？ 我认为应该从稳定、信任、丰富、透明四个关键词开始。
其中，稳定要求数据生产稳定、有保障的可靠意味着数据质量足够高；丰富意味着数据涵盖的业务方面足够丰富；透明是数据配置流程体系透明，用户放心
选择基于大数据平台构建数据仓库，这取决于大数据平台的丰富特点。
强大的计算和存储功能允许更扁平化的数据流程设计，从而简化计算过程
通过各种编程接口和框架，丰富了数据加工的手段
丰富的数据收集通道允许收集非结构化数据和半结构化数据
各种安全和管理措施确保了平台的可用性
仓库的设计原则主要有以下四点。
自上而下与自下而上相结合，保障数据采集的全面性；
第二高容错能力是随着系统耦合度的增加，任何系统出现问题都会影响对数仓库服务，因此数仓库建设过程中高容错能力是必不可少的因素；
可以毫不夸张地说，第三种数据质量监控需要贯穿整个数据过程进行，数据质量监控消耗的资源与数据仓库构建的资源相当；
第四，充分利用存储空间，方便使用，而不必担心数据冗馀。
模型设计
构建数仓的第一步是进行模型设计。
维度建模或实体关系建模
典型的模型设计思路包括维度建模和实体关系建模。 维度建模实施简单，便于实时数据分析，适用于业务分析报告和BI； 关系建模结构复杂，但主体数据容易沟通，适用于复杂数据内容的深度挖掘。
在为每个企业构建自己的仓库时，必须根据业务形态和需求场景选择合适的建模方法。 在应用复杂性的企业中，可以在基础级别采用维建模，将维更清晰等各种建模结合起来。中间层采用实体关系建模方式，使中间层更容易在上层APP应用中使用。
星型和雪花型
除了建模方式外，星形模型和雪花模型的选择也有可能困扰用户。 其实，两种模型并存，星形是雪花模型的一种。 理论上实际数据的模型都是雪花模型； 实际的数据仓库中共存着两种模式。
星型模型结构比较简单，我们可以在数据中间层利用数据冗馀将雪花模型转化为星型模型，有利于数据应用和减少计算资源消耗。
数据分层
确定建模思路和模型类型后，下一步是数据分层。 数据分层使数据构建体系更加清晰，数据用户可以快速放置数据，数据分层简化了数据加工过程，降低了计算复杂性。
我们常用的数据仓库数据层次通常分为三层结构：市场层、中间层和基础数据层。 从传统的多层结构减少到上下三层结构的目的是压缩整个数据处理过程的长度，同时扁平化的数据处理过程有助于数据质量管理和数据传输。
在上下3层结构的右侧添加了流数据，作为数据体系的一部分进行了添加。 这是因为当前数据APP应用的方向越来越关注数据的时效性，越是实时数据价值越高。
但由于流数据集的收集、加工、管理成本较高，一般采用需求驱动的方式建设； 另外，考虑到成本，流数据体系的结构更加扁平化，通常不设计中间层。
具体看看各层的作用吧。
数据基础层
数据基础层主要进行以下工作：
数据收集：将不同数据源的数据统一收集到一个平台上
清洗数据，清洗不符合质量要求的数据，不要让脏数据参与后续的数据计算
通常对数据进行分类，创建数据目录，然后在基础级别按源系统和业务域进行分类
对数据结构化、半结构化和非结构化的数据进行结构化
数据规范化。 包括维度标识规范化、测量单位统一等规范化操作
数据中间层
数据中间
层最为重要的目标就是把同一实体不同来源的数据打通起来，这是因为当前业务形态下，同一实体的数据可能分散在不同的系统和来源，且这些数据对同一实体的标识符可能不同。此外，数据中间层还可以从行为中抽象关系。从行为中抽象出来的基础关系，会是未来上层应用一个很重要的数据依赖。例如抽象出的兴趣、偏好、习惯等关系数据是推荐、个性化的基础生产资料。
在中间层，为了保证主题的完整性或提高数据的易用性，经常会进行适当的数据冗余。比如某一实事数据和两个主题相关但自身又没有成为独立主题，则会放在两个主题库中；为了提高单数据表的复用性和减少计算关联，通常会在事实表中冗余部分维度信息。
数据集市层
数据集市层是上下三层架构的最上层，通常是由需求场景驱动建设的，并且各集市间垂直构造。
在数据集市层，我们可以深度挖掘数据价值。值得注意的是，数据集市层需要能够快速试错。（了解更多数据仓库建设内容，欢迎点击阅读：6000字详解数据仓库建设方法）
数据架构
数据架构包括数据整合、数据体系、数据服务三部分：
其中，数据整合又可以分为结构化、半结构化、非结构化三类。
数据整合
结构化数据采集又可细分为全量采集、增量采集、实时采集三类。三种采集方式的各自特点和适应场合如下图所示，其中全量采集的方式最为简单；实时采集的采集质量最难控制。
在传统的架构中，日志的结构化处理是放在数仓体系之外的。在大数据平台仓库架构中，日志在采集到平台之前不做结构化处理；在大数据平台上按行符分割每条日志，整条日志存储在一个数据表字段；后续，通过UDF或MR计算框架实现日志结构化。
在笔者看来，日志结构越规范，解析成本越低。在日志结构化的过程中，并不一定需要完全平铺数据内容，只需结构化出重要常用字段；同时，为了保障扩展性，可以利用数据冗余保存原始符合字段（如useragent字段）。
非结构化的数据需要结构化才能使用。非结构化数据特征提取包括语音转文本、图片识别、自然语言处理、图片达标、视频识别等方式。
尽管目前数仓架构体系中并不包含非结构化数据特征提取操作，但在未来，这将成为可能。
数据服务化
数据服务化包括统计服务、分析服务和标签服务：
统计服务主要是偏传统的报表服务，利用大数据平台将数据加工后的结果放入关系型数据库中，供前端的报表系统或业务系统查询。
分析服务用来提供明细的事实数据，利用大数据平台的实时计算能力，允许操作人员自主灵活的进行各种维度的交叉组合查询。分析服务的能力类似于传统cube提供的内容，但是在大数据平台下不需要预先建好cube，更灵活、更节省成本。
标签服务，大数据的应用场景下，经常会对主体进行特征刻画，比如客户的消费能力、兴趣习惯、物理特征等等，这些数据通过打标签转换成KV的数据服务，用于前端应用查询。（了解更多数据服务化的内容，欢迎点击阅读：快手大数据平台服务化实践）
架构设计中一些实用的点
在架构设计中有一些实用的点，这里给大家分享一下：
第一，通过巧用虚拟节点实现多系统数据源同步，实现跨系统间的数据传输，实现多应用间数据交互。通过巧用虚拟节点减少运维人员在实际出现问题时的运维成本。
第二，采用强制分区，在所有的表都上都加上时间分区。通过分区，保证每个任务都能够独立重跑，而不产生数据质量问题，降低了数据修复成本；此外通过分区裁剪，还可以降低计算成本。
第三，应用计算框架完成日志结构化、同类数据计算过程等操作，减轻了开发人员的负担，同时更容易维护。
第四，优化关键路径。优化关键路径中耗时最长的任务是最有效的保障数据产出时间的手段。（了解更多数据仓库架构设计方法，欢迎点击阅读：万字长文详解数据仓库架构和建设方法论）
数据治理
数据治理的内容主要体现在三个方面：
保障体系：开展数据治理组织建设，并建立配套的流程和标准规范
内容建设：包括数据架构顶层规划设计、数据模型标准设计、数据开发、生产运营维护、数据共享服务
管理体系：数据治理和数据安全是核心重点
数据治理不是独立于系统之外的保障，它应该贯穿在数仓架构内部和数据处理的流程之中。（了解更多数据治理的内容，欢迎点击阅读：详解数据治理九大核心领域，以银行业为例）
数据质量
保障数据质量，可以从事前、事中、事后入手：
事前，我们可以通过制定每份数据的数据质量监控规则，越重要的数据对应的监控规则应该越多。
事中，通过监控和影响数据生产过程，对不符合质量要求的数据进行干预，使其不影响下流数据的质量。
事后，通过对数据质量情况进行分析和打分，将一些不足和改进反馈数据监控体系，推动整体的数据质量提升。（了解更多数据质量的内容，欢迎请点击阅读：企业数据质量管理的核心要素和技术路线（PPT））
数据生命周期管理
出于成本等因素的考虑，在大数据平台上依然需要对数据生命周期进行管理。根据使用频率将数据分为冰、冷、温、热四类。一个合理的数据生命周期管理要保证温热数据占整个数据体系大部分；同时为了保障数据资产的完整性，对于重要的基础数据会长久保留。
对于数据中间计算过程数据，在保障满足绝大部分应用访问历史数据需要的前提下，缩短数据保留周期，有助于降低存储成本；最后一点值得注意的是，冷备已经成为历史，在大数据平台下不需要单独的冷备设备。
识别 下方二 维码 ，即可关注公众号获取最新大厂技术