Stream load

    Stream load is mainly suitable for importing local files or data from data streams through procedures.

    The following figure shows the main flow of Stream load, omitting some import details.

    In Stream load, Doris selects a node as the Coordinator node. This node is responsible for receiving data and distributing data to other data nodes.

    Users submit import commands through HTTP protocol. If submitted to FE, FE forwards the request to a BE via the HTTP redirect instruction. Users can also submit import commands directly to a specified BE.

    The final result of the import is returned to the user by Coordinator BE.

    Support data format

    Currently Stream Load supports two data formats: CSV (text) and JSON

    Stream load submits and transfers data through HTTP protocol. Here, the command shows how to submit an import.

    Users can also operate through other HTTP clients.

    1. curl --location-trusted -u user:passwd [-H ""...] -T data.file -XPUT http://fe_host:http_port/api/{db}/{table}/_stream_load
    3. The properties supported in the header are described in "Load Parameters" below
    4. The format is: - H "key1: value1"

    Examples:

    1. curl --location-trusted -u root -T date -H "label:123" http://abc.com:8030/api/test/date/_stream_load

    The detailed syntax for creating imports helps to execute HELP STREAM LOAD view. The following section focuses on the significance of creating some parameters of Stream load.

    Signature parameters

    • user/passwd

      Stream load uses the HTTP protocol to create the imported protocol and signs it through the Basic Access authentication. The Doris system verifies user identity and import permissions based on signatures.

    Load Parameters

    Stream load uses HTTP protocol, so all parameters related to import tasks are set in the header. The significance of some parameters of the import task parameters of Stream load is mainly introduced below.

    • label

      Identity of import task. Each import task has a unique label inside a single database. Label is a user-defined name in the import command. With this label, users can view the execution of the corresponding import task.

      Another function of label is to prevent users from importing the same data repeatedly. It is strongly recommended that users use the same label for the same batch of data. This way, repeated requests for the same batch of data will only be accepted once, guaranteeing at-Most-Once

      When the corresponding import operation state of label is CANCELLED, the label can be used again.

    • column_separator

      Used to specify the column separator in the load file. The default is \t. If it is an invisible character, you need to add \x as a prefix and hexadecimal to indicate the separator.

      For example, the separator \x01 of the hive file needs to be specified as -H "column_separator:\x01".

      You can use a combination of multiple characters as the column separator.

    • line_delimiter

      Used to specify the line delimiter in the load file. The default is \n.

      You can use a combination of multiple characters as the column separator.

    • max_filter_ratio

      The maximum tolerance rate of the import task is 0 by default, and the range of values is 0-1. When the import error rate exceeds this value, the import fails.

      If the user wishes to ignore the wrong row, the import can be successful by setting this parameter greater than 0.

      The calculation formula is as follows:

      (dpp.abnorm.ALL / (dpp.abnorm.ALL + dpp.norm.ALL ) ) > max_filter_ratio

      dpp.abnorm.ALL denotes the number of rows whose data quality is not up to standard. Such as type mismatch, column mismatch, length mismatch and so on.

      dpp.norm.ALL refers to the number of correct data in the import process. The correct amount of data for the import task can be queried by the ``SHOW LOAD` command.

    • where

      Import the filter conditions specified by the task. Stream load supports filtering of where statements specified for raw data. The filtered data will not be imported or participated in the calculation of filter ratio, but will be counted as num_rows_unselected.

    • partition

      Partition information for tables to be imported will not be imported if the data to be imported does not belong to the specified Partition. These data will be included in dpp.abnorm.ALL.

    • columns

      The function transformation configuration of data to be imported includes the sequence change of columns and the expression transformation, in which the expression transformation method is consistent with the query statement.

      1. Examples of column order transformation: There are three columns of original data (src_c1,src_c2,src_c3), and there are also three columns （dst_c1,dst_c2,dst_c3) in the doris table at present. 
      2. when the first column src_c1 of the original file corresponds to the dst_c1 column of the target table, while the second column src_c2 of the original file corresponds to the dst_c2 column of the target table and the third column src_c3 of the original file corresponds to the dst_c3 column of the target table,which is written as follows:
      3. columns: dst_c1, dst_c2, dst_c3
      5. when the first column src_c1 of the original file corresponds to the dst_c2 column of the target table, while the second column src_c2 of the original file corresponds to the dst_c3 column of the target table and the third column src_c3 of the original file corresponds to the dst_c1 column of the target table,which is written as follows:
      7. Example of expression transformation: There are two columns in the original file and two columns in the target table (c1, c2). However, both columns in the original file need to be transformed by functions to correspond to the two columns in the target table.
      8. columns: tmp_c1, tmp_c2, c1 = year(tmp_c1), c2 = mouth(tmp_c2)
      9. Tmp_* is a placeholder, representing two original columns in the original file.

    • exec_mem_limit

      Memory limit. Default is 2GB. Unit is Bytes

    • merge_type The type of data merging supports three types: APPEND, DELETE, and MERGE. APPEND is the default value, which means that all this batch of data needs to be appended to the existing data. DELETE means to delete all rows with the same key as this batch of data. MERGE semantics Need to be used in conjunction with the delete condition, which means that the data that meets the delete condition is processed according to DELETE semantics and the rest is processed according to APPEND semantics

    • two_phase_commit

      Stream load supports the two-phase commit mode。The mode could be enabled by declaring two_phase_commit=true in http header. This mode is disabled by default. the two-phase commit mode means：During Stream load, after data is written, the message will be returned to the client, the data is invisible at this point and the transaction status is PRECOMMITTED. The data will be visible only after COMMIT is triggered by client。

      1. User can invoke the following interface to trigger commit operations for transaction：
      1. curl -X PUT --location-trusted -u user:passwd -H "txn_id:txnId" -H "txn_operation:commit" http://fe_host:http_port/api/{db}/_stream_load_2pc

      or

      1. User can invoke the following interface to trigger abort operations for transaction：
      1. curl -X PUT --location-trusted -u user:passwd -H "txn_id:txnId" -H "txn_operation:abort" http://fe_host:http_port/api/{db}/_stream_load_2pc

      or

      1. curl -X PUT --location-trusted -u user:passwd -H "txn_id:txnId" -H "txn_operation:abort" http://be_host:webserver_port/api/{db}/_stream_load_2pc

    Return results

    Since Stream load is a synchronous import method, the result of the import is directly returned to the user by creating the return value of the import.

    Examples:

    1. {
    2.     "TxnId": 1003,
    3.     "Label": "b6f3bc78-0d2c-45d9-9e4c-faa0a0149bee",
    4.     "Status": "Success",
    5.     "ExistingJobStatus": "FINISHED", // optional
    6.     "Message": "OK",
    7.     "NumberTotalRows": 1000000,
    8.     "NumberLoadedRows": 1000000,
    9.     "NumberFilteredRows": 1,
    10.     "NumberUnselectedRows": 0,
    11.     "LoadBytes": 40888898,
    12.     "LoadTimeMs": 2144,
    13.     "BeginTxnTimeMs": 1,
    14.     "StreamLoadPutTimeMs": 2,
    16.     "WriteDataTimeMs": 1933,
    17.     "CommitAndPublishTimeMs": 106,
    18.     "ErrorURL": "http://192.168.1.1:8042/api/_load_error_log?file=__shard_0/error_log_insert_stmt_db18266d4d9b4ee5-abb00ddd64bdf005_db18266d4d9b4ee5_abb00ddd64bdf005"
    19. }

    The following main explanations are given for the Stream load import result parameters:

    • TxnId: The imported transaction ID. Users do not perceive.

    • Label: Import Label. User specified or automatically generated by the system.

    • Status: Import completion status.

      “Success”: Indicates successful import.

      “Publish Timeout”: This state also indicates that the import has been completed, except that the data may be delayed and visible without retrying.

      “Label Already Exists”: Label duplicate, need to be replaced Label.

      “Fail”: Import failed.

    • Message: Import error messages.

    • NumberTotalRows: Number of rows imported for total processing.

    • NumberLoadedRows: Number of rows successfully imported.

    • NumberFilteredRows: Number of rows that do not qualify for data quality.

    • NumberUnselectedRows: Number of rows filtered by where condition.

    • LoadBytes: Number of bytes imported.

    • BeginTxnTimeMs: The time cost for RPC to Fe to begin a transaction, Unit milliseconds.

    • StreamLoadPutTimeMs: The time cost for RPC to Fe to get a stream load plan, Unit milliseconds.

    • ReadDataTimeMs: Read data time, Unit milliseconds.

    • WriteDataTimeMs: Write data time, Unit milliseconds.

    • CommitAndPublishTimeMs: The time cost for RPC to Fe to commit and publish a transaction, Unit milliseconds.

    • ErrorURL: If you have data quality problems, visit this URL to see specific error lines.

    Users can’t cancel Stream load manually. Stream load will be cancelled automatically by the system after a timeout or import error.

    Relevant System Configuration

    FE configuration

    • stream_load_default_timeout_second

      The timeout time of the import task (in seconds) will be cancelled by the system if the import task is not completed within the set timeout time, and will become CANCELLED.

      At present, Stream load does not support custom import timeout time. All Stream load import timeout time is uniform. The default timeout time is 300 seconds. If the imported source file can no longer complete the import within the specified time, the FE parameter stream_load_default_timeout_second needs to be adjusted.

    • streaming_load_max_mb

      The maximum import size of Stream load is 10G by default, in MB. If the user’s original file exceeds this value, the BE parameter streaming_load_max_mb needs to be adjusted.

    Application scenarios

    The most appropriate scenario for using Stream load is that the original file is in memory or on disk. Secondly, since Stream load is a synchronous import method, users can also use this import if they want to obtain the import results in a synchronous manner.

    Since Stream load is based on the BE initiative to import and distribute data, the recommended amount of imported data is between 1G and 10G. Since the default maximum Stream load import data volume is 10G, the configuration of BE streaming_load_max_mb needs to be modified if files exceeding 10G are to be imported.

    1. For example, the size of the file to be imported is 15G
    2. Modify the BE configuration streaming_load_max_mb to 16000

    Stream load default timeout is 300 seconds, according to Doris currently the largest import speed limit, about more than 3G files need to modify the import task default timeout.

    Complete examples

    Data situation: In the local disk path / home / store_sales of the sending and importing requester, the imported data is about 15G, and it is hoped to be imported into the table store_sales of the database bj_sales.

    Cluster situation: The concurrency of Stream load is not affected by cluster size.

    • Step 1: Does the import file size exceed the default maximum import size of 10G

      1. BE conf
      2. streaming_load_max_mb = 16000

    • Step 2: Calculate whether the approximate import time exceeds the default timeout value

      1. Import time 15000/10 = 1500s
      2. Over the default timeout time, you need to modify the FE configuration
      3. stream_load_default_timeout_second = 1500

    • Step 3: Create Import Tasks

      1. curl --location-trusted -u user:password -T /home/store_sales -H "label:abc" http://abc.com:8000/api/bj_sales/store_sales/_stream_load

    Common Questions

    • Label Already Exists

      The Label repeat checking steps of Stream load are as follows:

      1. Is there an import Label conflict that already exists with other import methods?

        Because imported Label in Doris system does not distinguish between import methods, there is a problem that other import methods use the same Label.

        Through SHOW LOAD WHERE LABEL = "xxx"', where XXX is a duplicate Label string, see if there is already a Label imported by FINISHED that is the same as the Label created by the user.

      2. Are Stream loads submitted repeatedly for the same job?

        Since Stream load is an HTTP protocol submission creation import task, HTTP Clients in various languages usually have their own request retry logic. After receiving the first request, the Doris system has started to operate Stream load, but because the result is not returned to the Client side in time, the Client side will retry to create the request. At this point, the Doris system is already operating on the first request, so the second request will be reported to Label Already Exists.

        To sort out the possible methods mentioned above: Search FE Master’s log with Label to see if there are two redirect load action to destination =redirect load action to destination cases in the same Label. If so, the request is submitted repeatedly by the Client side.

        It is recommended that the user calculate the approximate import time based on the amount of data currently requested, and change the request overtime on the client side to a value greater than the import timeout time according to the import timeout time to avoid multiple submissions of the request by the client side.

      3. Connection reset abnormal

      After the upgrade, also upgrade the http client version of your program to 4.5.13，Introduce the following dependencies in your pom.xml file

      1.     <dependency>
      2.       <groupId>org.apache.httpcomponents</groupId>
      3.       <artifactId>httpclient</artifactId>