SparkStreaming部分:kafka的总结【文字说明+图片展示+各种命令】

Kafka的架构:分布式消息系统,默认将消息存入磁盘,存储时间是7天。

Producer:消息的生产者,自己决定消息写往哪个partition,两种:1.hash,2.轮询

Broker:组建kafka集群的节点,broker之间没有主从关系,broker由zookeeper来协调,broker负责消息的读写,存储。每个broker可以管理多个partition。

Topic:一类消息的总称/消息队列/分类,由partition组成,有多少,创建可以指定

Partition:实际存储数据的地方,每个partition有副本,有多少?创建topic时可以指定,partition是直接接触磁盘,append追加消息,每个partition都有一个broker来管理。这个broker叫做这个partition的leader

Consumer:消息的消费者。每个consumer都有自己的消费者组。组与组之间消费同一个topic时,互不影响。同一个消费者组内的消费者同一个topic时,这个topic中同一条数据只能被消费一次。Consumer自己通过zookeeper来维护消费者的offset

Zookeeper:协调数据,存储元数据,broker,partition等

————————————————————————————————————————————————————————

Kafka和sparkstreaming整合:

用flume也可以接sparkstreaming

问题:

Flume------->sparkStreaming,sparkStreaming由于峰值的影响,之间有数据丢失,数据卡了,kafka起到了解耦和压力缓冲

是一个分布式的消息队列系统。

Kafka是零拷贝,就是不经过内存,直接写到磁盘的。,直接存起来.kafka有三种作用:解耦,缓冲,异步通信

生产者不丢数据,消费者不丢数据,永久保存

一般情况下没有峰值

Kafka的吞吐量很大,可以达到百兆每秒

Kafka后期可以给sparkstreaming提供很稳定的流输出,做了一个解耦

同时起到了压力峰值的缓冲

存消息队列的系统

Kafka是一个生产者,消费者队列系统,会保证自己不丢失数据,而且是一个分布式的,也有集群

Hash:基于(K,V)格式

轮询:先在一个partition中写,写一会儿,再去切换另一个部分。

Partition内部是强有序的。

Offset是生产者的偏移量

kafka会源源不断的提供数据

Kafka的架构:分布式消息系统,默认将消息存入磁盘,存储时间是7天。是一个分布式的,也就是有很多节点,保证自己不丢数据,消费者也不丢数据。

——————————————————————————————————————————————————————+

kafka启动时需要修改权限:

chmod +x startkafka.sh

启动:

./startkafka.sh

创建topic:

 ./kafka-topics.sh --zookeeper node01:2181,node02:2181,node03:2181 --create --topic t0730 2 --partitions 2 --replic
ation-factor 2

查看创建的节点:

./kafka-topics.sh --zookeeper node01:2181,node02:2191,node03:2181 --list

kafka集群的搭建:

  1. kafka集群搭建
  1. 上传kafka_2.10-0.8.2.2.tgz包到三个不同节点上,解压。
  2. 配置../ kafka_2.10-0.8.2.2/config/server.properties文件

节点编号:(不同节点按0,1,2,3整数来配置)

真实数据存储位置:

zookeeper的节点:

  1. 启动zookeeper集群。
  2. 三个节点上,启动kafka:

bin/kafka-server-start.sh   config/server.properties

最好使用自己写的脚本启动,将启动命令写入到一个文件:

nohup bin/kafka-server-start.sh   config/server.properties > kafka.log 2>&1 &

 

脚本附件:

(放在与bin同一级别下,注意创建后要修改权限:chmod 755 startkafka.sh)

  1. 相关命令:

创建topic:

./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181  --create --topic topic2017 --partitions 3 --replication-factor 3

用一台节点控制台来当kafka的生产者:

./kafka-console-producer.sh  --topic  topic2017

--broker-list node1:9092,node2:9092,node3:9092

用另一台节点控制台来当kafka的消费者:

./kafka-console-consumer.sh --zookeeper node3:2181,node4:2181,node5:2181 --topic topic2017

查看kafka中topic列表:

./kafka-topics.sh  --list --zookeeper node3:2181,node4:2181,node5:2181

查看kafka中topic的描述:

./kafka-topics.sh --describe --zookeeper node3:2181,node4:2181,node5:2181  --topic topic2017

 

