关于数据库:大数据处理黑科技揭秘PB级数仓GaussDBDWS-并行计算技术

47次阅读

共计 3939 个字符,预计需要花费 10 分钟才能阅读完成。

摘要: 通过这篇文章,咱们理解了 GaussDB(DWS) 并行计算技术的原理以及调优策略。心愿宽广开发者敌人们可能在实践中尝试该技术,更好地进行性能优化。

随着硬件零碎的越来越好,数据库运行的 CPU、磁盘、内存资源都日渐增大,SQL 语句的串行执行因为不能充分利用资源,曾经不能满足日益倒退的须要。为此,GaussDB(DWS) 开发了并行计算技术,在语句执行时能够充分利用硬件资源进行并行减速,进步执行的吞吐率。本文将具体介绍 GaussDB(DWS) 并行计算技术的原理,以及其在 performance 信息中的展现,帮忙各位开发者敌人更好地剖析并行的性能,从而进行并行执行方面的调优。

并行计算的原理很简略,将本来一个线程的工作平均分配到多个线程来实现,示意图如下图所示:图示中的关联操作,本来须要操作四份数据,通过并行度为 4 的并行计算后,每个子线程仅须要解决一份数据,实践上性能晋升能够达到 4 倍。

通常状况下,实践上的性能晋升是达不到的,因为并行计算也有其性能损耗,包含:启动线程的代价,以及线程之间进行数据传输的代价。因而,只能性能损耗较低,大大低于并行带来的收益时,并行计算的收益才比拟显著。所以,并行只有在数据量较大的场景下能力取得较高的性能收益,非常适合于剖析型的 AP 场景。

通过上述剖析,咱们能够看出,并行计算的难点不在于如何并行,而在于如何正确抉择并行度。当数据量较小时,兴许串行的性能是最好的,当数据量增大时,能够思考进行并行。对于一个简单的执行打算来说,可能蕴含多个算子,每个算子解决的数据量都不一样,如何综合思考并行度,以及解决好各算子之间的数据收发关系,将成为并行计算技术的要害难点。

GaussDB(DWS) 基于代价估算,依据表的数据量信息来为打算片段生成适合的并行度,上面以 TPC-DS Q48 为例来看一下,GaussDB(DWS) 的并行打算长什么样?

select sum (ss_quantity)
 from   store_sales, store, customer_demographics, customer_address, date_dim
 where s_store_sk = ss_store_sk
 and    ss_sold_date_sk = d_date_sk and d_year = 1998
 and 
 (
  (
     cd_demo_sk = ss_cdemo_sk
     and
     cd_marital_status = 'M'
     and
     cd_education_status = '4 yr Degree'
     and
     ss_sales_price between 100.00 and 150.00 
     )
 or
  (
    cd_demo_sk = ss_cdemo_sk
     and
     cd_marital_status = 'D'
     and
     cd_education_status = 'Primary'
     and
     ss_sales_price between 50.00 and 100.00  
  )
 or  
 (
    cd_demo_sk = ss_cdemo_sk
    and
     cd_marital_status = 'U'
     and
     cd_education_status = 'Advanced Degree'
     and
     ss_sales_price between 150.00 and 200.00 
 )
 )
 and
 (
  (
    ss_addr_sk = ca_address_sk
    and
    ca_country = 'United States'
    and
    ca_state in ('KY', 'GA', 'NM')
    and ss_net_profit between 0 and 2000   
  )
 or
    (ss_addr_sk = ca_address_sk
    and
    ca_country = 'United States'
    and
    ca_state in ('MT', 'OR', 'IN')
    and ss_net_profit between 150 and 3000
  )
 or
    (ss_addr_sk = ca_address_sk
    and
    ca_country = 'United States'
    and
    ca_state in ('WI', 'MO', 'WV')
    and ss_net_profit between 50 and 25000
  )
 )
;

对应的 performance 信息为:

通过将 performance 信息转变为打算树,能够失去该打算的打算树如下图所示:其中 1 - 3 号算子在 CN 上执行,DN 上以跨线程数据传输的 Stream 算子进行分隔,一共会启动 5 个线程。GaussDB(DWS) 采纳 pipeline 的迭代执行模式,线程 4 和 5 从磁盘读取数据,其它每个 Stream 算子分隔的线程从子线程读取数据,进行执行,并将后果返回给下层算子,顶层 DN 线程将数据返回给 CN 解决。通过这个图,咱们能够看出,线程 1,4,5 采纳的并行度是 1,而线程 2,3 采纳的并行度是 26。通过打算信息,咱们能够看出,8-13 号算子解决的数据量较大,刚好是线程 2,3 解决的范畴,所以抉择了较高的并行度。

