如何配置 Flink DataStream 作业以处理 725MB 表的不可变 ListState？

Question

我在 Flink Data Stream API 版本 1.10.1 中运行 TPC-H 查询。 其中一个 UDF 读取整个表LineItem并将其存储在 memory 中（使用默认的MemoryStateBackend ）。 首先，我存储了对象List<LineItem> 。 但是我的 memory 用完了，最好只存储我将使用的字段。 所以我存储List<Tuple2<Integer, Double>> 。 我还为发送方和接收方增加了请求和接收心跳的超时时间heartbeat.timeout: 100000 。 当我使用大约 500MB 的数据源表文件时，我可以执行我的查询。 但是，原始大小是 725MB，在这个大小下，我在指标上遇到了一些滞后。 我还增加了任务管理器和作业管理器的 memory 大小。 但似乎这不再是问题了。

jobmanager.heap.size: 4g # default: 2048m
heartbeat.timeout: 100000
taskmanager.memory.flink.size: 12g
taskmanager.memory.jvm-overhead.max: 4g
taskmanager.memory.jvm-metaspace.size: 2048m # default: 1024m

这是我使用ListState的 UDF。

public class OrderKeyedByProcessFunction extends KeyedProcessFunction<Long, Order, Tuple2<Integer, Double>> {
    private ListState<Tuple2<Integer, Double>> lineItemList = null;

    @Override
    public void open(Configuration parameters) {
        try {
            super.open(parameters);
            ListStateDescriptor<Tuple2<Integer, Double>> lineItemDescriptor = new ListStateDescriptor<>("lineItemState",
                    TypeInformation.of(new TypeHint<Tuple2<Integer, Double>>() {
                    }));
            lineItemList = getRuntimeContext().getListState(lineItemDescriptor);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public void processElement(Order order, KeyedProcessFunction<Long, Order, Tuple2<Integer, Double>>.Context context,
            Collector<Tuple2<Integer, Double>> out) {
        try {
            if (lineItemList != null && Iterators.size(lineItemList.get().iterator()) == 0) {
                LineItemSource lineItemSource = new LineItemSource();
                List<Tuple2<Integer, Double>> lineItems = lineItemSource.getLineItemsRevenueByOrderKey();
                lineItemList.addAll(lineItems);
            }

            for (Tuple2<Integer, Double> lineItem : lineItemList.get()) {
                if (order != null && (lineItem.f0.intValue() == ((int) order.getOrderKey()))) {
                    out.collect(Tuple2.of((int) order.getCustomerKey(), lineItem.f1));
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

我正在使用 Prometheus + Grafana 在flink-conf.yaml上获取指标和此配置属性

# Metrics Reporter
metrics.reporter.prom.class: org.apache.flink.metrics.prometheus.PrometheusReporter
metrics.reporter.prom.host: 127.0.0.1
metrics.reporter.prom.port: 9250-9260

和/etc/prometheus/prometheus.yml上的这个配置

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node_exporter'
    scrape_interval: 5s
    static_configs:
            - targets: ['localhost:9100', 'r02:9100', 'r01:9250', 'r04:9250']
  - job_name: 'flink'
    scrape_interval: 5s
    static_configs:
            - targets: ['localhost:9090', 'localhost:9250', 'localhost:9251', 'r02:9250', 'r01:9250', 'r04:9250']
    metrics_path: /

我可以调整什么样的配置，以免在指标上出现这种滞后？

Answer 1

这似乎是使用 Flink state 只会让事情变得更糟的情况。 如果您加载到这些列表中的数据是不可变的，并且您希望将其保存在 memory 中，那么将其存储在 ListState 中的开销不会给您带来任何有用的东西。 我这样说是因为没有理由检查此 state，并且因为您没有利用 RocksDB state 后端将其溢出到磁盘。 所以我认为你最好使用普通的 java map 的顺序键到元组列表。 进行该更改可能足以解决您的性能问题。

（另外，值得一提的是，在processElement中， lineItemList永远不会是 null，因为它是在open方法中初始化的。）