探析大数据需求下的分布式数据库

一、前言

大数据技术从诞生到现在,已经经历了十几个年头。市场上早已不断有公司或机构,给广大金融从业者“洗脑”大数据未来的美好前景与趋势。随着用户对大数据理念与技术的不断深入了解,人们已经开始从理论探索转向对场景落地的寻找,让大数据在企业中落地并开花结果。

从大数据的管理和应用方向集中在两个领域。第一,大数据分析相关,针对海量数据的挖掘、复杂的分析计算;第二,在线数据操作,包括传统交易型操作以及海量数据的实时访问。大数据高并发查询操作。用户根据业务场景以及对数据处理结果的期望选择不同的大数据管理方法。

分析型的大数据管理以Hadoop/Spark技术为主,适用于数据批处理分析挖掘的场景。随着时间推移,Hadoop由于开源生态体系过于庞大且扩张迅速,对于大数据工具选择、实施复杂度以及性价比都比较难以控制。近期,著名市场分析和咨询机构Gartner发布报告[Gartner 2017年报告《Hype Cycle for Data Management,2017》],报告指出目前大数据服务不再依赖单一Hadoop大数据商业平台,必须从满足用户的场景和案例的角度出发。

分布式数据库则是在线操作性的大数据管理而诞生的,强调满足大数据在实时高并发请求压力下的交互业务场景。这一领域的“大数据”应用也正在被更多的人接受,又由于分布式数据库的落地更简单,开发运维上更接近与传统数据管理系统。因此近年来分布式数据库市场也在快速地发展壮大。

二、技术体系对比

在上述大数据技术实现中,Hadoop技术看似是自成一套体系。Hadoop/Spark与分布式数据库的设计思路为什么有所差异,其定位和使用场景应该如何与分布式数据库技术进行区分?这需要从两种技术的起源与发展来进行分析。(Gartner 2017年报告)

1. 大数据分析

大数据分析体系以Hadoop生态为主,近年来逐渐火热的Spark技术也是主要的生态之一。其中,Hadoop技术只能算是以HDFS+YARN作为基础的分布式文件系统,而不是数据库。

Hadoop的历史可以向前追溯10年,当年Google为了在几万台PC服务器上构建超大数据集合并提供极高性能的并发访问能力,从而发明了MapReduce,也是Hadoop诞生的理论基础。

从Hadoop的诞生背景可以看出,其主要解决的问题是超大规模集群下如何对非结构化数据(Google扒取的网页信息)进行批处理计算(例如计算PageRank等)。实际上,在Hadoop架构中,一个分布式任务可以是类似传统结构化数据的关联、排序、聚集操作,也可以是针对非结构化数据的用户自定义程序逻辑。

再来看Hadoop的发展道路。最开始的Hadoop以Big、Hive和MapReduce三种开发接口为代表,分别适用于脚本批处理、SQL批处理以及用户自定义逻辑类型的应用。而Spark的发展更是如此,最开始的SparkRDD几乎完全没有SQL能力,还是套用了Hive发展出的Shark才能对SQL有了一部分的支持。但是,随着企业用户对Hadoop的使用越发广泛,SQL已经渐渐成为大数据平台在传统行业的主要访问方式之一。Hortonworks的Stinger、Cloudera的Impala、Databricks的SparkSQL、IBM的BigSQL都在两年前开始慢慢抢占市场,使得Hadoop看起来貌似也成为了SQL的主战场。

2. 分布式数据库

分布式数据库有着悠久的历史,从以Oracle RAC为代表的联机交易型分布式数据库,到IBM DB2 DPF统计分析性分布式数据库,分布式数据库覆盖了OLTP与OLAP几乎全部的数据应用场景。

大部分分布式数据库功能集中在结构化计算与在线增删改查上。例如IBM DB2 DPF,用户可以像使用普通单点DB2数据库一样,几乎透明地使用DPF版本。DPF中的SQL优化器能够将一个查询自动拆解并分发到多个节点中并行执行。

