首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Spark Streaming的背压机制(类比Storm雪崩)

    默认情况下,SparkStremaing根据Receiver以生产者生产数据的速度来接收数据,但是在工作状态下, 实际计算一个批次数据的时间一般要大于Streaming应用设置的批处理间隔。这就意味着Spark Streaming处理数据的速度要小于数据接收的速度, 数据处理能力低,导致数据全部堆积在内存中,进一步导致Receiver所在的Executor会发生内存溢出的问题。        同为优秀的大数据实时处理框架,这个问题和类比于Storm的雪崩问题,Storm中若是Spout,或者是其他上游的Bolt发送数据的速度过快,而下游Bolt因为并行度,或者是业务逻辑较为复杂, 就会导致数据堆积到内存中,进而引发雪崩的问题。Storm解决这个问题,有两种思路。第一种,控制上游发送数据的速度topology.max.spout.pending,比如说内存中未处理的Tuple(Storm中的数据处理单位,类似于kafka中的message)达到10000条的时候,堵塞发送线程,停止发送,直到内存中的数据小于我们设置的阈值;第二种思路,就是提高下游处理数据的速度, 提高并行度, 设置下excutor的数目。其实还有第三种思路,即当内存中的数据达到一定阈值后,将其写入Disk中。        Spark Streaming的解决思路和Storm的解决思路是一样的,但是比Storm更为灵活。因为Storm设置上游发送数据的Tuple数目,当消费者消费数据能力很大的时候,会造成资源利用率下降等问题。为了更好的协调数据接收速率与资源处理能力,Spark Streaming可以动态控制数据接收速率来适配集群数据处理能力。        Spark Streaming Backpressure: 根据JobScheduler反馈作业的执行信息来动态调整Receiver数据接收率。通过属性“spark.streaming.backpressure.enabled”来控制是否启用backpressure机制,默认值false,即不启用。

    01

    使用Storm处理事务型实时计算需求时的几处难点

    比流量或者订单淘宝可以把我们甩出几条大街。淘宝的兄弟可以自豪地说他们的实时应用已经承受住了双十一全世界范围内最大的单日数据流的冲击。而阿里巴巴中文站的流量和订单与淘宝相比则少的可怜。同时B2B自身业务又存在不同的特点,我们的客单价和笔单价要高得多,因此对于实时数据的误差是零容忍的(比如丢了一个几百万的单子,那实时数据就没有参考价值了)。 所以中文站的实时应用的特点是零误差,事务性,故障可恢复。 在开发实时应用的过程中,我发现当实时计算需要保证数据完全不出错的时候,逻辑就变得复杂起来。效率和精度本身就是不

    07
    领券