具备这些特性的系统正在NewSQL、NoSQL以及Hadoop业界当中不断涌现，但不同的系统方案也拥有各自的权衡考量--这往往与开发者的初始假设关系密切。
    就在大约十年之前，我们还几乎无法想象利用商用硬件对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通讯基础设施相配套的处理引擎。
    无论企业用户的实际需求如何，这些工具都表现出了帮助我们以更快速度了解更多数据信息的能力，而且往往能够全面替代更为孱弱或者其它类型的系统方案。