Flink任务优化分享

已于 2023-09-18 23:34:59 修改
阅读量807 收藏
点赞数 1
分类专栏： Flink 文章标签： flink java 大数据
于 2023-07-25 14:32:26 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_31405633/article/details/131917297
版权
文章介绍了线上Flink计算任务耗时过长的问题，通过分析FlinkHistoryServer执行计划，发现了不必要的数据分叉和SQL逻辑导致的性能瓶颈。优化策略包括调整SQL逻辑，减少分叉，将GROUPBY+LATERALTABLE+JOIN替换为基于OverAggregate的UDAF，从而显著提升了任务执行速度，将计算时长从40分钟降低到7分钟。
摘要由CSDN通过智能技术生成

Flink任务优化分享

1.背景介绍

线上计算任务在某版本上线之后发现每日的任务时长都需要三个多小时才能完成，计算时间超过了预估时间，通过Dolphinscheduler的每日调度任务看，在数据层 dwd 的数据分段任务存在严重的性能问题，每天的计算耗时将近40分钟，并且随着数据量的上涨，时间越来越长，因此这个计算节点需要着重优化。

2.改进思路及实施

现在的大数据计算任务是用 flink 执行的，因此优化的入手点就是从 Flink History Server 上看任务的执行计划，找到耗时较多的节点以及是否有节点因为sql逻辑被重复执行，导致耗时较高。

在这里插入图片描述

如图所示，可以发现计算任务走了三个分叉，从sql最后的输出来看，只有两个insert表操作，所以这里至少有一条分叉是不必要的；然后就是找到分叉点的原因，为什么会导致任务分成了三个分支，这个就需要执行计划慢慢去理，界面上可以点开每个节点看到他的执行计算优化之后的结果，然后来判断这一节点对应了sql的哪一步。着重需要判断的就是产生分支的那个节点

