分享 双十一 Kafka+Flink+Redis 的电商大屏实时计算案例_redis 实现实时双十一大屏

一年一度的双11又要到了，阿里的双11销量大屏可以说是一道特殊的风景线。实时大屏（real-time dashboard）正在被越来越多的企业采用，用来及时呈现关键的数据指标。并且在实际操作中，肯定也不会仅仅计算一两个维度。由于Flink的“真·流式计算”这一特点，它比Spark Streaming要更适合大屏应用。本文从笔者的实际工作经验抽象出简单的模型，并简要叙述计算流程（当然大部分都是源码）。

数据格式与接入

简化的子订单消息体如下：

{
    "userId": 234567,
    "orderId": 2902306918400,
    "subOrderId": 2902306918401,
    "siteId": 10219,
    "siteName": "site\_blabla",
    "cityId": 101,
    "cityName": "北京市",
    "warehouseId": 636,
    "merchandiseId": 187699,
    "price": 299,
    "quantity": 2,
    "orderStatus": 1,
    "isNewOrder": 0,
    "timestamp": 1572963672217
}

由于订单可能会包含多种商品，故会被拆分成子订单来表示，每条JSON消息表示一个子订单。现在要按照自然日来统计以下指标，并以1秒的刷新频率呈现在大屏上：

• 每个站点（站点ID即siteId）的总订单数、子订单数、销量与GMV；
• 当前销量排名前N的商品（商品ID即merchandiseId）与它们的销量。

由于大屏的最大诉求是实时性，等待迟到数据显然不太现实，因此我们采用处理时间作为时间特征，并以1分钟的频率做checkpointing。

    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);
    env.enableCheckpointing(60 \* 1000, CheckpointingMode.EXACTLY_ONCE);
    env.getCheckpointConfig().setCheckpointTimeout(30 \* 1000);

然后订阅Kafka的订单消息作为数据源

    Properties consumerProps = ParameterUtil.getFromResourceFile("kafka.properties");
    DataStream<String> sourceStream = env
      .addSource(new FlinkKafkaConsumer011<>(
        ORDER_EXT_TOPIC_NAME,                        // topic
        new SimpleStringSchema(),                    // deserializer
        consumerProps                                // consumer properties
      ))
      .setParallelism(PARTITION_COUNT)
      .name("source\_kafka\_" + ORDER_EXT_TOPIC_NAME)
      .uid("source\_kafka\_" + ORDER_EXT_TOPIC_NAME);

给带状态的算子设定算子ID（通过调用uid()方法）是个好习惯，能够保证Flink应用从保存点重启时能够正确恢复状态现场。为了尽量稳妥，Flink官方也建议为每个算子都显式地设定ID，参考官方文档。

接下来将JSON数据转化为POJO，JSON框架采用FastJSON。

    DataStream<SubOrderDetail> orderStream = sourceStream
      .map(message -> JSON.parseObject(message, SubOrderDetail.class))
      .name("map\_sub\_order\_detail").uid("map\_sub\_order\_detail");

JSON已经是预先处理好的标准化格式，所以POJO类SubOrderDetail的写法可以通过Lombok极大地简化。如果JSON的字段有不规范的，那么就需要手写Getter和Setter，并用@JSONField注解来指明。

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString
public class SubOrderDetail implements Serializable {
  private static final long serialVersionUID = 1L;
  
  private long userId;
  private long orderId;
  private long subOrderId;
  private long siteId;
  private String siteName;
  private long cityId;
  private String cityName;
  private long warehouseId;
  private long merchandiseId;
  private long price;
  private long quantity;
  private int orderStatus;
  private int isNewOrder;
  private long timestamp;
}

统计站点指标

将子订单流按站点ID分组，开1天的滚动窗口，并同时设定ContinuousProcessingTimeTrigger触发器，以1秒周期触发计算。注意处理时间的时区问题，这是老生常谈了。

    WindowedStream<SubOrderDetail, Tuple, TimeWindow> siteDayWindowStream = orderStream
      .keyBy("siteId")
      .window(TumblingProcessingTimeWindows.of(Time.days(1), Time.hours(-8)))
      .trigger(ContinuousProcessingTimeTrigger.of(Time.seconds(1)));

