2019独角兽企业重金招聘Python工程师标准>>> 
干货：解码OneData，阿里的数仓之路。
免费开通大数据服务：https://www.aliyun.com/product/odps
据IDC报告，预计到2020年全球数据总量将超过40ZB(相当于4万亿GB)，这一数据量是2013年的10倍。正在“爆炸式”增长的数据的潜在巨大价值正在被发掘，它有可能成为商业世界的“新能源”，变革我们的生产，影响我们生活。当我们面对如此庞大的数据之时，如果我们不能有序、有结构的进行分类组织和存储，那么在价值被发现前，也许数据成本灾难已经来临。它犹如堆积如山的垃圾，给我们企业带来的是极大的成本，而且非常难以消费和发掘价值，也许数据更可悲的命运是在价值发现之前它以死去。不得已的历史数据清理还在进行中吗？
那么，企业大数据体系的数据架构应该如何建立？如何保障数据快速支撑业务并且驱动业务发展？在2016数据库技术大会上，数据中台的高级技术专家王赛结合阿里数据的实践成果，按照背景、方法思路以及如何落地实现、效果如何的逻辑，为大家详细介绍阿里数据中台的秘密武器——OneData体系。
背景》》》》》》》
在企业发展初期，数据研发模式一般紧贴业务的发展而演变的，数据体系也是基于业务单元垂直建立，不同的垂直化业务，带来不同的烟囱式的体系。但随着企业的发展，一方面数据规模在快速膨胀，垂直业务单元也越来越多，另一方面基于大数据的业务所需要的数据不仅仅是某个垂直单元的，使用数据类型繁多(Variety)的数据才能具备核心竞争力。跨垂直单元的数据建设接踵而至，混乱的数据调用和拷贝，重复建设带来的资源浪费，数据指标定义不同而带来的歧义、数据使用门槛越来越高……这些问题日益凸显，成为企业发展迫在眉睫必须要解决的问题。
1）数据标准不统一
在建立OneData之前，阿里数据有30000多个指标，其中，即使是同样的命名，但定义口径却不一致。例如，仅uv这样一个指标，就有十几种定义。带来的问题是：都是uv，我要用哪个？ 都是uv，为什么数据却不一样？
2）服务业务能力
由于数据模式是跟着垂直业务，导致一开始只支持了淘宝、天猫、1688等少数业务团队。而更多有个性化需求的业务团队却无法提供更多支持。
3）计算存储成本
由于没有统一的规范标准管理，造成了重复计算等资源浪费。而数据表的层次、粒度不清晰，也使得重复存储严重，仅淘系的数据表就超过了25000张，集团总数据的存储量每年以2.5倍的速度在增长，可以预见的未来的将会带来巨大的数据成本负担，我们不得不去做一些改变。
4）研发成本
每个工程师都需要从头到尾了解研发流程的每个细节，对同样的“坑”每个人都会重新踩一遍，对研发人员的时间和精力成本造成浪费
建立的方法和思路》》》》》》》》
基于这样的问题和挑战，阿里集团规划建设一个全集团的全域数据公共层，将公共的数据、计算沉淀于此，降低数据存储和计算成本，提升数据互通和消费的效率，从而支撑快速数据业务应该的创新。公共层中重要的一环是数据模型的构建，那么我们先从行业看看一些方法体系和经验：
1）他山之石——行业内是如何做的？
A、实体关系（ER）模型
数据仓库之父Immon的方法从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，它与OLTP系统中的3NF的区别，在于数据仓库中的3NF上站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象，它更多的是面向数据的整合和一致性治理，正如Immon所希望达到的：“single version of the truth”。但是要采用此方法进行构建，也有其挑战：
- 需要全面了解企业业务和数据
- 实施周期非常长
- 对建模人员的能力要求也非常高
B、维度模型
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，它的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling》是数据仓库工程领域最流行的数仓建模经典。
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。
C、DataVault
DataVault是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。它强调建立一个可审计的基础数据层，也就是强调数据的历史性可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时也基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型应对源系统变更的扩展性。它主要由：Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成 。
D、Anchor模型
Anchor模型是由Lars. Rönnbäck设计的，初衷是设计一个高度可扩展的模型，核心思想：所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。Anchor模型由：Anchors 、Attributes 、Ties 、Knots 组成，相关细节可以参考《Anchor Modeling-Agile Information Modeling in Evolving Data Environments》
2）阿里的数仓模型体系要如何构建？
阿里巴巴集团在很早就已经把大数据做为战略目标实施，而且其各个业务也非常依赖数据支撑运营，那么阿里究竟采取何种方法构建自己的体系？阿里的数据仓库模型建设经历的多个发展周期：
第一阶段：完全应用驱动的时代，阿里巴巴第一代的数据仓库系统构建在Oracle上，数据完全以满足报表需求为目的出发，将数据以与源结构相同的方式同步到Oracle后，我们叫ODS（Operational Data Store）层，数据工程师基于ODS数据进行统计，基本没有模型方法体系，完全基于对Oralce数据库特性的利用进行数据存储和加工，部分采用了一些维度建模的缓慢变化维方式进行历史数据处理。那时候的数据架构只有两次层ODS+DSS。
第二阶段：随着阿里业务的快速发展，数据量也在飞速增长，性能已经是一个较大问题，因此引入了当时MPP架构体系的Greenplum，同时阿里的数据团队也在着手开始进行一定的数据架构优化，希望通过一些模型技术改变烟囱式的开发模型，消除一些冗余，提升数据的一致性。来做传统行业数仓的工程师，开始尝试将工程领域比较流行的ER模型+维度模型方式应用的阿里集团，构建出一个四层的模型架构ODL（操作数据层）+BDL(基础数据层)+IDL（接口数据层）+ADS(应用数据层)。ODL保持和源系统保持一致，BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装。其中我们在构建ER模型遇到了比较大的困难和挑战，互联网业务的快速发展，人员的快速迭代变化，业务知识功底的不够全面导致ER模型设计迟迟不能产出，至此，我们也得到了一个经验，在一个不太成熟，快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建。
第三阶段：阿里集团的业务和数据还在飞速发展，这个时候迎来了以hadoop为代表的分布式存储计算平台的快速发展，同时阿里集团自主研发的数加大规模计算服务MaxCompute（原ODPS）也在紧锣密鼓的进行中；我们在拥抱分布式计算平台的同时，也开始建设我们的第三代模型架构，我们需要找到一个核心问题，找打适合阿里集团业务发展，又能充分利用分布是计算平台能力的数据模型方式。
我们选择了以Kimball的维度建模为核心理念基础的模型方法论，同时对其进行了一定的升级和扩展，构建了阿里集团的数据架构体系——OneData
OneData体系分为：数据规范定义体系、数据模型规范设计、ETL规范研发以及支撑整个体系从方法到实施的工具体系。
落地实现》》》》》》
A）数据规范定义
将此前个性化的数据指标进行规范定义，抽象成：原子指标、时间周期、其他修饰词等三个要素。
例如，以往业务方提出的需求是：最近7天的成交。而实际上，这个指标在规范定义中，应该结构化分解成为：
原子指标（支付订单金额 ）+修饰词-时间周期（最近7天）+修饰词-卖家类型（淘宝）
B）数据模型架构
将数据分为ODS（操作数据）层、CDM（公共维度模型）层、ADS（应用数据）层。
其中：
ODS层主要功能
这里先介绍一下阿里云数加大数据计算服务MaxCompute，是一种快速、完全托管的TB/PB级数据仓库解决方案，适用于多种数据处理场景，如日志分析，数据仓库，机器学习，个性化推荐和生物信息等。
- 同步：结构化数据增量或全量同步到数加MaxCompute（原ODPS）；
- 结构化：非结构化(日志)结构化处理并存储到MaxCompute（原ODPS）；
- 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、数据清洗；
CDM层主要功能
CDM层又细分为DWD层和DWS层，分别是明细宽表层和公共汇总数据层，采取维度模型方法基础，更多采用一些维度退化手法，减少事实表和维度表的关联，容易维度到事实表强化明细事实表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多宽表化的手段构建公共指标数据层，提升公共指标的复用性，减少重复的加工。
ADS层主要功能
- 个性化指标加工：不公用性；复杂性（指数型、比值型、排名型指标）
- 基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串
其模型架构图如下，阿里通过构建全域的公共层数据，极大的控制了数据规模的增长趋势，同时在整体的数据研发效率，成本节约、性能改进方面都有不错的结果。
C）研发流程和工具落地实现
将OneData体系贯穿于整个研发流程的每个环节中，并通过研发工具来进行保障。
实施效果》》》》》》
- 数据标准统一：数据指标口径一致，各种场景下看到的数据一致性得到保障
- 支撑多个业务，极大扩展性：服务了集团内部45个BU的业务，满足不同业务的个性化需求
- 统一数据服务：建立了统一的数据服务层，其中离线数据日均调用次数超过22亿；实时数据调用日均超过11亿
- 计算、存储成本：指标口径复用性强，将原本30000多个指标精简到3000个；模型分层、粒度清晰，数据表从之前的25000张精简到不超过3000张。
- 研发成本：通过数据分域、模型分层，强调工程师之间的分工和协作，不再需要从头到尾每个细节都了解一遍，节省了工程师的时间和精力。
背景
作为一家高度数字化和技术驱动的公司，美团非常重视数据价值的挖掘。在公司日常运行中，通过各种数据分析挖掘手段，为公司发展决策和业务开展提供数据支持。经过多年的发展，美团酒旅内部形成了一套完整的解决方案，核心由数据仓库+各种数据平台的方式实现。其中数据仓库整合各业务线的数据，消灭数据孤岛；各种数据平台拥有不同的特色和定位，例如：自助报表平台、专业数据分析平台、CRM数据平台、各业务方向绩效考核平台等，满足各类数据分析挖掘需求。早期数据仓库与各种数据平台的体系架构如图1所示：
图1 酒旅早期各数据平台和数据仓库体系架构图
图1所示的体系架构，在业务需求的满足上非常高效，但在长时间的使用过程中，也产生了如下一些问题：
· 各数据平台或平台内不同模块的指标定义不一致。
· 各数据平台或平台内不同模块指标计算口径不一致。
· 各数据平台或平台内不同模块指标数据来源不一致。
上述这些问题总结归纳起来，就是指标数据不一致的问题，最终带来的后果是指标数据可信度底，严重影响分析决策。通过后续追踪分析，上述问题的由来，主要是不同业务线的数据分析人员、数据开发人员，以及不同的产品之间，缺乏有效的沟通，也没有一个统一的入口，来记录业务的发生和加工过程。在加上人员的流动，长时间积累之后就产生了这些问题。针对这些问题，酒旅内部启动了数据治理项目，通过建设一个专业数据治理平台，实现指标维度及数据的统一管理，也探索一套高效的数据治理流程。
挑战
在建设起源数据治理平台的过程中，主要面临的挑战如下：
· 起源数据治理平台应该在架构中的哪个位置切入，减少对原有系统的侵入，并实现数据治理目标。
· 探索一套简洁高效的管理流程，实现指标维度信息统一管理，保证信息的唯一性、正确性。
· 整合各种存储引擎，实现一套高并发、高可用的数据唯一出口。
· 做好各业务线间的信息隔离和管理，确保数据安全。
解决思路
为了达成数据治理的目标，起源数据治理平台就必须记录下业务发展过程，并映射到数据加工和数据提取，规范约束这些过程。因此起源数据治理平台归纳到数据治理层，该层就位于数据仓库层（或数据集市层）之上，数据应用层之下起到桥梁的作用，而且提供一系列规则，改变原来无序交互方式，将数据仓库层和数据应用层的交互变为有序的、可查询、可监控。新的体系架构如图2所示：
图2 数据治理后的新体系架构图
如上图所示，在新的体系架构下：对于数据仓库层，起源数据治理平台综合业务组织形式、指标数据来源、上层产品的使用及查询的效率，指导数据仓库模型的建设；对于应用层的产品，业务元数据信息及数据信息都是由起源数据治理平台提供，保证了各数据产品获取到的信息一致，而且还简化了应用层产品数据获取成本，也降低了对原有系统的侵入。
平台架构
起源数据治理平台核心是保证数据一致，在数据安全的前提下，尽可能提升数据分发能力。因此平台内部有着极其复杂的关系，需要在建设过程中进行抽象，形成具有相对单一功能的模块；合理地组织模块的层级和连接关系，降低平台的开发难度，并提升平台的可维护性。平台架构如图3所示，展示了平台的内部模块组织方式。
图3 起源数据治理平台架构图
如上图所示起源数据治理平台在功能模块上由数据存储、数据查询、数据缓存、元数据管理、业务管理、安全管理、应用管理、对外API接口构成，各模块的功能介绍如下。
数据存储
起源数据治理平台管理的数据存储范围包括：数据仓库中的Topic层和数据应用层，存储方式包括：Hive、MySQL、Kylin、Palo、ES、Druid。如下图4所示：
图4 起源数据治理平台管理的数据存储
上图所示的这些数据存储中的数据的加工过程，由数据开发工程师负责，具体采用哪种存储介质，由数据开发工程师综合所需数据存储空间、查询效率、模型的组织形式等因素决定。但后续的使用维护都由起源数据治理平台管理，管理方式是通过管理这些数据表的元数据信息和查询实现，具体实现细节会在下面章节中详解。
数据存储托管之后，数据表元数据信息变更监控、表数据生产（存储空间、生产状态及完成时间）监控、表数据波动（同环比等）监控以及表的使用（模型的构建及查询效率等）监控及评估，都由起源数据治理平台自动完成，所有信息的变动都会自动周知对应的负责人，保证数据应用的安全和稳定。
元数据管理
元数据信息宏观上包括两大部分：业务元数据信息和数据元数据信息。其中业务元数据信息包括：指标业务定义、维度的业务定义等；数据元数据信息包括：数据表元数据信息、模型元数据信息、维表与维度的绑定关系、数据模型字段与指标的绑定关系。
起源平台为了实现元数据信息的管理，设计了四个模块实现，分别是：数据表管理模块、模型管理模块、指标管理模块、维度管理模块。元数据管理是起源数据治理平台的核心，起源平台就是通过控制好元数据，来驱动数据的生产和消费。
数据表管理模块
数据表管理模块管理了数据库信息和数据表信息。其中数据库信息包括数据库链接信息，数据库信息维护后，起源数据治理平台自动获取对应库中表的元数据信息。数据表信息包括：表的元数据信息（引擎、字段等）、表类型（维表或事实表）、表的使用情况（是否被模型使用）、表对应的ETL、表的负责人、表的推荐度、描述信息、表的监控配置及报警历史、以及样例数据等。上述这些信息为业务用户提供指导，为模型管理提供数据支持，为数据表和数据的稳定提供监控和预警。
模型管理模块
模型管理模块能够还原业务落地后数据表的组织关系，包括：数据表的关联方式（join、left join、semi join等）、数据表的关联限制、模型ER图、模型包含字段、模型字段与维度的绑定关系、模型与指标的绑定关系。不过在实际使用过程中，面向业务和面向分析的模型有所不同，起源数据治理平台是面向分析的，所以主要的模型包括维度建模中的星型模型或雪花模型，再就是OLAP多维分析的MOLAP或ROLAP。模型管理如下图5、图6所示：
图5 起源数据治理平台数据表模型
图6 起源数据治理平台SQL模型
维度管理模块
维度管理模块包括基础信息和技术信息，对应着不同人员维护。其中基础信息对应维度的业务信息，由业务管理人员维护，包括维度名称、业务定义、业务分类。技术信息对应维度的数据信息，由数据开发工程师维护，包括是否有维表（是枚举维度还是有独立的维表）、是否是日期维、对应code英文名称和中文名称、对应name英文名称和中文名称。如果维度有维表，则需要和对应的维度表绑定，设置code和name对应的字段；如果维度是枚举维，则需要填写对应的code和name。维度的统一管理，有利于以后数据表的标准化，也方便用户的查看。
指标管理模块
指标管理模块核心包括基础信息和技术信息管理，衍生信息包括关联指标、关联应用管理。基础信息对应的就是指标的业务信息，由业务人员填写，主要包括指标名称、业务分类、统计频率、精度、单位、指标类型、指标定义、计算逻辑、分析方法、影响因素、分析维度等信息；基础信息中还有一个比较重要的部分是监控配置，主要是配置指标的有效波动范围区间、同环比波动区间等，监控指标数据的正常运行。
技术信息构成比较复杂，包括数据类型、指标代码，但是核心部分是指标与模型的绑定关系，通过使用演进形成了当前系统两类绑定关系：绑定物理模型和构建虚拟模型。绑定物理模型是指标与模型管理中的物理模型字段绑定，并配置对应的计算公式，或还包含一些额外的高级配置，如二次计算、模型过滤条件等；创建虚拟模型是通过已有指标和其对应的物理模型，具体步骤首先配置已有指标的计算方式或指标维度的过滤，然后选择指标已绑定的物理模型，形成一个虚拟模型，虚拟模型的分析维度就是所选指标基础模型的公共维度。
衍生信息中的关联指标、关联应用管理，是为了方便观察指标被那些其他指标和数据应用使用，这是因为指标技术信息采用了严格权限控制，一旦被使用为了保证线上的运行安全是禁止变更的，只有解绑并审核通过后才可以编辑，所以这些衍生信息就是方便管理人员使用。指标技术信息如图7所示：
图7 起源数据治理平台指标技术信息
业务管理
业务管理按照功能划分为业务线管理、主题管理和工单管理三部分，在系统的实际建设中是拆分为业务主题管理、数据主题管理和工单管理三大模块实现的。相关模块的建设主要保证业务人员和数据人员业务主题建设，相关模块的权限控制，业务流程审核，对应资源的隔离以及业务资源加工申请和加工过程的记录追踪。具体实现和功能如下：
业务主题管理
实现业务业务线管理和业务主题管理，实现不同业务线的管理以及业务线下的业务主题管理。业务线的拆分还隐藏着其他模块的权限管控和资源隔离的功能，不同业务线的用户只能看到有权业务线的指标和维度；而且业务线的用户划分为普通用户和管理员，分别查看或编辑维度和指标的业务信息。而且业务线和业务主题中分别维护的商分负责人对指标进行二级审核，因为新创建的指标仅仅是普通指标，如果想要全网都能查看，则需要发起认证，由这些人员审核。
数据主题管理
数据主题管理实现数据业务线和数据主题管理，实现不同数据线的管理以及数据线下的数据主题管理。数据线的拆分也隐藏着对数据表、模型、指标、维度的资源隔离和权限管控的功能，不同数据线的用户只能查看有权数据线的资源；而且数据线的用户分为普通用户和管理员，对有权资源进行查看或编辑。数据线的接口人在工单模块中具有审核工单的权限功能。数据主题的负责人拥有审核模型和指标技术信息的权限功能。
工单模块管理
工单模块管理实现了指标维度和对应模型加工线上申请、审核、加工、审批的流程。整个模块也是围绕着这四个流程实现的，具体是业务人员发起指标和维度集合的加工申请，然后由数据线接口人审核工单的合理性并分配对应的数据开发工程师，数据开发工程师加工模型并与对应的维度指标绑定，然后在工单中提交由数据接口人审核是否合理，最终由工单发起人验收。
这个流程是一个标准的工单流程，每个节点的业务流程可能会反复，但是每次操作都进行记录，方便业务人员后期追踪。工单管理如下图8所示：
图8 起源数据治理平台工单管理
安全管理
安全管理是起源数据治理平台核心功能之一，分为平台操作权限管理和接口调用权限管理两大部分。其中平台操作权限管理是通过与公司将军令权限管理系统打通，并配合平台其他模块中权限控制代码，实现了权限管理、审批、审计三大功能模块；接口权限管理是通过平台内的数据应用管理和外部应用管理模块的映射关系，并在接口调用时鉴权实现，这部分会在下面的应用管理章节中介绍。
权限管理模块
权限管理模块是将平台的资源分划分为页面权限、业务线&数据线用户权限、数据应用权限来实现的。页面权限实现平台内页面访问控制。业务线&数据线用户权限是将用户分类为普通用户和管理员，普通用户只能查看业务线和数据线内资源，管理员可以操作业务线和数据线内的资源；并且通过业务线和数据线的独立管理实现资源隔离，业务线实现了所属维度和指标的隔离；数据线实现了所属数据表和模型的隔离，并且通过建立业务线和数据线的关联关系，也保证了指标和维度的技术信息操作隔离。数据应用中每个应用都是独立管理的，每个应用权限都拆分普通用户和管理员，普通用户可以访问查询应用，管理员可以操作应用。
审批模块
审批模块包含审批工作流、我的申请、我的审批构成。审批工作流是根据不同的应用场景实现不同层级的审批，例如：在指标管理中服务于个人的普通指标变更为服务于整个业务线的认证指标，就需要发起两级审批，由业务主题负责人和业务商分审核通过才可以；模型管理中新增或修改模型上线，都需要数据主题负责人审批；数据应用的变更，都需要下游所有依赖外部应用负责人审批才生效。我的申请和我的审批是平台页面方便用户查看流程进度和操作审核。审批模块目标是保证发布信息的正确性、系统服务的稳定性。
审计模块
审计模块包括用户操作记录和记录查看追踪。用户操作记录是平台各模块调用接口记录用户每次操作前后的数据变更；记录查看追踪是检索查询页面，查看对应的变更。审计模块保证了用户操作追踪追责，也保证误操作的信息恢复。
应用管理
应用管理由数据应用、外部应用、数据地图三大模块组成，它们构成了对外服务的主体，记录了外部应用与平台内管理的指标、维度、模型和表的关联关系，也提供数据查询展示、应用层ETL生产的能力。而且数据开发人员从底层向上观察，可以追踪数据最终的所有流向；业务分析人员从顶层向下观察，可以看到构成服务的所有数据来源。
数据应用模块
数据应用模块是记录生成每个服务所需的指标、维度和数据模型的关系。每次服务中可以包含多个指标，这些指标可以来源于多个数据模型，不过不同的数据模型中需要包含公共维度，因为是通过这些公共维度将不同模型关联起来。
数据应用中构建的服务可以发布成查询服务、应用层ETL生产服务、对外API数据接口服务、通用报表配置服务，来满足业务的不同需求。数据应用管理如下图9所示：
图9 起源数据治理平台数据应用
外部应用模块
外部应用模块管理外部应用和应用内的模块，以及这些模块订阅的对应数据应用，目标是实现API接口调用的权限管理和数据最终流向的记录。具体的实现上模块首先创建对应的外部应用，记录外部应用的名称、URL、APPKEY等信息，然后由对应应用的负责人创建模块，记录模块名称、URL、moduleKey等信息。这些信息完善后，由对应的数据应用赋权给对应的模块，建立起数据应用与外部应用的联系。最后在外部应用调用平台对外API接口时，进行权限管理。
数据地图
数据地图功能是追查数据的流向，可以从数据表、模型、指标、数据应用、外部应用任意节点查看上游数据来源和下游数据去向。起源数据治理平台核心功能也是组织这些节点间的关系，形成完整的服务，数据地图就是通过上面介绍模块记录的关系，追踪数据流向，方便数据开发人员和业务分析人员了解数据消费和数据来源。数据地图如下图10所示：
图10 起源数据治理平台数据地图
对外API
对外API接口是一套完整的对外信息提供接口，提供的功能分为元数据信息类的接口、数据类接口、监控统计类接口，分别满足外部平台和分析人员的对应需求。外部系统通过起源数据治理平台获取到的元数据和数据是经过认证并由平台自动校验后的，可以保证信息的一致性、正确性。
元数据信息接口
元数据信息接口提供的包括指标、维度业务元数据信息和数据表、模型、指标计算、维度维表相关的数据元数据信息，实现与上游系统信息共享，达到信息一致性的目标。
数据类接口
数据类接口提供指标维度数据查询服务，不单单满足常见的单条SQL查询，而且可以实现多次查询聚合运算（例如：同环比等）以及跨引擎查询，并通过并发处理，可以有效提升查询效率，满足更多的业务场景。接口具有监控功能，能够评估每次查询效率，提供查询指导或预警的能力。
监控统计类接口
监控统计类接口提供指标数据监控信息、指标维度使用统计、数据接口的调用效率统计等服务，帮助下游服务平台了解服务质量。
内部工作原理
起源数据治理平台内部工作原理就是实现指标、维度业务信息与数据模型计算关系的映射管理，并根据外部应用所需的指标、维度以及查询条件选择最优的模型动态的实现查询SQL或查询Query的拼接，然后通过分布式查询引擎实现数据的高效查询，具体过程如下图11所示：
图11 起源数据治理平台内部工作原理
上图所示的分布式查询引擎，整合了大数据分析常见的各种存储，通过封装的接口提供服务。而且分布式是通过Akka Cluster自主实现，通过Cluster Singleton解决单点故障的问题，通过Redis实现了任务队列的持久化，通过平衡子节点任务量实现任务的合理调度，通过查询状态监控自动实现查询降级和任务队列的拆解，并且也完善了整个调度的监控，可以实时查看任务和节点的运行情况。
管理流程
起源数据治理平台生产所需参与的角色包括：业务人员和数据开发人员（RD）。为了保证信息的正确性，平台内有着严格的管理流程，需要不同的角色在对应的节点进行维护管理，平台的管理流程如下图12所示：
图12 起源数据治理平台管理流程
所上图所示，指标的业务信息需要业务人员首先进行维护，然后数据RD同学进行相应的数据表的建设，维护对应的数据表和模型的元数据信息，并完成指标与模型的绑定，最后由数据RD同学构建数据应用为用户、业务系统及数据产品等提供服务。
建设成果
经过长时间的探索开发，完成了起源数据治理平台的建设，成功的解决了上面提到的问题，并且已经完成了酒旅内部10+个数据平台（包括定制化产品和通用报表服务平台）的数据治理支持。起源数据治理平台还带来了一些额外的收获，总结归纳起来实现了3个目标，提供了4种能力，如下：
· 统一指标管理的目标。保证指标定义、计算口径、数据来源的一致性。
· 统一维度管理的目标。保证维度定义、维度值的一致性。
· 统一数据出口的目标。实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。
· 提供维度和指标数据统一监控及预警能力。
· 提供灵活可配的数据查询分析能力。
· 提标数据地图展示表、模型、指标、应用上下游关系及分布的能力。
· 提供血缘分析追查数据来源的能力。
如果换位到指标的角色，以辩证的角度分析，起源数据治理平台解决了一个终极哲学问题：我是谁，我从哪里来，我到哪里去。
未来展望
起源数据治理平台是天工体系（从数据管理、查询到展示的一个完整生态）的一部分，整个天工体系还包括如意通用报表系统、筋斗云数据查询系统。通过对天工体系的建设，直接目标是为业务提供一整套高效、高质量的数据服务平台；但是在天工体系的建设中，进行微服务治理，抽象形出一套统一标准，吸纳更多的业务参与建设，为业务提供开发降级，避免服务的重复建设，提升服务建设速度。如下图13所示：
图13 天工体系架构图
如上图所示，天工体系开放三套交互标准，实现模块的可插拔和自由扩展，分别是：
· 元数据交互标准，实现元数据管理的可插拔。
· 数据查询标准，实现数据查询引擎的可插拔。
· 可视化组件数据交互标准，实现可视化组件的可插拔。
股份制改革对我国银行业来说只是一个开始，企业在风险管理、创造价值等方面还有很长的路要走。风险管理要求提供精准的数据模型、创造价值要求充分银行数据资产，这是数据治理的外部推动因素。此外，随着第三次工业革命的到来，银行业也需要进入定制化时代，以更低的成本，生产多样化的金融产品，从而满足不同顾客的不同需求。对数据本身而言，业务发展加快了数据膨胀的速度，也带来了数据不一致等问题，业务部门的频繁增加和剥离同样会对数据治理提出挑战。这些日益复杂的内外因决定了我国银行业对数据治理的超高标准要求，而目前对应的经验能力却稍显薄弱。
数据治理不仅需要完善的保障机制，还需要理解具体的治理内容，比如我们的数据该怎么进行规范，元数据又该怎么来管理，每个过程需要哪些系统或者工具来进行配合呢？这些问题都是数据治理过程中最实际的问题，也是最复杂的问题，今天我们将从数据治理的各个核心领域来解答这些问题。
银行数据治理核心领域
每个数据治理的领域都可作为一个独立方向进行研究治理，目前总结的数据治理领域包括但不限于一下内容：数据标准、元数据、数据模型、数据分布、数据存储、数据交换、数据生命周期管理、数据质量、数据安全以及数据共享服务。
同时各领域之间需要有机结合，如数据标准、元数据、数据质量等几个领域相互协同和依赖。通过数据标准的管理，可以提升数据合法性、合规性，进一步提升数据质量，减少数据生产问题；在元数据管理的基础上，可进行数据生命周期管理，有效控制在线数据规模，提高生产数据访问效率，减少系统资源浪费；通过元数据和数据模型管理，将表、文件等数据资源按主题进行分类，可明确当事人、产品、协议等相关数据的主数据源归属、数据分布情况，有效实施数据分布的规划和治理。
数据治理领域是随着银行业务发展而不断变化的，领域之间的关系也需要不断深入挖掘和分布，最终形成一个相互协同与验证的领域网，全方位的提升数据治理成效。
数据治理核心领域
1.数据模型
数据模型是数据治理中的重要部分，合适、合理、合规的数据模型，能够有效提高数据的合理分布和使用，它包括概念模型、逻辑数据模型和物理数据模型，是数据治理的关键、重点。数据模型包含三个部分，数据结构、数据操作、数据约束。
数据结构。数据模型中的数据结构主要用来描述数据的类型、内容、性质以及数据间的联系等。数据结构是数据模型的基础，数据操作和数据约束都基本是建立在数据结构的之上的。不同的数据结构有不同的操作和约束。
数据操作。数据模型中的数据操作主要用来描述在相应的数据结构上的操作类型和操作方式。
数据约束。数据模型中的数据约束主要用来描述数据结构内数据间的语法、词义联系、他们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效和相容。
2.元数据管理
元数据分为业务元数据、技术元数据和操作元数据，三者之间关系紧密。业务元数据指导技术元数据，技术元数据以业务元数据为参考进行设计，操作元数据为两者的管理提供支撑。
业务元数据。业务元数据是定义和业务相关数据的信息，用于辅助定位、理解及访问义乌信息。业务元数据的范围主要包括：业务指标、业务规则、数据质量规则、专业术语、数据标准、概念数据模型、实体/属性、逻辑数据模型等。
技术元数据。它可以分成结构性技术元数据和关联性技术元数据。结构性技术元数据提供了在信息技术的基础架构中对数据的说明，如数据的存放位置、数据的存储类型、数据的血缘关系等。关联性技术元数据描述了数据之间的关联和数据在信息技术环境之中的流转情况。技术元数据的范围主要包括：技术规则（计算/统计/转换/汇总）、数据质量规则技术描述、字段、衍生字段、事实/维度、统计指标、表/视图/文件/接口、报表/多维分析、数据库/视图组/文件组/接口组、源代码/程序、系统、软件、硬件等。技术元数据一般以已有的业务元数据作为参考设计的。
操作元数据。操作元数据主要指与元数据管理相关的组织、岗位、职责、流程，以及系统日常运行产生的操作数据。操作元数据管理的内容主要包括：与元数据管理相关的组织、岗位、职责、流程、项目、版本，以及系统生产运行中的操作记录，如运行记录、应用程序、运行作业。
很多初学者，对大数据的概念都是模糊不清的，大数据是什么，能做什么，学的时候，该按照什么线路去学习，学完往哪方面发展，想深入了解，想学习的同学欢迎加入大数据学习扣裙：805+127+855，有大量干货（零基础以及进阶的经典实战）分享给大家，并且有清华大学毕业的资深大数据讲师给大家免费授课，给大家分享目前国内最完整的大数据高端实战实用学习流程体系
3.数据标准
数据标准是银行建立的一套符合自身实际，涵盖定义、操作、应用多层次数据的标准化体系。它包括基础标准和指标标准（或称应用标准）。与数据治理其他核心领域具有一定的交叉，比如元数据标准、数据交换和传输标准、数据质量标准等。商业银行的数据标准一般以业界的标准为基础，如国家标准、监管机构（如国家统计局、中国人民银行、工信部）制定的标准，结合商业银行本身的实际情况对数据进行规范化，一般会包括格式、编码规则、字典值等内容。良好的数据标准体系有助于商业银行数据的共享、交互和应用，可以减少不同系统间数据转换的工作。数据标准的主要由业务定义、技术定义和管理信息三部分构成。
数据标准的主体构成
业务定义。业务定义主要是明确标准所属的业务主题以及标准的业务概念，包括业务使用上的规则以及标准的相关来源等。对于代码类标准，还会进一步明确编码规则以及相关的代码内容，以达到定义统一、口径统一、名称统一、参照统一以及来源统一的目的，进而形成一套一致、规范、开放和共享的业务标准数据。
技术定义。技术定义是指描述数据类型、数据格式、数据长度以及来源系统等技术属性，从而能够对信息系统的建设和使用提供指导和约束。
管理信息。管理信息是指明确标准的所有者、管理人员、使用部门等内容，从而使数据标准的管理和维护工作有明确的责任主体，以保障数据标准能够持续的进行更新和改进。
4.数据质量管理
数据质量管理已经成为银行数据治理的有机组成部分。高质量的数据是商业银行进行分析决策、业务发展规划的重要基础，只有建立完整的数据质量体系，才能有效提升银行数据整体质量，从而更好的为客户服务，提供更为精准的决策分析数据。
制度和规范。从技术层面上，应该完整全面的定义数据质量的评估维度，包括完整性、时效性等，按照已定义的维度，在系统建设的各个阶段都应该根据标准进行数据质量检测和规范，及时进行治理，避免事后的清洗工作。
数据质量评价维度
明确相应的管理流程。数据质量问题会发生在各个阶段，因此需要明确各个阶段的数据质量管理流程。例如，在需求和设计阶段就需要明确数据质量的规则定义，从而指导数据结构和程序逻辑的设计；在开发和测试阶段则需要对前面提到的规则进行验证，确保相应的规则能够生效；最后在投产后要有相应的检查，从而将数据质量问题尽可能消灭在萌芽状态。数据质量管理措施，宜采用控制增量、消灭存量的策略，有效控制增量，不断消除存量。
商业银行数据质量管理流程
5.数据生命周期管理
任何事物都具有一定的生命周期，数据也不例外。从数据的产生、加工、使用乃至消亡都应该有一个科学的管理办法，将极少或者不再使用的数据从系统中剥离出来，并通过核实的存储设备进行保留，不仅能够提高系统的运行效率，更好的服务客户，还能大幅度减少因为数据长期保存带来的储存成本。数据生命周期一般包含在线阶段、归档阶段（有时还会进一步划分为在线归档阶段和离线归档阶段）、销毁阶段三大阶段，管理内容包括建立合理的数据类别，针对不同类别的数据制定各个阶段的保留时间、存储介质、清理规则和方式、注意事项等。
数据生命周期中各参数间的关系
从上图数据生命周期中各参数间的关系中我们可以了解到，数据生命周期管理可以使得高价值数据的查询效率大幅提升，而且高价格的存储介质的采购量也可以减少很多；但是随着数据的使用程度的下降，数据被逐渐归档，查询时间也慢慢的变长；最后随着数据的使用频率和价值基本没有了之后，就可以逐渐销毁了。
6. 数据分布和存储
数据分布和存储主要涵盖了数据如何划分和存储，总行系统以及总分行数据如何分布，主数据及参考数据（也称为副本数据或者辅数据）如何管理。只有对数据进行合理的分布和存储，才能有效的提高数据的共享程度，才能尽可能的减少数据冗余带来的存储成本。
通常情况下，综合数据规模、使用频率、使用特性、服务时效等因素，从存储体系角度，可以将商业银行的数据存储划分为四类存储区域，即交易型数据区、集成型数据区、分析型数据区、历史型数据区。
1、交易型数据区。交易型数据区包括渠道接入、交互控制、业务处理、决策支持与管理等各类联机应用数据；存储客户自助或与银行操作人员在业务交互办理过过程中产生的原始数据的存储，包括业务处理数据，内部管理数据和一些外部数据，其存储的是当前状态数据。
2、集成型数据区。集成型数据区包括操作型数据（OLTP）和数据仓库型数据（OLAP）。
3、分析型数据区。分析型数据主要是用于决策支持与管理的各类集市应用的数据。为了对业务执行情况进行深入分析，需要对原始数据进行进一步汇总统计分析，统计分析结果用于最终的决策展示，因此分析型数据区存储了这些统计、分析模型结构的指标数据。
4、历史数据区。这里存储了所有近线应用、归档应用、外部审计数据平台应用等的数据，主要满足各种历史数据归档后的数据保管和数据查询服务。
数据存储布局
7.数据交换
数据交换是银行进行数据交互和共享的基础，合理的数据交换体系有助于银行提高数据共享程度和数据流转时效。一般商业银行会对系统间数据的交换规则制定一些原则，比如对接口、文件的命名、内容进行明确，规范系统间、银行系统与外部机构间的数据交换规则，指导数据交换工作有序进行。建立统一的数据交换系统，一方面可以提高数据共享的时效性，另一方面也可以精确掌握数据的流向。
8.数据安全
商业银行的重要且敏感数据大部分集中在应用系统中，例如客户的联络信息、资产信息等，如果不慎泄露，不仅给客户带来损失，也会给商业银行带来不利的声誉影响，因此数据安全在数据管理和治理过程中是相当重要的。
数据存储安全。包括物理安全、系统安全存储数据的安全，主要通过安全硬件的采购来保障数据存储安全。
数据传输安全。包括数据的加密和数据网络安全控制，主要通过专业加密软件厂商进行规范设计和安装。
数据使用安全。需要加强从业务系统层面进行控制，防范非授权访问和下载打印客户数据信息；部署客户端安全控制工具，建立完善的客户端信息防泄漏机制，防范将客户端上存储的个人客户信息非授权传播；建立完善的数据安全管理体系，建立数据安全规范制度体系，组建数据安全管理组织机构，建立有效的数据安全审查机制；对于生产及研发测试过程中使用的各类敏感数据进行严密管理；严格与外单位合作中的个人客户信息安全管理等。
9.数据服务
数据的管理和治理是为了更好的利用数据，是数据应用的基础。银行应该以数据为根本，以业务为导向，通过对大数据的集中、整合、挖掘和共享，实现对多样化、海量数据的快速处理及价值挖掘，利用大数据技术支持产品快速创新，提升以客户为中心的精准营销和差异化客户服务能力，增强风险防控实时性、前瞻性和系统性，推动业务管理向信息化、精细化转型，全面支持信息化银行的建设。
建立结构化数据处理分析平台。数据仓库建设能够实现企业异构数据的集成，企业按照分析主题重组数据，建立面向全行的一致的信息视图。下图是一个典型的银行数据仓库服务体系：
银行典型的数据仓库服务体系
数据资产视图。在建立了数据仓库之后，需要建立统一的分析和可视化平台，解决数据在哪里，数据怎么用的问题。一个典型的应用是建立全行统一客户视图，包含客户信息统一视图、客户信息风险视图和网点业绩视图。
数据资产视图示例
数据治理的展望
数据治理不是一个临时性的运动，从银行业务发展、数据治理意识形成、数据治理体系运行的角度，需要一个长效机制来进行保证。在大数据时代，经过数据治理的银行数据可以发挥更大的作用。
1
利用大数据挖掘技术分析各类海量信息，发现市场热点与需求，实现产品创新服务
可以将大数据应用到产品生命周期，深入挖掘客户需求，把握客户痛点，推动产品创新。利用大数据技术对社交网络信息、在线客户评论、博客、呼叫中心服务工单、用户体验反馈等信息进行深度挖掘和分析，充分洞察客户，分析客户的情绪，了解客户对产品的想法，获知客户需求的变化趋势，从而对现有产品进行及时的调整和创新，事情贴近客户的生活场景和使用习惯。
基于大数据创新产品评价方法，为产品创新提供数据支撑。通过大数据分析，改变目前以规模、总量为主的业务评价方式，建立一整套完整的以质量、结构为主的全新的评价方式，以引导全行真正追求有质量、有效益的发展。
2
加强内外部信息联动，重点利用外部信息提升银行风险防控能力
进一步加强与税务、海关、法院、电力部门、水务部门、房产交易登记中心、环保部门以及第三方合作机构的数据互联共享，有效拓宽信息来源渠道，深度挖掘整合系统内外客户信息、关联关系、交易行为、交易习惯、上下游交易对手、资金周转频率等数据信息，利用大数据技术查找与分析不同数据变量间的关联关系，并建立相应的决策模型，提升银行风险防控能力。
在信用风险方面，可以结合外部数据，完善信用风险防范体系，基于可视化分析有效防控信用风险的传导。引入大数据理念和技术，统一信用风险模型管理，构建覆盖信用风险训练、模型管理、日常预警、评分评级、客户信用视图以及业务联动控制的信贷大数据平台，建立多维度、全方位的缝隙爱你预警体系。
在市场风险方面，基于市场信息有效预测市场变动，基于大数据处理技术提升海量金融数据交易的定价能力，构建定价估值引擎批量网格计算服务模式，支持对海量交易的实时定价，有效提升银行风险管控与定价能力，为金融市场业务的发展提供有力支撑。
在操作风险方面，依托大数据信息整合优势，有效防控操作风险。通过可视化技术，从业务网数据中发现识别风险线索，实现由“风险监控”向“业务监控”模式转变，提升风险的提前预警能力。加强跨专业风险监控模型的研发，通过由点带线、由线及面的矩阵式关联监控，提前识别风险交织趋势，防范风险传染。
3
利用大数据技术提升经营管理水平，优化业务流程，实现精细化经营决策
在经营决策方面，通过外部数据的补充和整理，实现经营分析外延的拓展，从市场和经营环境的高度分析各级机构的发展方向、竞争压力，制定更合理、更有效的经营策略。同时，应用大数据可视化技术，实现复杂分析过程和分析要素向用户的有效传递，增强分析结果说服力和指导性，向经营人员提供有力的信息支撑。
在资源配置方面，依托大数据采集和计算能力，提升测算的敏感性和有效性，加强财务预测的可靠性和有效性，为总体资源配置提供更好的信息支撑，实现对具体资源配置的动态管理。
在过程改进方面，优化业务流程，对交易、日志的专业挖掘，探索当前业务处理流程节点的瓶颈，寻求最有的解决方案。比如通过分析客户从排队到等候完成全部交易的流程合理性，提出过程改进方法，提升网点整体运营效率和客户体验。
在运维保障方面，基于流数据处理技术，搭建准实时的应用交易级监控平台，实现交易运行情况的即时监控，保障业务运行稳定高效。