写点什么

解读数据架构的 2020:开放、融合、简化

数据架构,不止于数据

2020 年 12 月 24 日

解读数据架构的2020:开放、融合、简化

本文是 InfoQ“解读 2020”年终技术盘点系列文章之一。


在数字时代,数据架构堪称企业 IT 架构的大动脉。这个架构里包括了诸多模块:数据导入导出、处理、存储、管理、查询、应用和可视化。过去十年,整个数据架构发生了大幅的更新和改变,尤其伴随着公有云崛起、数据爆炸、人工智能复兴等诸多大潮席卷而来,整个数据架构正在发生天翻地覆的变化。并且在未来十年,这个趋势仍会继续,原有的架构会不断被改良甚至颠覆。


本文将简要谈谈笔者所看到的 2020 年数据架构现状和对未来趋势的展望。

现状:数据驱动、AI & ML、公有云、云原生、开源成为主流


毋庸置疑,2020 年是里程碑的一年。在全球疫情大流行的阴影笼罩下,传统经济形态受创严重,由于各国的封城政策,实体经济要不拥抱数字经济,与互联网融为一体,要不就歇业甚至倒闭。“ 两年的数字化转型在两个月完成了”,微软 CEO Staya Nadella 在年初如是说。阿里巴巴这几年也一直强调自己是一家数据公司。在数字化的大背景下,数据驱动、人工智能和机器学习已经成为公司能否脱颖而出的标配。智能推荐、异常检测、日志分析这些典型的智能应用已经成为数字架构的基本应用场景。根据领英的2020新兴职业报告,数据科学家、数据工程师和人工智能专家在各个国家都炙手可热。


与此同时,公有云在欧美国家已经成为主流,即使在数据架构最保守的金融业也是如此。美国信用卡行业巨擘 Capital One Bank 在 2020 年冬天完全关闭了所有的数据中心,全线进入公有云。无独有偶,美国国防部 100 亿美金的 JEDI 项目也在九月正式确认选择微软的云服务。由此可见,公有云已经成为数据架构平台的主流趋势,安全性问题不再是上云的拦路虎。各大公有云厂商的靓丽财报也充分说明了各大企业在用实际行动投票。


另外,在公有云的大背景下,云原生成为了新一代数据架构的主流标准。公有云所提供的对象存储、弹性计算、按需使用等特性在架构设计的考虑中需要重新设计。除了公有云厂商的标配服务外,跨云平台的第三方的服务提供商(比如,Snowflake 和 Databricks 等)也受到用户的追捧。云原生的数据仓库提供商 Snowflake 在 2020 年秋天上市,市值一度攀升至超过一千亿美金。相比之下,传统数据仓库的顶尖提供商(如 Teradata)市值还不到 30 亿美金。可见,华尔街的资本市场对云原生和公有云的前景信心十足。


最后,开源软件的战略意义,随着中美贸易摩擦加剧,被提到了前所未有的高度。作为企业的核心 IT 生命线,数据架构需要做到风险可控和成本可控。成熟的架构选型需要保证企业的数据架构不被特定国家的政策影响,不被特定软件锁定,不被特定云厂商锁定。因此,基于开源项目的产品和服务在架构选型中异常热门。在红帽公布的2020企业开源报告里,数据库和数据分析的开源软件使用高居第三和第四名。与此同时,各大 IT 企业也积极参与到了开源社区的工作中,投入资源,共同开发开源软件。

趋势:AI 和 BI 的统一


数据架构的核心在于使用场景和使用群体。以 BI(商务智能)为主要使用场景的数据仓库一直是数据架构的核心。而过去十年,通过大数据驱动的 AI(人工智能)渐渐从新贵变成了主流。高效支持 AI 的数据使用也成为数据架构设计的必选项。因此,数据架构的设计必须考虑到 AI 和 BI 的不同需求。数据架构的用户也不再仅仅是主攻 SQL 来做报表的数据分析师,而是扩展到了数据工程师和数据科学家。数据工程师要设计和维护大量的数据 Pipeline(比如 ETL/ELT)来实现数据清理和管理。数据科学家则需要做数据的探索、建模、部署、修正。如何满足以上不同需求并简化架构,变成了数据架构设计的核心指标。