Sort(
    orderBy=[tenant_id ASC, room_id ASC, msg_start_time ASC]
) -> 
Calc(
    select=[__etl_time__, date_id, tenant_id, brand_id, channel, channel_app_id, channel_session_type, msg_id, msg_start_time, msg_end_time, msg_from_id, msg_from_orig_id, 
        msg_from_nk, msg_from_role, msg_to_ids, msg_to_users, msg_type, msg_content, msg_detail, group_chat_info, dialogue_id, room_id, operation_flags, recording_properties, 
        asr_properties, metric_properties, tags, tag_properties, dialogue_properties, lastMsgEndTime, nextMsgStartTime, is_cut_by_msg_time, is_fit_specific_event, pre_is_fit_specific_event, fit_specific_row,
        CAST(FROM_UNIXTIME(w0$o0)) AS start_time,
        CAST(FROM_UNIXTIME(w0$o1)) AS end_time,
        CAST(w1$o0) AS fit_specific_rows,
        GenIsFitConsecutiveRowsAndTime(channel_session_type, tenant_id, CAST(w1$o0), CAST(CAST(FROM_UNIXTIME(w0$o0))), CAST(CAST(FROM_UNIXTIME(w0$o1))), is_fit_specific_event) AS is_fit_specific_flag,
        (is_cut_by_msg_time = _UTF-16LE'1':VARCHAR(2147483647) CHARACTER SET "UTF-16LE") AS $39, // 
        (GenIsFitConsecutiveRowsAndTime(channel_session_type, tenant_id, CAST(w1$o0), CAST(CAST(FROM_UNIXTIME(w0$o0))), CAST(CAST(FROM_UNIXTIME(w0$o1))), is_fit_specific_event) = 1) AS $40
    ]
) -> 
OverAggregate(
    partitionBy=[tenant_id, room_id],
    orderBy=[msg_start_time ASC],
    window#0=[
        LAG(is_fit_specific_flag) AS w0$o0
        RANG BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ],
    select=[__etl_time__, date_id, tenant_id, brand_id, channel, channel_app_id, channel_session_type, msg_id, msg_start_time, msg_end_time, msg_from_id, msg_from_orig_id, 
        msg_from_nk, msg_from_role, msg_to_ids, msg_to_users, msg_type, msg_content, msg_detail, group_chat_info, dialogue_id, room_id, operation_flags, recording_properties, 
        asr_properties, metric_properties, tags, tag_properties, dialogue_properties, lastMsgEndTime, nextMsgStartTime, is_cut_by_msg_time, is_fit_specific_event, pre_is_fit_specific_event, fit_specific_row,
        start_time, end_time, fit_specific_rows, is_fit_specific_flag, 
        $39,    // 是否按时间切 
        $40,    // 当前条是否为 1
        w0$o0 -> pre_is_fit_specific_flag // 前一条是否满足特殊规则
    ]
) -> (
    Calc(
        select=[date_id, tenant_id, channel_session_type, msg_id, msg_start_time, room_id, tags,
            IF(($39 OR (w0$o0 IS NULL AND $40) OR ((w0$o0 <> is_fit_specific_flag) IS TRUE AND w0$o0 IS NOT NULL)), 1, 0) AS is_cut_flag,
            CAST(tenant_id) AS $8,
            CAST(msg_start_time) AS $9,
            GenCutPointTypeByFeature(channel_session_type, tenant_id, tags) AS $10
        ]
    ) -> 
    OverAggregate(
        partitionBy=[tenant_id, room_id],
        orderBy=[msg_start_time ASC],
        window#0=[
            COUNT(is_cut_flag) AS w0$o0,
            $SUM0(is_cut_flag) AS w0$o1
            RANG BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        ],
        select=[date_id, tenant_id, channel_session_type, msg_id, msg_start_time, room_id, tags, is_cut_flag, 
            $8, -> tenant_id
            $9, -> msg_start_time
            $10, -> 特征切分点: START/END/NO
            w0$o0, -> count
            w0$o1 -> sum
        ]
    ) -> 
    Calc(
        select=[
            CONCAT_WS(_UTF-16LE'-', $8, room_id, date_id, CAST(CASE((w0$o0 > 0:BIGINT), w0$o1, null:INTEGER))) AS dialogue_id1,
            channel_session_type, tenant_id, msg_id, $9 AS $f4, tags, $10 AS cutPointType
        ]
    ), 
    #####################
    CREATE TEMPORARY VIEW keep_cutpoint_view AS
    SELECT dialogue_id1, smoothRes.smoothResultVoMap
    FROM (
            SELECT dialogue_id1,
                    smoothCutPoint(channel_session_type, tenant_id, dialogue_id1, msg_id, msg_start_time, tags, cutPointType) AS smoothRes
            FROM gen_cut_type_by_feature_view
            GROUP BY dialogue_id1
    );
    #####################
    
    Calc(
        select=[__etl_time__, date_id, tenant_id, brand_id, channel, channel_app_id, channel_session_type, msg_id, msg_start_time, msg_end_time, msg_from_id, msg_from_orig_id, 
            msg_from_nk, msg_from_role, msg_to_ids, msg_to_users, msg_type, msg_content, msg_detail, group_chat_info, dialogue_id, room_id, operation_flags, recording_properties, 
            asr_properties, metric_properties, tags, tag_properties, dialogue_properties, lastMsgEndTime, nextMsgStartTime, is_cut_by_msg_time, is_fit_specific_event, pre_is_fit_specific_event, 
            fit_specific_row, start_time, end_time, fit_specific_rows, is_fit_specific_flag, 
            w0$o0 AS pre_is_fit_specific_flag, 
            CASE(w0$o0 IS NULL, is_fit_specific_flag, (w0$o0 <> is_fit_specific_flag), 1, 0) AS is_cut_by_specific, 
            IF(($39 OR (w0$o0 IS NULL AND $40) OR ((w0$o0 <> is_fit_specific_flag) IS TRUE AND w0$o0 IS NOT NULL)), 1, 0) AS is_cut_flag, 
            IF((IF(($39 OR (w0$o0 IS NULL AND $40) OR ((w0$o0 <> is_fit_specific_flag) IS TRUE AND w0$o0 IS NOT NULL)), 1, 0) = 1), _UTF-16LE'start', null:VARCHAR(2147483647) CHARACTER SET "UTF-16LE") AS $42,
            CAST(tenant_id) AS $43, 
            GenCutPointTypeByFeature(channel_session_type, tenant_id, tags) AS $44
        ]
    ) -> 
    OverAggregate(
        partitionBy=[tenant_id, room_id],
        orderBy=[msg_start_time ASC],
        window#0=[
            COUNT(is_cut_flag) AS w0$o0,
            $SUM0(is_cut_flag) AS w0$o1
            RANG BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        ], select=[__etl_time__, date_id, tenant_id, brand_id, channel, channel_app_id, channel_session_type, msg_id, msg_start_time, msg_end_time, msg_from_id, msg_from_orig_id, 
            msg_from_nk, msg_from_role, msg_to_ids, msg_to_users, msg_type, msg_content, msg_detail, group_chat_info, dialogue_id, room_id, operation_flags, recording_properties, 
            asr_properties, metric_properties, tags, tag_properties, dialogue_properties, lastMsgEndTime, nextMsgStartTime, is_cut_by_msg_time, is_fit_specific_event, pre_is_fit_specific_event, 
            fit_specific_row, start_time, end_time, fit_specific_rows, is_fit_specific_flag, pre_is_fit_specific_flag, is_cut_by_specific, is_cut_flag, 
            $42, -> cut_point_type
            $43, 
            $44, 
            w0$o0, 
            w0$o1
        ]
    ) -> 
    Calc(
        select=[date_id, tenant_id, brand_id, channel, channel_app_id, channel_session_type, msg_id, msg_start_time, msg_end_time, msg_from_id, msg_from_orig_id, msg_from_nk, 
            msg_from_role, msg_to_ids, msg_to_users, msg_type, msg_content, msg_detail, group_chat_info, room_id, operation_flags, recording_properties, asr_properties, metric_properties, tags, tag_properties, 
            dialogue_properties, 
            CONCAT_WS(_UTF-16LE'-', $43, room_id, date_id, CAST(CASE((w0$o0 > 0:BIGINT), w0$o1, null:INTEGER))) AS dialogue_id1, 
            $44 AS cutPointType
        ]
    )
)

