Tapdata 技术博客
Tapdata 技术博客

Tapdata 杨哲轩:数据孤岛何去何从,主数据管理能药到病除么?

2022-06-20 17:16Tapdata 运营合伙人杨哲轩

一、数字化正长风破浪


新冠肺炎疫情当前,上海的封城之殇仍绕梁余耳,被称为疫一代的我们,算下来疫情下生活工作也有近 3 年了。如果说什么对我们的生活、工作方式改变最大,那莫过于疫情了。正因此,以 Zoom 为代表的会议办公软件异军突起,顺带着腾讯会议等同行业参与者也茁壮成长。


疫情,加速了企业数字化的进程


微观视角下,新冠肺炎疫情给普通人带来的是工作生活方式的改变,宏观视角下给企业带来的则是数字化的新要求。一些改变,润物无声,不留心注意,可能会觉得理所当然。


和新冠肺炎疫情发生前相比,越来越多的企业已经允许新员工以线上的方式参与入职和相关培训。甚至,跨地域部署团队已成常态,远程工作文化也越来越深入人心。


疫情加速了企业数字化的进程

新冠肺炎疫情让企业重新思考,数字化对于他们的意义是什么。越来越多的企业开始建设新的定制化系统,开始将线下的活动逐步地搬到线上。为了支撑越来越多的数字化需求,企业需要越来越多的定制化系统,比如:

  • 人事部门需要定制化的招聘和绩效系统;

  • 财务需要定制化的回款、报销系统;

  • 研发效能团队则需要定制化的项目管理、进展跟进系统。

无独有偶,在国务院关于印发《“十四五”数字经济发展规划》的通知中特别强调:数字经济是继农业经济、工业经济之后的主要经济形态,是以数据资源为关键要素,以现代信息网络为主要载体,以信息通信技术融合应用、全要素数字化转型为重要推动力,促进公平与效率更加统一的新经济形态。

数字化转型正长风破浪,各行各业都迸发出各种定制化业务系统的需求。


当前时代处于一个技术大爆炸的时期,不同的技术范式和技术趋势层出不穷。你方唱罢我登场,此起彼伏,对于同一种问题往往有好几种技术理念和对应的供应商,这无疑也加重了当前企业技术栈的复杂程度。


数据资源为关键要素


草蛇灰线,伏脉千里,数据孤岛的问题在企业的数字化征程中变得越来越严重,或成为企业的阿喀琉斯之踵,造成企业无法真正完成数字化转型。我认为,在漫长的企业信息化和数字化的过程中,主数据和主数据管理作为一个持续保持热度的技术范式,值得被重点关注。


二、数据孤岛成拦路虎


此时此刻,回望过去,来时的路大概是曲折蜿蜒,人是这样,企业也是如此。从十几个人的小团队成长到数千人的中型公司。企业的成长之路,并非只是人数的增加,我想也是企业文化、协作和管理等机制的成长之路。


数据也成了一座座孤岛


而在互联网如此发达的今天,这些无形的东西又通过企业信息化凝聚成了一座又一座的数据孤岛。数据在不同部门相互独立存储,独立维护,彼此间相互孤立,在物理上形成了孤岛。目前银行业经常提的银保协同和开放银行等战略,都是希望能解决因为业务在不同部门而造成的物理性的数据隔离。


数据也成了一座座孤岛


除了物理性的数据孤岛以外,还有一种是在认知层面的的现象,即不同部门站在自己的角度对数据进行理解和定义,使得一些相同的数据被赋予了不同的含义,无形中加大了跨部门数据合作的沟通成本。


数据孤岛的问题,到底是什么?


很明显,不管物理上的还是逻辑上的数据孤岛,它们的存在都不是好事,但它们真正的问题是什么?


简而言之,就是数据孤岛相当于天然的数据隔离,不同部门视角下的业务视图是不一致和不完整的。这将给公司业务的运营带来诸多挑战和不便。在数据孤岛的存在下,每个团队最终都独立工作。他们只能访问自己的数据,所以那是他们工作的唯一数据。这创造了一个分裂的组织。各个团队在项目上不相互协作,这使得公司几乎不可能有共同的愿景。


在数据孤岛成为常态的环境中,透明和信任的文化是很难维持的。相反,企业中的管理者因为没有全局视角,基于本位主义,可能只会专注于团队的目标,在团队之间制造竞争和对抗。这让组织内部门间的协作变得无比困难。