接下来写个聚合函数

    DataStream<OrderAccumulator> siteAggStream = siteDayWindowStream
      .aggregate(new OrderAndGmvAggregateFunc())
      .name("aggregate\_site\_order\_gmv").uid("aggregate\_site\_order\_gmv");

  public static final class OrderAndGmvAggregateFunc
    implements AggregateFunction<SubOrderDetail, OrderAccumulator, OrderAccumulator> {
    private static final long serialVersionUID = 1L;
 
    @Override
    public OrderAccumulator createAccumulator() {
      return new OrderAccumulator();
    }
 
    @Override
    public OrderAccumulator add(SubOrderDetail record, OrderAccumulator acc) {
      if (acc.getSiteId() == 0) {
        acc.setSiteId(record.getSiteId());
        acc.setSiteName(record.getSiteName());
      }
      acc.addOrderId(record.getOrderId());
      acc.addSubOrderSum(1);
      acc.addQuantitySum(record.getQuantity());
      acc.addGmv(record.getPrice() \* record.getQuantity());
      return acc;
    }
 
    @Override
    public OrderAccumulator getResult(OrderAccumulator acc) {
      return acc;
    }
 
    @Override
    public OrderAccumulator merge(OrderAccumulator acc1, OrderAccumulator acc2) {
      if (acc1.getSiteId() == 0) {
        acc1.setSiteId(acc2.getSiteId());
        acc1.setSiteName(acc2.getSiteName());
      }
      acc1.addOrderIds(acc2.getOrderIds());
      acc1.addSubOrderSum(acc2.getSubOrderSum());
      acc1.addQuantitySum(acc2.getQuantitySum());
      acc1.addGmv(acc2.getGmv());
      return acc1;
    }
  }

累加器类OrderAccumulator的实现很简单，看源码就大概知道它的结构了，因此不再多废话。唯一需要注意的是订单ID可能重复，所以需要用名为orderIds的HashSet来保存它。HashSet应付我们目前的数据规模还是没太大问题的，如果是海量数据，就考虑换用HyperLogLog吧。

接下来就该输出到Redis供呈现端查询了。这里有个问题：一秒内有数据变化的站点并不多，而ContinuousProcessingTimeTrigger每次触发都会输出窗口里全部的聚合数据，这样做了很多无用功，并且还会增大Redis的压力。所以，我们在聚合结果后再接一个ProcessFunction，代码如下:

    DataStream<Tuple2<Long, String>> siteResultStream = siteAggStream
      .keyBy(0)
      .process(new OutputOrderGmvProcessFunc(), TypeInformation.of(new TypeHint<Tuple2<Long, String>>() {}))
      .name("process\_site\_gmv\_changed").uid("process\_site\_gmv\_changed");

  public static final class OutputOrderGmvProcessFunc
    extends KeyedProcessFunction<Tuple, OrderAccumulator, Tuple2<Long, String>> {
    private static final long serialVersionUID = 1L;
 
    private MapState<Long, OrderAccumulator> state;
 
    @Override
    public void open(Configuration parameters) throws Exception {
      super.open(parameters);
      state = this.getRuntimeContext().getMapState(new MapStateDescriptor<>(
        "state\_site\_order\_gmv",
        Long.class,
        OrderAccumulator.class)
      );
    }
 
    @Override
    public void processElement(OrderAccumulator value, Context ctx, Collector<Tuple2<Long, String>> out) throws Exception {
      long key = value.getSiteId();
      OrderAccumulator cachedValue = state.get(key);
 
      if (cachedValue == null || value.getSubOrderSum() != cachedValue.getSubOrderSum()) {
        JSONObject result = new JSONObject();
        result.put("site\_id", value.getSiteId());
        result.put("site\_name", value.getSiteName());
        result.put("quantity", value.getQuantitySum());
        result.put("orderCount", value.getOrderIds().size());
        result.put("subOrderCount", value.getSubOrderSum());
        result.put("gmv", value.getGmv());
        out.collect(new Tuple2<>(key, result.toJSONString());
        state.put(key, value);
      }
    }
 
    @Override
    public void close() throws Exception {
      state.clear();
      super.close();
    }
  }

说来也简单，就是用一个MapState状态缓存当前所有站点的聚合数据。由于数据源是以子订单为单位的，因此如果站点ID在MapState中没有缓存，或者缓存的子订单数与当前子订单数不一致，表示结果有更新，这样的数据才允许输出。

最后就可以安心地接上Redis Sink了，结果会被存进一个Hash结构里。

    // 看官请自己构造合适的FlinkJedisPoolConfig
    FlinkJedisPoolConfig jedisPoolConfig = ParameterUtil.getFlinkJedisPoolConfig(false, true);
    siteResultStream
      .addSink(new RedisSink<>(jedisPoolConfig, new GmvRedisMapper()))
      .name("sink\_redis\_site\_gmv").uid("sink\_redis\_site\_gmv")
      .setParallelism(1);

  public static final class GmvRedisMapper implements RedisMapper<Tuple2<Long, String>> {
    private static final long serialVersionUID = 1L;
    private static final String HASH_NAME_PREFIX = "RT:DASHBOARD:GMV:";
 
    @Override
    public RedisCommandDescription getCommandDescription() {
      return new RedisCommandDescription(RedisCommand.HSET, HASH_NAME_PREFIX);
    }
 
    @Override
    public String getKeyFromData(Tuple2<Long, String> data) {
      return String.valueOf(data.f0);
    }
 
    @Override
    public String getValueFromData(Tuple2<Long, String> data) {
      return data.f1;
    }
 
    @Override
    public Optional<String> getAdditionalKey(Tuple2<Long, String> data) {
      return Optional.of(
        HASH_NAME_PREFIX +
        new LocalDateTime(System.currentTimeMillis()).toString(Consts.TIME_DAY_FORMAT) +
        "SITES"
      );
    }
  }

商品Top N

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取