【IT168 案例】

　　价值点评：支付宝案例是一个自主开发、技术创新实现元数据应用管理价值的独特案例。跳过市面上元数据管理工具少则几十万多则上百万的费用，支付宝用创新技术自主开发出符合CWM标准的元数据管理平台，也许并不适合每一家企业借鉴，但却给更多的企业以思路和信心。

　　支付宝(中国)网络技术有限公司是国内领先的独立第三方支付平台，由阿里巴巴集团创办。支付宝致力于为中国电子商务提供“简单、安全、快速”的在线支付解决方案。

　　支付宝公司从2004年建立开始，始终以“信任”作为产品和服务的核心，以技术的创新带动信用体系完善的理念。截止到2010年6月底，支付宝注册用户突破3.5亿，日交易额超过14亿，日交易笔数达到550万笔。

　　应用场景描述：智能决策引发元数据需求

　　元数据管理是BI系统建设的重要环节，BI是企业各应用数据集成与深度挖掘展现。支付宝BI数据来源于已有的11大业务系统及新增业务系统，支付宝BI有自主知识产权的建表、调度系统、ETL开发工具、监控系统等多个子系统集合而成，不同子系统以不同格式保存且用户界面不同，不利于业务人员和技术人员对于元数据的管理和使用。

　　在进行智能决策与采取信息化行动时 ，分析人员和决策人员需要根据自己需求来获取与数据仓库中数据的关系。仓库开发人员需要知道数据流向调用依赖、查询指标的数据来源哪些业务系统，是通过了哪些表、中间表、临时表或字段通过何种规则计算来的等。

　　要解决这些问题需要数据标准的建立和对元数据自动获取、ETL过程自动解析、集成和访问，以及建立一个综合的查询展现平台。建立元数据模块符合CWM标准的元数据管理平台，为支付宝BI模型逻辑设计、物理设计、运行、维护整个建设、扩充和数据交换打下基础。

　　案例技术细节：符合CWM标准的元数据管理平台

　　支付宝元数据建设已经进行三期：一期核心建立ETL过程依赖关系自动化分析，元数据的自动化采集;二期核心完善数据标准化与自动获取各个系统元数据并加以整合;三期核心提供完善的元数据综合查询，以及影响分析功能与对外其它BI软件接口服务。

　　1.通过对Oracle SQL解析算法，输出ETL程序与输入输出表、关联条件等。

　　该解析器采用lex&yacc进行语法解析器开发，采用多种分析算法，通过对ELT运行日志进行定时分析，及对各种复杂SQL分析得到表(视图)、字段、函数、常量等。经过算法处理，把SQL元素中复杂嵌套表达关系简化为：column、table、query、scalar、predicate、condition和SQL之间的关系，再由分解算分得到数据目标表、目标字段、源表、 源表字段、条件、关系等。

　　2.根据CWM元数据标准进化的支付行业数据仓库元数据模型。

　　根据CWM元数据标准，从2009年开始的元数据项目旨在规范业务数据管理并转化为分析信息，以增强支付宝数据资产可重用性，提高管理水平，规范业务流程，加强挖掘预测和决策的科学性。

　　支付宝数据仓库5层结构6大主题，分别对用的是会员、商户、交易、资金、产品、CTU。各个主体域分别支撑着每一块分析业务。每个主题的模型以星型模型为主，模型的事实表、维表都以关系的形式存储。维表、事实表从多个业务数据表抽取相关列生成，所有加载转换过程是采用自主开发的数据适配中间层TCL来实现ELT。仓库的数据来源涉及到13大业务系统，以及数以千台数据库服务器、分布式文件系统等。展现采用BO以及自主研发报表工具。模型内容包括业务数据的抽取、事实表的内容结构、数据的配物理配置等。

　　因此，通过CWM元数据标准建立模型，描述它们至少需要用到CWM的多个包：Transformation、Relational、SoftwareDeployment、KeysAndIndexs、DataType、Instance、Typemapping、Resource、Multidimensional、WarehouseProcess和WarehouseOperation等11个包。

　　资金主题中资金表是经过17张业务表抽取相应内容生成，其中包括资金交易流水、时间、资金各种状态、金额、资金类型、交易来源、银行订单号、对账信息、财务信息等，其中id(序列号是资金主题银行订单管理表的主键)，在CWM的描述范畴中。