因为无法跨团队访问数据,在协作上造成的困难是内生性的。假设我们站在企业客户的视角思考,我们接触到的不仅仅是一种声音,这些声音可能来自市场部门,也可能来自销售部门,还可能来自解决方案部门,归根结底,大多数企业中是有多个客户接触点的。


这些跟客户的互动,是在各种客户旅程的不同阶段发生的。当这些部门的数据没有被打通时,企业的客户会被反复“骚扰”。不久前,我从上海出差到深圳,还没入住到我预订的酒店时,就已经收到了来自不同区和街道网格员的问候,询问我的核酸报告和粤康码的情况。是的,你没有猜错,我一共被问了超过 5 次。没有什么比不同的人重复地跟“客户”讲述同样的事情更糟糕的体验了。


而数据孤岛的存在,不仅仅使得客户有糟糕的体验,也使得高效率团队变成一句空谈。数据没法自动地在各团队之间流转,而是被隔离在团队内部。这意味着需要数据的团队别无他法只能等待,直到他们意识到没有他们所需要的数据,再去寻找所需数据在组织内的位置。即使能顺利拿到数据并且进行分析,那些等待的时间也是如长江之水一去不复返。


如何保证数据自身的准确性?


企业虽然意识到数据是最宝贵的资产之一,但是数据本身的准确性如何被保证呢?


企业通常会使用不同的软件收集关于潜在客户、客户和合作伙伴的信息,以期望对数据的价值进行挖掘。但是,当这些数据过时、不完整或缺失时,企业能从中获得的价值就会大大下降,不难发现,数据孤岛威胁着企业关键数据的准确性。


如果每个需要相同数据的员工都把它保存到他们公司的存储文件夹中,这就浪费了宝贵的存储空间。浪费了存储预算的同时,也存储了不需要和不想要的数据,造成了很大的冗余,不仅不能提效还造成了成本的浪费。如果数据被精简到一个平台上,让该组织内的所有员工都能访问,那么它所消耗的空间就会少很多。


试图用孤立的数据来管理一个企业,就像试图在没有说明书的情况下安装一个复杂的家具,这是难度极大的事情。如果没有一个围绕数据的策略,持续地帮助企业缓解数据孤岛的问题,依据熵增定理,孤立的数据放置的时间越长,它就越有可能变成过时的,从而不准确、不可用。可是这样一来,企业的各种战略都会受阻,甚至成为影响企业存亡的严重问题。


三、主数据管理,是数据孤岛的苦口良药?


数据孤岛,本质是一个熵增的过程。


任何技术和架构都不是银弹,不能一劳永逸地解决所有问题


主数据管理更像是通过高层发起,重新构建企业对于主数据的认知,形成围绕主数据的流程设计,所有源自数据孤岛中的信息联系在一起,形成组织内的公共数据,帮助企业对业务有一个 360 度全方位的了解,才能逐步缓解数据孤岛引起的并发症。


从这个角度来看,主数据管理(MDM)之于数据孤岛,更像是一层业务抽象层,是一个由企业高层主导的计划,以确保组织的共享数据即主数据的一致性和准确性。



主数据管理(MDM)


先搞清楚什么是主数据,才能有的放矢


我想在回答什么是主数据管理之前,很有必要先来介绍下什么是主数据。


主数据,与参考数据和元数据一样,是组织中的一种关键数据资产。虽然在互联网上可以找到更复杂的主数据定义,但简单来说,主数据是驱动业务流程的实体,通过分析进行评估,并通过治理过程进行控制。


主数据是有关业务实体(比如雇员、客户、产品、财务体系、资产和位置等)的数据,这些实体为业务交易和分析,提供了上下文信息。实体是客观世界的对象(人、组织、地方或事物等)。主数据应该代表与关键业务实体有关的权威的、最准确的数据。


一般组织的主数据,包括这几方面的数据。我整理到图中了,大家可以看下:


什么是主数据


不同角度看主数据


横看成岭侧成峰,从不同的角度看主数据,或许有更深刻的理解。


从运营或业务流程的角度来看,主数据通常代表可交易的实体。例如,如果我们看一个典型的从订单到现金的流程:客户使用资产(即自助服务终端,比如信用卡、电子钱包或第三方支付渠道)从位于某个位置的商店购买产品;客户、产品、商店地点、资产等都是主数据的例子。


