导入分析

    如果你对 Doris 的查询计划树还不太了解，请先阅读之前的文章 。

    一个 Broker Load 请求的执行过程，也是基于 Doris 的查询框架的。一个Broker Load 作业会根据导入请求中 DATA INFILE 子句的个数讲作业拆分成多个子任务。每个子任务可以视为是一个独立的导入执行计划。一个导入计划的组成只会有一个 Fragment，其组成如下：

    BrokerScanNode 主要负责去读源数据并发送给 OlapTableSink，而 OlapTableSink 负责将数据按照分区分桶规则发送到对应的节点，由对应的节点负责实际的数据写入。

    而这个导入执行计划的 Fragment 会根据导入源文件的数量、BE节点的数量等参数，划分成一个或多个 Instance。每个 Instance 负责一部分数据导入。

    多个子任务的执行计划是并发执行的，而一个执行计划的多个 Instance 也是并行执行。

    查看导入 Profile

    1. SET is_report_success=true;

    然后提交一个 Broker Load 导入请求，并等到导入执行完成。Doris 会产生该导入的一个 Profile。Profile 包含了一个导入各个子任务、Instance 的执行详情，有助于我们分析导入瓶颈。

    目前不支持查看未执行成功的导入作业的 Profile。

    我们可以通过如下命令先获取 Profile 列表：

    这个命令会列出当前保存的所有导入 Profile。每行对应一个导入。其中 QueryId 列为导入作业的 ID。这个 ID 也可以通过 SHOW LOAD 语句查看拿到。我们可以选择我们想看的 Profile 对应的 QueryId，查看具体情况。

    查看一个Profile分为3个步骤：

    1. 查看子任务总览

    1. mysql> show load profile "/10441";
    2. +-----------------------------------+------------+
    3. | TaskId                            | ActiveTime |
    4. +-----------------------------------+------------+
    5. | 980014623046410a-88e260f0c43031f1 | 3m14s      |
    6. +-----------------------------------+------------+

    如上图，表示 10441 这个导入作业总共有一个子任务，其中 ActiveTime 表示这个子任务中耗时最长的 Instance 的执行时间。

    1. 查看指定子任务的 Instance 概况

      当我们发现一个子任务耗时较长时，可以进一步查看该子任务的各个 Instance 的执行耗时：

    这里展示了 980014623046410a-88e260f0c43031f1 这个子任务的四个 Instance 耗时，并且还展示了 Instance 所在的执行节点。

    1. 查看具体 Instance

      我们可以继续查看某一个具体的 Instance 上各个算子的详细 Profile：

    1. mysql> show load profile "/10441/980014623046410a-88e260f0c43031f1/980014623046410a-88e260f0c43031f5"\G
    2. *************************** 1. row ***************************
    3. Instance:
    4.       ┌-----------------------------------------┐
    5.       │(Active: 2m17s, non-child: 70.91)        │
    6.       │  - Counters:                            │
    7.       │      - CloseWaitTime: 1m53s             │
    9.       │      - MaxAddBatchExecTime: 1m46s       │
    10.       │      - NonBlockingSendTime: 3m11s       │
    11.       │      - NumberBatchAdded: 782            │
    12.       │      - NumberNodeChannels: 1            │
    13.       │      - OpenTime: 743.822us              │
    14.       │      - RowsFiltered: 0                  │
    15.       │      - RowsRead: 1.599729M (1599729)    │
    16.       │      - RowsReturned: 1.599729M (1599729)│
    17.       │      - SendDataTime: 11s761ms           │
    18.       │      - TotalAddBatchExecTime: 1m46s     │
    19.       │      - ValidateDataTime: 9s802ms        │
    20.       └-----------------------------------------┘
    21. ┌-----------------------------------------------------┐
    22. │[0: BROKER_SCAN_NODE]                                │
    24. │  - Counters:                                        │
    25. │      - BytesDecompressed: 0.00                      │
    26. │      - BytesRead: 5.77 GB                           │
    27. │      - DecompressTime: 0ns                          │
    28. │      - FileReadTime: 34s263ms                       │
    29. │      - MaterializeTupleTime(*): 45s54ms             │
    30. │      - NumDiskAccess: 0                             │
    31. │      - PeakMemoryUsage: 33.03 MB                    │
    32. │      - RowsRead: 1.599729M (1599729)                │
    33. │      - RowsReturned: 1.599729M (1599729)            │
    34. │      - RowsReturnedRate: 28.295K /sec               │
    35. │      - TotalRawReadTime(*): 1m20s                   │
    36. │      - TotalReadThroughput: 30.39858627319336 MB/sec│
    37. └-----------------------------------------------------┘

    通过以上3个步骤，我们可以逐步排查一个导入任务的执行瓶颈。