统一 AI 和 BI 是否意味要统一语言?有不少传统的 BI 系统(尤其是数据库和数据仓库的厂商)正在尝试扩展 SQL 语言来给数据科学家和数据工程师提供相关的功能。可是,这个努力正在被 SQL 语言的表达力所限制,而打破标准的形形色色的扩展也牺牲了应用的可迁移性。更为致命的缺陷是,这些 SQL 扩展很难融入 AI 的生态圈。AI 的应用不仅仅局限在若干 API 的调用或数据查询。AI 系统包含一系列复杂的数据操作,包括数据探索、可视化、清理、融合、建模、部署、修正。整个过程中经常需要调用大量的第三方库,而这些库往往又使用不同的语言。幸运的是,随着人工智能、机器学习和数据科学的爆发扩展,Python 逐渐成了这个领域的官方默认语言。拥抱和支持 Python 已经逐渐成为必选项。SQL 不会是数据架构的唯一语言,反而多语言的支持会是主流。


数据拷贝?为了同时支持 AI 和 BI 的使用场景,常见的方法是简单地将数据拷贝成多份,但这也会带来相当深远的危害。不单大幅增加了存储的费用,而且降低了数据的实时性和一致性,进而影响正确性和准确性。更重要的是,多拷贝会给数据安全带来重大隐患。任何数据的泄露都是影响公司品牌和用户隐私的重大事故。存储和计算的分离是数据架构当前的发展趋势。数据将以开放标准的数据格式(比如,Delta Lake 就选择了开源的 Apache Parquet 格式)来存储和管理,从而避免不必要的数据迁移和拷贝;数据查询、处理和使用则基于用户的具体需求来选择最合适应用程序和计算平台。

趋势:数据湖和数据仓库的统一


传统数据仓库的诸多局限(比如,价格昂贵、数据必须结构化等)促使数据湖在大数据时代横空出世。可是,数据湖的可靠性缺陷也让它的使用变得复杂异常,而且它的性能也不如数据仓库。过去几年间,数据仓库和数据湖方案都在快速变化,除了解决各自的不足,二者之间的边界也正在逐渐淡化。这个趋势在公有云更加明显,云原生的新一代数据架构不再遵循数据湖和数据仓库的经典架构。对于底层的数据存储媒介,新一代架构不再选择数据仓库在公有云上重建一套复杂的存储服务,反而像数据湖采用公有云所提供的可靠且廉价的对象存储服务(比如,AWS S3 和 Azure Blob)。与此同时,经典的数据仓库的相关性能优化和可靠性设计也被百花齐放的新一代存储结构所采纳。其中既有闭源的产品(比如,Snowflake、Redshift、Synapse、BigQuery),也有开源项目(比如,Delta Lake、Apache Hudi、Apache Iceberg、Hive ACID)。更准确地说,未来越来越多的云原生方案会融合数据湖和数据仓库的优势重新建构,取其精华、去其糟粕,而非局限于数据湖或者数据仓库的单一架构。今年年初Lakehouse的提出,就可以看作这个方向的一个典型例子。

趋势:从数据管理到元数据管理


数据管理和其元数据的管理是相伴相生的。最大化挖掘数据价值离不开元数据管理。数据发现、分享、使用和监控都建立在元数据管理的基础之上。在大数据时代,数据源的丰富化、数据内容的快速迭代、数据的分散管理、数据使用者的多样性,这些都让元数据管理变得异常艰难。


Gartner 的 ”Survey Analysis: Data Management Struggles to Balance Innovation and Control“ 显示,当前数据管理团队只有 8%的时间花在元数据管理和 Data Catalog 的约束上。从某种程度上说,元数据管理的重要性在绝大多数的数据架构里都被严重低估了。当前存在的一个普遍现象是,数据资源的查找和共享还处于原始社会阶段,而数据文档的质量和所有权也普遍缺乏规范。


为了解决元数据管理的急切需求,过去两年,各大公有云厂商都相继推出和增强 Data Catalog 服务。今年几个头部科技企业也陆续开源了自己的 Catalog 项目,比如,领英开源了DataHub,并且初创团队创立了 Metaphor Data 公司,而Lyft Amundsen也加入了 LF AI Foundation 并创立了 Stemma 公司。我们预计,未来元数据的管理系统将会成为数据架构的核心部件。元数据的可视化、数据的血统追溯、管理自动化、操作简单化和元数据的快速分析都会成为标准。

趋势:数据流水线(Data Pipeline)从复杂到简单


在数据驱动一切的当下,数据流水线就如心脏到大脑的血管,不容有错,可是数据的爆炸式增长和业务逻辑的动态性导致流水线的设计异常复杂。早在 2016 年,Spark 2.0 开始提出批流一体,当前已经被整个业界普遍接受,其核心理念是降低数据流水线的复杂度,将状态信息存储到 state store 里,从而简化批处理定期重启和容错处理的操作。2017 年,带有 ACID 属性的存储层(比如,Delta Lake)进一步解决了数据流水线的诸多痛点,比如 ACID 一致性、回滚、审查、数据更新和错误矫正。可是,即便如此,整个流水线还是异常复杂。背后的核心问题是流水线的设计和实现还停留在命令式(imperative),还是所谓的过程导向。当前,流水线的复杂性和脆弱性暴露给了终端使用者,维护和优化的难度相当之高。未来数据流水线也会被抽象成结果导向的声明式(declarative),只需要声明业务逻辑,就可以实现整个 pipeline。把复杂留给数据架构系统的实现者,而对使用者做到真正的简单易用。

