写点什么

阿里云为什么要做多模数据库?

2020 年 12 月 03 日

阿里云为什么要做多模数据库?

Gartner 曾在 2017 年预测多模数据管理将成为未来的主要趋势,并在随后几年逐渐成为主流数据库的选择。当前多模数据库的发展到底处于一个什么样的阶段?主要在哪些场景下使用?未来将会有怎样的突破?近日,InfoQ 有幸邀请到阿里巴巴资深技术专家沈春辉(天梧),请他聊一聊多模数据库的构建和发展。他还将在QCon全球软件开发大会(深圳站)“现代数据架构”专题中进行《阿里云Lindorm面向多模数据管理的技术创新与实践》的分享,敬请关注。


以下是采访实录:


InfoQ:您从 2011 年就开始从事面向大数据场景的分布式数据库研发工作,这期间您经历了大数据领域哪些新老技术的更迭和演进?


沈春辉:在大数据发展史上,有两个影响深远的标志事件,一个是 2004 年前后,谷歌发表 GFS、MapReduce、Bigtable 三篇论文,证明了大数据从理论概念到生产实践的业务价值,并给出了架构典范;另一个是 2008 年,Hadoop 正式成为 Apache 顶级项目,把大数据带入到各大企业尤其是互联网企业的 IT 基础设施中。


在过去的十多年,随着对数据规模、处理速度、易用性、成本、效率等越来越多的需求,我们看到大数据架构和产品不断地推陈出新。起初,Hadoop 作为大数据的代名词,支持存储和计算能力的水平扩展,很好地解决了规模化的挑战,但随着大数据应用到各个场景,各种需求开始井喷,Hadoop 也从单一系统走向一个多元化生态。比如:


  • Hive,让 SQL 进入到 Hadoop,大大降低了使用门槛;

  • HBase,通过 LSM 架构,满足了海量数据的高并发吞吐;

  • Spark,通过基于内存的分布式计算,大幅提升了数据处理的效率;

  • Storm、Flink、Spark Streaming 等流计算系统,有效提升了数据处理的实时性;

  • 还有 Presto、Kylin、Impala 等,在不同场景下,加速大数据复杂分析。


所以,现代企业的大数据平台大多都是基于 Hadoop 生态构建的“一存多算”的多元化架构,即以 HDFS 为统一存储,通过 HBase、Spark、Flink、Presto 等多种计算引擎满足不同场景的处理需求,这个架构的优点是适用范围广、灵活性强,但缺点是成本高、维护复杂、体验较差,这也会是未来技术继续向前演进的方向。


InfoQ:您将在QCon深圳2020分享的话题是“面向多模数据管理的技术创新与实践”,在您看来,当前多模数据库的发展整体处于一个什么样的阶段?


沈春辉:在互联网发展之前,数据库可以说基本就是在关系模型上发展,比如发展了几十年的 Oracle、DB2,而 NoSQL 的出现打破了这一惯性,KV、宽表、文档、图、时序等多种模型都得到了广泛应用和快速发展,但这个趋势也会使得应用开发变得越来越复杂,记得在 2012 年的 NoSQL 大会上,有大佬提出了“多模数据库”的概念,设想一个系统可处理多种类型数据,以简化应用数据架构,减少开发维护成本。随着 NoSQL 系统在单模能力上的成熟,以及应用数据需求的多样化,业界开始进入对多模数据库的探索和实践,通过 db-engine 网站,我们可以看到越来越多的流行数据库已经走向多模数据库。


多模数据库,其目标是将多个系统组合使用的解决方案下沉为数据库内置能力,与传统分库分表方案升级为分布式数据库能力相似,所以,这是一个相对漫长的建设过程,我们为其定义了四个阶段,也可以说是系统开发的四个路标,分别是多种类型、垂直引擎、跨模融合、统一访问,如果按此看,那么大部分业界多模数据库现在可能处于第一、二阶段,其能力主要是提供多种类型的数据接口,在不同模型的处理效率上有所侧重倾斜,在数据联接上有所缺失,还是很难在生产中真正替换多套系统组合使用的方案。


InfoQ:是什么原因驱动阿里从 HBase 转到多模数据库的?整体架构设计是如何考量的?


