Apache Flink OLAP引擎性能优化及应用

标签: apache flink olap | 发表时间:2020-04-25 10:06 | 作者:DataFunTalk
出处:https://www.infoq.cn

导读:本次分享的主题为Apache Flink新场景——OLAP引擎,主要内容包括:

  • 背景介绍
  • Apache Flink OLAP引擎
  • 案例介绍
  • 未来计划

1. OLAP及其分类

OLAP是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。主流的OLAP可以分为3类:多维OLAP ( Multi-dimensional OLAP )、关系型OLAP ( Relational OLAP ) 和混合OLAP ( Hybrid OLAP ) 三大类。

多维OLAP ( MOLAP )

  • 传统的OLAP分析方式
  • 数据存储在多维数据集中

关系型OLAP ( ROLAP )

  • 以关系数据库为核心,以关系型结构进行多维数据的表示
  • 通过SQL的where条件以呈现传统OLAP的切片、切块功能

混合OLAP ( HOLAP )

  • 将MOLAP和ROLPA的优势结合起来,以获得更快的性能

接下来为大家详细介绍下:

① MOLAP

典型代表

MOLAP的典型代表是Kylin和Druid。

处理流程

  • 对原始数据做数据预处理
  • 预处理后的数据存至数据仓库
  • 用户的请求通过OLAP server查询数据仓库中的数据

MOLAP的优点和缺点

MOLAP的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。数据预处理,将原始数据按照指定的计算规则预先做聚合计算,这样避免了查询过程中出现大量的临时计算,提升了查询性能,同时也为很多复杂的计算提供了支持。

但是这样的预聚合处理,需要预先定义维度,会限制后期数据查询的灵活性;如果查询工作涉及新的指标,需要重新增加预处理流程,损失了灵活度,存储成本也很高;同时,这种方式不支持明细数据的查询。

因此,MOLAP适用于对性能非常高的场景。

② ROLAP

典型代表

ROLAP的典型代表是Presto和Impala。

处理流程

  • 用户的请求直接发送给OLAP server
  • OLAP serve将用户的请求转换成关系型操作算子:
    1. 通过SCAN扫描原始数据
    2. 在原始数据基础上做过滤、聚合、关联等处理
  • 将计算结果返回给用户

ROLAP的优点和缺点

ROLAP不需要进行数据预处理 ( pre-processing ),因此查询灵活,可扩展性好。这类引擎使用MPP架构 ( 与Hadoop相似的大型并行处理架构,可以通过扩大并发来增加计算资源 ),可以高效处理大量数据。但是当数据量较大或query较为复杂时,查询性能也无法像MOLAP那样稳定。所有计算都是临时发生 ( 没有预处理 ),因此会耗费更多的计算资源。

因此,ROLAP适用于对查询灵活性高的场景。

③ HOLAP

混合OLAP,是MOLAP和ROLAP的一种融合。当查询聚合性数据的时候,使用MOLAP技术;当查询明细数据时,使用ROLAP技术。在给定使用场景的前提下,以达到查询性能的最优化。

2. Apache Flink介绍

① 当前Apache Flink支持的应用场景

Apache Flink支持的3种典型应用场景:

  1. 事件驱动的应用
  • 反欺诈
  • 基于规则的监控报警
  1. 流式Pipeline
  • 数据ETL
  • 实时搜索引擎的索引
  1. 批处理&流处理分析
  • 网络质量监控
  • 消费者实时数据分析

② Apache Flink 架构

③ Apache Flink 优势

  1. 统一框架 ( 不区分流处理和批处理 )
  • 用户API统一
  • 执行引擎统一
  1. 多层次API
  • 标准SQL APL
  • Table API
  • DataStream API ( 灵活,无schema限制 )
  1. 高性能
  • 支持内存计算
  • 支持代价模型优化
  • 支持代码动态生成
  1. 方便集成
  • 支持丰富的Connectors
  • 方便对接现有catalog
  1. 灵活的Failover策略
  • 在Pipeline下支持快速failover
  • 类似MapReduce、Spark一样支持shuffle数据落盘
  1. 易部署维护
  • 灵活部署方案
  • 支持高可用

