查看原文
其他

大数据基础技术的未来演进趋势预测

2016-11-01 Coda6 大数据开放实验室

进入本世纪以来,IT技术的革命性发展使数据产生的来源和渠道不断扩增,带动了数据在数量和维度上的爆炸性增长。近年间催生出了许多大数据产品并应用在各行各业,从传统关系型数据库到MPP再到Hadoop,数据管理产品的存储力不断扩展,分析能力不断增强,功能覆盖不断全面。

但是它依然面临着各种挑战和需求:

  • 在保证有效应对疯狂增长的数据量的前提下,使架构选型简单化;

  • 提供更快的服务更迅速的查询更优异的性能;

  • 提供市场所需的实时查询分析;

  • 在分布式系统中为应用服务实现自动化的资源管理分配;

为了应对如上的挑战,大数据技术的发展究竟会朝着哪些方向前进?以下为我们星环科技的一些预测观点。

混合架构将消失

SQL on Hadoop将取代混合架构广泛应用于生产。

在Hadoop发展到如今的水平之前,工业界在做大数据基础架构选型时,一般采用这样的混合架构策略:数据规模在TB级时选择MPP架构的关系型数据库,如果数据规模上升到PB级则选择Hadoop。而且过去我们选择MPP,是因为它对某些业务有一些自身优势,例如支持完整的SQL标准,有着全面的工具支持,生态链发展成熟等。然而随着SQL on Hadoop的演进,MPP在这些方面的特点将不再具有竞争优势。

SQL on Hadoop引擎在近五年间得到了快速的发展,各类产品不断出现,性能和功能不断强大。星环科技推出的自研SQL解析引擎Transwarp Inceptor,目前已支持SQL 2003标准以及PL/SQL,同期在国际市场上诞生的主流引擎还有Cloudera Impala、Hortonworks Tex/Stinger、Databricks SparkSQL、MapR Drill。这些产品对SQL的支持度都在日益提升,许多已接近或超越MPP,很大程度上降低了技术入门门槛,方便业务从传统数据库上迁移。同时SQL on Hadoop的产业链也在不断完善,不仅得到一些传统BI/ETL工具的支持,另外还带动了一批建立于Hadoop的分析工具的发展。

除此之外,MPP在生产应用中暴露出了一些自身弱点:需要进行数据重分布、较低的容错性、有限的扩展性。这些主要弱点已被SQL on Hadoop的优势克服,首先Hadoop不需要数据重分布,它提供了对数据分布不均的优化处理方法,使之避免受到数据倾斜的影响,从而消除数据重分布的性能开销。其次,Map/Reduce和Spark都具备容错调度机制,使基于二者的计算引擎都具有较高的容错能力。最后,Hadoop的横向扩展能力远强于MPP,例如Spark可扩展至~1000节点,而MPP至多仅scale out到~100。

日渐强大的SQL on Hadoop将逐渐覆盖MPP的能力范围,原来依靠MPP的业务和数据级今后都可以交给SQL on Hadoop。而且近年来一些MPP向SQL on Hadoop靠近的趋势,更凸显出下图所示发展方向的可预见性。


图1 混合架构将被SQL on Hadoop取代

固态盘将替代内存作为缓存

固态硬盘将取代内存作为SQL计算引擎中的缓存。

SDD在过去几年的发展有着非常大的突破,各种厂商不断推出容量愈来愈大,且性能表现越来越好,价格越来越低廉的SSD产品,使其具有更加广阔的应用前景。同传统机械硬盘相比,SSD吞吐性和延迟已经是其10倍以上。虽然和内存相比,SSD性能依然差了3~5倍,但是价格也便宜将近10倍。下表给出了常见内存(DDR3-1333)、SSD(Intel® SSD DC P3700、SanDisk UltraDIMM)、机械硬盘(10,000 rpm SATA drives)的读写性能对比。使用内存固然好但是部署开销对企业有较大的负担,所以大数据技术可以好好利用固态硬盘在价格和方面两方面的发展优势,有效应用在系统中。


图2 常见内存、SSD、机械硬盘的性能对比

随着SSD容量的不断扩增,SSD作为缓存的可靠性也在不断提升,因此将SSD作为缓存渐渐形成了一种趋势。我们将缓存在不同存储介质上的table作为目标对象,测试TPC-DS语句的运行速度,结果如下图所示。