大潮来袭


数据无处不在,并且已经成为各行各业商业决策的全新驱动引擎。随着以数据为核心的新兴应用场景不断涌现,数据架构必然会不断进化和蓬勃发展。这一切,仅仅是开始。我们坚信,未来十年还会持续涌现出新的架构和新的趋势。而数据架构是服务于具体业务需求的,因此,在数据架构的选型上,盲目求新往往是大忌。从业务实际需求出发,选择最适合的,才是企业数字化转型成功与否的关键。


由于篇幅有限,本文无法全面涉及每个模块的具体变化和发展。如有疏漏,敬请谅解。


作者介绍:

李潇,现就职于 Databricks,主管 Spark 研发团队,专注于 Apache Spark,Databricks Runtime 和 Koalas 的研制和开发。他也是 Apache Spark 项目管理委员会成员。本科毕业于南京理工大学,后在佛罗里达大学(University of Florida)获计算机博士学位, 曾就职于 IBM,获发明大师称号(Master Inventor),在数据处理领域发表专利十余篇。(Github: gatorsmile)


相关盘点文章:

《解读2018:13家开源框架谁能统一流计算?》

2020 年 12 月 24 日 13:251173
用户头像
蔡芳芳 InfoQ高级编辑

发布了 507 篇内容, 共 231.7 次阅读, 收获喜欢 1410 次。

关注

评论

发布
暂无评论
发现更多内容

只加两行代码,为什么用了整整两天时间?

程序员生活志

编程 bug

将设计模式应用到日常的curd中-模板方法和装饰器

LSJ

Java 设计 设计模式 装饰器 模板方法

快速学习秘诀:费曼学习法

池建强

学习

RushPlayer“一键下马”系列之-JavPlayer

flow

软件规模扩张与其组织粒度的进化

superman

中台 微服务 服务化改造

SpreadJS 纯前端表格控件应用案例:医疗行业智能报表系统

Geek_Willie

娱乐至穷

北柯

学习 互联网 娱乐 抖音

低/零代码的认知误区有哪些?

代码制造者

编程语言 低代码 零代码 信息化 开发应用

中国计算机软件开发合同纠纷分析报告(2019-2)

朱又生

项目管理 计算机软件开发合同纠纷 风险管理 司法大数据

华章科技好书5折优惠,满99再减10元

华章IT

Python AI 数字化转型 Java 25 周年 计算机科学丛书

week10 学习总结

任小龙

信息管理软件需求分析阶段的实践经验及论述(2010年)

朱又生

项目管理 产品经理 需求分析 用户需求调研

中国计算机软件开发合同纠纷分析报告(2019-1)

朱又生

项目管理 计算机软件开发合同纠纷 风险管理 司法大数据

Oracle常用命令

阡陌r

即大数据后-贵阳能否成为区块链的机遇之城?

CECBC区块链专委会

区块链 大数据 贵阳

微服务

石印掌纹

35岁腾讯员工被裁员感叹:北京一套房,存款700多万,失业好焦虑

程序员生活志

程序员生活

anyRTC 4.0 以心铸造,以梦相承

anyRTC开发者

anyRTC 4.0 官网升级

IMC御用设备到底有多强?英特尔携手掠夺者呈现“飞”一般5GHz电竞盛宴

飞天鱼2017

SpreadJS 纯前端表格控件应用案例:生产采购管理软件

Geek_Willie

第十周总结

晨光

微服务的认识

chenzt

不断壮大的电竞生态——英特尔大师挑战赛携手李宁中国选手等你来战!

飞天鱼2017

第四届IMC再起烽烟 极致性能助战力升级!

飞天鱼2017

Flink 支持的重启策略有哪些

古月木易

flink

架构师训练营第10周

大丁💸💵💴💶🚀🐟

中国计算机软件开发合同纠纷分析报告(2019-3)

朱又生

项目管理 计算机软件开发合同纠纷 风险管理 司法大数据

第十周作业

晨光

如何通过electron构建桌面跨平台音视频应用

ZEGO即构

音视频 Electron RTC

央行清算总中心与三家银行签署区块链福费廷交易平台合作协议

CECBC区块链专委会

区块链技术 人民银行

架构师训练营第十周作业

一剑

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

解读数据架构的2020:开放、融合、简化-InfoQ