(本文作者系阿博茨科技CTO刘铁锋)
“数据中台”概念自阿里提出以来,逐渐成为技术发展的趋势。由数据中台衍生出的“DT时代”、“中台战略”、“大中台,小前台”等概念取代了之前单一的“大数据”,被赋予先进的业务架构模式、业务创新念模式、业务管理模式等内涵。各行各业都在积极探讨和实践自家的“数据中台”如何落地,期待充分拥抱数据而带来的红利。
然而实际构建过程中,该不该上,应该如何分阶段落地数据中台,如何结合自身情况做好数据、技术、业务、应用的划分,却很容易进坑。有从数据治理角度探讨的,认为数据中台的核心基础就是数据治理。有从业务梳理角度探讨的,认为建设好数据中台,需要建立数据规范、梳理业务流程等等。也有从技术的角度来探讨,自身如何构建技术平台,迭代提升效率。
阿博茨根据为客户提供服务的经验,总结了数据中台的常见误区和避坑原则:
误区1: 直接对标阿里,盲目抄作业
数据中台为谁而建?数据中台解决的核心问题是什么?数据中台带来的直接收益是什么?不结合自身实际业务情况,直接对标阿里,容易直接入坑。
首先我们来看阿里最开始的思考: 很多人把数据比作“石油”,马老师(马云)也说过,阿里巴巴要成为全球电子商务的“水电煤”。我们现在搭建的数据中台,就是希望扮演“发电厂”的角色。”
“我们知道,电力的发展可以分为几个阶段,最开始一些有能力的企业自己发电,后来出现新的工业产能,有的企业电用不完,有的却不够用,这时候国家机构就出来了,这些机构去搭建国家级的电网,不管是核能发电,还是风力发电、水力发电,最大程度地保障不同群体的用电需求。”
“我们数据中台也是这样一个运转思路,我们落到实处是一个倒三角形,从下往上分为四个部分——”
“第一是数据技术。没有数据中台的时候,不管是阿里内部还是各商家,大家都有自己的数据中心、机房、小数据库。但当数据积累到一定体量后,这方面的成本会非常高,而且数据之间的质量和标准不一样,导致效率不高等问题。因此,我们需要通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。”
“第二是数据资产。数据中台把阿里系的数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而保证为集团各业务和商家提供高效服务。”
“第三和第四都是数据服务,包括服务商家和服务小二。例如生意参谋和阿里指数,就是数据中台中面向商家端提供的数据服务。”
“数据中台服务阿里,更多是在为各位商家服务。平台会确保大家在使用数据的过程中,口径、标准、时效性、效率都有保障,能有更高的可靠性和稳定性。”
相信这段话已经非常清楚地描述了最原始的”数据中台”的构想。
阿里巴巴的数据中台是 面向阿里上面成千上万的商家而服务,是为了这些商家而建设的。
解决的核心问题是保证商家使用数据的口径、标准、 时效性、效率、 可靠性和稳定性。
企业得有“石油”(数据),有“发电体系”(数据产生价值的应用和场景)需求,有“过剩”才有建“国家电网”(数据中台)的需求。
数据中台的建设也是因人而异,因企业而异。
避坑自查:
企业的业务经营是否有大量业务数据产生?
企业业务数据的价值在哪里?
企业业务数据价值应用和场景是什么?
数据中台是否能帮助业务形成正向改进闭环?
误区2:阿里的痛,就是我的痛
阿里的“痛”,真正是自身企业的“痛”吗?
企业构建数据中台之前,核心需要确认的问题在自身的痛点到底在哪里,为怎样的业务类型?为哪些用户?为怎样的使用场景?
绝大部分的企业的规模、需求和痛点和阿里的需求不在同一规模上。因此,同样是构建数据中台,各自的重点确各不相同。直接照搬阿里的数据中台的理念,犹如刻舟求剑。“你”说的都对,但“我”够不上。
盲目把阿里的痛,带入为自己的痛,也是挖坑方式之一。
避坑自查:
类别 | 阿里 | 自身企业 |
业务场景的必要性 | 访问数据是服务商家的核心需求 | “访问数据”是否在核心业务价值链上? |
业务改进的急迫性 | 访问数据的标准和效率,直接影响商家和平台的收益 | “访问数据”的能力是否为卡脖子需求? “访问数据”的瓶颈是否限制业务发展? |
核心用户的利益一致性 | 商家的交易规模和阿里的收益成正比 | 自身的用户是谁?内部还是外部? 这些用户的利益和企业利益是否一致? |
用户规模 | 商家规模千万级别 | 自身用户规模多少? |
是否形成闭环 | 用得越多,沉淀越多 | 是否存在改进闭环? |
数据规模 | 多平台,多应用,多格式。必须整合 | 是否有如此多数据规模? |
基于以上角度的对标,能有效帮助厘清自身痛点。
误区3: 贪多求全,重点不明。
阿里构建的技术中台,就是标准的数据中台建设方案吗?答案当然不是。
阿里构建的技术中台,解决的是阿里面临的数据规模和挑战,而企业面临的问题,是自身业务发展的问题。关键在于需要解决的核心问题在哪里。
能力需求一样,但是解决问题的层面不一样。理念一样,阿里构建的是航空母舰,面向星辰大海。对企业来说,同样是需要船,但面对是海、江、湖还是就是小水坑,这才是企业构建数据中台的真实挑战。也就是说,构建中台不完全是技术能力问题,而是看菜下饭,灵活针对企业实际需求而调整定制的选择重点的问题。
盲目对标阿里的数据中台系统,容易调入贪多求全、重点不明的坑中。
避坑自查:
核心问题 | 阿里 | 自身企业 |
数据应用需求 | 可构建商用的数据挖掘程序 | 谁来使用数据 |
数据API访问 | 解决千万级用户访问的效率问题 | 数据API的权限效率是否是关键问题 |
数据API创建 | 解决面向海量数据以及海量API的创建 | 数据API的规模多大? |
数据建模能力 | 处理复杂业务的模型构建需求 | 是否有复杂模型构建需求 |
数据衍生计算需求 | 个性化、种类多、复杂性高的数据模型计算需求 | 数据计算的多样性,复杂度 |
海量数据处理能力 | 海量数据计算的处理规模、及时性、扩展性等多方面需求 | 海量数据处理的实际要求 |
数据存储能力 | 复杂数据库的统一管理需求 | 数据库的规模 |
数据治理需求 | 多数据来源的数据统一和治理需求 | 数据治理的规模和必要性 |
误区4: 基建不足、匆忙上马。
数据中台的核心在于将石油(数据),放到发电厂(数据中台),产生电(数据访问能力),满足生产需要(服务客户)。企业自身是否有石油(数据),是否需要构建发电厂(数据中台),电(数据访问能力)是否能卖出去,则是是否要规划发电厂(数据中台)的前提条件。
是否建立数据中台,数据中台是否能成功,已经不完全是技术问题,也不简单是数据治理问题,而是企业的业务发展阶段是否需要数据中台支撑,以及数据中台带来的技术效率提升,能否直接反馈到业务的问题。核心在于,企业是否已经明确数据挖掘的深度和维度,是否清晰数据对业务带来的提升点,以及数据反馈闭环是否存在。对业务的支持,对数据应用的需求,决定了数据中台构建的深度和维度。
实践中,我们发现,很多企业基建不足,数据的基础建设没有完成。网络和物流还没接到村里,就期望对接电商销售产生订单。
避坑自查:
对企业自我评估有两个角度:
一是自上而下,从数据应用场景到数据的需求是否明确?
二是自下而上,从基础数据到业务实际需求对接的流程是否明确?
阶段 | 判断领域 | 对企业的要求 |
数字化转型阶段 | 业务基础 | 是否已经全电子数据化? |
数据使用 | 业务是否依赖于非结构化文档(PDF、Word、Excel等)?业务系统是否能能力将非结构化数据转为结构化数据? 业务系统是否存在数据的使用闭环? | |
数据治理阶段 | 数据质量 | 是否有明确的数据质量保证体系? 是否明确如何对数据进行清洗? |
数据中台建设阶段 | 数据计算 | 是否存在明确的数据计算场景和数据计算需求 |
数据API | 是否存在明确的API的使用者和场景 | |
数据应用 | 是否明确数据应用场景和API的明确需求 |
误区5: 急于求成,期望一步登天
数据中台的建设,本质上来说是对业务的重构,而不仅仅是技术的选型,更不是标准化的产品。数据中台的难点,表面上来看是数据治理,本质上来说是理解数据和业务的结合以及发展阶段。因此,明确自身的业务特点和技术发展的阶段,合理规划出阶段性目标,是提升项目成功率的有效方式之一。
而实践中,往往容易出现急于求成,期望一步登天的情况。欲速而不达。
避坑自查:
构建阶段 | 解决的业务问题 | 对企业需求 |
数据治理阶段 | 数据标准化 | 明确关键业务节点上的数据需求 明确从非结构化数据到结构化数据的难点和期望值 |
数据计算阶段 | 规模化数据挖掘问题 | 数据挖掘的范围、规模、产出 |
数据分析的深度,隔离业务和技术能力 | 明确数据模型的领域,区分出平台能力和业务能力 | |
数据应用阶段 | 基础数据调用问题 | 明确数据访问者的规模和需求 |
通用和基础的技术需求 | 明确技术应用的范围 | |
统一业务需求构建问题 | 抽象出业务的共同点,平衡通用需求和专用需求 | |
对外应用服务问题 | 抽象应用的共同点,平衡通用应用和定制化应用扩展性问题 |
阿博茨科技在金融领域,运用人工智能技术,帮助大量头部的券商以及基金公司构建了基础数据中台,在数据治理、数据计算平台搭建、技术中台构建、业务中台构建、应用中台构建中积累了大量的一线实践经验。以上探讨的观点只是阿博茨实践中的抽象和总结,对于具体的落地方案,欢迎大家联系我们,共同探讨。