阿里巴巴大数据实践：大数据建设方法论OneData

面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，一直是大数据系统建设不断追求的方向。

OneData即是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似的大数据项目快速落地实现。下面重点介绍OneData体系和实施方法论。

1．定位及价值

阿里巴巴集团大数据建设方法论的核心是：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。目前，阿里巴巴集团数据公共层团队已把这套方法论沉淀为产品，以帮助数据PD、数据模型师和ETL工程师建设阿里的大数据。这一体系包含方法论以及相关产品。

建设统一的、规范化的数据接入层（ODS）和数据中间层（DWD和DWS），通过数据服务和数据产品，完成服务于阿里巴巴的大数据系统建设，即数据公共层建设。提供标准化的（Standard）、共享的（Shared）、数据服务（Service）能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛。

2．体系架构

体系架构如图。

业务板块：由于阿里巴巴集团业务生态庞大，所以根据业务的属性划分出几个相对独立的业务板块，业务板块之间的指标或业务重叠性较小。如电商业务板块涵盖淘系、B2B系和AliExpress系等。

规范定义：阿里数据业务庞大，结合行业的数据仓库建设经验和阿里数据自身特点，设计出的一套数据规范命名体系，规范定义将会被用在模型设计中。后面章节将会详细说明。

模型设计：以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实（进行规范定义）。同时，在落地表模型时，基于阿里自身业务特点，设计出一套表规范命名体系。

3．模型设计

模型设计指导理论：阿里巴巴集团数据公共层设计理念遵循维度建模思想，可参考Star Schema-The Complete Reference和The Data Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

模型层次：阿里巴巴的数据团队把表数据模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），其中公共维度模型层包括明细数据层（DWD）和汇总数据层（DWS）。

操作数据层（ODS）：把操作系统数据几乎无处理地存放在数据仓库系统中。

同步：结构化数据增量或全量同步到MaxCompute。
结构化：非结构化（日志）结构化处理并存储到MaxCompute。
累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。

公共维度模型层（CDM）：存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。

CDM层又细分为DWD层和DWS层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。其主要功能如下。

组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。
公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表。
建立一致性维度：建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。

应用数据层（ADS）：存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。

个性化指标加工：不公用性、复杂性（指数型、比值型、排名型指标）。
基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串。

阿里巴巴通过构建全域的公共层数据，极大地控制了数据规模的增长趋势，同时在整体的数据研发效率、成本节约、性能改进方面都有不错的效果。

数据调用服务优先使用公共维度模型层（CDM）数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要建设公用的公共层时，方可直接使用操作数据层（ODS）数据。应用数据层（ADS）作为产品特有的个性化数据一般不对外提供数据服务，但是ADS作为被服务方也需要遵守这个约定。

基本原则：

高内聚和低耦合——一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储；
核心模型与扩展模型分离——建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可维护性。
公共处理逻辑下沉及单一——越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
成本与性能平衡——适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
数据可回滚——处理逻辑不变，在不同时间多次运行数据结果确定不变。
一致性——具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。
命名清晰、可理解——表命名需清晰、一致，表名需易于消费者理解和使用。

如何从具体的需求或项目转换为可实施的解决方案，如何进行需求分析、架构设计、详细模型设计等，则是模型实施过程中讨论的内容。