阿里观测站的经纬度_数据中台建设过程中“通用化+标准化+敏捷性”

一

数据中心定义

对于企业来说，数据中心的核心使命是积累有价值的数据，形成企业数据共享，数据服务可以应用到企业各部门、各领域的工作中。

从技术角度来看，数据中心是一个数据管理系统，其最重要的目标是支持各部门的业务数据并提供计算服务。数据中心的本质是“数据仓库+数据服务中间件”。

从业务角度来看，数据中心是指完成企业内外多源异构数据的采集、治理、建模、分析和应用，打通数据孤岛，实现数据集中管理和应用，成为数据中心企业数据资产管理。

数据中心中数据模型的分层。业界常见的分层方法是将数据模型分为五层：①ODS（Data Store，运营数据层）、②DIM（Data Layer，维度数据层）、③DWD（Data，明细数据层）、④DWS（Data、汇总数据层）、⑤ADS（Data Store，数据应用层）

二

数据中心发展历程

数据中台在业界是众所周知的。它是由阿里巴巴创立并推动的。 2015年，阿里巴巴提出“大中台、小前台”战略。该方法论讲“（统一数据）、（统一实体）、（统一服务）”，并致力于统一。数据标准让数据成为资产而不是成本；我们致力于统一实体，以便数据可以集成，而不是存在于孤岛中；我们致力于统一数据服务，使数据可以重用而不是复制。

随着金融行业数字化转型的加速，数据中台在金融领域受到重视，数据中台甚至被写入各大银行、保险等机构的发展战略。例如，2019年12月，招商银行宣布成立数据资产与平台研发中心，定位为“数据中台”； 2020年，农业银行制定了“六大中台”战略，打造数据、信贷、开放银行、零售营销、对公营销、运营等六大中台；中国太保集团首次携手阿里云打造集团级数据中台，充分受益于数据智能。

三

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

3.1

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

大型企业通常以IT线人员作为产品经理来主导数据中心的建设过程。虽然他们能够实现技术架构的进步，并围绕“ODS、DWD、DWS”投入大规模存储和计算性能，但企业参与仍然有限。太弱，导致系统对业务敏捷性响应较差，业务通用性低。往往企业推出新业务时，从业务的角度来看，业务需求非常简单：“访问数据、生成标签、报表统计、提取数据”。在数据中心，从需求分析到在线支持的周期是每月。 2020年底，有消息称阿里巴巴掌门人逍遥子要拆掉自己搭建的大中型平台。核心原因是对业务一线的响应效率差。

既然中台是链接业务、驱动业务、支撑业务的，那么衡量数据中台（包括业务中台）的价值就应该留给业务一线。从业务角度来看，可以用“通用+标准+敏捷”三个维度来评价中间平台是否是成功的关键。

3.2

“通用化+标准化+敏捷化”的描述

就多功能性而言，数据中心的核心价值是共享。因此，数据中心的数据标准、数据接口、数据规则是否通用，是衡量数据中心成功与否的标准。如果每一个新访问的数据源都需要重新设计界面、设计数据处理流程、更新宽表、开发新标签。然后数据中心只是将数据烟囱移至新平台。

对于标准化来说，数据中心肩负着积累数据的价值使命。数据的通用性和可用性主要依赖于“数据的标准化”。例如，目前企业对“地址”的标准化大多实现了“省、市、镇”的结构化和参数化，但由于实际省、市、镇的国家城镇化改革，区划参数不断变化。每次行政区划变更都涉及企业历史地址数据的更新。如果能够标准化为“经纬度”，更新历史数据的工作量将大大减少。 （只需通过地址经纬度翻译最新的省、市、镇即可）。

关于敏捷性，数据中心强调复用，复用的最大作用之一就是“快速、敏捷”地响应业务需求；如果中心的某个数据需求的响应时间不如过去的数据集市那么快，那么中心将无法满足日益加速的业务需求。韵律。

3.3

中台“通用化+标准化+敏捷化”实施案例

数据接入的“通用化+标准化+敏捷性”：实现接口的通用化，对实时接口、批量接口、文件上传接口的字段定义进行配置和模块化。例如，90%的事件数据可以被通用定义。 ：事件源（枚举值/文本）、事件对象（枚举值/文本）、事件开始时间（日期）、结束时间（日期）、事件内容（枚举值/文件/数值）、事件特殊标记（枚举值） /file/value/date），通用标准化的接口可以节省数据访问需求分析和重复接口设计的工作量，只需要维护数据源的定义表。同时考虑非分析数据应用场景，允许数据应用层跨层调用访问数据（避免ODS层和DWD层处理过程的时间消耗），并根据需要设置访问数据临时表（只存储一定时期内访问的）原始数据），可以直接被应用层调用（实际业务中，很多事件数据不需要经过DWS或DWD层处理），可以大大提高数据的时效性对业务的回应。

例如，在人寿保险领域，客户的保险、保全、理赔、投诉事件数据可以纳入通用接口中：事件类型设置3个数值字段（例如适用于咨询-投诉-销售投诉） ，并设置2个事件名称。文本字段（XX活动），事件对象设置6个文本字段（客户号码、手机号码、保单号），事件起止时间各设置2个日期字段（客户投诉时间、投诉事件时间、实际结案时间，设置建立三个文本字段（投诉内容、客服备注）和事件内容（投诉内容、客服备注），并设置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+管理”一体化团队，培养“业务+数据、业务+技术”复合型团队。