Flink流式计算从入门到实战五

Flink流式计算实战专题五

==楼兰

八、Flink项目实战

​ 这一个章节，我们来找一个常见的流式计算场景，将Flink真正用起来。

1、需求背景

​ 现在网络直播平台非常火爆，在斗鱼这样的网络直播间，经常可以看到这样的总榜排名，体现了主播的活跃度。我们就以这个贡献日榜为例，来设计一个Flink的计算程序。

​ 大家可以思考下这样的业务场景应该要如何实现？

​ 对于贡献日榜 这样的功能，可以理解为是一个典型的流式计算的场景，强调的是数据的实时处理。因为在这个场景下，必须要及时的累计用户的送礼物数据，才能形成你追我赶的实时效果，提升用户的参与体验。这个场景下的实时性，虽然不要求每一条数据都及时响应，但是整体的数据延迟还是要尽量缩短的。例如有一个狂热粉丝想要争抢日榜榜首的位置，虽然不要求送了礼物之后就立即刷新到榜首，但是最长也需要在几分钟内能够看到榜单的刷新效果。这在大数据场景下，也是非常有挑战的。

​ 这种场景下，使用Flink进行流批统一的计算，感觉就非常合适。

2、数据流程设计

​ 在确定了使用Flink进行计算后，首先就需要设计出数据的上下游流程，进行简单的方案可行性评估。

​ 对于数据上游，我们这个贡献榜统计的业务场景，数据来源自然就是粉丝们的打赏行为。一方面整个平台的打赏行为的数据量是非常大的，另一方面这些打赏行为涉及到账户操作，所以他的作用，更大的是体现在贡献榜功能以外的其他业务过程中。基于这两方面考虑，自然就会想到使用kafka来进行削峰以及解耦。而Flink在DataStream/DataSet API和 Table API&SQL 两个部分都对kafka提供了连接器实现，所以用kafka作为数据接入是可行的。

​ 而对于数据下游，其实可以想象，最终计算出来的数据，最为重要的是要强调查询的灵活性以及时效性，这样才能支持页面的快速查询。如果考虑查询的时效性，HBase和ElasticSearch都是比较理想的大数据存储引擎。但是如果考虑到查询的灵活性，就会想到ElasticSearch会相比HBase更适合。因为我们统计出来的这些粉丝贡献度的结果，不光可以作为每个直播间贡献榜的排名，也应该可以作为以后平台主播年度排名等其他业务场景的数据来源。如果想要兼顾这些查询场景，使用HBase就会对Rowkey产生大量的侵入，而Elasticsearch可以根据任意字段快速查询，就比较有优势。 另外，从官方文档中可以查到，对于HBase，Flink只提供了Table API&SQL 模块的connector支持，而DataStream/DataSet API中没有提供支持，而ElasticSearch则支持更为全面。当然，这跟HBase的具体场景是有关联的，但是也可以从另一个角度认为，使用ElasticSearch的可行性更高。

​ 这样，就初步确定了 kafka-> Flink -> ElasticSearch 这样的大致数据流程。这也是在实际开发中非常典型的一个组合方式。后续就可以着手搭建kafka集群以及ElasticSearch+Kibana的集群了。在这次示例中，我们还是会以hadoop01,hadoop02,hadoop03这三台机器来搭建集群。搭建的过程就略过了。

​ 然后确定数据的基础结构

​ 这一步主要是确定入口数据和出口数据的结构。只要这两个数据结构确定了，那么应用程序模块和大数据计算模块就可以分开进行开发了。是双方主要的解耦方式。

​ 在数据入口处，可以定义这样的简化的数据结构：

public static class GiftRecord{
    private String hostId; //主播ID
    private String fansId; //粉丝ID
    private long giftCount; //礼物数量
    private String giftTime; //送礼物时间。时间格式 yyyy-MM-DD HH:mm:SS
    .....
}

