对话阿里云李飞飞:关于云原生数据库的五大预判

对话阿里云李飞飞:关于云原生数据库的五大预判,第1张

作者:王慧贤

数据存储、数据分析、数据安全......如今,围绕“数据”的话题越来越多,离人们的生活也越来越近。

从陌生到熟悉,数据不仅“出圈”,甚至已然站在了C位。去年,中央发布的《关于构建更加完善的要素市场化配置体制机制的意见》中明确表示,继土地、劳动力、资本、技术后,数据成为第五大生产要素。

步入信息化时代后,数据库、 *** 作系统与中间件作为计算机最基础的三大软件,支撑着企业的正常运行。

当数据成为生产要素后,必然会迎来爆发式增长,企业的数据存储和处理需求将进一步释放。更重要的是,疫情加快了数字化转型的脚步,更加速了企业的上云速度。

从信息化到数字化,时代的变革,总会带来商业世界的变化。如何在云原生架构下使用数据库,成为企业的痛点和云厂商的机会,亚马逊AWS的CTO Werner Vogels曾多次强调:“数据库是云计算的终极之战。”

在数智化时代,云原生到底意味着什么?云原生数据库和传统数据库相比,核心优势是什么?是否把数据库搬上云就是云原生?基于这些问题,雷锋网与阿里巴巴集团副总裁、阿里云数据库产品事业部负责人李飞飞展开一场对话。

国产云原生数据库,摆脱「切肤之痛」

如今,数据库的商业世界,因为云的出现与发展,分成了两大派系。

一派是以Oracle为代表的传统商用数据库,一派是以国外AWS、国内阿里云为代表的云原生数据库,去“IOE革命”下的产物。

其实,早期较为火热的数据库种类有三种,层次式数据库、网络式数据库和关系型数据库。

在《浪潮之巅》一书中,作者吴军写下了这样的观点:“Oracle 的兴起很大程度上靠的是它最早看到关系型数据库的市场前景,并且在商业模式上优于 IBM。”

因此,在云原生数据库“入世”之前,数据库的天下一直是Oracle的,国内大部分互联网公司都不得不采用Oracle+IBM小型机+EMC的模式来维持正常运营。

高昂的费用,使得对于数据库需求较大的互联网巨头“忍无可忍”。

2009年,阿里巴巴的Oracle RAC 集群节点数达到了创记录的20个。可由于Oracle并没有d性扩展的功能,只能按照峰值流量购买小型机和数据库,导致阿里将业务上涨带来的大部分利润,都支付给了Oracle。

第二年,阿里便开始走上了去“IOE”之路,根据开源MySQL搭建了AliSQL,并顺利经过了淘宝双11的考验,国产云原生数据库算是正式摆脱了“切肤之痛”,逐渐受到市场的真正认可。

另一边,国外的AWS在2015年公布了基于云计算的自研数据库Amazon Aurora。Aurora是一个关系型数据库,可以跨3个可用区域复制6份数据,其最大的特性就是高性能和高可用性。

云计算巨头的入局,让云原生数据库在国内外一步步成为主流。据Gartner预测,到了2021年,云数据库在整个数据库市场中的占比将首次达到50%,到2023年,75%的数据库都要跑在云平台之上。

关于云原生数据库,随着逐步的出圈,也让人们关心的焦点从“是啥?”转变为“还能解决哪些问题?”

但云原生数据库存在着数据孤岛的问题,无法打通多个数据系统的情况下,企业在数据加工和数据管理上就会“压力较大”,甚至在数据安全方面还存在隐患。

传统数据仓库一般基于T+1数据集成构建离线数仓,以支撑企业各项分析与服务。传统方案不但会影响线上业务稳定性,且难以支持企业的实时需求。

因此,在李飞飞看来,云原生数据库已经走到2.0阶段。这个阶段要解决的问题,就是上述存在的痛点。

9月26日,在阿里云数据库创新上云峰会上,阿里云发布了首个一站式敏捷数据仓库解决方案。该方案结合一站式数据管理平台DMS及云原生数据仓库AnalyticDB(简称:ADB),实现了库仓一体的技术架构,提供在线数据实时入仓、T+1周期性快照、按需建仓等能力,数据延时低至秒级,持续赋能业务在线化,使企业的在线数据可以释放出更大的价值。

相较于传统方案,阿里云一站式敏捷数据仓库解决方案有4大核心优势:

1、对业务侧影响小,不会因为数据汇聚集中和实时加工影响业务侧正常运行,CPU、内存占用低于5%;

2、事务顺序和数据准确性有保障,且处理链路短,支持在线数据实时处理落仓,效率更高。数据传输效率100m/s,数据延时在10秒内;

3、支持复杂实时数据加工、计算逻辑;