但是,这些传统的分布式数据库以数仓及分析类OLAP系统为主,其局限性在于,其底层的关系型数据库存储结构在效率上并不能满足大量高并发的数据查询以及大数据数据加工和分析的效率要求。

因此,分布式数据库在近几年也有着极大的转型,从单一的数据模型向多模的数据模型转移,将OLTP、联机高并发查询以及支持大数据加工和分析结合起来,不再单独以OLAP作为设计目标。同时,分布式数据库在访问模式上也出现了K/V、文档、宽表、图等分支,支持除了SQL查询语言之外的其他访问模式,大大丰富了传统分布式数据库单一的用途。一般来说,多模数据库的主要目的是为了满足具有高性能要求的操作型需求以及目标明确的数据仓库功能,而不是类似大数据深度学习等数据挖掘场景。

3. 业务场景

从大数据技术的使用方式上来看,这些技术一方面可以按照结构化与非结构化数据类型划分,另一方面也可以按照业务类型,即统计分析与联机操作两种类型(图1)。

图1 大数据业务类型

Hadoop的设计思路是解决超大规模数据场景下的统计分析问题,而分布式数据库则根据细分领域不同,适用于结构化数据的统计分析,以及海量数据的联机操作。

Hadoop和分布式数据库最大的差异在于控制数据的颗粒细度不同。Hadoop倾向于对整体数据的操作,例如对全量数据的统计分析;而分布式数据库强调精准控制到数据行,譬如对于某一条记录的查询更改操作。由此可见,Hadoop的业务场景非常适合低并发、大吞吐量、离线为主的数据分析,而分布式数据库适合高并发、在线实时的数据操作。这些差异性在非结构化数据的处理中也非常显著。

三、行业发展趋势

不论是Hadoop还是分布式数据库,技术体系上两者都已经向着计算存储层分离的方式演进。对于Hadoop来说这一趋势非常明显,HDFS存储与YARN调度计算的分离,使得计算与存储均可以按需横向扩展。而分布式数据库近年来也在遵循类似的趋势,很多数据库已经将底层存储与上层的SQL引擎进行剥离,例如直接使用SparkSQL作为统计分析引擎、同时使用PostgreSQL作为交易处理引擎,这是业界多种分布式数据库使用的技术路线。

图2 分布式数据库/Hadoop体系结构

从Gartner在2016年最新的数据库报告中可以看到,国际业界对新型数据库的定义有了新的划分。传统的XML数据库、OO数据库、与pre-RDBMS正在消亡;新兴领域文档类数据库、图数据库、Table-Style数据库(类似Cassandra这类有着表结构定义,但是又不存在表之间关系定义的数据库叫做Table-Style数据库)与Multi-Model数据库正在扩大自身影响;传统关系型数据库、列存储数据库、内存分析型数据库(以SAP HANA为代表的内存分析型数据库,以PC服务器配置大量内存为硬件基础,将海量数据缓存在内存中换取极高的访问效率,做到对大量数据的实时交互式分析。这类业务也称作HTAP场景)正在考虑转型。

可以看到,从技术完整性与成熟度来看,Hadoop确实还处于相对早期的形态。直到今天,一些SQL-on-Hadoop的方案还处于1.x甚至Beta版,在很多企业应用中需要大量的手工调优才能够勉强运行。同时,Hadoop的主要应用场景一直以来面向批处理分析型业务,传统数据库在线联机处理部分不是其主要的发展方向。同时Hadoop技术由于开源生态体系过于庞大,同时参与改造的厂商太多,使得用户很难完全熟悉整个体系,这一方面大大增加了开发的复杂度,提升了用户使用的难度,另一方面则是各个厂商之间维护不同版本,使得产品的发展方向可能与开源版本差别逐渐加大。

另一方面,分布式数据库领域经历了几十年的磨练,传统RDBMS的MPP技术早已经炉火纯青,在分类众多的分布式数据库中,其主要发展方向基本可以分为“分布式联机数据库”与“分布式分析型数据库”两种。例如,以结构化数据和Multi-Model数据库对结构化与半结构化数据的高并发联机处理,和列存储、Table-Style、加内存分析型数据库的结构化数据批处理分析,是这两个方向最常见的技术实现手段。同时,新一代数据库在经历了5-10年的发展后,已经开始进入到一个与传统技术、其他技术互相融合的时代。

