OneDate建设探索之路：数仓建设

缺乏统一的业务和技术标准，如：开发规范、指标口径和交付标准不统一。缺乏有效统一的数据质量监控，如：列值信息不完整和不准确，SLA时效无法保障等。业务知识体系散乱不集中，导致不同研发人员对业务理解存在较大的偏差，造成产品的开发成本显著增加。数据架构不合理，主要体现在数据层之间的分工不明显，缺乏一致的基础数据层，缺失统一维度和指标管理。

碰到了哪些问题？

一、背景

好东西要借鉴，在数据建设方面，阿里巴巴提出了一种OneDate标准

行业经验

整个OneData体系覆盖范围广，包含数据规范定义体系、数据模型规范设计、ETL规范研发以及支撑整个体系从方法到实施的工具体系。实施周期较长，人力投入成本较高。推广落地的工作比较依赖工具。

1、对阿里巴巴OneDate的思考

现阶段工具保障方面偏弱，人力比较缺乏。现有开发流程不能全部推翻。经过综合考量，我们发现直接全盘复用他人经验是不合理的。那我们如何定义自己的OneData，即能在达到目标的前提下，又能避免上述的难题呢？

2、对现有实际的思考

思考

从设计、开发、部署和使用层面，避免重复建设和指标冗余建设，从而保障数据口径的规范和统一，最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。

OneData核心思想

文档模板

文档管理

应用迭代统一

统一性

码、码值、指标唯一

唯一性

字段、表数据命名规范

规范性

三特性

快速支撑多个业务，满足个性化需求

高扩展性

支持反复应用

强复用性

分层、分主题、数据沉淀降低ETL成本

低成本性

三效果

OneData核心特点

首先，结合行业经验，自身阶段的实践及以往的数仓经验，我们预先定义了OneData核心思想与OneData核心特点。

想法

统一业务归口

统一设计归口

统一应用归口

统一归口

统一指标管理

统一维度管理

统一数据出口

统一出口

策略

OneDate探索

1）模型分层

2）模型数据流向

1、模型

2、主题划分

1）词根

2）表命名规范

3）指标命名规范

4）清洗规范

3、规范

设计统一归口

1、交付标准化

2、数据资产管理

OneDate实践

流程改善

数仓全景图

构建前耗时，构建后耗时

研发效率

构建前指标情况，重复指标

指标冗余建设

运维质量

减少节约存储&计算资源

构建前单个报表开发需要多久，构建后需要多久

开发效率

项目收益

资产管理列表

实践的成果

OneDate建设探索之路：SaaS收银运营数仓建设