沈春辉:阿里 HBase 的发展已经有比较长的时间,过去主要聚焦在成本、性能、可用性等通用能力的深度自研,所以,在这个方向上算比较成熟了。然而,现代应用场景的玩法和功能变得越来越丰富,除了高扩展、低延时、高可用、低成本等核心需求之外,简单分析、多维检索等高级数据处理正在成为越来越多应用的基本需求,为此,我们看到当数据量小的时候,一个关系数据库基本能解所有问题,但数据量大的时候,很多场景需要混用 HBase、ES、TSDB、SQL 等系统,像是监控、IoT、画像、社交等等,每一个应用都需要开发数据中间层来对接多种数据库,去处理模型转换、数据分发、数据同步、查询合并等一系列问题,最终期望这多个异构系统组合成为一个数据库系统工作,面向上层的业务逻辑提供统一存储、统一访问并保证数据正确。


针对这种普遍存在的共性需求,我们期望使用多模数据库的思路进行解决,打造一个同时具备宽表、时序、搜索等多种模型处理能力的数据库,帮助业务重新聚焦于应用逻辑,这就是我们 2020 年 9 月上线的云原生多模数据库 Lindorm(中文名:灵动)。


Lindorm 目前主要聚焦于第三阶段跨模融合的能力建设,在业务需求满足上,可以达到及超过多套系统组合使用的效果,并相比有明显更低的开发维护成本,随着系统能力的逐渐完善,对业务的价值优势也会越来越明显。Lindorm 在系统架构上主要考虑了云原生、多模原生两个方面,核心是构建弹性按需伸缩、多模融合处理、高效低成本等能力,具体的架构设计也将在此次的 QCon 会议上分享,欢迎大家的关注。


InfoQ:哪些场景适合用 Lindorm,您认为多模数据库带来的最大改善和提升是什么?下一步的计划是什么?可以给想要做或者正在做这些事情的同学一些建议吗?


沈春辉:多模数据库 Lindorm 目前支持宽表、时序、搜索、文件四种模型,我们在选择模型时主要考虑面对海量数据的实际场景需求和自身过去的技术积累。比如,对于监控、IoT、广告、社交、风控等数据驱动型业务,目前可能混合使用了 MySQL、HBase、ElasticSearch、OpenTSDB、Ceph、Hive 等类似系统,这中间的数据链路会是比较复杂的,通过 Lindorm 则可以替换其中的多个组件,大幅简化架构,实现降本增效。


具体来说,对于一个监控系统,Metrics、Logging、Tracing、参数属性、报警视频等这些数据都各自需要一个系统进行存储,数据的关联、分析、同步和低成本处理都需要业务侧进行方案设计和实施,没有一个十几人团队很难把这样一个大型监控应用做好,其中大部分精力投入在数据层的设计、开发和维护,这还不包括背后的四五个数据库系统团队支撑,一句话总结就是协同成本和冗余成本巨高,而通过 Lindorm 的多模融合处理能力,将多种数据的操作管理需求下沉到数据库系统,使得应用在效率、成本、体验上可以获得非常明显的提升。


在技术上,Lindorm 吸取了阿里过去多年在宽表、时序、搜索等垂直领域的能力,如果仅仅将其当成一个单模系统使用,那么已经比较成熟了,而在多个数据模型之间的融合打通方面,还有不少工作要做,比如模型转换、统一访问、统一管理、资源共享等。另外,前面也提到,云原生是我们另一个关键方向,Serverless、云原生存储、智能运维等都是重点攻坚的工作。


如果要建设一个多模数据库系统,个人认为有两个选择是比较关键的:


  • 系统支持哪些模型?


可能会有一个误区,多模数据库的发展会进入到“All In One”,这可以看成是一种理想,但软件工程的自身能力是有限制的,随着数据种类支持的添加,其复杂性会大幅增加,并且对上层的统一抽象难度也会加大,其可实现性是未知的,或者说现有能力是不可实现的,所以,系统需选择有限的模型进行支持,具体的选择可以结合需求,比如 Lindorm 主要是根据业务场景的实际混合使用情况进行选择,你也可以根据被使用的规模大小和可结合性;


  • 多模技术中哪些共享,哪些独立?


共享的厚一点,工程迭代效率会更高,但可能会牺牲一定地运行效率,目前业界选择主要是两种,一种是在 KV 层共享,类似基于 HBase 构建 OpenTSDB、JanusGraph,另一种是在文件层共享,比如 Lindorm 的宽表引擎、时序引擎、搜索引擎都是构建在分布式文件系统之上,这样数据的组织索引就可以有更大的设计空间,在性能上可以有更大优势,从而除了多模混合使用场景之外,在独立的垂直场景,也无需换用专用数据库。


InfoQ:您认为大数据领域还有哪些值得关注的技术方向?


