阿里数据中台底座的12年建设实践

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: 阿里数据中台底座的12年建设实践

编者按: 从2016年诞生起,“中台”概念就一路火热至今,对互联网与金融行业数字化转型产生了极为深远的影响。 作为“中台”概念的提出者和先行者,阿里巴巴用12年的实践探索了中台能力建设和数据应用。在不断升级和重构的过程中,阿里巴巴的中台建设经历了从分散的数据分析到数据中台化能力整合,再到全局数据智能化的时代。 在当下如火如荼的金融行业中台建设浪潮中,不少金融机构对于中台建设仍存诸多迷思,中台建设将走向何方?数据资产到底该如何管理?阿里巴巴的中台建设之路应该能为金融机构带来借鉴。 日前,在阿里云举办的2021阿里云金融数据智能峰会上,阿里云智能计算平台事业部研究员关涛对阿里巴巴如何构建数据中台核心三要素中的平台技术部分进行了全盘分享,其中包括数据平台发展的四个典型阶段,支持中台业务的四大技术挑战,以及数据平台的四大技术趋势等。 在阿里中台的成功实践中,方法论、组织、平台能力是“数据中台”的核心三要素,而其中平台能力建设最为关键,难度也最大。阿里巴巴在打造强大的数据中台底座方面已经进行了积极探索,并且还在不断与时俱进夯实底座,构建面向未来的能力。 本文对其演讲内容做了精简编辑,希望能给金融机构构建数据中台带来更多借鉴与启发。


文/阿里云智能计算平台事业部研究员 关涛 

image.png


01

阿里巴巴数据平台发展的四大阶段



构建数据中台,一个强大的数据平台作为底座必不可少。 阿里巴巴数据平台发展的四个阶段,一定程度上其实也是阿里巴巴数据中台发展的四个阶段。这四个阶段里,你可以看到阿里巴巴对自身数据的商业价值的萃取,对原有分而治之的数据系统的聚合,对计算数据资产化和数据高效应用的新思路以及对数据平台治理过程中面临的组织变革等。

阶段一:业务百花齐放,发现数据价值

image.png


2009年到2012年,阿里巴巴电商业务进入爆发期,涌现出非常多有名的业务团队,比如淘宝、1688、AliExpresss、一淘等。每个业务都是基于数据驱动的全场景业务,业务方对数据有着强烈的诉求。 那个时候,阿里巴巴技术几乎都是IOE架构,核心数据系统是Oracle。2年时间内,阿里巴巴建成了全亚洲最大的Oracle集群。但是在2010年,Oracle已经不能满足计算的要求,有非常多数据延迟和不满足性,再加上昂贵的成本,没办法继续支撑业务发展。 阿里巴巴开始认真审视建设下一代数据平台的重要性,同时启动了两个并行项目:一个是“云梯1”,基于开源Hadoop技术体系,多个业务团队构建多个Hadoop集群,集群规模达到4000台服务器。 一个是“云梯2”(ODPS,现MaxCompute),作为阿里巴巴自研产品启动研发,集群规模1200台左右。蚂蚁小微贷款“牧羊犬”业务是第一个吃螃蟹的业务,上线“云梯2”的过程被称为“人肉云计算”与“分步试计算”。王坚院士2018年曾在央视《朗读者》节目朗读《进入空气稀薄地带》,形容的就是自研数据平台那时的现状与信念。 两个项目在阿里巴巴内部形成竞合状态,并行探索阿里巴巴数据平台发展的轨迹。这个时期,所有业务方的数据几乎都是垂直建设,以自己业务形态形成独立小闭环的形式飞快向前奔跑。

阶段二:业务垂直小闭环,数据孤岛显现

image.png