国内的巨杉数据库SequoiaDB作为分布式数据库,在Multi-Model多模操作型数据库基础上,已经开始全面支持分布式OLTP和分布式对象存储。

对比Hadoop与分布式数据库可以看出,Hadoop的产品发展方向定位,与分布式数据库中列存储数据库相当重叠。例如,Pivotal Greenplum、IBM DB2 BLU、以及国内的南大通用GBase 8a,都与Hadoop的定位有着明显的重合。而在高并发联机交易场景,在Hadoop中除了HBase能够勉强沾边以外,分布式数据库则占据绝对的优势。

图3 分布式数据库与Hadoop适用场景象限

目前,从Hadoop行业的发展来看,Cloudera、Hortonworks等厂商已经不再宣称自己是Hadoop分销商,而是将其定位改变为数据科学与机器学习服务商。因此,从商业模式上看以Hadoop分销的商业模式基本已经宣告结束,用户已经体验到维护整个Hadoop平台的困难而不愿被强迫购买整个平台。大量用户更愿意把原来Hadoop的部件拆开灵活使用,为使用场景和结果买单,而非平台本身买单。

另外一个细分市场——非结构化小文件存储,一直以来都是对象存储、块存储,与分布式文件系统的主战场。如今,一些新一代数据库也开始进入该领域,可以预见在未来的几年中,小型非结构化文件存储也可能成为具备多模数据处理能力的分布式数据库的战场之一。

四、应用场景

不同应用场景应该使用不同的技术,没有任何一种技术可以适用于全部业务场景。

大数据时代,在像金融这种相对严谨的行业中,核心交易类业务,由于一些历史原因,很少有企业敢于立刻使用新技术替换主核心系统。但是在其他的系统中,分布式数据库既有做到对传统Oracle、IBM数据库进行替换、“瘦身”,同时在大数据应用中,分布式数据库地位也不断上升。

数据仓库延展实际上就是对传统数仓模型的一个补充。一直以来,数据仓库的建设都是遵从着从顶向下的原则,也就是先建立数据模型,再根据数据模型构建表结构与SQL,之后进行ETL和数据清洗,最后得到相应的报表。而大数据与新兴的机器学习,带给人们另一种从底向上的分析思路:首先建立分析型数据湖,将需要分析的数据均纳入湖中进行脱敏和标准化,之后利用机器学习、深度挖掘等分布式计算技术,在这些海量的数据中寻找规律。这种思路与传统数仓思路的最大不同,在于以历史数据展现出的事实为基础构建分析模型,而非与假设出的数据模型为基础进行构建。数据仓库延展,是Hadoop与分布式列存储的主打场景。

对于在线和实时数据操作,分布式数据库则是另一个主要的技术类型。比如,分布式数据库用于ODS就是其中一个典型的应用案例。在规模相对较大的银行中,传统ODS一般仅仅保留一小段时间的历史数据作为数据加工的临时存放区,而更早期的历史数据要么被归档入带库,要么被加工清洗后进入数仓。但在大数据的场景中,很多业务开始对历史数据的在线交互式访问提出明确的更高需求。例如,前台柜面是否需要提供给用户对全历史周期的回单查询功能;银行内部运维团队能否对全行业务的历史进行在线查询访问,以应对司法查询的需求,等等。这些类型的应用场景存在并发量高、索引维度多、查询延迟低等特性,使用Hadoop的HBase存在众多不便,正是分布式联机数据库的主要应用场景。

除了存放历史数据以外,ODS延展的另一大方向就是作为数据集市,存放从Hadoop中分析和挖掘的结果,供外部应用调用查询。例如,手机银行根据每个用户画像的标签结果与当前行为提供实时产品推荐,就是将分析结果与实时行为数据相结合的场景。这类应用可以进一步扩展到事中风控等更核心的业务场景中去。