注意:ISR是检查数据的完整性有哪些个节点。

查看zookeeper中topic相关信息:

启动zookeeper客户端:

./zkCli.sh

查看topic相关信息:

ls /brokers/topics/

查看消费者相关信息:

ls /consumers

  1. 删除kafka中的数据。
    • :在kafka集群中删除topic,当前topic被标记成删除。

./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181 --delete --topic t1205

在每台broker节点上删除当前这个topic对应的真实数据。

读取写入的信息:

./kafka-console-consumer.sh --zookeeper node01:2181,no
de02:2181,node03:2181 --topic t0730 --from-beginning

分别去每台节点目录日志下删除日志文件:

[root@node02 kafka-logs]# rm -rf t0730-*
 

    • :进入zookeeper客户端,删除topic信息

rmr /brokers/topics/t1205

    • :删除zookeeper中被标记为删除的topic信息

rmr /admin/delete_topics/t1205

 

查看描述:

./kafka-topics.sh --zookeeper node01:2181,node02:2181,
node03:2181 --describe --topic t0730

 

————————————————————————————————————————————————————————

删除topic里面的数据

这里没有单独的清空数据的命令,这里要达到清空数据的目的只需要以下步骤:

一、如果当前topic没有使用过即没有传输过信息:可以彻底删除。

二、 如果当前topic有使用过即有过传输过信息:并没有真正删除topic只是把这个topic标记为删除(marked for deletion)。想要彻底删除topic数据要经过下面两个步骤:

①:删除topic,重新用创建topic语句进行创建topic

②:删除zookeeper中的consumer中的路径。    

这里假设要删除的topic是test,kafka的zookeeper root为/kafka

删除kafka相关的数据目录

数据目录请参考目标机器上的kafka配置:server.properties -> log.dirs=/var/kafka/log/tmp

rm -r /var/kafka/log/tmp/test*

 

删除kafka topic

./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181 --delete --topic kfk

 

删除zookeeper相关的路径

(1)登录zookeeper客户端:命令:./bin/zookeeper-client

(2)找到topic所在的目录:ls /brokers/topics

(3)找到要删除的topic,执行命令:rmr /brokers/topics/【topic name】即可,此时topic被彻底删除。

 

另外被标记为marked for deletion的topic你可以在zookeeper客户端中通过命令获得:ls /admin/delete_topics/【topic name】,如果你删除了此处的topic,那么marked for deletion 标记消失

完成

重启zookeeper和kafka可以用下面命令查看相关的topic还在不在:

/home/kafka/bin/kafka-topics.sh --list --zookeeper HadoopMaster:2181/kafka

 

