开源Apache Cassandra、Kafka、Spark和ES何时该用，何时不该用？

然而它们并不是适合各种使用场合的正确选择。

不妨更深入地研究这每一项技术以及适合和不适合这些开源解决方案的一些使用场合。

1.Apache Cassandra

Cassandra最初由Facebook于2007年创建，利用Dynamo架构和Bigtable样式的数据模型来提供NoSQL数据存储，从而提供高可用性和高扩展性。

•何时应该使用Apache Cassandra？

对于需要最高级的始终在线可用性的使用场合而言，Cassandra是理想的选择。该数据库还特别适合服务于这类企业：预计会有大量工作负载，或希望确保其服务可以随工作负载加大而灵活增加，Cassandra提供了易于扩展的优点。Cassandra在多个数据中心之间提供可靠的数据冗余和双活操作。

•何时不应该使用？

面对数据仓库或纯粹的分析存储（甚至考虑使用可用的Spark连接件以及Tableau和Hadoop插件）时，Cassandra消耗的资源比替代技术更多。Cassandra还不适合实时分析，尤其是最终用户临时查询或自定义查询这种形式的分析，因为应用程序端实现代码的需要可能变得很复杂。此外，Cassandra无法满足大多数ACID要求。

2.Apache Kafka

Apache Kafka最开始由LinkedIn的技术团队创建，它提供了一种高可扩展性高可用性的流平台和消息总线。Kafka充当分布式日志，新到达的消息被添加到队列的头部，读取者（使用者）将根据偏移量来使用它们。

•何时应该使用Apache Kafka？

对于涉及微服务和面向服务架构的使用场合而言，Apache Kafka通常是明智的选择。 Kafka还可以充当高效的工作队列，能够协调不同的工作路径，通过监听和等待、直到工作到达来保留计算能力。该平台的流处理功能适用于异常检测、向上钻取和聚合，还适用于传递度量指标。Kafka还是一种功能强大的技术，可用于事件源、跨各种微服务的数据协调以及为分布式系统提供外部提交日志。其他合适的使用场合包括日志聚合、数据屏蔽及过滤、数据丰富和欺诈检测。

•何时不应该使用？

虽然在一些情况下可能很诱人，但切勿将Kafka用作数据库或记录源，至少在没有充分了解Kafka在这种使用场合下的局限性和属性的情况下切勿这么做。真正的数据库几乎总是更易于操作且更灵活。对于涉及整个主题的顺序处理，Kafka是同样不适合的选择。在目标是将数据包快速推送到终端源的任何使用场合下，比如实时音频和视频或其他有损数据流，企业应使用定制的解决方案而不是Kafka。

3.Apache Spark

Apache Spark是一种通用集群计算框架，适用于涉及大量数据的使用场合，它对数据进行划分，并针对划分的数据执行计算，以便worker执行所有可能的工作，直至它们需要来自其他worker的数据。这种设计为Spark提供了巨大的可扩展性和可用性，同时让它极具弹性，可应对数据丢失。

•何时应该使用Apache Spark？

Spark适用于涉及大规模分析的使用场合，尤其是数据通过多个来源到达的情况。Spark是一种强大的解决方案，适用于ETL或任何这种使用场合：需要在系统之间移动数据，无论用于从事务型数据存储持续填充数据仓库或数据湖，还是诸如数据库或系统迁移之类的一次性场景。如果企业在现有数据上构建机器学习管道、处理高延迟数据流，或执行交互式分析、临时性分析或探索性分析，会发现Spark非常适合。Spark还从合规角度提供数据屏蔽、数据过滤和大型数据集审核等功能，适合帮助企业满足合规要求。

•何时不应该使用？

对于涉及实时或低延迟处理的使用场合，Spark通常不是最佳选择。（Apache Kafka或其他技术提供出色的端到端延迟以满足这些要求，包括实时流处理）。处理小型数据集或单个数据集时，Spark通常是一种大材小用的选择。另外说到数据仓库和数据湖，最好使用高级技术代替Apache Spark，不过确实存在面向Spark的此类产品。

4.Elasticsearch

Elasticsearch提供了一种全文搜索引擎，它有广泛的功能来搜索和分析非结构化数据。该技术提供接近实时的可扩展线性搜索、强大的搜索临时替代和强大的分析功能。

•何时应该使用Elasticsearch？

Elasticsearch非常适合需要全文搜索、地理搜索、抓取和汇总公共数据、日志记录及日志分析、可视化以及少量事件数据和度量指标的使用场合。

•何时不应该使用？

Elasticsearch不应该用作拥有关系数据的数据库或记录源，也不应该用来满足ACID要求。

选择互补技术