沈春辉:个人目前比较关注云原生、一体化这两个技术趋势,这也是目前很多大型企业正在大力投入资源推进落地的方向,不管是学习,还是实践到自己的企业,都值得了解:


  • 云原生:上云已经成为企业数字化的共识,上云之后如何用好云是当前大家的重点讨论和思考,如果仍然按照过去线下机房的模式去部署和使用大数据,不仅无法获得云计算的红利,甚至在成本效率上可能面临诸多不适。所以,以“存储计算分离+弹性 Serverless”为代表的云原生大数据架构,实现存储计算的独立伸缩、资源弹性按需使用,大幅提升资源利用率、系统运维灵活性,成为接下来的主要趋势。在阿里云平台,我们以 Lindorm(兼容 HDFS、HBase 等多模的 Serverless 存储)+DLA(提供 Spark、Presto 等多模态的 Serverless 计算)向企业提供了云原生的大数据最佳实践,大家有兴趣可以关注交流。


  • 一体化:开源大数据技术经过十多年的快速发展,在采集、存储、计算、调度、管理等各个方面的整体版图已经相当完善,同时面向各个场景的存储计算引擎也呈现出百花齐放的景象,但这也加大了用户的使用门槛和维护复杂度,多种系统的一体化也越来越成为下一个大的发展趋势,比如多种模型数据库的一体化、大数据与数据库的一体化、批计算与流计算的一体化、数据湖与数据仓库的一体化等,这些技术上的整合,可以帮助企业更加经济高效的用好数据。


会议推荐:


想了解更多阿里云多模数据库的发展和技术实践细节,可以来 12 月 6-7 日的QCon全球软件开发大会(深圳站)的现场,与沈春晖老师当面交流。

2020 年 12 月 03 日 16:501606
用户头像
Kitty 极客邦科技会议主编

发布了 27 篇内容, 共 96962 次阅读, 收获喜欢 34 次。

关注

评论

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

Ray 1.0 架构解读

lipi

分布式计算 Apache Arrow ray

Python优化机制:常量折叠

Python猫

Python

为您收录的操作系统系列 - 进程管理(加餐)

Arvin

线程 进程 同步 生产者与消费者

7. ✎会查新华字典不?会。Python字典已经掌握了

梦想橡皮擦

Python 爬虫 2月春节不断更 python入门

定投,积沙成塔的财富增长方式

boshi

理财 七日更

手摸手Go 深入剖析sync.Pool

Leo叔叔

go Go Concurrency Patterns sync.pool

写一个用例(第四周)

mas

GitHub 上的优质 Linux 开源项目,真滴牛逼!

JackTian

GitHub Linux 开源项目 运维工程师 2月春节不断更

12周架构

FreeOcean

hadoop mapreduce YARN

聊聊金钱

熊斌

2月春节不断更

并发编程系列:阻塞队列的实现原理

程序员架构进阶

jdk 阻塞队列 七日更 28天写作 2月春节不断更

第四周作业

Ashley.

【LeetCode】找到所有数组中消失的数字Java题解

HQ数字卡

算法 LeetCode 2月春节不断更

前端冲刺必备指南-this/call/apply/bind(万字长文)

魔王哪吒

学习 程序员 面试 前端 2月春节不断更

千行百业中的我们,数字山河间的中国速度

脑极体

【LeetCode】杨辉三角Java题解

HQ数字卡

算法 LeetCode 2月春节不断更

Elasticsearch 分词器

escray

elastic 七日更 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

LeetCode 数据库刷题 - 596. 超过5名学生的课

小马哥

七日更 二月春节不断更

8. ㊙ Python 集合三板斧,滚雪球学 Python

梦想橡皮擦

Python 2月春节不断更 python入门

书画装裱物料与选择参考

boshi

业余爱好 七日更

【STM32】stm32f407 + DS18B20 碰出不一样的火花

AXYZdong

硬件 stm32 2月春节不断更

微信限量纪念版code封面来啦,速看领取方式

孙叫兽

视频号 2月春节不断更 孙叫兽 微信红包封面 纪念版

这段时间学习机器学习的感受

Nydia

Elasticsearch query string 分词

escray

elastic 七日更 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

职场心得

时间是一个人最好的证明

职场

走进 Tokio 的异步世界

lipi

rust 异步 tokio

日记 2021年2月12日(周五)

Changing Lin

2月春节不断更

备战春招/秋招,开源社区系统 Echo,基于目前主流 Java Web 技术栈,并提供详细的开发文档和配套教程

飞天小牛肉

Java 开源 后端 springboot 2月春节不断更

翻译:《实用的Python编程》01_02_Hello_world

codists

Python

第四周笔记

Ashley.

【STM32】5分钟了解STM32的串口通信

AXYZdong

硬件 stm32 2月春节不断更

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

阿里云为什么要做多模数据库?-InfoQ