图3 TPC-DS测试集在内存、SSD、机械硬盘中的性能对比

就选用的测试集上看,我们发现内存比SSD的平均速度只快了9.6%,最高不到40%,大部分在10%以下,说明SSD和内存的差距不大,而且二者速度都比硬盘高出了几倍甚至数十倍。在SSD价格的吸引下,我们相信大部分企业应该不会拒绝用SSD替代内存作为缓存吧(土豪企业可无视)。

当然我们也可以将SSD用作存储,其中HDFS 2.6已经支持Storage Tier让应用程序选择磁盘或者SSD为存储层。但是直接将SSD部署在系统中是远远不够的,必须保证它在系统中能发挥长处,物尽其用。SSD在随机读写速率方面具有相当显著的优势,所以如果主要用它执行按序读写操作就是一种失败的设计,甚至会使其退化至近普通硬盘。所以,当选择SSD为存储介质时,必须针对SSD开发出能利用高性能随机读写特性的存储格式。

我们看到从2015年开始,大数据技术确实也是朝着这个方向发展的,其中有两方面演化趋势:一方面,现有的内存数据库开始为SSD进行优化;另一方面,基于磁盘的Hadoop借鉴着内存数据库的经验,开始为SSD设计新的文件格式。作为后者演进方向的代表,星环自主研发了分布式存储引擎Holodesk,设计并采用了列式存储结构,充分利用SSD的随机读写性能。测试发现,采用普通文本格式时,PCI-e SSD和硬盘相比带来的性能提升仅有1.5倍;但是采用改用内存和SSD设计的Holodesk列式存储时,比SSD上的文本格式提升了6倍,是硬盘上文本格式的8倍以上。

因此,在将SSD部署在大数据架构的趋势下,开发人员必须能够为SSD设计出专门的存储结构,充分利用随机读写性能,否则只是浪费SSD的先天优势。

实时大数据技术得到关注

大数据实时分析是响应大众需求顺应时代发展的一门技术。

人们对于查询速度的要求一直没有停止,对于5年前花40分钟得到结果就已经觉得惊人的分析业务,可能现在花费1分钟执行都认为速度不够。各行各业希望大数据技术越来越能够扮演一种“智人”的角色。我们问,它思考然后回答,就像人与人之间的对话。所以批处理对历史数据的分析已经远不能满足现实需求,亟求各个厂商对大数据提供实时分析的功能或解决方案。

为了应对实时性查询的需求和挑战,Storm的鼻祖Nathan Marz提出了一种基于Storm设计的实时分析架构——Lambda。Lambda将批处理(Batch Layer)和流计算(Speed Layer)分别放在两套系统中实现,最后由统一服务层(Serving Layer)负责整合两套系统结果并交互给用户。通常Lambda的实现方案是,数据进入分布式实时队列Kafka,Hadoop作为Batch Layer执行实时性需求不高的历史数据分析生成历史视图,Storm作为Speed Layer负责处理实时数据生成实时视图,二者结果的同一归宿是Druid,由它向用户提供交互式实时查询。结构如下图所示:


图4 Lambda架构图

但是Lambda架构有着自身难以避免的弊端,首先做实时查询时只能进行预先设定的分析,不能做Ad-Hoc分析;其次,用户需要维护跑在两套系统中的两套代码,不方便代码调试和参数调优;最后从开发、测试和运维的角度来看,在架构中部署两套系统的方式也是不利的。为此,前LinkedIn大神Jay Kreps设计了Kappa架构解决了Lambda中存在的问题。Kappa方案的诞生归功于Spark的发展,由于Spark对于批处理和流计算双方面的支持,使两套系统的合并成为可能。Kappa中实时计算和批处理可使用同一份代码,极大的方便了代码优化、模型验证工作。下图是实现Kappa的一种常用方案,有效利用了一套系统来进行两种时效性分析,但是其中存在一个问题,Kafka最多只能存储近30天的历史数据,对于数据规模较大的情况此结构将力不从心。

图5 常用Kappa架构图

星环选择了Kappa架构来构建实时系统,并对其做了一些改进。首先我们使用一款对SQL和PL/SQL支持能力很高的产品StreamSQL作为中间的批&流处理系统,并在原有设计结构的基础上增加了Holodesk存储引擎,用来存放经过行列转换过的StreamSQL的结果,Holodesk可以将之保留任意长时间,甚至永久保留,并可供Inceptor来日做分析。