4、低代码 *** 作,能够大大降低实时数仓的构建难度,提升构建效率的同时,支撑企业数字化转型过程中的各类实时场景。

除了实时统计分析场景外,企业为满足周期性数据分析需求,需建设周期性全量快照。

传统数仓的周期性全量集成方案会对生产业务造成稳定性影响、全量集成时效性差、且无法满足客户针对任意时间点进行数据回溯的业务诉求。

针对T+1周期性集成场景,一站式敏捷数据仓库解决方案支持基于拉链表的T+1全量数据快照,用户通过简单几个步骤,即可按需生成各种周期的全量或增量快照。

此外,业务还可按需进行任意时间点的数据回溯,以快速解决数据异常问题。

谈起未来数据库的发展趋势,李飞飞提到以下五点:

1、云原生+分布式一定是数据库的标配,分布式已经是必选项。分布式数据库由多个相互连接的数据库组合而成,面向用户则是以单个数据库的形态出现。云原生分布式数据库具备易用性、高扩展性、快速迭代、节约成本等特征,从资源池化到d性扩展,再到智能运维,再到离在线一体化,解决企业用户的核心诉求。

2、AI for DB(database,指数据库)和 DB for AI 将是主流趋势。用AI将数据库运维管控智能化,尤其在云原生+分布式这个前提下更重要,因为数据库不仅是内核的能力d性高可用、可拓展性,更重要的是部署后应用和运维的复杂度要大大降低。在数据库里,面对越来越多非结构化的数据,分析能力十分重要。

3、数据的安全可信,在今天这个大环境下变得愈发重要,如何确保整个数据库系统,在处理数据全链路过程中提供加密能力、多方安全计算能力、隐私保护的能力,也是很重要的趋势。

4、多模数据处理能力将越来越重要。比如,新型数据库多模态的处理能力,在新能源 汽车 企业打标签、智能电池化预测等应用场景中,将发挥越来越重要的作用。

5、一份数据,多个数据处理引擎:实现仓库一体、仓库联动、仓库打通,数据之间无缝流转。

以上判断,也从侧面反映出阿里云数据库的走向,这点毋庸置疑。但除此之外,业界最关心的,还有开源。

近半年,国内很多厂商相继提出开源战略,背后缘由显而易见,为了打造生态。就在今年的阿里云峰会上,阿里云智能总裁、达摩院院长张建锋(花名行癫)将2021年阿里云的发展关键词归纳为:做好服务、做深基础、做厚中台、做强生态。

做好服务与生态,成为如今厂商们不约而同的目标,而开源,就是最好的选择。

当雷锋网问到:“未来,阿里云数据库会不会把所有能力都开源?”这一问题时,李飞飞给到的回答是:“不会。”

之所以有这样的回答,是因为对于开源,他有着一些判断和看法。

李飞飞表示,这些部分,本就是阿里云数据库的商业化版本。

事实上,业界大多数的数据库厂商都不会针对自身的核心能力开源,如TiDB的核心管控组件、TiFlash。

与像MongoDB,、Cassandra、CouchDB这些以开源起家的数据库厂商不同,开源只是阿里云数据库的战略,不是阿里云数据库的命脉。

前几年,有业内人士表示,在面向开源时,国产数据库首先需要解决信任以及开源知识产权等问题。“开源会让厂商更加认真思考版权还有专利的问题,事实上,选择开源后,对于数据库厂商提出了更高的要求。”

李飞飞认为,开源只是一种选择,数据库开源成功并不代表着商业化就能够成功,不开源也不能代表厂商不先进。

更准确的说,开源只是一种有效手段。

最终,阿里云数据库希望客户能够通过开源版本把阿里云数据库产品技术快速用起来,并能够参与到技术产品的迭代过程中,在一些高阶能力上,借鉴团队专业能力和阿里云的服务能力,成为良好的商业合作伙伴,这是李飞飞以及阿里云数据库对于开源的一些基本思考。雷锋网雷锋网雷锋网

一、离线数据同步

DataX

阿里的Datax是比较优秀的产品,基于python,提供各种数据村塾的读写插件,多线程执行,使用起来也很简单, *** 作简单通常只需要两步;

创建作业的配置文件(json格式配置reader,writer);

启动执行配置作业。

非常适合离线数据,增量数据可以使用一些编码的方式实现,

缺点:仅仅针对insert数据比较有效,update数据就不适合。缺乏对增量更新的内置支持,因为DataX的灵活架构,可以通过shell脚本等方式方便实现增量同步。

参考资料:

github地址:https://github.com/alibaba/DataX

dataX3.0介绍:https://www.jianshu.com/p/65c440f9bce1

datax初体验:https://www.imooc.com/article/15640

文档:https://github.com/alibaba/DataX/blob/master/hdfswriter/doc/hdfswriter.md