######################
根据时间+特殊规则先生成一轮 dialogu_id1
特征的切分点命中被提前下推到这个阶段执行

BUG&优化点:
1. 平滑使用了 groupBy 再 join 会主表, 导致计算流走了分支, 导致部分计算逻辑重复执行了, 这一部分可以考虑用 over 聚合来做
  gen_fit_sprcific_flag_view -> gen_cut_flag_view -> gen_dialogue_id_by_cut_flag_view -> gen_cut_type_by_feature_view -> keep_cutpoint_view

2. CASE WHEN pre_is_fit_specific_flag IS NULL THEN is_fit_specific_flag
                    WHEN pre_is_fit_specific_flag <> is_fit_specific_flag THEN 1
                    WHEN pre_is_fit_specific_flag = is_fit_specific_flag THEN 0
                    ELSE 0
                   END AS is_cut_by_specific
    逻辑不对, 导致 GenIsFitConsecutiveRowsAndTime 被重复执行
3. IF(is_cut_flag = 1, 'start', CAST(NULL AS STRING)) AS cut_point_type, 需要判断一下是否还有必要

5. 
======================
Sort(
    orderBy=[dialogue_id1 ASC]
) -> 
SortAggregate(
    isMerge=[false], 
    groupBy=[dialogue_id1], 
    select=[dialogue_id1, 
        smoothCutPoint(channel_session_type, tenant_id, dialogue_id1, msg_id, $f4, tags, cutPointType) AS smoothRes
    ]
) -> 
Calc(
    select=[dialogue_id1, smoothRes.smoothResultVoMap AS smoothResultVoMap]
) -> (
    Correlate(
        invocation=[GetCutPointBySplit($cor7.smoothResultVoMap)],
        correlate=[table(GetCutPointBySplit($cor7.smoothResultVoMap))],
        select=[dialogue_id1,smoothResultVoMap,msgId,cutPointMap],
        rowType=[
            RecordType(
                VARCHAR(2147483647) dialogue_id1, 
                (VARCHAR(2147483647), (VARCHAR(2147483647), VARCHAR(2147483647)) MAP) MAP smoothResultVoMap,
                VARCHAR(2147483647) msgId,
                (VARCHAR(2147483647), VARCHAR(2147483647)) MAP cutPointMap
            )
        ], joinType=[INNER]
    ) -> 
    Calc(
        select=[dialogue_id1, msgId, ITEM(cutPointMap, _UTF-16LE'isKeep') AS isKeep]
    ),
    
    Correlate(
        invocation=[GetCutPointBySplit($cor9.smoothResultVoMap)],
        correlate=[table(GetCutPointBySplit($cor9.smoothResultVoMap))],
        select=[dialogue_id1,smoothResultVoMap,msgId,cutPointMap], 
        rowType=[
            RecordType(
                VARCHAR(2147483647) dialogue_id1, 
                (VARCHAR(2147483647), (VARCHAR(2147483647), VARCHAR(2147483647)) MAP) MAP smoothResultVoMap, 
                VARCHAR(2147483647) msgId, 
                (VARCHAR(2147483647), VARCHAR(2147483647)) MAP cutPointMap
            )
        ], joinType=[INNER]
    ) -> 
    Calc(
        select=[dialogue_id1, msgId, ITEM(cutPointMap, _UTF-16LE'isKeep') AS isKeep]
    ), 
    Correlate(
        invocation=[GetCutPointBySplit($cor8.smoothResultVoMap)], 
        correlate=[table(GetCutPointBySplit($cor8.smoothResultVoMap))], 
        select=[dialogue_id1,smoothResultVoMap,msgId,cutPointMap], 
        rowType=[
            RecordType(
                VARCHAR(2147483647) dialogue_id1, 
                (VARCHAR(2147483647), (VARCHAR(2147483647), VARCHAR(2147483647)) MAP) MAP smoothResultVoMap, 
                VARCHAR(2147483647) msgId, 
                (VARCHAR(2147483647), VARCHAR(2147483647)) MAP cutPointMap
            )
        ], joinType=[INNER]
    ) ->
    Calc(
        select=[dialogue_id1, msgId, ITEM(cutPointMap, _UTF-16LE'isKeep') AS isKeep]
    )
)