1. Apache Flink OLAP引擎

① 为什么Apache Flink 可以做ROLAP引擎?

  • Flink的核心和基础是流计算,支持高性能、低延迟的大规模计算
  • Blink将批看作有限流,批处理是针对有限数据集的优化,因此批处理引擎也是构建在流引擎上 ( 已开源 )
  • OLAP是响应时间要求更短的批处理,因此OLAP可以看作是一种特殊的批。OLAP引擎也可以构建在现有的批引擎上

注:Flink OLAP引擎目前不带存储,只是一个计算框架

② Apache Flink 做OLAP引擎的优势

统一引擎:流处理、批处理、OLAP统一使用Flink引擎

  • 降低学习成本,仅需要学习一个引擎
  • 提高开发效率,很多SQL是流批通用
  • 提高维护效率,可以更集中维护好一个引擎

既有优势:利用Flink已有的很多特性,使OLAP使用场景更为广泛

  • 使用流处理的内存计算、Pipeline
  • 支持代码动态生成
  • 也可以支持批处理数据落盘能力

相互增强:OLAP能享有现有引擎的优势,同时也能增强引擎能力

  • 无统计信息场景的优化
  • 开发更高效的算子
  • 使Flink同时兼备流、批、OLAP处理的能力,成为更通用的框架

2. 性能优化

OLAP 对查询时间非常敏感,当前很多组件的性能不满足要求,因此我们对Flink做了很多相关优化。

① 服务架构的优化

客户端服务化

下图介绍了一条SQL怎么在客户端一步一步变为JobGraph,最终提交给JM:

在改动之前,每次接受一个query时会启动一个新的JVM进程来进行作业的编译。其中JVM的启动、Class的加载、代码的动态编译 ( 如Optimizer模块由于需要通过Janino动态编译进行cost计算 ) 等操作都非常耗时 ( 需要约3~5s )。因此,我们将客户端进行服务化,将整个Client做成Service,当接收到用户的query时,无需重复各项加载工作,可将延时降低至100ms 左右。

自定义CollectionTableSink

这部分优化,源于OLAP的一个特性:OLAP会将最终计算结果发给客户端,通过JobManager转发给Client。假如某个query的结果数据量很大,会让JobManager OOM ( OutOfMemory );如果同时执行多个query,也会相互影响。因此,我们从新实现了一个CollectionTableSink,限制数据的条数和数据大小,避免出现OOM,保证多个Query同时运行时的稳定性。

调度优化

在Batch模式下的调度存在以下问题:

  • 使用Lazy_from_sources模式调度,会导致整体运行时间较长,也可能造成死锁。

    注:调度死锁是指在资源有限的情况下,多个Job同时运行时,如果多个Job都只申请到了部分资源并没有剩余资源可以申请,导致Job没法继续执行,新的Job也没法提交

  • RM ( Resource Manager ) 按OnDemand方式分配Slot需求,也会造成死锁

  • RM以单线程同步模式向TM ( Transaction Manager ) 分配Slot请求,会造成等待时间更长。

针对上述问题,我们提出了以下几点改动:

  • 采用Eager调度模式 ( 确保所有的资源都申请到后才开始运行 )
  • 使用FIFO ( 先进先出队 ) 模式申请资源 ( 确保当前Job的资源分配结束后才开始下一个Job的资源分配 )
  • 将单线程同步模式改为多线程异步模式,减少任务启动时间和执行时间

② 针对source的优化

在ROLAP的执行场景中,所有数据都是通过扫描原始数据表后进行处理;因此,基于Source的读取性能非常关键,直接影响Job的执行效率。

Project&Filter下堆

像Parquet这类的列存文件格式,支持按需读取相所需列,同时支持RowGroup级别的过滤。利用该特性,可以将Project和Filter下推到TableSource,从而只需要扫描Query中涉及的字段和满足条件的RowGroup,大大提升读取效率。

Aggregate下堆