　　这三个表以及事实表都是Relational包中Table类的实例，而抽取过程则是Transformation包中Transformation类的一个实例。三个业务表和事实表分别对应了Transformation类转换源和转换目标，各个列则是Relational包中Column类的实例，其中用户序列号还与会员主题中会员主表关键字对象关联，后者是Relational包中PrimaryKey类的一个实例，它们之间的关联继承自KeysAndIndexs包中。另外，抽取过程属于某个转换任务(TransformationTask的实例)，该转换任务以存储过程的方式在服务器上安装实现。因此，对于BI模型及ETL转化过程的CWM描述需要采用申述的各类包来进行。

　　3.自定义存储数据结构支持的影响分析。

　　通过对SQL内容进行分析得出以下结论：

　　n SQL类型有：INSERT、QUERY、UPDATE、DELETE、ALTER、DROP等;

　　n SCALAR：表达字段与字段、常量、函数、SQL等之间的关系;

　　n CONDITION：类型有：WHERE、HAVING、CASE WHEN等;

　　n PREDICATE：表达SCALAR与SCALAR、COLUMN、常量等之间的关系;

　　n TABLE：FROM表达式中的TABLE，也有可能是一个子查询;

　　n COLUMN：字段信息。

　　通过对结论分析存储模型可以定义为：

　　n PDS_Condition条件查询、PRS_SQL标准SQL语句存放表;

　　n PRS_PREDICATE断言、PRS_tab信息表;

　　n PRS_scalar表、PRS_columns字段信息表

　　来共同组成复杂的SQL解析存储模型。

　　4.自主产权的元数据综合查询界面及影响(血缘)分析。

　　元数据CWM标准模型设计、采集设计、SQL解析器设计与开发全部是为了元数据的应用做服务，元数据结构规划采用5层设计。

　　n 源系统层：元数据主要提供者，涵盖DW、业务类系统。

　　n 采集桥接器：结构化、非结构化元数据的采集分析接口。

　　n 元数据存储层：元数据存储时元数据管理实现的核心，存储层为功能应用提供信息支撑。

　　n 功能管理层：元数据的维护接口、实体关联度分析接口、版本管理接口、变更通知接口、实体查询接口、影响分析接口、血统分析接口、导入导出接口、实体差异分析接口、元数据访问配置接口、管理接口。

　　n 访问接口层：元数据的维护、实体关联度分析、版本管理、变更通知、实体查询、影响分析、血统分析、导入导出、实体差异分析、元数据访问等展现。

　　截止到现在，实现了元数据综合查询：通过某一个元数据可以查询该元数据的业务来源到报表展现层数据流关系，某张表、字段变动对其他表、字段等影响有哪些;还可以查询到仓库在日常运维中数据质量监控、数据分发中心的数据情况。

　　案例实施效果：技术创新带来更好实施效果

　　目前市场上的元数据管理工具，如IBM DataStage的MetaStage、Informatica的Superglue等元数据管理工具的费用少则几十万多则上百万，而实施效果需要更多的评估。在自主知识产权的SQL mapping分析器下，基于标准CWM的元数据模型，再花费几名开发人员的情况下效果更好，100%适应自身元数据应用需求的最好效果。

　　支付宝元数据管理平台的案例显示，采用Oracle、Greenplum、DB2作为BI数据库，在ELT数据加工过程中效果优秀。同时，该案例也体现出如下技术创新之处：

　　1.通过对Oracle SQL自实现解析算法，输出ETL程序与输入输出表、关联条件等。

　　在BI行业，很多抽取过程采用ELT方式，通过自主开发的Mapping解析器，将SQL中的字段、表、常量及他们之间的关系，存储在数据库的SQL存储模型中，以便做mapping和其他分析。

　　2.根据CWM元数据标准进化的支付行业数据仓库元数据模型。

　　根据标准CWM元数据标准，规范业务数据管理并转化为分析信息，把支付宝数据仓库5大层次6大主题等信息通过元数据CWM模型多个包进行标准的元数据描。

　　3.自定义存储数据结构支持的影响分析

　　通过自定义SQL mapping二叉树的支持来展现影响分析、血缘分析等应用。