此外,记录销售情况的财务账户,或该商店的员工也是主数据的一部分。虽然持有主数据的系统通常不记录交易,但它们持有一致的实体信息以确保业务流程不会失败。

从分析的角度,或商业智能的角度来看,主数据是组织跟踪或检查的实体。例如,为了报告同一商店的销售情况,可将与商店地点相关的每个财务账户的交易数据进行聚合,展示在一个仪表板上。在这个例子中,财务账户、地点、客户、产品是主数据。


主数据通常代表可交易的实体


虽然管理主数据的系统通常没有交易细节,但它们持有符合要求的维度和属性(即主数据),这些维度和属性被分析工具用来正确地汇总和分析数据,保证分析报告和仪表盘等是准确的。


从治理的角度来看,主数据是受到控制的实体。例如,隐私法规通常决定了客户、雇员或病人的数据应该如何被控制。资产和地点受风险管理政策的约束,比如应急计划,或资产管理政策。会计制度(如 GAAP,IFRS)和财务法规影响着财务账户层次的设计和控制。


虽然持有主数据的系统通常不记录政策和治理细节(这是数据治理或 GRC 平台所提供的),但它们在被治理团队所定义的实体范围之内。


以制造企业为例,我们主要关注制造业特有物料或物料分组,通常它的 PLM 系统是对产品的全生命周期进行数据管理,涵盖了组成零件、设计图纸、工程图纸、工艺文件、产品文件、材料等在内的和产品相关的所有数据。


这个例子中,围绕产品生命周期的原材料、制造零件、外购件、标准件等都是主数据的一部分。此外还有源于 ERP 系统和 MES 系统中的企业内部基础数据,通过对于 PLM、ERP 和 MES 系统,共享数据的整合,能够对制造业“供产销”的业务流程进行管控和降本增效。


四、借助主数据管理,组织可以在哪些方面借力?主数据管理的理解上,有必要再往深里挖


只有做到对主数据实体和标识符的控制,才能保证在系统间实现对核心业务实体最准确、 最及时的数据的一致使用,而这一过程就被称之为主数据管理。

我想,只是了解到这一层还不够。咱们再来看看 Gartner 对”主数据管理“是怎么定义的:


一个技术支持的知识领域,在这个过程中业务和技术协同工作,以确保企业官方共享主数据资产的统一性、准确性、管理性、语义一致性和问责性。主数据是由标识符和扩展属性组成的一个一致且统一的集合,它描述了企业的核心实体,包括客户、潜在客户、企业员工、供应商、位置、层次结构和会计科目等。


我们再具体细看下,Gartner 的这个定义里,强调了什么:主数据管理是一个由人、流程和技术组成的知识领域,并不是一个特定的应用程序解决方案。然而,MDM(主数据管理)这一缩写词,却通常被用于特指管理主数据的应用系统或产品。主数据管理应用系统,可以简化主数据管理的一些方法,有时还非常有效。不过,仅仅依靠使用主数据管理系统,并不能保证被管理的主数据能够满足组织的需要。


如果说主数据是企业内不同业务的共享数据,那么主数据管理则是企业的制度和流程。


主数据管理是企业的制度和流程


借力:提升整体生产力,优化供应链管理成本


实际上,实施了主数据管理的企业,等同于在尽可能消灭数据孤岛的前提下,重构了整个企业的指挥和协作体系,重新建立了不同部门对于业务的共识,提升了整体的协作程度。


主数据管理可以提供一个关于客户主数据、产品主数据和关键主数据实体之间关系的统一视图。统一视图,能帮助企业的销售人员对于来自不同渠道上的客户,做出合适的引导来增加收入。


借助主数据管理,可以通过在整个组织中提供完整、一致、可靠的主数据来源,消除 IT 开销和成本,提高运营效率,提升整体的生产力。


主数据管理提供了对产品的集中视角,并提供了贯穿整个供应链的库存、产品退货和缺货物品的准确信息,从而改善库存管理、预测和客户服务,优化供应链的管理成本。


借力:企业可更快推出新产品、服务,提升客户满意度、业务合规性


主数据管理,通过允许业务用户直接访问、管理和直观地与主数据互动,可以加快洞察和行动的时间。有了更丰富的产品、客户和供应商数据来源,企业可以更快地推出新产品和服务。