######################
计算平滑逻辑

优化点:
1. smoothCutPoint 很大的性能问题, 改成基于 over 聚合的 udaf, 优化掉 GROUPBY + LATERAL TABLE + JOIN

对应sql如下：

--根据配置文件特征数据对数据进行特征切分标记
CREATE TEMPORARY VIEW gen_cut_type_by_feature_view AS
SELECT *,
       GenCutPointTypeByFeature(channel_session_type, tenant_id, tags) AS cutPointType
FROM gen_dialogue_id_by_cut_flag_view;

CREATE TEMPORARY VIEW keep_cutpoint_view AS
SELECT dialogue_id1, smoothRes.smoothResultVoMap
FROM (
         SELECT dialogue_id1,
                smoothCutPoint(channel_session_type, tenant_id, dialogue_id1, msg_id, msg_start_time, tags, cutPointType) AS smoothRes
         FROM gen_cut_type_by_feature_view
         GROUP BY dialogue_id1
);


CREATE TEMPORARY VIEW keep_cutpoint_breakup AS
SELECT dialogue_id1, smoothResultVoMap, msgId, cutPointMap, cutPointMap['isKeep'] AS isKeep
FROM keep_cutpoint_view, LATERAL TABLE(GetCutPointBySplit(smoothResultVoMap)) AS T(msgId, cutPointMap);


CREATE TEMPORARY VIEW keep_cutpoint_join AS
SELECT t1.*,t2.isKeep, IF(t2.isKeep = '0', 'no', t1.cutPointType) AS curCutPointType, msg_start_time
FROM gen_cut_type_by_feature_view t1
LEFT JOIN keep_cutpoint_breakup t2 ON t1.dialogue_id1 = t2.dialogue_id1 AND t1.msg_id = t2.msgId;

CREATE TEMPORARY VIEW gen_dialogue_id_by_feature_view0 AS
SELECT
    date_id,
    tenant_id,
    brand_id,
    channel,
    channel_app_id,
    channel_session_type,
    msg_id,
    msg_start_time,
    msg_end_time,
    msg_from_id,
    msg_from_nk,
    msg_from_orig_id,
    msg_from_role,
    msg_to_ids,
    msg_to_users,
    msg_type,
    msg_content,
    msg_detail,
    group_chat_info,
    room_id,
    operation_flags,
    recording_properties,
    asr_properties,
    metric_properties,
    tags,
    tag_properties,
    dialogue_properties,
    dialogue_id1,
    cutPointType,
    curCutPointType,
    preCutPointType,
    isKeep,
    CONCAT_WS(
            '-',
            CAST(tenant_id AS STRING),
            room_id,
            date_id,
            CAST(
                    SUM(IF(preCutPointType IS NULL OR preCutPointType = 'end' OR curCutPointType = 'start', 1, 0)) OVER (PARTITION BY tenant_id, room_id, date_id ORDER BY msg_start_time)
                AS STRING)
        ) AS dialogue_id