2012年到2015年,阿里巴巴电商业务在飞速发展的同时,涌现出更多的新兴业务:2013年,创立菜鸟,启动“all-in 无线”战略;2014年,投资高德,与银泰合资,阿里旅行成立;2015年,推出钉钉/零售通、成立口碑、控股阿里健康等等。 这个时期,阿里巴巴业务蓬勃发展,形成了12个业务部门和9套不同的平台系统,而且每套平台系统架构都不一样,用户数字化流程需要横跨多个BU的多套数据系统。 数据孤岛现象开始日益严重,数据成本越来越高,统一的数据平台建设已经迫在眉睫,这也是阿里巴巴数据中台的起点。 与此同时,“云梯1”和“云梯2”也正在经历大变革。 2013年3月28日,阿里巴巴集团技术保障部架构师云铮的邮件直达集团高层:“按照数据增量与未来业务增长的情况,云梯1和云梯2两套系统的存储和计算能力将在今年6月21日到达瓶颈。”届时,许多的业务将因为技术的限制而无法展开。 这意味着,数据平台已经无法再同时并行“云梯1”与“云梯2”两个项目,必须选择其中1个。如果选择“云梯1”,Hadoop的5000节点限制如何突破?涉及到金融业务,开源体系如何保证大数据的安全与可用性?跨机房方案业界无参考如何解决?业务交互频繁,跨机房如何保证数据稳定交互? 一系列的技术难题都逐渐将数据平台推向自研道路。 最终,阿里巴巴集团多个技术部门合璧,决定选择“云梯2”挑战5K巅峰。短短几个月时间,“云梯2”从1500台跨入5000台并突破单物理机房限制,通过10倍压力测试,同时支持跨集群计算与高可用,为阿里巴巴未来多年的大数据发展奠定了坚实的技术基础。 5K项目完成技术突破后,新的压力接踵而来。业务快速发展导致数据规模也急剧膨胀,如何统一管理数据、统一保证数据安全、具备统一开放能力等问题成为数据平台思考的核心。 为此,阿里巴巴内部启动了一个比较有名的项目,将所有业务部门数据都同步到统一的大数据平台,统一进行管理。这个项目经历了两年,涉及阿里巴巴所有事业部,这个过程中,还逐渐推进通用数据平台能力产品化并具备金融级平台的能力。 从当时来看,阿里巴巴建设数据平台的过程是全面统一数据的过程,也是中国第一个超大规模数据中台建设和迁移的过程。

阶段三:数据中台支撑业务可持续发展

image.png


2015年到2018年,阿里巴巴数据中台方法论开始确立,拉开了数据中台建设的大幕。2015年,阿里巴巴集团宣布启动“中台战略”后,开始构建符合DT时代的更灵活的“大中台,小前台”组织机制和业务机制。阿里巴巴每个运营小二都可以基于数据制定覆盖用户生命周期的数据化运营策略,生意参谋开始探索数据业务化,更多的业务开始走向实时化。 但是,数据和计算的高速增长、资源的高速消耗带来了数据需要治理的问题。阿里巴巴的团队们开始思考怎么把数据中台的方法论落实到平台层,让数据平台支撑数据中台的建设。
· 数据是谁的? 谁来用? 谁来管控?数据质量由谁负责?· 平台团队和业务团队是两个团队,成本关系是什么?· 中台方法论,如何落地在数据平台落地?如何治理?· 数字增长很快,超过业务增长,怎么办?· 一张核心表12PB,每个部门复制1份,一年几千万就没了怎么办?· 我知道要删除一半的数据,但到底是哪一半?
这些问题的背后是数据的治理以及资产化,我们需要一套平台系统把方法论承载进来,真正形成统一化。在数据平台侧,DataWorks 构建大规模协同数据开发与治理的一站式能力,MaxCompute 支持服务器集群达到十万级,服务阿里集团全部BU、20多万员工的日常运营,一起支撑各项业务的可持续发展。

阶段四:云上数据中台与业务伴生

image.png


2018年之后,整个阿里巴巴数据平台系统已经很成熟,平台方和业务方达成一个非常好的配合状态。业务方认可数据平台的价值,业务部门与技术部门相伴相生,数据中台服务业务达到正循环,成为数据中台建设成功的一个标志。 阿里巴巴从2018年内部所有系统开始上云,到2021年实现了云上数据中台与业务伴生:双11核心系统100%上云,阿里巴巴全面云原生化;每秒53.8万笔,阿里云抗住全球最大流量洪峰;数据中台覆盖阿里集团所有BU;运营小二及时发现问题、分析问题,实现实时运营决策;短视频、直播等新业务继续涌现…… 可以看到,阿里巴巴的数据中台建设是成功的,并且仍在高速向前发展。
MaxCompute 智能数仓让双11成为日常,湖仓一体逐步成为下一代大数据平台架构,DataWorks建设的数据中台全面服务业务,支持集团内数百个数据应用,通过全链路数据治理,以低成本增长支持集团业务高速增长。

02

数据平台建设的四个核心挑战