除此之外,企业还可以通过主数据管理对客户的具体愿望和需求有一致性理解,通过个性化的互动,提供跨渠道的一致体验提升客户忠诚度,同时根据定制产品和服务来增加销售。这些举措,无疑能帮助企业提升客户满意度。


最后,集中和完整的主数据,有助于降低与合规性报告和处罚相关的成本,提升业务合规性。通过主数据管理,供应商和产品合规性问题减少,也进而加快了新产品的推出和供应商的参与速度。


五、结语


数据孤岛是熵增,而主数据管理则是熵减,如同孪生双子。任何熵减的工作都有反向做功,比如整洁的桌面、舒适的居家环境都需要付出额外的努力。


曾经跟圈内朋友讨论数字化转型和主数据管理在国内实践的问题,大家普遍的回答是在数字化转型项目开展到深水区之后,才发现是原本一开始的主数据没定义好,又回头返工把主数据和主数据管理的这些基础设施工作做好。


可是如果一开始,我们能向企业高层正确地灌输主数据正确的认知和其好处,后续的很多工作是不是往往就可以避免甚至是提速完成了。数据孤岛是企业的拦路虎,而主数据管理则是苦口良药。


如果需要药到病除,需要一个好的主数据管理软件和高层的支持。这两者缺一不可。一般而言主数据管理的关键处理步骤,包括数据模型管理、数据采集、数据验证、标准化和数据丰富、实体解析、管理和共享等。


主数据管理的关键处理步骤


这也对主数据管理的软件提出了不同的要求,一个好的主数据管理软件,是可以让主数据管理在企业中落地时事半功倍的。而高层支持,则需要对主数据和主数据管理有正确的认知,且能够一起推动企业的变革。


Tapdata 实时主数据服务平台 Active Master Data Platform


传统的主数据管理采用T+1的方式从业务系统获取源数据,加工处理后形成企业的标准数据, 并通过导出方式输送到业务系统使用。这种方案的局限性在于数据更新较为滞后。Tapdata 的实时主数据方案允许用户用实时数据管道及强大的 UDF 功能让用户可以简单的实现去重、规则判断等主数据治理功能。端到端的秒级延迟 + 自动API 服务意味着客户直接从Tapdata 获取需要的主数据。免费试用 >


本文作者: 杨哲轩 - Tapdata 运营合伙人&客户工程团队负责人,毕业于明尼苏达大学,后加入 PingCAP 担任基础架构研发工程师,参与负责 TiDB、TiSpark 等核心项目。而后转型成为区域售前业务负责人,为多家知名华南银行保险证券机构和其他诸多行业,设计过解决方案,对分布式数据库、HTAP、DaaS、主数据等技术领域,拥有独到见解和丰富的实践经验。


推荐阅读

DTCC 干货分享:Real Time DaaS - 面向TP+AP业务的数据平台架构

2021年10月20日,Tapdata 创始人唐建法(TJ)受邀出席 DTCC 2021(中国数据库技术大会),并在企业数据中台设计与实践专场上,发表主旨演讲“Real Time DaaS :打造面向 TP+AP 业务的数据平台架构”,从 AP 业务场景 vs. TP 业务场景、常见数据平台优劣势、如何打造面向 TP+AP 业务的数据平台等角度,全面分享了 Tapdata 在全链路实时数据融...

Tapdata 在数字化防疫场景的最佳实践

在“动态清零”总方针的指导下,国内疫情防控工作渐趋规范化、常态化,各类防疫应用和手段层出不穷,防疫战也是数据战。Tapdata 基于数据虚拟化和主数据管理能力的防疫专项解决方案,助力张家港市卫健委高效落地疫情防控数字化,实现精准防疫。

Tapdata 在线研讨会:DaaS vs 大数据平台,是竞争还是共处?

我们为什么需要一个Real Time DaaS?它和大数据平台技术上有什么区别?如果企业还没有构建数据平台,我是应该考虑DaaS还是Big Data?如果已经有了大数据平台,我是否还需要DaaS?如果你想了解更多,请参加本次的在线研讨会。

下一个十年,你还在用 Big Data 搭建数据中台吗?