FROM (
         SELECT
             date_id,
             tenant_id,
             brand_id,
             channel,
             channel_app_id,
             channel_session_type,
             msg_id,
             msg_start_time,
             msg_end_time,
             msg_from_id,
             msg_from_nk,
             msg_from_orig_id,
             msg_from_role,
             msg_to_ids,
             msg_to_users,
             msg_type,
             msg_content,
             msg_detail,
             group_chat_info,
             room_id,
             operation_flags,
             recording_properties,
             asr_properties,
             metric_properties,
             tags,
             tag_properties,
             dialogue_properties,
             dialogue_id1,
             cutPointType,
             curCutPointType,
             isKeep,
             LAG(curCutPointType) OVER ( PARTITION BY dialogue_id1 ORDER BY msg_start_time) AS preCutPointType
         FROM keep_cutpoint_join
     );

之前sql对于这个分段平滑逻辑的实现是，先根据idalogue_id group by数据，使用udaf去得到聚合结果，然后在通过msg_id将聚合结果join回原来的明细数据里，这种做法就会产生分岔，不仅性能差，而且会重复执行计算节点导致耗时上升。这种做法在后边的相关性聚合也是差不多的，这样一分析问题就找到了，就是要把聚合结果join回主表这种做法换一种更高效的方式实现，具体改进思路就是将原来这种方式改成基于 over 聚合的 udaf, 优化掉 GROUPBY + LATERAL TABLE + JOIN

优化之后的sql：

--根据配置文件特征数据对数据进行特征切分标记
CREATE TEMPORARY VIEW gen_cut_type_by_feature_view AS
SELECT *,
       GenCutPointTypeByFeature(channel_session_type, tenant_id, tags) AS cutPointType
FROM gen_dialogue_id_by_cut_flag_view;


CREATE TEMPORARY VIEW keep_cutpoint_view AS
SELECT *,
       smooth_result[msg_id]['is_keep'] AS isKeep,
       CASE WHEN smooth_result[msg_id]['is_keep'] = '0' THEN 'no' ELSE cutPointType END AS curCutPointType
FROM(
        SELECT *,
               smoothCutPoint(channel_session_type, tenant_id, dialogue_id1, msg_id, msg_start_time, tags, cutPointType) OVER ( PARTITION BY dialogue_id1) AS smooth_result
        FROM gen_cut_type_by_feature_view
    );

CREATE TEMPORARY VIEW gen_dialogue_id_by_feature_view0 AS
SELECT
    date_id,
    tenant_id,
    brand_id,
    channel,
    channel_app_id,
    channel_session_type,
    msg_id,
    msg_start_time,
    msg_end_time,
    msg_from_id,
    msg_from_nk,
    msg_from_orig_id,
    msg_from_role,
    msg_to_ids,
    msg_to_users,
    msg_type,
    msg_content,
    msg_detail,
    group_chat_info,
    room_id,
    operation_flags,
    recording_properties,
    asr_properties,
    metric_properties,
    tags,
    tag_properties,
    dialogue_properties,
    CONCAT_WS(
            '-',
            CAST(tenant_id AS STRING),
            room_id,
            date_id,
            CAST(
                    SUM( CASE WHEN dialogue_id1 <> preDialogueId OR preCutPointType IS NULL OR preCutPointType = 'end' OR curCutPointType = 'start' THEN 1 ELSE 0 END) OVER (PARTITION BY tenant_id, room_id, date_id ORDER BY msg_start_time)
                AS STRING)
        ) AS dialogue_id
FROM (
         SELECT
             date_id,
             tenant_id,
             brand_id,
             channel,
             channel_app_id,
             channel_session_type,
             msg_id,
             msg_start_time,
             msg_end_time,
             msg_from_id,
             msg_from_nk,
             msg_from_orig_id,
             msg_from_role,
             msg_to_ids,
             msg_to_users,
             msg_type,
             msg_content,
             msg_detail,
             group_chat_info,
             room_id,
             operation_flags,
             recording_properties,
             asr_properties,
             metric_properties,
             tags,
             tag_properties,
             dialogue_properties,
             dialogue_id1,
             cutPointType,
             curCutPointType,
             LAG(dialogue_id1) OVER ( PARTITION BY tenant_id, room_id, date_id ORDER BY msg_start_time) AS preDialogueId,
             LAG(curCutPointType) OVER ( PARTITION BY tenant_id, room_id, date_id ORDER BY msg_start_time) AS preCutPointType
         FROM keep_cutpoint_view
     );

