在大容量环境下，数据积累的速度往往是惊人的，但其分析和存储仍然困扰着很多用户。VoltDB的软件架构师JohnHugg认为，相对于传统的简单存储机制，为后续分析提供数据，我们现在可能已经进入了一个新的历史阶段——在这里，系统完全有能力使用ApacheKafka等工具来继续保持与高速数据输入的同步分析。--PaulVenezia大约十年前，我们几乎无法想象使用商用硬件分析PB级的历史数据。然而在今天，由数万个节点组成的Hadoop集群完成这个任务并不困难。Hadoop等开源技术的出现，帮助我们拓展了思路，有效处理商用和虚拟化硬件上PB级甚至更高级别数据的处理，并让这种能力以低成本服务于全球开发者。总体来说，大数据产业已经正式形成。今天所谓的快速数据概念已经引发了类似的创新浪潮。首先，让我们先定义快速数据。大数据通常由以非常高的速率生成的数据创建，包括点击流数据、金融交易数据、日志聚合或传感器数据。这些事件往往每秒发生数千次甚至数万次。难怪人们将这种数据类型称为“消防水带”。当我们讨论大数据领域的消防水带话题时，计量单位并不是我们熟悉的数据仓库机制的GB、TB、PB等传统概念。我们更喜欢使用时间单位进行测量：每秒MB、每小时GB或每天TB。讨论中提到的速度和容量之间的区别恰恰代表了大数据和数据仓库之间的核心区别。大数据不仅“大”，而且“快”。一旦来自消防水带的新鲜且速度极快的数据被转储到HDFS、分析型RDBMS甚至平面文件中，大数据的优势将完全消失——这是因为它的“瞬时事件”执行或预警能力消失了。流出的是活动数据、即时状态或正在进行的数据。相比之下，数据仓库是一种查看历史数据以了解过去情况和预测未来的方法。长期以来，处理传入的数据一直被视为一项不可能完成的任务——或者至少是非常昂贵且实施起来有些不切实际，尤其是在商用硬件上。就像大数据中隐藏的价值一样，快数据的价值随着消息查询和流式系统的实现而被释放，而这方面最具代表性的解决方案无疑是Kafka和Storm。此外，开源的NoSQL和NewSQL产品也为此类需求提供了坚实的数据库解决方案基础。从快速数据中获取价值在传入数据中获取价值的最佳方式是在信息到达时做出反应并采取行动。如果你批量处理输入数据，就意味着你失去了它的时效性，从而失去了快数据的核心价值。为了每秒处理数万甚至数百万的事件相关数据，我们需要两类技术作为前提：第一，事件到达后可以立即传递的流式系统；一种数据存储方案，在项目到达时立即对其进行处理。快速数据交付在过去的几年中，有两种流系统解决方案得到了市场的广泛认可：ApacheStorm和ApacheKafka。作为最初由Twitter的工程技术团队开发的项目，Storm可以非常可靠地处理每秒高达***级别的消息数据流。Kafka作为LinkedIn工程团队开发的项目，是一个具有极高数据吞吐能力的分布式消息查询系统。这两个系统解决方案解决了快速数据处理任务的前提问题。但相比之下，卡夫卡的作用更为独特。Kafka旨在实现消息查询并打破现有技术对此类任务的限制。这类似于一种基于查询的分布式部署方案，具有无限的可扩展性，支持多租户，并且极其耐用。企业用户可以通过部署Kafka集群来满足他们所有的消息查询需求。但在项目的核心，Kafka只能传递消息——也就是说，它不支持任何形式的处理或查询。为快速数据处理消息只是解决方案的一部分。传统的关系数据库通常在性能方面存在局限性。它们中的一些可以以非常高的速率存储数据，但在接收到数据后验证、填充和执行数据时总是出错。NoSQL系统已经具备了集群能力和出色的性能，但需要牺牲传统SQL系统所能提供的处理能力和安全性。对于基本的消防水带处理任务，NoSQL解决方案可能足以满足您的业务需求。但是，如果在事件中执行复杂的查询和业务逻辑操作，那么只有内存中的NewSQL方案才能有效解决性能和事务复杂度两大问题。以Kafka为代表，许多NewSQL系统都是围绕shared-nothing集群构建的。相关负载分布在各个集群节点之间，从而获得理想的性能。为了安全性和可用性，数据在集群节点之间进行复制。为了处理不断增长的负载，我们可以透明地向集群添加节点。可以删除（或失败）单个节点，而集群的其余部分继续正常运行。数据库和消息查询机制的设计都成功地避免了单点故障的问题。这些功能也是大型系统设计方案中的典型特征。此外，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