Sqoop

Sqoop(发音:skup)是一款开源的工具,主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql…)间进行数据的传递,可以将一个关系型数据库(例如 : MySQL ,Oracle ,Postgres等)中的数据导进到Hadoop的HDFS中,也可以将HDFS的数据导进到关系型数据库中。

地址:http://sqoop.apache.org/

Sqoop导入:导入工具从RDBMS到HDFS导入单个表。表中的每一行被视为HDFS的记录。所有记录被存储在文本文件的文本数据或者在Avro和序列文件的二进制数据。

Sqoop导出:导出工具从HDFS导出一组文件到一个RDBMS。作为输入到Sqoop文件包含记录,这被称为在表中的行。那些被读取并解析成一组记录和分隔使用用户指定的分隔符。

Sqoop支持全量数据导入和增量数据导入(增量数据导入分两种,一是基于递增列的增量数据导入(Append方式)。二是基于时间列的增量数据导入(LastModified方式)),同时可以指定数据是否以并发形式导入。

Kettle

Kettle是一款国外开源的ETL工具,纯java编写,可以在Window、Linux、Unix上运行,数据抽取高效稳定。

Kettle的Spoon有丰富的Steps可以组装开发出满足多种复杂应用场景的数据集成作业,方便实现全量、增量数据同步。缺点是通过定时运行,实时性相对较差。

NiFi

Apache NiFi 是一个易于使用、功能强大而且可靠的数据拉取、数据处理和分发系统,用于自动化管理系统间的数据流。它支持高度可配置的指示图的数据路由、转换和系统中介逻辑,支持从多种数据源动态拉取数据。

NiFi基于Web方式工作,后台在服务器上进行调度。 用户可以为数据处理定义为一个流程,然后进行处理,后台具有数据处理引擎、任务调度等组件。

几个核心概念:

Nifi 的设计理念接近于基于流的编程 Flow Based Programming。

FlowFile:表示通过系统移动的每个对象,包含数据流的基本属性

FlowFile Processor(处理器):负责实际对数据流执行工作

Connection(连接线):负责不同处理器之间的连接,是数据的有界缓冲区

Flow Controller(流量控制器):管理进程使用的线程及其分配

Process Group(过程组):进程组是一组特定的进程及其连接,允许组合其他组件创建新组件

参考资料

Nifi简介及核心概念整理

官方网站:http://nifi.apache.org/index.html

二、实时数据同步

实时同步最灵活的还是用kafka做中间转发,当数据发生变化时,记录变化到kafka,需要同步数据的程序订阅消息即可,需要研发编码支持。这里说个mysql数据库的同步组件,阿里的canal和otter

canal

https://github.com/alibaba/canal

数据抽取简单的来说,就是将一个表的数据提取到另一个表中。有很多的ETL工具可以帮助我们来进行数据的抽取和转换,ETL工具能进行一次性或者定时作业抽取数据,不过canal作为阿里巴巴提供的开源的数据抽取项目,能够做到实时抽取,原理就是伪装成mysql从节点,读取mysql的binlog,生成消息,客户端订阅这些数据变更消息,处理并存储。下面我们来一起搭建一下canal服务

早期,阿里巴巴B2B公司因为存在杭州和美国双机房部署,存在跨机房同步的业务需求。不过早期的数据库同步业务,主要是基于trigger的方式获取增量变更,不过从2010年开始,阿里系公司开始逐步的尝试基于数据库的日志解析,获取增量变更进行同步,由此衍生出了增量订阅&消费的业务,从此开启了一段新纪元。

ps. 目前内部版本已经支持mysql和oracle部分版本的日志解析,当前的canal开源版本支持5.7及以下的版本(阿里内部mysql 5.7.13, 5.6.10, mysql 5.5.18和5.1.40/48)

基于日志增量订阅&消费支持的业务:

数据库镜像

数据库实时备份

多级索引 (卖家和买家各自分库索引)

search build

业务cache刷新

价格变化等重要业务消息

otter

https://github.com/alibaba/otter

otter是在canal基础上又重新实现了可配置的消费者,使用otter的话,刚才说过的消费者就不需要写了,而otter提供了一个web界面,可以自定义同步任务及map表。非常适合mysql库之间的同步。

另外:otter已在阿里云推出商业化版本 数据传输服务DTS, 开通即用,免去部署维护的昂贵使用成本。DTS针对阿里云RDS、DRDS等产品进行了适配,解决了Binlog日志回收,主备切换、VPC网络切换等场景下的同步高可用问题。同时,针对RDS进行了针对性的性能优化。出于稳定性、性能及成本的考虑,强烈推荐阿里云用户使用DTS产品。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5898210.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-07
下一篇 2023-03-07

发表评论

登录后才能评论

评论列表(0条)

保存