数据中台的存在是有合理性的,企业需要中台帮助他们来有效管理企业的数据资产,为业务所用。但在经历过大数据时代的热度之后,你在为企业构建数据中台的时候可以考虑另外一种比较务实的 DaaS 架构。DaaS 更加专注于数据层面:打通企业内部的孤岛数据,在中台构建共享模型,以API方式快速发布数据服务...

解锁5大应用场景,最新实时同步实现方案分享

数字化时代的到来,企业业务敏捷度的提升,对传统的数据处理和可用性带来更高的要求,实时数据同步技术的发展,给基于数据的业务创新带来了更多的可能。 Tapdata 产品合伙人徐亮带来实时数据同步的5大典型场景以及4种主流的技术模式分享,并一起了解作为新生代实时数据同步的 Tapdata Cloud 如何更轻松灵活的满足各种实时数据场景。

Tapdata 钛铂数据的产品理念

Tapdata 是全球首个基于数据即服务架构理念、面向 TP 场景的企业实时主数据服务平台,可以帮助企业快速实现主数据的统一管理和发布,并为所有数据库、数仓、大数据平台提供最实时的源数据,让数据随时可用。

Tapdata 数据库实时同步的技术要点

Tapdata 专注于实时数据的处理技术,在数据库迁移和同步方面,Tapdata 的表现非常优秀,实时、多元、异构,尤其在关系数据库到非关系数据库之间的双向同步方面,无论是从操作上,还是效率上,都体现了业界领先的水平。本文重点阐述 Tapdata 在数据库实时同步方面的技术要点。

教育中台与第三方系统对接整合数据案例

最近, 南京秦淮区教育中台系统,成功地和市系统进行了一次圆满对接。通过教育中台提供的统一数据能力和低代码API对接能力,实现了对市系统数据的实时推送和拉取,以及各类业务逻辑上的处理。这次对接为南京市中小学生创客大赛的成功举办提供了及时可靠的数据支撑, 体现了中台系统在快速响应业务方面的优越性。

周生生 | 全渠道商品中心建设

通过Tapdata 构建全渠道商品中心,实现: - 支持中国大陆港澳台的上千家门店的生产环境; - 使用JS脚本来进行流处理计算,业务需求从开发到上线过程快至 1 天以内; - 任务配置与执行监测全程可视化操作,不懂技术也能完成操作,极大降低维护成本; - 一套产品可满足不同需求,根据业务需求产出不同类型的业务模型节省大量人力物力。

关系型数据库到MongoDB实时数据同步解决方案

使用MongoDB作为主机下行或新一代数据库的选择,将业务数据从已有主机或Oracle等关系型数据库复制到MongoDB; 使用Tapdata Replicator的CDC技术,实时监听现有业务库的数据变动并同步至MongoDB; 使用Tapdata 的RDM技术将关系型表合并转型到MongoDB JSON数据结构,并保持和源库的高度数据一致; 在MongoDB上进行新业务的开发。

Tapdata肖贝贝:实时数据引擎系列(一)-新鲜的数据流

前言2006 年诞生的 hadoop 和 她周边的生态, 在过去的这些年里为大数据的火热提供了足够的能量, 十几年过去了, 场景在变化, 技术在演变, 大家对数据的认知已经不再局限于 T+1 与 高吞吐高延迟 为主要特征的上一代框架理念, 在真实的场景里, 实时, 准确, 多变 的数据也发挥着越来越重要的作用为满足这些新的需求, 各种框架和中间件如雨后春笋般不断涌出hive 的出现让这头大象...

Tapdata 肖贝贝:实时数据引擎系列(六)-从 PostgreSQL 实时数据集成看增量数据缓存层的必要性

对于 PostgreSQL 的实时数据采集, 业界经常遇到了包括:对源库性能/存储影响较大, 采集性能受限, 时间回退重新同步不支持, 数据类型较复杂等等问题。Tapdata 在解决 PostgreSQL 增量复制问题过程中,获得了一些不错的经验和思考,本文将分享 Tapdata 自研的 TAP-CDC-CACHE,和其他几种市面常见的解决方案的优势和特性。

搭建企业级实时数据融合平台难吗?Tapdata + ES + MongoDB 就能搞定

如何打造一套企业级的实时数据融合平台?Tapdata 已经找到了最佳实践,下文将以 Tapdata 的零售行业客户为例,与您分享:基于 ES 和 MongoDB 来快速构建一套企业级的实时数据融合平台。