并行计算的 Stream 线程依然沿用 DN 间的 Stream 线程进行启动和进行,但 DN 外部的数据传输改为内存拷贝进行,更节俭网络资源,但带来肯定水平的内存开销。同时,并行度的增大也使得跨 DN 间数据传输的数据缓冲区增大,内存开销变大。因而,大内存也是进步并行度的一个必备因素。那么线程之间是如何进行并行度的连接呢?

通过打算,咱们能够看出,并行场景下,Stream 线程均显示为:Streaming(type: T dop:N/M),这是在串行场景根底上的扩大,同时也能够以线程为级别看到每个线程执行工夫,解决的行数和应用的内存。在串行场景下,咱们反对三种类型的 Stream 算子,别离为 redistribute, broadcast 和 gather,具体介绍参见《GaussDB(DWS) 性能调优系列根底篇二:大道至简 explain 分布式打算》中第一章节介绍。

并行场景是对串行场景中 DN 上的 redistribute 和 broadcast 类型 Stream 算子进行裁减,包含以下几类:

1)Streaming(type: SPLIT REDISTRIBUTE):同串行场景下的 Redistribute,但以线程为单位进行数据传输,每条元组发送给一个目标线程。

2)Streaming(type: SPLIT BROADCAST):同串行场景下的 Broadcast,但以线程为单位进行数据传输,每个线程都将收到全量数据。

3)Streaming(type: LOCAL REDISTRIBUTE):作用是 DN 外部依据以后散布键进行数据 Redistribute。通常作用于基表扫描后,因为基表扫描是按页面进行线程划分,此时线程间并不是按 DN 的散布键散布的,须要减少该 DN 内重散布操作。

4)Streaming(type: LOCAL BROADCAST):作用是 DN 外部进行数据 Broadcast,每个线程把数据发送给这个 DN 的所有线程,每个线程取得该 DN 的全量数据。5)Streaming(type: LOCAL GATHER):作用是 DN 外部把数据从多线程汇总到一个线程。

留神 :“dop:N/M”示意发送端的 dop 为 M,接收端的 dop 为 N,从而实现从 M 个线程的并行度转变为 N 个线程并行度的工作。

在 GaussDB(DWS) 中,咱们减少了参数 query_dop,来管制语句的并行度,取值如下:

1)query_dop=1,串行执行,默认值

2)query_dop=[2..N],指定并行执行并行度

3)query_dop=0,自适应调优,依据系统资源和语句复杂度状况自适应抉择并行度

因为开启并行会占用较多的内存,所以目前 GaussDB(DWS) 的默认并行度为 1。在内存较大的环境下,能够通过手动设置 query_dop 达到并行减速的目标。通常状况下,咱们能够思考首先设置 query_dop=0,查看语句的执行打算、performance 信息和性能。在 performance 信息的下方 Query Summary 一栏,能够看到自适应 dop 抉择的信息,例如:TPC-DS Q48 dop 抉择信息如下图所示,能够看出初步选定的 initial dop 为 24,最终确定的 final dop 为 26。dop 的抉择会综合思考各种因素,其信息也在图中显示进去。

因为自适应抉择并行度是依据语句复杂度和系统资源利用状况来进行抉择,而系统资源利用状况是获取前一段时间的资源利用状况,有可能呈现不精确的状况,此时就须要人为来设置并行度了。人为设置并行度,并不是设置越大越好,dop 设置过大,会导致系统中的线程数量急剧增多,导致 CPU 抵触进行线程切换的额定开销。要想人为设置并行度,同样须要应用单机 CPU 核数和语句复杂程度进行考量。咱们定义单机 CPU 核数 / 单机 DN 数为每个 DN 可用的 CPU 核数 x,而后依据串行打算中 DN Stream 算子的个数初步断定语句的复杂度 y(例如下图 TPC-H Q1 打算中只有一个 Stream 节点,则 y 为 1),单并发时,应用 x / y 的值设置 query_dop。并发场景,再除以并发数 p 设置 query_dop。因为此公式为粗略估计值,因而在设置时能够思考扩充搜寻范畴,来寻找适合的并行度。

在并发场景下,GaussDB(DWS) 还反对 max_active_statements 来管制执行语句的个数,当语句的个数超过 CPU 核数时,能够思考应用该参数限度并发数,而后再设置正当的 query_dop 进行调优。还是以方才的示例为例,单机有 96 核,2 个 DN,则每个 DN 可用 48 核,则同时执行 6 个 TPC-H Q1 查问时,并行度能够设置为 8。

通过这篇文章,咱们理解了 GaussDB(DWS) 并行计算技术的原理以及调优策略。心愿宽广开发者敌人们可能在实践中尝试该技术,更好地进行性能优化。

点击关注,第一工夫理解华为云陈腐技术~

正文完
 0