相关性的优化也是一样的思路，改成基于 over 聚合的 udaf，减少聚合结果join回原表的这种操作

相关性sql对比：

CREATE TEMPORARY VIEW dialogue_relevant_view AS
SELECT
    `tenant_id`,
    `brand_id`,
    `channel`,
    `channel_app_id`,
    `channel_session_type`,
    `date_id`,
    dialogue_id as dialogue_id,
    res.relevant_config_version as relevant_config_version ,
    res.relevant_config as relevant_config ,
    res.metrics as metrics ,
    res.dialogue_relevant as dialogue_relevant
FROM (select dialogue_relevant_udaf(channel_session_type, tenant_id, msg_id, msg_start_time, msg_end_time, msg_from_role,tags) as res,
             `tenant_id`,
             `brand_id`,
             `channel`,
             `channel_app_id`,
             `channel_session_type`,
             `date_id`,`dialogue_id`
      from gen_dialogue_id_by_feature_view
      group by `tenant_id`,
               `brand_id`,
               `channel`,
               `channel_app_id`,
               `channel_session_type`,
               `date_id`,`dialogue_id`);

CREATE TEMPORARY VIEW dialogue_view_all AS
select
    NOW() as `__etl_time__`,
    a.date_id,
    a.tenant_id,
    a.brand_id,
    a.channel,
    a.channel_app_id,
    a.channel_session_type,
    a.msg_id,
    a.msg_start_time,
    a.msg_end_time,
    a.msg_from_id,
    a.msg_from_nk,
    a.msg_from_orig_id,
    a.msg_from_role,
    a.msg_to_ids,
    a.msg_to_users,
    a.msg_type,
    a.msg_content,
    a.msg_detail,
    a.group_chat_info,
    a.room_id,
    a.operation_flags,
    a.recording_properties,
    a.asr_properties,
    a.metric_properties,
    a.tags,
    a.tag_properties,
    map_put(map_put(a.dialogue_properties , 'dialogue_relevant' , b.dialogue_relevant),'relevant_config',b.relevant_config)  as dialogue_properties,
    a.dialogue_id1,
    a.cutPointType,
    a.curCutPointType,
    a.preCutPointType,
    a.isKeep,
    a.dialogue_id
from  gen_dialogue_id_by_feature_view  a
          left join dialogue_relevant_view b
                    on  a.tenant_id = b.tenant_id and
                        a.brand_id = b.brand_id and
                        a.channel = b.channel and
                        a.channel_app_id = b.channel_app_id and
                        a.channel_session_type = b.channel_session_type and
                        a.dialogue_id = b.dialogue_id;
                        
#####################################

CREATE TEMPORARY VIEW dialogue_view AS
select
    date_id,
    tenant_id,
    brand_id,
    channel,
    channel_app_id,
    channel_session_type,
    msg_id,
    msg_start_time,
    msg_end_time,
    msg_from_id,
    msg_from_nk,
    msg_from_orig_id,
    msg_from_role,
    msg_to_ids,
    msg_to_users,
    msg_type,
    msg_content,
    msg_detail,
    group_chat_info,
    room_id,
    operation_flags,
    recording_properties,
    asr_properties,
    metric_properties,
    tags,
    tag_properties,
    dialogue_properties,
    dialogue_id,
    dialogue_relevant_udaf(channel_session_type, tenant_id, msg_id, msg_start_time, msg_end_time, msg_from_role,tags) OVER (PARTITION BY `tenant_id`,
               `brand_id`,
               `channel`,
               `channel_app_id`,
               `channel_session_type`,
               `date_id`,`dialogue_id`) AS res
from gen_dialogue_id_by_feature_view ;
3.优化结果

优化之后的执行计划清爽很多，执行速度也有了明显提升，从原来的将近40分钟的计算时长，减少到7分钟，提升巨大

在这里插入图片描述