一个数据中台建设的成功与否的核心指标,不是系统效率,不是平台效率,而是“数据效率”。 阿里巴巴主要从规模与弹性、数据的成本、数据的正确性与可维护性、数据利用率4个方面来衡量“数据效率”。 image.png

在这个核心指标下,方法论、组织、平台能力则是数据中台成功的核心三要素。那么,数据平台要想建设好,背后究竟有哪些方法,建设过程中有哪些难点需要注意?背后要做的工作其实非常多,本次仅从面向业务的4个切面做介绍,暂未涉及存储、计算引擎等层面的挑战。

挑战一:数据资产管理体系

对于数据资产来说,首先要解决的一个问题是:什么叫企业的数据资产?阿里巴巴的每个BU都有一个自己事业部的数据资产全景图,我们通过一张图统管阿里巴巴99.9%计算数据资产,每个部门的存储计算成本将全部量化,直接展现在管理者的面前。 第二个问题:如何看资产?对于企业而言,资产难道就是一个个成本的数字吗?阿里巴巴通过数据资产的透视,让管理者知道我自己的数据来源于哪,服务给谁,谁又是我最好的合作伙伴,同时又可以满足数据流动审计的需求。 第三个问题:如何进行资产的规模化?新的业务合并/收购/创新,如何将这套资产体系快速地复制?在DataWorks等工具中提供数据中台建模工具,能够为数据中台建设提供规范化图纸,针对不同的业务域进行划分,进行智能建模,让新业务快速复用之前成熟的数据架构,达到资产规模化的能力。

挑战二:数据质量体系

对于数据质量来说,首先要先解决的一个问题是:事前质量如何定义?金融行业经常提到一个概念叫对账,阿里巴巴数据也要对账,针对超过千万级别数据表的对账问题,我们提了“质量规则”的概念。700多万质量规则,每天新增1万多条,人工要怎么配?阿里巴巴建设了37种规则模板,通过智能规则推荐匹配,采纳率达到75%。 第二个问题:事中质量如何执行?700多万条质量规则需要耗费大量计算资源怎么办?通过什么方式来降低成本?我们通过智能化技术建设了数据质量调度引擎、ETL引擎,数据变更后实时触发质量监控,采用优先级策略,进行空闲运行。 第三个问题:事后质量如何自动化?规则写死了,但数据是活的,遇到周期性波动和变化怎么办?我们在数据质量建设的时候融入很多人工智能的技术,通过机器学习方式学习数据生成的样子,能够对动态阈值进行智能预测,通过算法匹配周期性波动。

挑战三:数据安全体系

对于数据安全来说,要解决如何降低使用成本,提高易用性;如何覆盖数据全生命周期;如何做权限管控;如何数据脱敏,如何识别敏感行为进行数据溯源等问题,阿里巴巴内部沉淀了超过20项不同的安全治理规则,这些规则最终能够帮助平台在满足业务高速增长的情况下同时满足个人合规的要求。

挑战四:数据治理体系

当数据治理进入深水区,数据成本增速如何不超过业务增速;如何调动全员治理的积极性,培养成本意识,在阿里巴巴,数据治理是引擎、平台和人的互相配合,引擎对算力和成本极致追求,持续打破快速增长的数据计算与成本增长的线性关系,平台通过存储健康分、计算健康分成为集团各团队数据治理战役的核心指标,推动人做数据治理和管理,利用平台全链路工具,构建数据治理技术运营体系。通过这样的成本报表的方式把平台层的成本和价值展示清楚。 可以看出,在12年数据平台建设期间,阿里巴巴从数据的资产、质量、安全、治理等多个纬度沉淀出了数据中台产品化的能力。 

03

作为中台底座,数据平台下一站走向何方

 

未来,作为中台的底座,数据中台将从数据智能到智能数据,“湖仓一体”满足架构灵活升级、“智能数仓”解决超大规模下的数据管理难题、“智能查询”极大降低数据分析门槛、AI的云原生化/规模化/标准化与普惠化让其成为大数据的终极出口,不断加速大数据与AI一体化的融合。

趋势一:一体两面的湖仓一体

image.png