这个优化也是充分利用了TableSource的特性:例如Parquet文件的metadata中已经存储了每个RowGroup的统计信息 ( 如 max、min等 ),因此在做max、min这类聚合统计时,可直接读取metadata信息,而不需要先读取所有原始数据再计算。

③ 在没有统计信息场景下做的优化

消除CrossJoin

CrossJoin是没有任何Join条件,将Join的两张表的数据做笛卡尔积,导致Join的结果膨胀非常厉害,这类Join应该尽量避免。我们对含有CrossJoin的Plan进行改写:将有join条件的表格先做join ( 通常会因为一些数据Join不上而减少数据 ),从而提高执行效率。这是一个确定性的改写,即使在没有统计信息的情况下,也可以使用该优化。

自适应的Local Aggregate

通常情况下,两阶段的Aggregate是非常高效的,因为LocalAggregate能聚合大量数据,导致Shuffle的数据量会变少。但是当LocalAggregate的聚合度很低的时候, Local聚合操作的意义不大,反而会浪费CPU。在没有任何统计信息的情况下,优化器没法决定是否要产生LocalAggregate算子;因此,我们采用运行时采样的方式来判断聚合度,如果聚合度低于设定的阈值,我们将关闭聚合操作,改为仅做数据转发;经我们测试,部分场景有30% 的性能提升。

3. 测试结果

上图是Flink和Presto基于1T数据做的SSB ( Star Schema Benchmark ) 测试,从图中可以看出 Flink和Presto整体上不相上下,甚至有些Query Flink性能优于Presto。注:Flink OLAP从开始到嘉宾分享时,只有3个月时间。

1. Apache Flink OLAP在数据探查上的应用

上图描述了一个数据湖应用的完整架构,Flink OLAP主要用于"数据探查"。数据探查是对数据结构做智能判断,给出数据的探查结果,快速了解数据的信息和质量情况。即用户可以在管控平台上了解数据湖中任意一份数据的数据特性。用户通过Web交互操作选择相应的表和指标后立即展示相关结果指标,因此要求低延迟、实时反馈。而且数据湖中很多数据没有任何统计信息;前述的各种查询、聚合层面的优化,主要为这类场景服务。

2. 整体架构

上图是这类应用的整体架构。整套服务托管到Kubernetes上,最终访问的数据是OSS;目前这套架构正在阿里云上做公测,邀请广大用户试用。

  • 推回社区:目前所有工作都是基于内部Flink,希望推回社区;
  • 资源隔离:后期很多功能的开发和优化会围绕多Query运行时的"资源隔离";
  • 优化&性能:围绕OLAP的特性,在此场景下会进一步做优化和性能提升等方面的工作。

本次的分享就到这里,谢谢大家。

本文来自 DataFunTalk

原文链接

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247499058&idx=1&sn=219bf1398dcd8bc92ee83f1ca7049a31&chksm=fbd74f5ecca0c64880f93c34352659ba354e7a356ca588f8ac61d71a2fef76942de8b49fd256&scene=27#wechat_redirect

相关 [apache flink olap] 推荐:

Apache Flink OLAP引擎性能优化及应用

- - InfoQ推荐
导读:本次分享的主题为Apache Flink新场景——OLAP引擎,主要内容包括:. Apache Flink OLAP引擎. OLAP是一种让用户可以用从不同视角方便快捷的分析数据的计算方法. 主流的OLAP可以分为3类:多维OLAP ( Multi-dimensional OLAP )、关系型OLAP ( Relational OLAP ) 和混合OLAP ( Hybrid OLAP ) 三大类.

Apache Flink:特性、概念、组件栈、架构及原理分析

- - 简单之美
Apache Flink是一个面向分布式数据流处理和批量数据处理的开源计算平台,它能够基于同一个Flink运行时(Flink Runtime),提供支持流处理和批处理两种类型应用的功能. 现有的开源计算方案,会把流处理和批处理作为两种不同的应用类型,因为他们它们所提供的SLA是完全不相同的:流处理一般需要支持低延迟、Exactly-once保证,而批处理需要支持高吞吐、高效处理,所以在实现的时候通常是分别给出两套实现方法,或者通过一个独立的开源框架来实现其中每一种处理方案.