<think>好的,用户让我介绍一下RTB电商中的架构图。首先,我需要明确RTB(实时竞价)在电商中的应用场景。RTB通常用于广告领域,比如程序化广告购买,电商中可能用RTB来实时竞价广告展示位置,比如在用户浏览商品时,实时决定展示哪个广告。 接下来,用户要的是架构图,但可能他们需要的是架构的组成部分和流程,因为用文字描述图可能更合适。我需要分解RTB电商系统的各个模块,然后解释它们如何交互。 首先,RTB流程通常包括用户访问电商平台,触发广告请求,然后平台通过SSP(供应方平台)发送请求到AD Exchange(广告交易平台),DSP(需求方平台)参与竞价,胜出的广告展示给用户。但在电商环境下,可能电商平台自己充当SSP,或者与第三方合作。 需要区分电商业务架构和RTB系统架构。电商的核心模块包括商品管理、订单、支付、用户系统等,而RTB部分可能作为广告模块集成进去。但用户可能更关注RTB部分的架构,而不是整个电商系统。 可能的架构组成部分:用户端(APP/Web)、电商业务系统、广告服务(SSP)、ADX、DSP、DMP(数据管理平台)。数据流方面,用户行为数据收集到DMP,用于定向广告。当用户访问页面时,电商系统通过SSP发送广告请求到ADX,ADX向各DSP发起竞价,DSP根据用户数据和广告主需求出价,胜出者广告返回展示。 还需要考虑实时竞价中的技术组件,如实时数据处理、竞价算法、用户画像、日志记录、计费等。可能涉及的技术包括消息队列(如Kafka)、实时计算(如Flink)、数据库(如Redis缓存用户数据)、机器学习模型用于预测点击率等。 需要确保架构的高可用性和低延迟,因为实时竞价通常在毫秒级完成。可能使用分布式系统、负载均衡、缓存机制等。 用户可能的背景是技术相关,比如开发者或架构师,想了解如何将RTB集成到电商系统中,或者学习RTB架构的设计。他们可能需要了解各组件的作用和数据流向,以及关键技术选型。 可能忽略的点:电商中的RTB是否与一般广告RTB有不同之处?比如电商可能有更多第一方用户数据,DMP可能更侧重于购买行为和商品偏好。此外,竞价策略可能更关注转化率而非点击率。 总结,架构图应包含客户端、电商业务系统、广告服务模块、ADX、DSP、DMP,以及数据流和实时处理组件。需要分层次描述,从用户端到后端服务,再到外部DSP和数据处理。</think>RTB(实时竞价,Real-Time Bidding)在电商中通常用于广告投放场景,例如在用户浏览商品时,通过实时竞价动态展示相关广告。以下是一个典型的 **RTB电商广告系统架构图** 及核心模块说明: --- ### **架构分层与核心组件** 1. **用户端(Client)** - **Web/App**:用户访问电商平台,触发广告展示请求(如商品详情页的广告位)。 - **用户行为数据**:记录点击、浏览、加购等行为,用于后续的广告定向和效果分析。 2. **电商业务系统** - **商品/订单系统**:管理商品信息、用户购买记录等。 - **用户画像系统**:基于历史行为生成用户标签(如性别、购买偏好)。 - **广告位管理**:定义广告位的规格(如尺寸、位置)和竞价规则。 3. **广告服务层(RTB核心)** - **SSP(供应方平台)** - 电商平台通过SSP管理广告位资源,向广告交易平台(ADX)发送广告请求。 - **ADX(广告交易平台)** - 接收SSP请求,组织实时竞价拍卖,向多个DSP广播竞价请求(Bid Request)。 - **DSP(需求方平台)** - 广告主通过DSP参与竞价,基于用户画像、广告位上下文等实时计算出价(Bid Response)。 - **DMP(数据管理平台)** - 整合用户行为数据(如浏览、搜索、购买)、第三方数据(如地域、设备),为DSP提供定向支持。 4. **实时数据处理层** - **实时日志采集**:通过Flume/Kafka收集用户行为日志。 - **实时计算引擎**:使用Flink/Spark Streaming分析用户实时行为,更新用户画像。 - **模型预测**:机器学习模型预估广告点击率(CTR)或转化率(CVR),辅助DSP出价。 5. **存储与基础设施** - **缓存(Redis/Memcached)**:存储用户实时画像、广告素材等高频数据。 - **数据库(MySQL/OLAP)**:存储广告订单、竞价日志、效果数据。 - **CDN**:加速广告素材(如图片、视频)的加载。 --- ### **RTB流程(数据流)** 1. **用户触发广告请求** 用户访问电商页面时,客户端向SSP发送广告请求(含用户ID、广告位信息)。 2. **SSP发起竞价** SSP将请求发送至ADX,ADX生成包含用户画像、上下文信息的Bid Request,广播给多个DSP。 3. **DSP实时竞价** - DSP接收Bid Request,结合DMP数据、广告主预算及目标,计算最优出价。 - 使用CTR/CVR预测模型,确保广告相关性及ROI。 4. **竞价胜出与广告返回** ADX选择最高出价的DSP,返回广告素材至用户端展示,并记录竞价日志用于计费。 5. **效果追踪与反馈** 用户点击或转化行为回传至DSP和电商平台,用于优化后续竞价策略。 --- ### **技术挑战与优化** - **低延迟**:竞价需在100ms内完成,依赖高性能网络和分布式计算。 - **数据一致性**:实时用户画像与离线数据需同步(如Lambda架构)。 - **算法优化**:结合深度学习提升CTR预估精度,动态调整出价策略。 --- ### **简化架构图(文字描述)** ``` 用户端 → 电商业务系统 → SSP → ADX → DSP(+DMP) ↑ ↓ ↓ 用户画像系统 ← 实时计算 ← 日志存储 ``` 通过这一架构,电商平台可实现广告资源的实时竞价与精准投放,平衡用户体验与广告收益。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值