作为下一代数据平台架构,湖仓一体满足复杂现状下架构的灵活升级。数据仓库主打企业级数据,处理更精细、更经济、更高效。企业可以建设自己的数据中台,无论是引擎优化,还是数据管理,有一整套方法论以及支撑的工具。但是进入门槛很高,成本又贵,还有使用门槛。数据湖是脱胎于开源体系的技术,进入门槛和成本较低,比较灵活,企业容易实现自建数据湖,只是数据统一存储之外,企业需要进一步做各种精细化管理,希望数据能治理,能管理,成本低,还可运维。 如何打通数据湖和数据仓库割裂的体系,架构上融合数据湖的灵活性以及数据仓库的企业级能力,阿里巴巴提出的湖仓一体架构,统一存储和元数据,打通数据体系,利用智能数仓技术针对不同的数据和义务,做自动分类存储和处理。

趋势二:数据仓库进入“自动驾驶”时代

image.png


超大规模数据带来管理难题,传统的“DBA模式”已经很难胜任。阿里巴巴有超过千万级别的表,很多核心数据开发工程师,一个人负责上万张表,没有办法做精细化的治理和建模,这样的系统不能随人的方式扩展,所以未来,越来越多的AI技术会融合进大数据系统,进入“自动驾驶”时代。

趋势三:所查即所得,基于自然语言的智能数据查询

阿里巴巴正在数据之上尝试构建一个超大规模的知识图谱,通过知识图谱的方式做数据到语义层的翻译,再通过NLP(自然语言处理)等技术跟用户做结合,形成一个桥梁。比如用户输入北京市互联网客户有哪些,就可以自动生成得到一份数据。阿里巴巴正试图把通过自然语言的智能查询在海量数据上用起来,规模化起来,让更多的非专业数据人员也可以独立完成数据分析工作。

趋势四:数据即智能,AI工程化的基础能力

image.png


数据需要智能的加速,AI是大数据的终极出口。我们知道,真正想把AI用起来是一个非常难的事情,从最初的数据兴起、数据提炼、模型训练、模型调优,再到模型部署和服务,整个链路非常长。如果我们有5万人可以直接使用数据,可能真正能用AI的人可能不超过5000人,那如何把AI技术随着数据赋能给业务方,这就是所谓的AI工程化。 image.png

最后总结一下,上述内容只是泛泛地提到了阿里数据中台底座建设的四个典型阶段,遇到的四大技术挑战,以及数据平台的四大技术趋势等话题,这些内容还不是阿里巴巴数据中台的全部。通过12年时间,阿里巴巴数据平台建设已经有了非常多的技术积累,这些平台能力也在不断推动数据中台向智能化进化,并且还会一直向前演进,服务阿里巴巴并输出给全社会。

