大数据之所以可以坐拥一个“大”字，首要依托连绵不断且态势安稳的输入数据流。在大容量环境之下，数据的堆集速度往往十分惊人，不过其剖析与存储依然困扰着不少用户。

VoltDB公司软件架构师John Hugg以为，相关于传统为后续剖析供给数据的简略存储机制，或许现在咱们现已步入了前史的新阶段——在这里，体系彻底有才能使用Apache Kafka等东西在持续坚持高速数据输入的一起完结剖析。

-- Paul Venezia

就在大约十年之前，咱们还简直无法幻想使用商用硬件对PB等级的前史数据加以剖析。但是时至今日，由不计其数节点构成的Hadoop集群完结这项使命现已不是什么难事。Hadoop等开源技能的呈现协助咱们拓宽了思路，得以有用处理PB乃至更高等级数据在商用及虚拟化硬件上的处理工作，并让这种才能以低价的本钱服务世界各地的开发人员。整体来讲，大数据业界现已正式成型。

现在所谓快数据概念则引发了相似的一轮改造浪潮。首要，咱们先为快数据下一个界说。大数据通常是由出产速度极高的数据所创立，其间包含点击流数据、金融交易数据、日志聚合数据或许传感器数据等。这些事情每一秒钟往往会产生数千乃至数万次。无怪乎人们会将这种数据类型称为“消防水龙”。

当咱们在大数据范畴评论消防水龙这个论题时，计量单位并非传统的GB、TB以及PB等为数据仓库机制所了解的概念。咱们更倾向于使用时刻单位来进行计量：每秒MB数量、每小时GB数量或许每天TB数量。在评论中采纳的这种速率与容量之间的差异，正好代表着大数据与数据仓库之间的中心差异地点。大数据并不仅仅是“大”：它一起也要“快”。

一旦消防水龙中新鲜且传输速度极高的数据被倾倒进HDFS、剖析RDBMS乃至是平面文件傍边，大数据的优势就将消失殆尽——这是由于其“在事情产生的一起当即”履行或许警示的才能现已不复存在。消防水龙中喷涌而出的是活动数据、即时情况或许正在进行傍边的数据。与之相反，数据仓库则是一种审视前史数据以了解曩昔情况然后猜测未来的手法。

在数据输入的一起进行处理一向被视为不或许完结的使命——或许至少需求极高的施行本钱且有些不实在际，特别是在商用硬件之上。正如大数据中蕴藏的价值相同，快数据的价值现已跟着音讯查询与流体系的完结得以解锁，而在这方面***代表性的处理计划无疑是Kafka与Storm。除此之外，开源NoSQL与NewSQL产品也为这类诉求供给了坚实的数据库计划根底。

在快数据中捕捉价值

捕捉输入数据价值的***方法就是在信息抵达时当即作出反应及操作。假如咱们以批量方法处理输入数据，那就意味着各位现已失去了其时效性、然后丢掉了快数据的中心价值。

为了处理每秒呈现的数万乃至数百万事情的相关数据，咱们需求两类技能作为条件：首要，一套可以在事情抵达的一起当即进行交给的流体系;第二，一套可以在所有条目抵达的一起当即进行处理的数据存储计划。

快数据的交给

在曩昔几年傍边，有两套流体系计划获得了商场的广泛认同：Apache Storm与Apache Kafka。作为开始由Twitter工程技能团队开宣布的项目，Storm可以十分可靠地处理每秒音讯量高达***其他数据流。而作为由LinkedIn工程技能团队开宣布的项目，Kafka则是一套具有极高数据吞吐才能的散布式音讯查询体系。这两大流体系计划处理了快数据处理使命的条件性难题。不过相比之下，Kafka的作用显得更为共同。

Kafka的规划意图在于完结音讯查询并打破现有技能在此类使命中的限制。这相似于一种立足于查询之上而又具有无限可扩展性的散布式布置计划，支撑多租户且持久性极强。企业用户可以经过布置Kafka集群来满意本身的悉数音讯查询需求。不过作为项目中心，Kafka只能交给音讯——也就是说，它不支撑任何方法的处理或许查询操作。

快数据的处理

音讯仅仅处理计划的组成部分之一。传统联系型数据库往往在功用方面存在限制。其间一些可以以极高速率完结数据存储，但在接收到数据后的验证、填充以及履行方面却总会栽跟头。NoSQL体系现已具有集群化才能与超卓的功用体现，但却需求对传统SQL体系所能供给的处理才能及安全性作出献身。关于根本的消防水龙处理使命，NoSQL计划或许现已足以满意咱们的业务需求。但是假如咱们在事情中履行的是杂乱的查询以及业务逻辑操作，那么只要内存内NewSQL处理计划可以实在处理功用体现与业务杂乱性这两大难题。

以Kafka为代表，不少NewSQL体系都围绕着无同享集群进行树立。相关负载被散布在各个集群节点傍边，然后带来抱负的功用体现。数据会在各个集群节点之间进行仿制，旨在保证其安全性与可用性。为了处理持续增长的负载量，咱们可以以透明化方法将节点添加到集群傍边。各个节点可被移除（或许呈现毛病），集群中的其它部分仍能持续正常完结功用。数据库与音讯查询机制在规划上都成功避免了单点毛病的问题。这些功用也正是规模化体系规划计划中的典型特征。

除此之外，Kafka与一部分NewSQL体系有才能使用集群化与动态拓朴机制完结规模化，一起又不用献身强壮的数据保证作用。Kafka供给音讯序列保证，一起一部分内存内处理引擎还可以完结序列化一致性与ACID语义。这些体系都使用集群辨认客户端来交给更多功用或许简化装备。***，二者也都经过来自不同设备的磁盘——而非RAID或许其它逻辑存储计划——带来冗余耐久特性。

大数据处理东西箱

在体系中进行大数据消防水龙处理时，咱们需求寻求哪些必要的支撑机制？

• 寻觅一套经过本地无同享集群化机制完结冗余与可扩展性优势的体系计划。
• 寻觅一套依托内存内存储与处理机制以完结各节点高数据吞吐才能的体系计划。
• 寻觅一套可以在数据抵达的一起进行处理的体系。这套体系能否履行情况逻辑？它又能否查询GB乃至更高等级的现有情况，然后为决议计划供给信息支撑？
• 寻求一套可以将不同操作阻隔开来，并为操作供给有力保证的体系计划。这样一来，用户就可以编写更为简略的代码并将留意力会集在业务难题上——而非忙于处理并发问题或许数据不合。需求留意，某些体系的确可以供给强壮的一致性作用，但却会给功用形成严重影响。

具有这些特性的体系正在NewSQL、NoSQL以及Hadoop业界傍边不断呈现，但不同的体系计划也具有各自的权衡考量——这往往与开发者的初始假定联系密切。关于那些期望以实时方法处理快数据的企业来说，这些东西可以有用处理快速了解数据内容时面对的杂乱性难题。

Kafka带来了一种安全及具有高可用性的处理方法，可以有用完结数据在很多出产者与顾客之间的移动，一起也为管理者供给杰出的功用与稳健性。内存内数据库则可以供给一套完好的联系型引擎，其具有强壮的业务型逻辑、计数与聚合才能，并具有足以满意任何负载的超卓可扩展性。与联系型数据库不同，这类体系应当被作为与Kafka通讯根底设施相配套的处理引擎。

不管企业用户的实践需求怎么，这些东西都体现出了协助咱们以更快速度了解更多数据信息的才能，并且往往可以全面代替更为懦弱或许其它类型的体系计划。

英文：http://www.infoworld.com/t/big-data/fast-data-the-next-step-after-big-data-244102