云计算·大数据 频道

数据中台建设中的“通用化+标准化+敏捷性”

  对于一个企业,数据中台核心使命,沉淀有价值数据,形成企业数据共享,数据服务或应用于企业各部门、各领域的工作。

  从技术视角,数据中台是一种数据管理体系,最重要的目标是支持各部门业务数据和提供计算服务。数据中台的本质就是“数据仓库+数据服务中间件”。

  从业务视角,数据中台是指通过完成企业内外部多源异构的数据采集、治理、建模、分析、应用,打通数据孤岛实现数据集中管理应用,成为企业数据资产管理中枢。

  数据中台数据模型的分层,业界比较通用的分层方式是将数据模型分为5层:

  ①ODS(Operate Data Store,操作数据层)

  ②DIM(Dictionary Data Layer ,维度数据层)

  ③DWD(Data Warehouse Detail ,明细数据层)

  ④DWS(Data Warehouse Service,汇总数据层)

  ⑤ADS(Application Data Store,数据应用层)

  数据中台发展历程

  数据中台为行业熟知,由阿里兴起并推广,2015年阿里提出“大中台,小前台”的策略,方法论讲“OneData(统一数据)、OneEntity(统一实体)、OneService(统一服务)”,OneData致力干统一数据标准,让数据成为资产而非成本;OneEntity致力于统一实体,让数据融通而以非孤岛存在;OneService致力于统一数据服务,让数据复用而非复制。

  随着金融行业数字化转型加快,数据中台在金融领域被重视,数据中台甚至写进了各大银行、保险等机构的发展战略。例如,2019年12月,招商银行宣布设置数据资产与平台研发中心,其定位就是“数据中台”;2020年,中国农业银行制定了“六大中台”战略,打造数据、信贷、开放银行、零售营销、对公营销和运营六大中台;中国太保集团携手阿里云首次打造集团级数据中台,全面向数据智能要红利。

  数据中台建设中的“通用+标准+敏捷”

  1、“通用化+标准化+敏捷性”的重要性

  大型企业在数据中台建设过程中通常以IT条线人员作为产品经理主导,虽然能够做到技术架构的先进性,围绕“ODS、DWD、DWS”大规模存储及计算性能展开投入,但业务参与度太弱,导致系统对业务响应的敏捷度较差,业务通用性低。往往企业新上一个业务,在业务看来很简单的“接入数据、生成标签、报表统计、提取数据”业务需求,在数据中台从需求分析到上线支持以月为周期。2020年底,传出阿里掌门逍遥子要拆掉亲自搭建的大中台,核心原因对业务一线响应效率较差。

  既然中台是链接业务,驱动业务,支持业务,那么衡量数据中台(包含业务中台)价值应该交给业务一线,那么从业务视角,“通用+标准+敏捷”三个维度评价中台是否成功关键。

  2、“通用化+标准化+敏捷性”的说明

  关于通用性,数据中台的核心价值就是共享,因此数据中台的数据标准、数据接口、数据规则是否具备通用性衡量了数据中台的成功与否的标准,如果每一个新接入的数据源需要重新设计接口,设计数据处理流程、更新宽表、开发新的标签,那么数据中台不过是把数据烟囱平移到新的平台而已。

  关于标准化,数据中台具有沉淀数据的价值使命,数据通用性、可用性主要依赖于“数据的标准化”,如对“地址“的现行大多企业标准化做到了“省市区镇”的结构化、参数化,但实际省市区镇的由于国家城镇改革,区划参数在不断变化中,每一次行政区划变动涉及企业历史地址数据更新,若能够标准化到“经纬度”,那么大幅减少历史数据的更新工作量(仅需通过地址经纬度翻译出最新省市区镇即可)。

  关于敏捷性,数据中台强调复用,复用最大的效果之一响应业务需求“快速敏捷”;如果一个数据需求中台响应时效不如过去的数据集市,那么中台难以满足日益提速的业务节奏。

  3、中台“通用化+标准化+敏捷性”的实现案例

  数据接入的“通用化+标准化+敏捷性”:实现接口的通用化,对实时接口、批量接口、文件上传接口中字段的定义配置化与模块化,如90%事件数据可以进行通用化定义:事件来源(枚举值/文本)、事件对象(枚举值/文本)、事件开始时间(日期)、结束时间(日期)、事件内容(枚举值/文件/数值)、事件特殊标记(枚举值/文件/数值/日期)。通用化、标准化的接口可以节约数据接入需求分析及接口重复设计工作量,仅需维护数据源的定义表。同时考虑对于非分析数据应用场景,允许数据应用层可以跨层调用接入的数据(避免ODS层、DWD层处理流程消耗的时效),根据需要设置接入数据临时表(只存储一定周期接入原始数据),直接供应用层调用(实际业务中很多事件数据无需DWS或DWD层进行加工),可大幅提高响应业务时效。

  如在寿险保险领域,客户的投保、保全、理赔、咨诉事件数据都可以纳入通用化接口:事件类型设置3个数值字段(如应用到咨诉-投诉-销售投诉)、事件名称设置2个文本字段(XX活动)、事件对象设置6个文本字段(客户号、手机号、保单号)、事件开始与结束时间各设置两个日期字段(客户投诉时间、投诉事件发生时间、实际结案时间、客户要求结案时间)、事件内容设置三个文本字段(投诉内容、客服备注内容),特殊标记设置2个数值、2个文本、2个日期(如投诉是否升级等),实践证明通用化接口兼容80%以上保险领域事件数据,减少需求分析及接口设计工作。考虑到寿险实际业务中“作业报表、触点推送”两类应用中很多数据无需在DWS或DWD层汇总加工。因此增加设置接入数据临时表,供中台的报表、触点两两大应用模块取用进行快速增量更新,实现与数据写入ODS层流程解耦,有效解决排期不一致各种问题。

  应用层的“通用化+标准化+敏捷性”,此处主要探讨从数据接入到完成业务部署的通用化流程。

  首先最为常见的标签,实际传统金融行业50%的标签可直接来源于ODS数据,且具有阶段性需求特征,无需进行加工计算。如客户是否购买、是否理赔、是否参加活动、活动类型等,这类型标签完全可以在应用层配置化,通用化,无需DWD、DWS层重新设计开发。

  具体案例如在寿险客户标签应用层,通过在ADS层预设“数值、枚举值、文本、日期”四个类型的万能标签。当业务阶需要新增的标签为临时事件类标签,无需“汇总、排序”等计算,完全可以借用在ADS层预设的标签,绕开DWD、DWS层,直接通过ODS接入数据按照通用的“证件号、手机号、保单号”比对逻辑在原有的ADS层的客户数据、保单数据上完成即时标签生成,并在界面自定义标签名称,标签部署时效缩短至“分钟”。

  中台另一个报表领域,传统行业中业务生产数据报表80%的指标计算规则是可复用的,可实现计算规则封装。同时传统作业管理报表使用源数据即可快速完成计算,无需“ODS层、DWD层、DWS层、ADS层”层层加工。因此基于数据中台构建的报表可以在数据接入模块化的基础上实现配置化。

  如寿险领域保全作业管理数据报表主要为“不同客群、产品下的保全事件数、客户数、成功率、对应业务人员数等固化指标”,可以基于实时接入的保全事件数据,结合已经构建好的ADS层的保单数据、客户数据,在界面快速配置数据源、调用封装好指标计算规则,快速生成指定的报表,由于跨过了庞大的“DWD层、DWS层”数据计算,报表更新频率可提升至分钟。

  规则参数的“通用化+标准化+敏捷性”,在中台构建数据领域的规则引擎,统一前中后端规则。如对于“省市区、渠道、职业”等参数枚举值统一由业务部门在规则引擎界面维护管理,实现规则透明化,前中后系统规则统一,可大幅减少数据清洗系统工作量。

  如对地址的省市区的结构化,中台不仅统一枚举值,同时可转化出地址对应的“经纬度”,即便后续国家行政区划参数发生变动,中台可通过“经纬度”翻译出最新的“省市区”,避免历史数据治理与清洗。

  写在最后的话

  希望通过上述具象案例说明“数据中台”建设需符合企业实际,中台构建应以业务为导向。当前传统企业“IT与业务”分属不同的部门,中台建设多以支持者角色出现,难以满足“中台数据业务化+业务数据化”的管理组织要求,传统企业的数字化转型可尝试构建“业务+IT+管理”融合型团队,培养“业务+数据,业务+技术”复合型团队。

0
相关文章