因此,在大数据时代中,Hadoop与分布式数据库在金融行业的架构中应当相辅相成,互相弥补各自的不足。Hadoop与分布式分析型数据库在结构化数据批处理分析中都可以很好地满足需求;Hadoop对于非结构化数据分析有着数据库无法比拟的优势;而分布式联机数据库则在高并发在线业务场景中能够更灵活地管理和使用数据。

譬如说,近几年来很多银行在做“用户画像”业务,希望通过用户的历史交易行为给每个用户打标签,并在柜面、网银、手机银行等多个渠道有针对性地推荐理财产品。当使用大数据技术实现该场景时,一个比较简单常见的做法是:

(1)将用户的历史行为批量写入Hadoop;

(2)在Hadoop中使用机器学习对用户行为分类建模;

(3)在Hadoop中定期批量扫描用户历史行为,根据模型对用户打标签;

(4)将用户标签结果写入分布式数据库;

(5)各渠道业务通过中间件连接数据库,查询用户标签进行产品推荐。

五、展望未来

对于大数据技术未来的发展,还是会回归用户的真正需求,Hadoop/Spark将会继续在数据分析领域独占鳌头,而在实时联机交互领域,分布式数据库则会成为另一股重要技术力量。

在银行中,对于新技术的产品选型不能单从当前业务场景的需求出发,更要考虑到该产品未来3-5年的发展道路和方向,是否能够不断迭代满足企业未来的需求。因此,用户仅了解每一种技术的现状是远远不够的,只有当认识到一种技术的发展策略以及其架构局限性后,才能够预见和洞察未来。

架构局限性并不等于功能的缺失。很多新型技术在开始时都无法提供像Oracle一样完备的企业级功能,但并不是说用户必须要等到全部功能完备后才开始考虑学习和使用。用户在评估一种新产品和技术时,产品的功能点需要满足几个必备的基础功能,而一些高级功能则不需要立刻具备。作为IT决策层,最重要的是评估该产品和技术的架构局限性,即是否在可预见的未来,基于该架构能够实现和满足银行一段时间后的业务需求。

Hadoop的架构基础核心是HDFS与YARN,任何请求首先被发送至YARN进行调度。而YARN则是根据NameNode计算出一个任务需要访问的数据块所在服务器生成一系列任务,并发送给相应的服务器进行执行。除非从底层重写整个调度算法,该机制冗长的流程制约着Hadoop向联机业务继续发展。

数据库的架构核心是数据存储结构。只有存在可定义的存储结构,数据库才能够提供对数据字段的检索、查询、更新等操作。该机制一方面提供了对结构化与半结构化数据有效的管理能力,另一方面却制约着用户对于非结构化数据的处理能力。短期来看,分布式数据库在非结构化数据管理上,主要还停留在小文件的存储和检索领域。对于文件内部信息的查询能力,可以使用全文检索索引实现,但是对于二进制非文本类的无结构数据,分布式数据库还不存在较好的方式能够对其中的信息做到全维度自由检索和查询。

从分布式数据库的角度来看,笔者认为,在未来的3-5年中,新一代数据库将会渐渐向Multi-Model数据库演进,同时提供SQL和API两种数据访问模式。 例如,巨杉数据库SequoiaDB在支持SQL和API访问结构化和半结构化存储的同时,也支持其他类型的数据存储格式,包括非结构化的对象存储。同时,分布式关系型数据库会进一步加强融合,提供多引擎存储方案(GBase 8a/8t),甚至有的产品已经开始支持JSON等半结构化数据(PostgreSQL)。

总而言之,在大数据技术下,分布式数据库与Hadoop两者相辅相成。Hadoop适合非结构化批处理分析场景;分布式数据库则更适合高并发在线业务场景。

我的博客:CODE大全www.codedq.net业余草www.xttblog.com爱分享www.ndislwf.comifxvn.com

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,905评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,140评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,791评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,483评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,476评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,516评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,905评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,560评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,778评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,557评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,635评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,338评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,925评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,898评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,142评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,818评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,347评论 2 342

推荐阅读更多精彩内容