一、为什么要做数据标准管理
数据治理的问题并不仅仅只是治理数据本身,其最终目标是提升数据价值,它是一个包括组织、制度、流程、工具的管理体系。去年我曾写过一篇关于数据治理的文章《数据治理落地难?携程度假数据治理需求设计实践》,从团队提效、需求梳理、模型设计、指标管理四个方面分享了携程度假在数据治理中的经验。
数据治理不是简单的一次性的行为,它是一个长期持续性的项目集,要想通过数据治理将企业的数据管理、数据应用水平提升到新高度,而不是沦为理论实践两张皮,需要跨组织职能的协调以及在数据治理的各环节中将标准管理落实到位。
数据治理是涵盖数据的采集、处理、分析、使用的全流程管理体系,数据标准则是数据治理各项活动的基础,是企业数据治理理论和方法与实际信息系统和数据的桥梁。携程度假的实践经验总结发现,数据标准管理需要包含以下三要素:
范围:成功的数据治理应当是清楚地了解需要治理什么
工具:对规范数据治理活动标准提供系统的支持
制度:对在人员和流程方面的行为方式及有效地使用工具提供指导
二、数据标准管理在携程度假的实践
下文将从数据管理的两个核心领域中选取部分案例来分享一下携程度假在数据治理方面的探索与实践:
2.1 数据集成
携程度假覆盖的数据源有业务系统类的结构化数据、埋点日志类的半结构化数据及其他内容类的非结构化数据。数据集成不仅只是解决技术上的从源端抽取到数据中台,其数据内容的变更通常会对现有流程及下游的数据应用产生影响,因此基础数据的管理重点在于变更管理和统一标准管控。这里会介绍针对结构化数据生产变更的标准管理。
2.1.1 生产变更的标准管理
生产变更的标准管理主要解决了以下问题:
第一、哪些变更是需要通知的?
1)结构类变更,这部分的操作都会经过数据库的DDL转换,所以方案上只需要监听变更消息,自动进行解析出核心的变更信息,比如库名、表名、表OWNER、变更类型(新增/修改/删除)、变更对象(表/字段)等,并且定义一个标准的数据结构用于通知。目前工具可以对以下类型的变更做自动化感知及通知:
2)内容类变更,这部分往往通过系统化的方式无法感知到,需要对应表的研发评估出影响面,并线下周知下游。这种方式常常会有两种问题产生,其一是影响面评估不准——漏报;其二是依赖人的责任心——忘报。目前工具可以对以下类型的变更做线上人工提报及通知:
第二、变更通知谁(影响范围)?
能评估全、评估准生产变更对于数据侧的影响面及通知人对于研发侧的TO来说是一件有挑战的事情。但从数据中台能力的角度而言,数据血缘是一个中台基础元数据组件,其中已经包含了完整的关系信息,表与人、表与表、表与字段、字段与字段等,我们可以基于这些关系信息建立起影响分析的能力。
目前携程度假的感知做到了ODS层,如图,TO在界面上选择相应的库和表,影响分析就能识别展示出相关的影响面及通知人。下一阶段我们还将打通应用端的影响分析,将会通过整合应用端数据血缘信息覆盖到数据应用终端的影响面识别。
第三、有工具如何能保证强执行?
生产变更制度与流程:
1)当生产发生变更时,通过自动化感知或TO在线提报的方式通知到下游相关数据OWNER,正常境况下都会有一定的时间余量。
2)数据OWNER接收到生产变更通知后,需要及时确认影响面,必要的沟通确认还是不可缺少的重要环节,并评估改动成本及计划时间。
3)无论是自动感知还是在线提报,都有可能由于人为因素导致执行不到位,所以必须对于所有的变更感知方式有一个事后的DQC告警,同时告警的能力最好能够做到T+0,因为可以及时感知告警在第一时间处理解决,保障任务的基线和数据应用不受影响。
4)最后需要把质量闭环加入到流程中,保证在流程中发现的问题和由于人为因素导致的执行不到位能定期反馈到QA或者在质量会上曝光,以此来提升大家的质量意识,形成良性循环。
2.2 元数据管理
元数据对于数据管理和数据使用来说都是必不可少的。所有大型组织都会产生和使用大量的数据,在整个组织中,不同的人拥有不同层面的数据知识,但没有人知道关于数据的一切。因此,必须将这些信息记录下来,否则组织可能会丢失关于自身的宝贵知识。
元数据管理提供了获取和管理组织数据的主要方法,建立业务术语表,用于定义和定位组织中的数据,确保组织中数量繁多的元数据被管理和应用。假如没有可靠的元数据,组织就不知道它拥有什么数据,为保证其高质量,应把元数据当作产品来进行管理。好的元数据不是偶然产生,而是认真计划的结果。这里介绍携程度假对于业务元数据的标准管理。
2.2.1 业务元数据的标准管理
业务元数据的标准管理主要解决了以下问题:
第一、数据地图中的业务元数据需要覆盖哪些?
携程度假的数据地图工具集成了模型、指标、看板、数据集四种业务元数据,除了元数据信息的搜索与展示,也打通了权限申请流程及在线管理的功能。
第二、如何管理并维护准确一致的元数据?
数仓模型建表的流程需要严格遵守建表工具规范,主要的元数据信息有:
分层:按照经典建模分层思路,分为ODS层(操作数据层),EDW层(明细数据层),CDM层(汇总数据层),ADM层(数据应用层),MID层(中间层),DIM层(维度层)
一级主题:按照数据域进行划分,例如常规的订单域、日志域、商品域、服务域等
二级主题:按照业务线进行划分,度假包含的业务线较多,例如团队游、门票、用车、租车等
分区类型:全量分区或增量分区
重要等级:标识表的重要程度优先级,分为P0-P3
敏感级别:标识商密与个密敏感程度,分为L1-L4
建表工具会根据元数据的选择自动生成标准的建表语句模板,其中包含了表名规范、字段名及注释规范等,表owner根据工具的引导完成表名及表的逻辑结构的设计,并将这些信息和完整的注释通过工具提交建立正式表。
指标的定义是由组成指标的业务术语构建而成,主要的业务术语有:
数据域:指面向业务分析,将业务过程或者维度进行抽象的集合。例如常规的订单域、日志域、商品域、服务域等
业务过程:指企业的业务活动事件。例如订单域中的下单、支付、退款等
时间周期:指用来明确数据统计的事件范围或者时间点。例如最近30天、最近半年、截至当日等
修饰词类型:指对修饰词的一种抽象划分。例如商品维度-商品类型、时间维度-预定日期、渠道维度-分销渠道等
修饰词:指除了统计维度外指标的业务场景限定抽象。
原子指标:指基于某一业务行为下的度量,是业务定义中不可再拆分的指标。例如成交-订单数
维度:指用来反应业务的一类属性,这类属性的集合构成一个维度。例如商品维度、时间维度、渠道维度等
维度属性:指隶属于一个维度下的属性值。例如地理维度下的城市ID、城市名称、所属国家等
派生指标:派生指标=业务线+一个原子指标+多个修饰词(可选)+时间周期。例如团队游_成交-订单数
指标的设计与注册必须严格遵守指标的定义规范,且在指标管理系统中进行操作,所有上述的业务属于都在系统后台事先进行标准化,标准化的内容包括术语的命名、分类以及准确的定义。原子指标和派生指标的生成过程都是基于标准化的组装,所有的相关信息也是结构化的自动生成。
指标实践中在最终生成一个派生指标完整元数据时,有两个设计上必须考虑到两点:
第一,指标的口径必须有一个明确的业务维护人而不应该只有一个数据开发owner,关于指标的生命周期管理(变更或者下线)都是需要指标业务owner收口,这样才能保证指标的定义和业务的一致性;
第二,在业务术语定义标准结构化的同时,最好加上一个业务话术的定义描述,便于业务更好的理解指标的业务含义。
第三、数据地图如何更好的帮助业务使用数据?
业务门户看板是固化场景的数据查询分析入口,其中包含了标准化的指标、筛选条件及可视化图表。由于前端展示的个性化需求,指标的展示名称往往不能直接反应指标的口径,往往存在同名不同意的情况,导致业务汇报及使用数据的混乱或需要频繁的线下沟通及确认。
门户看板的指标应用标准化就是通过整合数据地图的指标元数据,在看板工具中强制需要绑定标准化过的指标ID,即已在指标管理系统中维护的指标,在前端的交互上,会清晰的显示出相关指标的指标定义,如果业务还需要进一步查看更多元数据信息,也可以跳转到具体指标信息详情页,会有更多的相关信息可供业务查看。
除了固化场景的看板与数据集,自助取数是另一个让业务能快速利用数据解决业务分析的通道。但对于业务而言,自身对于数据的理解程及取数能力往往远低于门槛线,自助取数中的效率和质量都难以达到相对可用的标准。
自主分析的取数场景标准化就是通过固化相对标准且注释清晰的取数场景模板,简化业务方编写SQL代码的能力,通过简单参数的修改,一键查询即可跳转至自助取数平台进行业务分析。
三、总结与思考
数据管理是一个复杂的过程,在这个过程中绝不仅仅只是数据团队的努力,要将制定制度和实施细则,在组织内多个层次上实践数据管理,并参与组织变革管理工作,积极向组织传达改进数据治理的好处以及成功地将数据作为资产管理所必须的行为。
企业的数据战略必须和业务战略目标保持高度一致,即使拥有最佳的数据战略,数据治理和数据管理计划也可能不会成功,除非企业愿意接受并进行管理变革。数据治理越显著地帮助解决组织问题,才会有越来越多的人去接受改变、去接受数据治理实践。
携程度假的数据治理之路还很漫长,其中也参考了不少领域中优秀成熟的治理思路与方案,希望本文的一点点实践经验能给读者带来一点点的帮助。
CIO之家 www.ciozj.com 公众号:imciow