相关实践学习
阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
通过该实验体验在阿里云百炼中构建企业专属知识库构建及应用全流程。同时体验使用ADB-PG向量检索引擎提供专属安全存储,保障企业数据隐私安全。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
相关文章
|
6月前
|
SQL 运维 关系型数据库
基于AnalyticDB PostgreSQL的实时物化视图研发实践
AnalyticDB PostgreSQL企业数据智能平台是构建数据智能的全流程平台,提供可视化实时任务开发 + 实时数据洞察,让您轻松平移离线任务,使用SQL和简单配置即可完成整个实时数仓的搭建。
612 1
|
15天前
|
JSON 数据可视化 NoSQL
基于LLM Graph Transformer的知识图谱构建技术研究:LangChain框架下转换机制实践
本文介绍了LangChain的LLM Graph Transformer框架,探讨了文本到图谱转换的双模式实现机制。基于工具的模式利用结构化输出和函数调用,简化了提示工程并支持属性提取;基于提示的模式则为不支持工具调用的模型提供了备选方案。通过精确定义图谱模式(包括节点类型、关系类型及其约束),显著提升了提取结果的一致性和可靠性。LLM Graph Transformer为非结构化数据的结构化表示提供了可靠的技术方案,支持RAG应用和复杂查询处理。
61 2
基于LLM Graph Transformer的知识图谱构建技术研究:LangChain框架下转换机制实践
|
3月前
|
机器学习/深度学习 自然语言处理 搜索推荐
LangChain在个性化内容生成中的实践
【8月更文第3天】随着人工智能技术的发展,个性化内容生成已经成为许多应用的核心竞争力。LangChain 是一种开源框架,旨在简化语言模型的应用开发,尤其是针对自然语言处理任务。本文将探讨 LangChain 如何帮助开发者根据用户的偏好生成定制化的内容,从挑战到实践策略,再到具体的案例分析和技术实现。
176 1
|
6月前
|
机器学习/深度学习 人工智能
【LangChain系列】第九篇:LLM 应用评估简介及实践
【5月更文挑战第23天】本文探讨了如何评估复杂且精密的语言模型(LLMs)应用。通过创建QA应用程序,如使用GPT-3.5-Turbo模型,然后构建测试数据,包括手动创建和使用LLM生成示例。接着,通过手动评估、调试及LLM辅助评估来衡量性能。手动评估借助langchain.debug工具提供执行细节,而QAEvalChain则利用LLM的语义理解能力进行评分。这些方法有助于优化和提升LLM应用程序的准确性和效率。
547 8
|
6月前
|
存储 机器学习/深度学习 人工智能
【LangChain系列】第八篇:文档问答简介及实践
【5月更文挑战第22天】本文探讨了如何使用大型语言模型(LLM)进行文档问答,通过结合LLM与外部数据源提高灵活性。 LangChain库被介绍为简化这一过程的工具,它涵盖了嵌入、向量存储和不同类型的检索问答链,如Stuff、Map-reduce、Refine和Map-rerank。文章通过示例展示了如何使用LLM从CSV文件中提取信息并以Markdown格式展示
290 2
|
6月前
|
机器学习/深度学习 自然语言处理 数据挖掘
【LangChain系列】第七篇:工作流(链)简介及实践
【5月更文挑战第21天】LangChain是一个框架,利用“链”的概念将复杂的任务分解为可管理的部分,便于构建智能应用。数据科学家可以通过组合不同组件来处理和分析非结构化数据。示例中展示了如何使用LLMChain结合OpenAI的GPT-3.5-turbo模型,创建提示模板以生成公司名称和描述。顺序链(SimpleSequentialChain和SequentialChain)则允许按顺序执行多个步骤,处理多个输入和输出
951 1
|
6月前
|
存储 人工智能 搜索推荐
【LangChain系列】第六篇:内存管理简介及实践
【5月更文挑战第20天】【LangChain系列】第六篇:内存管理简介及实践
191 0
【LangChain系列】第六篇:内存管理简介及实践
|
6月前
|
存储 机器学习/深度学习 人工智能
【LangChain系列】第一篇:文档加载简介及实践
【5月更文挑战第14天】 LangChain提供80多种文档加载器,简化了从PDF、网站、YouTube视频和Notion等多来源加载与标准化数据的过程。这些加载器将不同格式的数据转化为标准文档对象,便于机器学习工作流程中的数据处理。文中介绍了非结构化、专有和结构化数据的加载示例,包括PDF、YouTube视频、网站和Notion数据库的加载方法。通过LangChain,用户能轻松集成和交互各类数据源,加速智能应用的开发。
365 1
|
6月前
|
人工智能 测试技术 API
【AIGC】LangChain Agent(代理)技术分析与实践
【5月更文挑战第12天】 LangChain代理是利用大语言模型和推理引擎执行一系列操作以完成任务的工具,适用于从简单响应到复杂交互的各种场景。它能整合多种服务,如Google搜索、Wikipedia和LLM。代理通过选择合适的工具按顺序执行任务,不同于链的固定路径。代理的优势在于可以根据上下文动态选择工具和执行策略。适用场景包括网络搜索、嵌入式搜索和API集成。代理由工具组成,每个工具负责单一任务,如Web搜索或数据库查询。工具包则包含预定义的工具集合。创建代理需要定义工具、初始化执行器和设置提示词。LangChain提供了一个从简单到复杂的AI解决方案框架。
688 3
|
6月前
|
人工智能 安全 API
【LangChain系列】第十篇:数据保护简介及实践
【5月更文挑战第24天】本文探讨了在使用大型语言模型时保护个人数据的重要性,特别是涉及敏感信息如PII(个人可识别信息)的情况。为了降低数据泄露风险,文章介绍了数据匿名化的概念,通过在数据进入LLM前替换敏感信息。重点讲解了Microsoft的Presidio库,它提供了一个可定制的文本匿名化工具。此外,文章还展示了如何结合LangChain库创建一个安全的匿名化流水线,包括初始化匿名器、添加自定义识别器和操作符,以及在问答系统中集成匿名化流程。通过这种方式,可以在利用LLMs的同时保护数据隐私。
166 0