6 星环科技优化后的Kappa架构

实时分析的实现是大数据分析系统向“拟人化”迈进的重要一步,随着实时分析扮演的角色越来越多,应用范围越来越广,相信今后会有很多的企业将Kappa、Lambda等批处理流计算结合的架构用于生产实践,依靠它们提供高效可靠的决策意见。

云计算与大数据的融合

云计算和大数据联手构建云上大数据。

规模巨大的数据、数量众多的用户,迫使越来越多的服务必须由处理节点分布在不同机器上的Data Center提供。想想在笔记本电脑上执行程序的时候,我们需要为每个程序指定执行CPU,指定可用的内存或缓存,幸好有操作系统在底层帮助进行这些复杂的资源管理。同样,Data Center在提供服务时,也会涉及到资源分配与管理问题。以前我们基本依靠人力实现,但是人为从事这项工作的速度很缓慢且不可靠,也因而往往成为快速开发与快速应用部署的瓶颈。因此,为Data Center开发出高效可靠的操作系统——Data Center Operation System(Datacenter OS)必定是未来趋势。

和传统操作系统类似,Datacenter OS从上至下应有三层结构:上层的平台服务层,中间层的操作系统内置服务,底层的操作系统内核。结构示意图如下所示:

图7 Datacenter OS的结构示意

  • 平台层服务负责按照需求动态创建分布式服务(如HDFS,HBase等),动态的部署传统应用。

  • 操作系统内置服务提供Datacenter OS 的必备功能,例如集群扩容减配、服务发现、流量计费等。

  • 操作系统内核负责管理存储器、文件、外设和资源,方便创建部署Container或虚拟机或集群等物理资源管理。

近年来云计算的不断发展带动着Datacenter OS的逐渐成型。首先对Container概念的定义解决了在虚拟机中运行Hadoop集群的I/O瓶颈,随后出现的Docker技术简化了Container的应用部署。而Kubernetes更是方便了分布式集群应用在Container上的部署,并提供基础分布式服务。同期诞生的Mesosphere可以同时满足传统应用和大数据应用的快速部署和基础服务需求。

借助这些技术的帮助,目前涌现了很多对于Datacenter OS的实现方案,大概有两种流派。第一种是让Hadoop的应用可以在Mesosphere资源框架上运行。这个方案有两项弱点:首先是不具备通用性,所有的大数据和数据库的框架都需要定制和改造,无法标准化;其次在于隔离性太弱。另外一种方案是使用Kubernetes + Docker的方式,使所有应用容器化,由Kubernetes提供资源调度和多租户管理,因此更加标准化,方便统一化部署和运维。目前我们认为后者是更优方案,也是我们在Transwarp OS中采用的架构方式。

总结

本文中我们预测了大数据基础技术的四大演进趋势:混合架构将消失,SSD将广泛部署于Hadoop集群,大数据实时技术将受到重视,Datacenter OS将应运而生。我们看到这其中的许多技术都处于初级或者发展不完善的阶段,每种趋势上都有很大的发展空间,很多公司也都在朝着这些趋势迎头赶进。星环也在这些演进方面做着不懈努力与贡献,对计算引擎进行不断的迭代更新,提供功能日新月异的存储引擎,开发更好的流处理流式机器学习产品,研发并推广云上数据中心。在市场的竞争与合作过程中,今后定会有更多优秀的产品诞生在大数据产业界。

 

对此文章如有任何问题,欢迎联系我们,也欢迎各位读者通过邮件分享自己在大数据演进趋势方面的观点和想法bigdataopenlab@transwarp.io




往期原创文章

Kappa:比Lambda更好更灵活的实时处理架构

Transwarp Data Hub中的指标监控利器

深入浅出解析大数据Lambda架构

由星环大数据产品剖析基于SQL on Hadoop的数据仓库技术

自动化分布式环境检测工具——Koalas

一站式rJava自主开发的应用实现

Docker+Jenkins打造自动化测试以及部署升级环境

从PageRank算法入门Graphene

从关系型数据库到大数据,谈谈数据字典的故事

开篇:写给致力于大数据技术发展的志同道合者




大数据开放实验室由星环信息科技(上海)有限公司运营,专门致力于大数据技术的研究和传播。若转载请在文章开头明显注明“文章来源于微信订阅号——大数据开放实验室”,并保留作者和账号介绍。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存