获课：xingkeit.top/5543/

Spark流式处理用户行为：实时增量更新ES索引

用户在App里点了什么、看了什么、搜了什么——这些行为数据如果等到第二天才能看到，运营决策永远慢一拍。Spark Structured Streaming配合Elasticsearch，能把用户行为的端到端延迟压到秒级。核心逻辑不复杂：Kafka收流，Spark做增量计算，ES实时写入。但每个环节都有坑。

数据流架构：三层解耦

整条链路分为三层，每层只干一件事。

采集层负责把行为数据送进来。前端SDK埋点，用户每次点击、浏览、加购都生成一条JSON事件，通过HTTP或Kafka推送到后端。这里推荐用Kafka，因为它天然支持分区和回溯，Spark挂了重启后能从上次的offset继续消费，不丢数据。

计算层是Spark Structured Streaming的主战场。从Kafka读取行为流，做实时清洗、字段补全、行为序列拼接，然后增量更新ES。注意是"增量更新"，不是全量重写——每条行为只触发一次ES写入，而不是把所有历史数据重新刷一遍。

存储层是Elasticsearch。用户行为数据写入ES后，运营可以通过Kibana实时看大屏，算法可以直接调ES接口拿特征，推荐系统可以毫秒级拉取用户最近行为。ES不只是存储，更是下游所有业务的实时数据源。

增量更新ES： upsert是核心

行为数据更新ES，最怕的是重复写入和覆盖丢失。ES提供了upsert语义：文档存在就更新，不存在就插入。Spark通过_id字段控制——_id用用户ID加行为类型加时间戳拼接，保证每条行为有唯一标识。

但增量更新有个陷阱：ES的写入不是即时生效的。默认有1秒的refresh interval，写入后要等1秒才能被搜到。实时大屏场景下，这个延迟不可接受。解决办法是把refresh interval调到500毫秒，或者写入后手动调用refresh API。代价是ES的写入吞吐量会下降15%到20%，需要在延迟和性能之间做取舍。

更优雅的做法是用ES的Pipeline批量写入。Spark不是每条行为就写一次ES，而是攒够5000条或等2秒，一次性批量提交。批量写入的吞吐量是单条写入的10倍以上，延迟只增加不到1秒。

Exactly-Once：不丢不重的关键

流式处理最怕两件事：数据丢了，数据重了。Spark Structured Streaming配合Kafka的事务机制，能实现端到端的精确一次语义。

关键在于checkpoint。Spark每处理完一个微批，就把Kafka的消费offset和ES的写入状态一起存到checkpoint目录。作业重启后，从checkpoint恢复offset，从上次中断的地方继续消费，已经写入ES的数据不会重复写入，未写入的数据不会丢失。

但这里有个细节：checkpoint必须存到高可用存储（HDFS或S3），不能存本地。本地磁盘一挂，checkpoint丢失，精确一次语义直接崩溃。

窗口计算：让行为数据产生价值

原始行为流只是一堆点击记录，没有上下文。窗口计算把孤立的点连成线。

比如"用户最近5分钟内浏览了多少商品"——这是一个滚动窗口，每来一条新行为，窗口向前滑动，重新计算。再比如"用户最近1小时内搜索了3次以上"——这是会话窗口，按30分钟不活跃切分会话。

这些窗口计算的结果，才是真正有业务价值的标签。窗口结果同样增量写入ES，下游直接查标签，不用再做二次计算。

一句话总结

Spark流式处理用户行为的本质，是把"用户做了什么"这件事从T+1变成T+0。Kafka保证数据不丢，Spark保证计算不重，ES保证查询不慢。三层各司其职，增量更新替你扛住写入压力，精确一次替你兜住数据一致性。把这条链路跑通，用户画像就不再是昨天的快照，而是此刻的现场直播。