2017年12月_立喆

原创彻底删除Kafka中的topic

1、删除kafka存储目录（server.properties文件log.dirs配置，默认为"/tmp/kafka-logs"）相关topic目录2、Kafka 删除topic的命令是： ./bin/kafka-topics --delete --zookeeper 【zookeeper server】 --topic 【topic name】如

2017-12-25 16:30:30 268

转载 kafka broker 配置说明

The essential configurations are the following:基本配置如下:broker.idlog.dirszookeeper.connectTopic-level configurations and defaults are discussed in more detail below.下文将详细论述了主题级别配置和默认值。

2017-12-25 16:18:01 848

转载 Spark SQL 之 Join 实现

Join作为SQL中一个重要语法特性，几乎所有稍微复杂一点的数据分析场景都离不开Join，如今Spark SQL(Dataset/DataFrame)已经成为Spark应用程序开发的主流，作为开发者，我们有必要了解Join在Spark中是如何组织运行的。SparkSQL总体流程介绍在阐述Join实现之前，我们首先简单介绍SparkSQL的总体流程，一般地，我们有两种方式使用Spar

2017-12-08 16:22:36 406

转载 Spark Streaming 流计算优化记录(6)-GC优化与shuffle service

11.Spark应用的GC调优说到GC, 可能很多人都倾向于使用新潮的G1垃圾收集器, 特别是intel的那几个兄弟在databrick发表了篇用G1调优Spark应用的博文后, 就更多人热衷于尝试G1了.但其实我们再去年就对G1和老牌的CMS+NewPar进行过对比测试, 发现G1根本没有比CMS好, 有时候还会导致更多的FullGC, 而实际上连Oracle官方都觉得G1还没有pr

2017-12-01 11:48:02 515 1

转载 Spark Streaming 流计算优化记录(5)-分区与内存的优化

8.不一定非得每秒处理一次由于Spark Streaming的原理是micro batch, 因此当batch积累到一定数量时再发放到集群中计算, 这样的数据吞吐量会更大些. 这需要在StreamingContext中设置Duration参数. 我们试着把Duration调成两秒, 这样Spark就会在接收Kafka的模块中积累了2秒的数据后, 在调度作业到集群中计算.结合上述做过的优

2017-12-01 11:47:23 1483

转载 Spark Streaming 流计算优化记录(4)-时间都去哪儿了,关于调度与空转

6.时间都去where了,青春不能等,调度也是除了上述优化, 我们还注意到一个奇怪的现象: 怎么回事, 即使接收不到消息都要花掉5秒?!! 虽然Spark Streaming空转依然会产生空task, 这些空task依然会消耗序列化, 压缩, 调度等时间, 但也不至于那么多吧!!!我们拿一个Stage看看, 就拿处理Kafka消息的那个Stage作例子吧: Kafka没

2017-12-01 11:46:58 460

转载 Spark Streaming 流计算优化记录(3)-控制流量与join的地点

4.流量控制好像之前说过”一下子从Kafka拉取几十万条消息进行处理”的事情, 其实酱紫是不对滴, 饭要一口一口吃, 一下子吃太多, 会导致还没吃成胖子就已经被撑死的. 所以我们要对为了做压力测试而早已在Kafka中囤积多时的几十万条消息分批次进行处理, 毕竟实际跑起的时候每秒拥入我们知道, Spark Streaming进行流处理的原理是micro batch, 即把每秒或每几秒

2017-12-01 11:40:33 1294

转载 Spark Streaming 流计算优化记录(2)-不同时间片数据流的Join

1. 不同时间片数据流的Join 初体验之后, 看了一下Spark WebUi 的日志, 发现由于Spark Streaming需要每秒跑一次, 以实时计算数据, 所以程序不得不每秒都读一次HDFS去获取数据进行inner join. 本来SparkStreaming会对其进行处理的数据进行缓存, 以减少IO和提高计算速度的, 但由于现在我们的场景是

2017-12-01 11:38:20 566

转载 Spark Streaming 流计算优化记录(1)-背景介绍

1.背景概述业务上有一定的需求, 希望能实时地对从中间件进来的数据已经已有的维度表进行inner join, 以便后续的统计. 维表十分巨大, 有近3千万记录,约3G数据, 而集群的资源也较紧张, 因此希望尽可能压榨Spark Streaming的性能和吞吐量.技术架构大致上如下述: 数据从Kafka流入, SparkStreaming 会从HDFS中拿到维度表的数据, 与流入的消

2017-12-01 11:35:12 392

leone911的博客