分布式大数据多维分析(OLAP)引擎:Apache Kylin 在百度地图的实践

- - leejun2005的个人页面
百度地图开放平台业务部数据智能组主要负责百度地图内部相关业务的大数据计算分析,处理日常百亿级规模数据,为不同业务提供单条SQL毫秒级响应的OLAP多维分析查询服务. 对于Apache Kylin在实际生产环境中的应用,在国内,百度地图数据智能组是最早的一批实践者之一. Apache Kylin在2014年11月开源,当时,我们团队正需要搭建一套完整的大数据OLAP分析计算平台,用来提供百亿行级数据单条SQL毫秒到秒级的多维分析查询服务,在技术选型过程中,我们参考了Apache Drill、Presto、Impala、Spark SQL、Apache Kylin等.

flink-watermark

- - ITeye博客
     当我们统计用户点击的时候,有时候会因为各种情况数据延迟,我们需要一个允许最大的延迟范围进行统计.        模拟初始数据:早上10:00 11.10 用户点击了一次,但是延迟到10:00 11.15 才发送过来,允许最大延迟5秒, 5秒窗口统计. /** 实际时间-偏移量 偏移后的时间*/.

多维分析OLAP引擎Mondrian学习

- - Web前端 - ITeye博客
随着信息技术的飞速发展,在电力、电信、金融、大型制造等各个行业ERP、CRM、SCM、OA等越来越多的IT系统得以成功实施,这些分散建设的IT系统为各部门的运营效率提升发挥了很大的作用. 同时,为了满足业务管理和决策的报表系统(包括传统报表、数据仓库、OLAP等)也被创建出来,企业主管通过报表了解企业的总体运行状态.

开源OLAP引擎综评:HAWQ、Presto、ClickHouse

- - InfoQ推荐
谈到大数据就会联想到Hadoop、Spark整个生态的技术栈. 大家都知道开源大数据组件种类众多,其中开源OLAP引擎包含Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin等. 当前企业对大数据的研究与应用日趋理性,那么,如何根据业务特点,选择一个适合自身场景的查询引擎呢.

一文精通 Flink on YARN

- - IT瘾-dev
本文主要是讲解flink on yarn的部署过程,然后yarn-session的基本原理,如何启动多个yarn-session的话如何部署应用到指定的yarn-session上,然后是用户jar的管理配置及故障恢复相关的参数. flink on yarn的整个交互过程图,如下:. 要使得flink运行于yarn上,flink要能找到hadoop配置,因为要连接到yarn的resourcemanager和hdfs.

Flink SQL 编程实践

- - Jark's Blog
注: 本教程实践基于 Ververica 开源的. sql-training 项目. 基于 Flink 1.7.2. 本文将通过五个实例来贯穿 Flink SQL 的编程实践,主要会涵盖以下几个方面的内容. 如何使用 SQL CLI 客户端. 如何在流上运行 SQL 查询. 运行 window aggregate 与 non-window aggregate,理解其区别.

谈谈 Flink Shuffle 演进

- - 时间与精神的小屋
在分布式计算中,Shuffle 是非常关键但常常容易被忽视的一环. 比如著名的 MapReduce 的命名跳过 Shuffle ,只包含其前后的 Map 跟 Reduce. 背后原因一方面是 Shuffle 是底层框架在做的事情,用户基本不会感知到其存在,另一方面是 Shuffle 听起来似乎是比较边缘的基础服务.

Flink 1.16:Hive SQL 如何平迁到 Flink SQL

- - Jark's Blog
Hive SQL 迁移的动机. Flink 已经是流计算的事实标准,当前国内外做实时计算或流计算一般都会选择 Flink 和 Flink SQL. 另外,Flink 也是是家喻户晓的流批一体大数据计算引擎. 然而,目前 Flink 也面临着挑战. 比如虽然现在大规模应用都以流计算为主,但 Flink 批计算的应用并不广泛,想要进一步推动真正意义上的流批一体落地,需要推动业界更多地落地 Flink 批计算,需要更积极地拥抱现有的离线生态.