最近笔者在总结某运营商整体大数据平台架构时发现，上层应用能够较快地进行梳理，但是在梳理底层架构时，笔者觉得比较惭愧，作为数据仓库全球领先公司Teradata的一员，关于数据仓库的认知居然变得有些”陌生“，所以笔者认真反思了下，并进行了总结思考。
何为数据仓库
比较经典的概述是“数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策”。曾经在读书以及刚来公司时，对于此概念的理解也只是停留在“概念”阶段，但随着大数据的不断实践，对于这几个关键字也有了自己的理解。
01、面向主题的
操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。比如说在某运营商主题设计时，通过不断的分析整合，设为参与人、服务、资源等主题。
02、集成的
数据仓库的数据来自于分散的操作型数据，将所需数据从原来的数据中抽取出抽取出来进行加工与集成，统一与综合之后才能进入数据仓库。比如说某运营商由于业务众多衍生很多操作性系统，由于各源数据之间存在差异，所以必须经过相应的加工处理，从而保证数据仓库内的信息是关于整个企业的一致的全局信息。
03、相对稳定的
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
04、反映历史变化的
数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
为何要建数据仓库
相信这个问题在很多关于数据仓库的书籍或是文章中皆有阐述，笔者在这里就不长篇大论地进行叙述了，主要针对某运营商的境况谈点个人的总结看法。
伴随着企业的发展，必须逐渐摆脱从前的经验型管理模式，向分析型管理和精确化管理转变，这一需求对企业的服务内容、服务方式、服务质量、经营管理以及服务意义提出了严峻的挑战。如何提升企业竞争力，必须充分利用与挖掘企业经营、业务多方向的数据信息，建设先进的信息分析及处理平台。具体主要包含如下三个方面：
一是市场针对性营销要求，需要从客户、产品、时间、地域等多个维度进行经营分析，掌握细分市场和客户群，加强营销的针对性，提高市场开发效率、降低市场开发成本；二是精确配置资源，即企业需要对资源进行优化配置，适应从规模型增长到效益型增长的转变；三是适应企业全业务经营的需求。
为了满足这些需求，运营商启动了数据仓库的建设，以实现信息共享、创造数据价值。所以，建设数据仓库并不是一个IT诉求，而是一个业务诉求，在建设的初期就应进行长远的总体规划，利用数据仓库的工程实施方法，在整体架构设计上要充分考虑该架构的扩展性和灵活性。
如何构建数据架构
就如同在产品架构中，我们需要考虑性能、成本、效率等因素，同样的，在数据模型架构中也需要考虑以上因素，通常会进行分层设计。其好处如下：
01、空间换时间
通过建设多层数据模型供用户使用，避免用户直接操作底层操作型数据，可以更高效的访问数据。
02、清晰的数据血缘关系
方便各个业务团队，在某个业务数据出现问题，或者是梳理数据逻辑的时候，能够清晰准确的找到自己想要的表。
03、减少数据重复计算
规划数据分层，有条件的公司可以做数据中台，提炼出通用性的中间表，减少重复计算。
04、复杂问题简单化
将一个需要关联多个业务表才能产出结果的业务逻辑，分成多步计算，这样可以将复杂的问题简单化，这样当每一层数据出问题或者修改业务逻辑时，不用修复所有的数据，只需要在本层以及下级依赖中进行相关操作。
05、便于处理业务的变化
随着业务的变化，只需要调整底层的数据，数据中台、数据集市等应用型层级对业务调整零感知。
目前市场上比较通用的模型架构分为如下五层：
ODS层：操作数据层，即为数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响。从业务系统增量抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题逻辑划分。
DWD层：数据明细层，为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑。数据模型与ODS层一致，不做清晰转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理。
DW层：数据汇总层，为DM、ST层提供细粒度数据，细化成DWB和DWS。DWB是根据DWD明细数据转换的，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理等；DWS是根据DWB层数据按各个维度ID进行粗粒度汇总聚合得出的，如按交易来源，交易类型进行汇合。
DM层：数据集市层，根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储，满足一些特定查询、数据挖掘应用。
ST层：数据应用层，该层面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析，面向最终结果用户，适合作OLAP报表模型，如ROLAP、MOLAP。
如何构建数据模型
目前主要有四种数据仓库模型的构建方法，其中实体关系模型和维度模型比较常见。
01、实体关系模型
数据仓库之父Immon的方法从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，它与OLTP系统中的3NF的区别，在于数据仓库中的3NF上站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象，它更多的是面向数据的整合和一致性治理，但是要采用此方法进行构建，也有其挑战：
- 需要全面了解企业业务和数据
- 实施周期非常长
- 对建模人员的能力要求也非常高
02、维度模型
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。
03、DataVault
DataVault是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。它强调建立一个可审计的基础数据层，也就是强调数据的历史性可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时也基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型应对源系统变更的扩展性。它主要由：Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成 。
04、Anchor模型
Anchor模型是由Lars. Rönnbäck设计的，初衷是设计一个高度可扩展的模型，核心思想是所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。Anchor模型由：Anchors 、Attributes 、Ties 、Knots 组成，相关细节可以参考《Anchor Modeling-Agile Information Modeling in Evolving Data Environments》。
如何构建大数据管理平台
上述所建立完成好的数据仓库，需要抽数、推数、查询、监控、展示，因此需要有一套完善的大数据平台来达到自动化实现这些。
以上是某运营商大数据管理架构图，以元数据为核心，实现从数据设计、开发到数据销毁的全生命周期管理，并通过把架构、标准、质量规则和安全策略固化在平台上，实现从事前管理、事中控制和事后稽核、审计的全方位质量管理和安全管理。
结语
目前项目组能够深耕各行业进行大数据赋能，少不了底层高质量数据的助力，在这里笔者非常感谢当时参与底层数据架构的童鞋们。最后，底层数据管理是一项持续性的工作，需要不断地进行上下游协同才能真正让数据价值遍地开花。