逐风正在敲代码
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Flink任务运行的详细步骤：从入门到精通
u013558123的博客
03-29 840
Flink 是一个高性能的流处理框架，适用于各种实时数据处理场景。通过本文的介绍，您应该已经了解了 Flink 任务运行的详细步骤。在实际应用中，Flink 可以帮助您更好地管理实时数据，提高数据处理能力和效率。无论您是数据处理的新手还是有一定经验的开发者，都应该掌握 Flink 的使用，以便在项目中发挥其强大的功能。希望本文的内容能对您有所帮助，让您的数据处理之路更加顺畅！
Flink任务调度和执行流程
yangzhihua的专栏
06-18 938
第一阶段是全局调度，由ResourceManager负责，它根据资源的可用情况和当前Job的特点，将Job分配给不同的TaskManager，同时还需要考虑Task之间的数据依赖关系。第二阶段是局部调度，由TaskManager负责，它会在自己的本地资源中，将不同的子Task分配到不同的线程上执行。通过对Flink的任务调度和执行流程的详细分析，我们可以更好地了解Flink在实时数据处理中的运行机制，对于吸收和应用Flink技术都有一定的指导意义。本文将详细分析Flink的任务调度和执行流程。
Flink作业任务部署解读
阿甘兄
08-14 1924
Flink作业任务部署有几种模式，分别为：Application 模式、Per-Job 模式、Session模式。无论何种模式，都是提交到JobManager的，JobManager会把作业分发到不同的TaskManager，TaskManager为实际的工作者。对于JobManager及TaskManager，又可以部署到不同的资源管理器中，如：Standlone 独立集群、Yarn 资源管理器 、K8S 集群（本质也是资源管理器）。......
Flink原理——任务调度原理
静远小和尚的博客
08-06 2686
原文链接：https://mp.toutiao.com/profile_v4/graphic/preview?pgc_id=6857894528381092364 本文主要从以下几个方面介绍Flink的任务调度原理 一、Flink运行时的组件 二、TaskManger与Slots 三、程序与数据流 四、Flink的执行图 五、Flink程序执行的并行度 六、Flink程序任务链 一、Flink运行时的组件 Flink的运行组件 Flink 运行时架构主要包括四个不同的组件，它们会在运
flink学习（四）——flink任务执行原理详解
Yohohaha的博客
12-19 3164
在前文中我们学习了flink的整体架构和任务提交执行的流程。现在我们来学习flink在内部具体如何执行任务。 任务执行图 在flink中有四层执行图，StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图，如图所示： StreamGraph：是根据用户通过 Stream API 编写的代码生成的最初的图，用来表示程序的拓扑结构。每个转换操作会生成一个StreamNode，两个StreamNodes之间由StreamEdge连接在一起，Str
初识Flink.pdf
06-03
首先，Flink的处理速度非常快，能够以极高的速度处理数据密集型和迭代任务，这得益于其基于内存的数据流处理能力和深度集成的迭代处理算法。其次，Flink的可靠性与可扩展性非常强，拥有自己的内存管理组件、序列化...
flink 开发实例和资料
07-26
压缩包中的“课件文档”可能包含了 Flink 的教程、案例分析和实践指南，这些资源可以帮助你深入理解 Flink 的核心概念，学习如何编写 Flink 作业，以及如何优化 Flink 应用的性能。通常，这些文档会涵盖以下内容： ...
Apache Flink运维和实战
03-20
总的来说，本专题深入浅出地介绍了Apache Flink在运维和实战中的关键技术和实践案例，为开发者提供了全面的指导，无论是在K8s上的部署优化，还是在实际业务场景中的问题解决，都提供了宝贵的知识和经验分享。...
FlinkSQL编程.pdf
07-17
此外，Flink也具备容错机制，能够处理任务失败和节点故障等情况，保证整个系统的稳定性。Flink还支持精确一次(exactly-once)的状态一致性保证，这意味着即使在发生故障的情况下，数据也不会丢失或重复处理。 由于...
Flink Forward 2018.zip
05-22
5. **性能优化**：分享如何针对特定业务场景优化Flink作业，提高处理效率和资源利用率。 6. **故障恢复与容错**：探讨Flink的检查点和保存点机制，以及如何应对集群故障和数据丢失。 7. **机器学习与流式分析**：...
flink sql设置并行度_Flink原理——任务调度原理
weixin_39731922的博客
11-30 927
本文主要从以下几个方面介绍Flink的任务调度原理一、Flink运行时的组件二、TaskManger与Slots三、程序与数据流四、Flink的执行图五、Flink程序执行的并行度六、Flink程序任务链一、Flink运行时的组件Flink的运行组件Flink 运行时架构主要包括四个不同的组件，它们会在运行流处理应用程序时协同工作：作业管理器(JobManager)、资源管理器(ResourceM...
【Flink】详解Flink任务提交流程
pcx171的博客
07-18 1425
本文主要介绍Flink的任务提交流程，从源码入手分析Flink如何解析命令行、提取验证有效参数、环境配置参数、程序和用户指定参数如何打包、依赖路径如何获取、客户端模式如何确定以及最后程序的主入口是哪一个
flink 任务提交流程源码解析
Direction_Wind的博客
02-20 1294
flink cliFronted类， 解析参数，封装commandLine， 执行用户代码生成streamGraph 并将streamGraph转化成JobGraphyarnjobClusterExcutor 初始化一个yarnclient对象,构造yarnClusterDescriptoryarnClusterDescriptor 将 依赖,jar，及其集群配置上传到Yarn Resource manager上yarn检查集群配置。
大数据学习之Flink环境搭建+提交任务方式
y_wang_的博客
08-03 2319
Flink环境搭建与任务提交详解
Flink任务实战优化
weixin_42049123的博客
01-05 3937
一个好产品，功能应该尽量包装在服务内部；对于Flink而言，无疑是做到了这一点。但是用户在使用Flink的时候，依然可以从版本的选择、代码逻辑、资源参数、业务的数据情况等方面做任务级的定制化优化；用最合理的资源使用，保障实时性、稳定性和最佳Tps的处理能力
Flink中任务（Tasks）和任务槽（Task Slots）详解
最新发布
pp1981002445的博客
03-19 1159
在之前不做共享的时候，每个任务都平等地占据了一个slot，但其实不同的任务对资源的占用是不同的。所以对于第一个任务节点source→map，它的6个并行子任务必须分到不同的slot上（如果在同一slot就没法数据并行了），而第二个任务节点keyBy/window/apply的并行子任务却可以和第一个任务节点共享slot。另外，同一个任务节点的并行子任务是不能共享slot的，所以允许slot共享之后，运行作业所需的slot数量正好就是作业中所有算子并行度的最大值。而不同的任务节点的子任务可以共享slot。
【Flink】Flink 任务实时监控
九师兄
01-13 6601
1.概述 转载：Flink 任务实时监控最佳实践 我们都知道 Flink 任务是一个 7*24 小时不停运行的任务,所以对于任务的实时监控就显得尤为重要,因为任务运行的状态对于我们来说是一个黑盒,比如任务是否挂掉,是否存在反压,使用的内存,CPU 等情况我们是不知道的,虽然 Flink 的 UI 上面可以添加相关的 metrics 来查看,但是需要手动的一个一个添加,还是比较麻烦的,特别是在任务非常多的情况下.所以就需要有一种统一的监控方案来解决这个问题.Flink 本身提供了非常丰富的 Metric Re
八种Flink任务监控告警方式
weixin_42049123的博客
01-28 3819
Flink任务告警方式的选择，要从任务的使用情况和期盼来考量；简单的使用，且任务少，可以用监控目标数据库的数据写入情况、per-job和application运行任务探活、Sesion运行方式通过RestApi来告警；特定场景的业务可以靠监控存储中间偏移量来告警；通用大规模应用场景可以通过采集运行时日志、使用调度平台，使用调度平台、引入开源SDK方式、自定义SDK写入通用系统通用系统里方式选择。
Flink提交任务
别人笑我太疯癫，我笑他人看不穿。
11-03 5068
Flink提交任务的方式有两种，第一种是自带的UI页面，但是这种提交方式很少有团队正式使用，因为这种方式的资源分配是按照task节点为单位运行并度的，一个并行度就要占用一个task节点，国内九成九的都是普通公司，不是大厂，根本用不起，这也是flink很少在国内使用的原因。第二种提交方式就是命令行模式，这种方式下就和UI提交是同源的，也可以提交给yarn。说白了就是国内使用flink时，也只是提交给了yarn，很少有公司有那个经济实力，直接把任务交给flink自身的jobmanager。
Flink 1.13 State Backend 优化与生产实践
"State backend Flink-1.13优化及生产实践分享.pdf" Apache Flink 是一个流行的开源流处理框架，其在版本1.13中对State backend进行了多项优化和改进，旨在提升性能和稳定性，同时更好地适应大规模生产环境的需求。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值