深入认识快数据与Spark/Kafka/Cassandra技术架构
Posted 小象
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了深入认识快数据与Spark/Kafka/Cassandra技术架构相关的知识,希望对你有一定的参考价值。
译者:刘旭坤
原文链接:https://dzone.com/articles/why-developers-are-flocking-to-fast-data-and-the-s
小象科技原创作品,欢迎大家疯狂转发;
机构、自媒体平台转载务必至后台留言,申请版权
大数据领域最值得注意的发展趋势是企业环境中数据管道的处理速度和灵活性的要求正日益提高。
九十年代在大型互联网公司应对空前增长的数据量的努力中诞生了大数据这个概念。现在人们提到大数据的时候通常想到的是Hadoop或者NoSQL数据库。不过其实直到最近Hadoop的核心组件(HDFS、MapReduce、YARN)都是以批处理的方式运行的。数据获取之后被存储起来然后周期性地进行批量处理。
最初大部分的搜索引擎也是这么工作的,将爬虫收集的数据存储起来然后周期性地更新进搜索结果。大数据注重的是数据的获取和批量处理分析,而快数据则将缩短获取数据与分析出结果之间的间隔作为主要的目标。与批处理相对的是实时处理,指事件发生时迅速完成处理。通常处理的时间达到毫秒甚至微秒级别。需要实时处理的一个例子是高频交易系统,因为在市场交易中谁的速度更快谁获益的可能性就更大。
此外还有一种流处理模式,可以把它看作由一个个微型的批处理所组成的,处理的时间从几分钟到几秒钟不等。
快数据
快数据描述的是这么一种系统或者方式:它取得了处理时间、花费和开发效率上的平衡。一个应用架构必须满足下面的三个要求才能称得上是快数据架构:
可靠的数据获取
灵活的存储和查询
先进的分析工具
此外这些模块也必须满足能够进行扩展、容错、具有高可靠性并且由事件驱动等要求。
快数据的技术架构
研究显示对于无需实时处理的系统现在最流行的工具组合是Spark Streaming、Kafka和Cassandra。Spark Streaming从Kafka、数据库或者文件系统以微型批处理的方式获取数据,之后使用Spark从ETL到机器学习的全套分析功能来进行处理。这使得Spark很适应于Lambda架构,做到了批处理与流处理的分离。
对于历史数据,采用批处理的方式进行分析,而对于新接收到的事件则采取流处理的方式。分析的结果会被集中到一个显示全局数据的视图中。但通常这种架构有一个问题,批处理管道和流处理管道的逻辑会发生重复。不过使用Spark Streaming的话,为批处理管道写的逻辑可以直接用在流处理管道上,避免了重复劳动。Kafka提供了可扩展而又可靠的流数据获取方式,它的功能不多,但现有的功能非常完善,很好地连接了下游的Spark和上游的数据源。尤其有的数据源不能重复查询时就更得靠Kafka了。
最后分析的结果可以存储到Cassandra这样可扩展的数据库中,其他选择还包括Riak、HBase、HDFS和S3等。Kafka也可以暂时充当存储媒介。
快数据在商业上的应用
其实大多数商业企业的数据规模还停留在TB级别而并没有上升到PB级别。这些企业希望通过大数据将不同数据源不同格式的数据进行操作和整合。大型数据集的处理是一个好的开始,但仅仅触及了企业对数据处理需求的冰山一角。
现在企业中要求的更多的是处理的速度,要求从数据收集到获得处理结果之间的间隔尽量缩短。一些传统的方法可以在实时性上进行提升来满足这一需求,不过使用Spark来高效地处理从小到大各种格式的数据会是一个更好的选择。
你可能以为流数据/快数据运动是从开源界开始的,实则不然,因为最先有这样需求的是谷歌这样的大型互联网公司。对于想要探索快数据的开发人员来说,Spark、Kafka和Cassandra的组合是一个绝佳的起点。
以上是关于深入认识快数据与Spark/Kafka/Cassandra技术架构的主要内容,如果未能解决你的问题,请参考以下文章