大数据技术下 分布式数据库何去何从？

转自：安华信达的文章
链接地址：http://www.sohu.com/a/133784835_481676

一、大数据技术的发展

大数据技术从诞生到现在，已历经了十几个年头，市场上也早已有公司或机构对广大金融从业者灌输大数据未来的美好前景与趋势。随着对大数据理念与技术了解的不断深入，人们开始寻找场景落地，以期让大数据在自身的企业中落地并开花结果。

从数据的应用角度来看，大数据的应用方向主要集中在两个领域。第一是大数据分析相关，也就是传统数据仓库的延展，将更多的数据挖掘、更复杂的分析算法通过大数据技术来实现;第二是在线数据访问，也就是传统ODS的延展，将更长期的数据做到在线化、将所有大量相对静态的数据(参数)从昂贵的存储设备下放到大数据平台，提供给更多的渠道进行并发实时访问。

大数据技术发展到今天，全新的大数据实现技术大致可以分为3类：Hadoop技术、分析型分布式数据库和联机交互型分布式数据库。

在人们刚开始接触大数据技术时，第一个想到的场景大多是海量数据分析。但是，随着人们对大数据技术更加深入的了解，除了单纯的批处理分析之外，海量数据交互式实时应用的场景同样也成为技术人员关注的一个重点。因此，如果从技术路线的角度进行划分，上述所说的3类实现技术中，Hadoop技术适用于结构化与非结构化的数据批处理分析;分析型分布式数据库适用于结构化数据批处理分析与OLAP;而联机交互型分布式数据库则适用于交互式实时业务场景。

二、技术体系对比

在上述大数据的3种技术实现中，Hadoop技术貌似自成一套体系。Hadoop①与分布式数据库的设计思路为什么有所差异，其定位和使用场景应该如何与分布式数据库技术进行区分，这需要从两种技术的起源与发展来进行分析。

(一)Hadoop

本质上，Hadoop技术只能算是以分布式文件系统 (HDFS)+分布式调度器(YARN)作为基础的分布式计算框架，而不是数据库。

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

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

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

(二)分布式数据库

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

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

但是，传统分布式数据库最大的局限性在于对非结构化数据的支持。由于大部分分布式数据库都是用SQL作为标准查询语言，因此其数据的处理能力也仅局限在结构化数据，对于无法使用SQL进行解析的裸数据则完全无能为力。

分布式数据库在近几年也有着极大的转型。从早年间NoSQL的异军突起占据了互联网分布式数据库的半壁江山，到如今很多传统关系型数据库纷纷开始支持JSON格式，数据库已经从单一的关系型数据库向混合型数据库发展。

(三)业务场景

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

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

三、行业发展趋势

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

Gartner2016年最新的数据库报告中可以看到，国际业界对新型数据库的定义有了新的划分。传统的XML数据库、OO数据库与pre-RDBMS正在消亡;新兴领域的文档类数据库、图数据库、Table-Style数据库②与Multi-Model③数据库正在扩大自身影响;而传统关系型数据库、列存储数据库、内存分析型数据库④也在考虑转型。

可以看到，从技术完整性与成熟度来看，Hadoop确实还处于相对早期的形态。直到今天，一些SQL-on-Hadoop的方案还处于1.x甚至Beta版，在很多企业应用中需要大量的手工调优才能够勉强运行。同时，Hadoop的主要应用场景一直以来面向批处理分析型业务，传统数据库在线联机处理部分不是其主要的发展方向。

分布式数据库领域经历了几十年的磨练，传统RDBMS的MPP技术早已经炉火纯青。不像Hadoop的发展方向完全固定为批处理作业，在分类众多的分布式数据库中，其主要发展方向基本可以分为“分布式联机数据库”与“分布式分析型数据库”两种。例如，以文档和Multi-Model数据库对结构化与半结构化数据的高并发进行联机处理，以及列存储、Table-Style、加内存分析型数据库的结构化数据批处理分析，是这两个方向最常见的技术实现手段。

同时，新型NoSQL数据库在经历了5-10年的发展后，已经开始进入到与传统技术、其他技术互相融合的时代。例如，全球最知名的文档数据库与Multi-Model数据库应属MongoDB，在支持JSON存储的同时也开始支持内置图计算功能。国内的巨杉数据库SequoiaDB也是以文档数据库为基础，开始支持SQL与对象存储。

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

在另外的一个细分市场，即非结构化小文件存储上，一直以来该领域都是对象存储、块存储、与分布式文件系统的主战场。如今，非关系型数据库也开始进入该领域，可以预见，在未来的几年中，小型非结构化文件存储也可能成为分布式数据库的战场之一。

四、应用场景

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

大数据时代，在像金融这种传统保守的行业中，对于交易类业务很少有企业敢于使用新技术替换主核心系统。一些企业开始尝试在部分非核心交易的业务中使用MySQL，PostgreSQL等开源关系型数据库。相比起过往任何业务都要使用Oracle或IBM的数据库来说，这已经是国内金融行业在去IOE道路上的一大进步。

Hadoop与新型分布式数据库在金融行业中的主要战场则集中在非交易型业务上，也就是数据仓库的延展，以及ODS的延展两大方向。

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

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

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

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

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

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

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

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

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

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

五、展望未来

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

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

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

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

从分布式数据库的角度来看，笔者认为，在未来3-5年中，NoSQL数据库将渐渐向Multi-Model数据库演进，在提供直接API访问数据的同时，提供SQL结构化数据的访问方式。例如，业界知名的MongoDB与国内的巨杉数据库SequoiaDB都在支持JSON存储的同时，支持SQL甚至其他类型的数据存储格式⑤。同时，分布式关系型数据库会进一步加强融合，提供多引擎存储方案(GBase 8a/8t)，甚至开始支持JSON等半结构化数据(PostgreSQL)。

总而言之，在大数据技术下，分布式数据库与Hadoop两者相辅相成。Hadoop适合非结构化批处理分析场景;分布式分析型数据库与SQL-on-Hadoop方案在结构化批处理分析场景中有所重叠;而分布式联机数据库则更适合高并发在线业务场景。

① 尽管如今Spark异军突起，MapReduce后继无力，但多数厂商或机构渐渐开始将Spark与Hadoop进行融合。本文中，所有提到Hadoop的部分均指Hadoop与Spark两种技术。

② 类似Cassandra这类有着表结构定义，但是又不存在表之间关系定义的数据库叫做Table-Style数据库。

③ 类似MongoDB这类在一个数据库中支持多种存储格式，例如JSON、图、表，并提供不同类型使用接口的数据库。

④ 以SAP HANA为代表的内存分析型数据库，以PC服务器配置大量内存为硬件基础，将海量数据缓存在内存中换取极高的访问效率，做到对大量数据的实时交互式分析。这类业务也称作HTAP场景。

⑤ SequoiaDB支持小文件对象存储;MongoDB支持内置图计算机制。