​ 在kafka中，确定使用gift作为Topic，MQ的消息格式为 #{hostId},#{fansId},#{giftCount},#{giftTime} 这样的字符串。

​ 在数据出口处，可以定义ES中这样简化的索引结构：

-- 贡献日榜索引
PUT daygiftanalyze
{
  "mappings":{
    "properties": {
      "windowEnd":{
        "type": "long"
      },
      "hostId": {
        "type": "keyword"
      },
      "fansId": {
        "type": "keyword"
      },
      "giftCount":{
        "type": "long"
      }
    }
  }
}

​ 这样，一个简单的设计方案就形成了。应用程序只需要在粉丝发送礼物时往kafka中同步一条消息记录，然后从ES中查询主播的贡献日榜和贡献周榜数据即可。而我们也可以模拟数据格式进行开发了。

3、应用实现

贡献日榜：

基础数据结构：

public static class GiftRecord{
    private String hostId; //主播ID
    private String fansId; //粉丝ID
    private long giftCount; //礼物数量
    private String giftTime; //送礼物时间。时间格式 yyyy-MM-DD HH:mm:SS
    .....
}

在kafka中，确定使用gift作为Topic，MQ的消息格式为 #{hostId},#{fansId},#{giftCount},#{giftTime} 这样的字符串。

ES索引：

PUT daygiftanalyze
{
  "mappings":{
    "properties": {
      "windowEnd":{
        "type": "long"
      },
      "hostId": {
        "type": "keyword"
      },
      "fansId": {
        "type": "keyword"
      },
      "giftCount":{
        "type": "long"
      }
    }
  }
}

​ 然后运行Flink程序，com.roy.flink.project.flink.DayGiftAna，从kafka中读取数据。测试数据见giftrecord.txt。计算程序会及时将十分钟内的粉丝礼物统计都存入到ES当中。

ES查询语句：

GET daygiftanalyze/_search
{
  "query": {
    "bool": {
      "must": [
        {"range": {
          "windowEnd": {
            "gte": 1631635200000,
            "lte": 1631721600000
          }
        }},
        {"match": {
          "hostId": "1001"
        }}
      ]
    }
  },
  "aggs": {
    "groupByFans": {
      "terms": {
        "field": "fansId",
        "size": 3,
        "order": {
          "giftCount": "desc"
        }
      },
      "aggs": {
        "giftCount": {
          "sum": {
            "field": "giftCount"
          }
        }
      }
    }
  }
}

ES中的查询结果：

直播应用就可以根据这个查询结果组织客户端查询代码，最终实现日榜排名的功能。

4、实现效果分析

​ 具体的计算方案参见示例代码，这里就不多做分析了。这里只分析一下在实现过程中需要注意的几个重要的问题：

1、时间语义分析：

​ 对于网络直播这样的场景，从下午六点到第二天早上六点才是一天的高峰期，所以，在进行统计时，将每一天的统计时间定义为从早上六点到第二天早上六点，这样就能尽量保持高峰期的完整性。很多跟娱乐相关的场景，比如网络游戏，也大都是以这样的范围来定义一天，而不是传统意义上的从0点到24点。

2、并行度优化：

​ 可以直接使用Flink的开窗机制，待一周的数据收集完整了之后，一次性向ES中输出统计结果，这种场景下要注意累计器的持久化，以及计算程序出错后的重启恢复机制。

3、后续的改进方式：

​ 状态后端、

而对于贡献日榜的计算，就不能等一天的数据收集齐了再计算了。这时是有两种解决方案，一种是完全的流处理方式。也就是每来一条数据就往ES中更新结果。另一中方式是采用小批量的流处理方式。以五分钟为单位，将数据拆分成一个一个小窗口来进行处理。显然后一种方式对数据处理的压力会比较小一点。虽然数据量会更多，但是ES的存储以及快速查询能力可以比较好的弥补数据量的问题。也因此，在设计ES数据机构时，将贡献日榜的文档结构设计成了一个一个的小范围。