如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 寫入 您可以從連線的裝置、IT 系統和工業設備收集時間序列資料，並將其寫入 Timestream for Live Analytics。Timestream for Live Analytics 可讓您在時間序列屬於相同資料表時，從單一時間序列和/或單一寫入請求中多個序列的資料點寫入資料點。為了方便起見，Timestream for Live Analytics 為您提供彈性的結構描述，可根據您調用寫入資料庫時指定的度量值的維度名稱和資料類型，自動偵測 Timestream for Live Analytics 資料表的資料欄名稱和資料類型。您也可以將批次資料寫入 Timestream for Live Analytics。 **注意** Timestream for Live Analytics 支援讀取的最終一致性語意。這表示當您在將一批資料寫入 Timestream for Live Analytics 後立即查詢資料時，查詢結果可能不會反映最近完成的寫入操作的結果。結果也可能包含一些過時的資料。同樣地，在寫入具有一或多個新維度的時間序列資料時，查詢可能會在短時間內傳回部分欄位子集。如果您在短時間內重複這些查詢請求，結果應該會傳回最新的資料。 您可以使用 [AWS SDKs](getting-started-sdks.md)、 或透過 [AWS CLI](Tools.CLI.md)、、[AWS Lambda](Lambda.md)、[Amazon MSK](MSK.md)、 [AWS IoT Core](IOT-Core.md) [Amazon Managed Service for Apache Flink](ApacheFlink.md) [Amazon Kinesis](Kinesis.md)和 來寫入資料[開放原始碼 Telegraf](Telegraf.md)。 **Topics** + [資料類型](#writes.data-types) + [無前期結構描述定義](#writes.no-upfront-schema) + [寫入資料 （插入 和 upsert)](#writes.writing-data-inserts-upserts) + [讀取的最終一致性](#writes.eventual-consistency) + [使用 WriteRecords API 批次寫入](writes.batching-writes.md) + [批次載入](batch-load-how.md) + [選擇 WriteRecords API 操作和批次載入](writes.writes-or-batch-load.md) ## 資料類型 Timestream for Live Analytics 支援下列寫入資料類型。 | 資料類型 | Description | | --- | --- | | BIGINT | 代表 64 位元帶正負號的整數。 | | BOOLEAN | 代表邏輯的兩個事實值，即 true 和 false。 | | DOUBLE | 實作二進位浮點運算 IEEE 標準 754 的 64 位元變數精確度。 有 的查詢語言函數`Infinity`和`NaN`雙值可用於查詢。但您無法將這些值寫入 Timestream。 | | VARCHAR | 變數長度字元資料，具有選用的最大長度。上限為 2 KB。 | | 多個 | 多度量記錄的資料類型。此資料類型包含類型 `BIGINT`、、`VARCHAR`、 `BOOLEAN` `DOUBLE`和 的一或多個量值`TIMESTAMP`。 | | TIMESTAMP | 使用以 UTC 為單位的奈秒精確度時間，以時間表示執行個體，追蹤自 Unix 時間以來的時間。此資料類型目前僅支援多度量記錄 （即在 類型的度量值內`MULTI`)。 `YYYY-MM-DD hh:mm:ss.sssssssss` 將 範圍內的支援時間戳記寫入 `1970-01-01 00:00:00.000000000` `2262-04-11 23:47:16.854775807`。 | ## 無前期結構描述定義 將資料傳送至 Amazon Timestream for Live Analytics 之前，您必須使用 AWS 管理主控台、Timestream for Live Analytics SDKs 或 Timestream for Live Analytics API 操作建立資料庫和資料表。如需詳細資訊，請參閱[建立 資料庫](console_timestream.md#console_timestream.db.using-console)及[建立資料表](console_timestream.md#console_timestream.table.using-console)。建立資料表時，您不需要預先定義結構描述。Amazon Timestream for Live Analytics 會根據傳送的資料點的量值和維度自動偵測結構描述，因此您不再需要離線更改結構描述，以適應快速變化的時間序列資料。 ## 寫入資料 （插入 和 upsert) Amazon Timestream for Live Analytics 中的寫入操作可讓您插入和*更新*資料。根據預設，Amazon Timestream for Live Analytics 中的寫入會遵循*第一個寫入器的*語意，其中資料會儲存為僅附加，而重複的記錄會遭到拒絕。雖然第一個寫入器的語意滿足許多時間序列應用程式的需求，但在某些情況下，應用程式需要以等冪方式更新現有記錄，和/或使用最後一個寫入器寫入資料則會獲得語意，其中具有最高版本的記錄存放在服務中。為了解決這些案例，Amazon Timestream for Live Analytics 提供升級資料的功能。Upsert 是一種操作，可在記錄不存在時將記錄插入系統，或在記錄存在時更新記錄。記錄更新時，會以等冪方式更新。 沒有要刪除的記錄層級操作。但是可以刪除資料表和資料庫。 **將資料寫入記憶體存放區和磁性存放區** Amazon Timestream for Live Analytics 可讓您將資料直接寫入記憶體存放區和磁性存放區。記憶體存放區已針對高輸送量資料寫入進行最佳化，而磁性存放區已針對延遲到達資料的較低輸送量寫入進行最佳化。 延遲抵達資料是指時間戳記早於目前時間且超出記憶體存放區保留期間的資料。您必須透過啟用資料表的磁性存放區寫入，明確啟用將延遲抵達資料寫入磁性存放區的能力。此外， `MagneticStoreRejectedDataLocation` 會在建立資料表時定義。若要寫入磁性存放區， 的發起人`WriteRecords`必須具有在建立資料表`MagneticStoreRejectedDataLocation`期間在 中指定的 S3 儲存貯體的`S3:PutObject`許可。如需詳細資訊，請參閱 [CreateTable](https://docs.aws.amazon.com/timestream/latest/developerguide/API_CreateTable.html)、 [WriteRecords](https://docs.aws.amazon.com/timestream/latest/developerguide/API_WriteRecords.html) 和 [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html)。 **使用單一度量記錄和多度量記錄寫入資料** Amazon Timestream for Live Analytics 可讓您使用兩種類型的記錄撰寫資料，也就是單一度量記錄和多度量記錄。 **單一度量記錄** 單一度量記錄可讓您為每個記錄傳送單一度量。使用此格式將資料傳送至 Timestream for Live Analytics 時，Timestream for Live Analytics 會為每個記錄建立一個資料表列。這表示如果裝置發出 4 個指標，而且每個指標都是以單一指標記錄傳送，則即時分析的 Timestream 會在資料表中建立 4 列來存放此資料，而且每列都會重複裝置屬性。當您想要從應用程式監控單一指標，或您的應用程式不會同時發出多個指標時，建議使用此格式。 **多度量記錄** 使用多度量記錄，您可以將多個度量存放在單一資料表資料列中，而不是在每個資料表資料列中存放一個度量。因此，多度量記錄可讓您將現有資料從關聯式資料庫遷移至 Amazon Timestream for Live Analytics，並將變更降至最低。 您也可以在單一寫入請求中批次處理比單一度量記錄更多的資料。這會增加資料寫入輸送量和效能，並降低資料寫入的成本。這是因為在寫入請求中批次處理更多資料，可讓 Amazon Timestream for Live Analytics 在單一寫入請求 （如適用） 中識別更多可重複的資料，並僅收取一次重複資料的費用。 **Topics** + [多度量記錄](#writes.writing-data-multi-measure) + [使用過去或未來的時間戳記寫入資料](#writes.timestamp-past-future) ### 多度量記錄 透過多度量記錄，您可以將時間序列資料以更精簡的格式存放在記憶體和磁性存放區中，這有助於降低資料儲存成本。此外，精簡的資料儲存本身有助於撰寫更簡單的查詢以進行資料擷取、改善查詢效能，並降低查詢成本。 此外，多度量記錄也支援 TIMESTAMP 資料類型，用於在時間序列記錄中存放多個時間戳記。多度量記錄中的 TIMESTAMP 屬性支援未來或過去的時間戳記。因此，多度量記錄有助於改善效能、成本和查詢簡單性，並為存放不同類型的相關度量提供更多彈性。 **優勢** 以下是使用多度量記錄的好處。 + **效能和成本** – 多度量記錄可讓您在單一寫入請求中寫入多個時間序列度量。這會增加寫入輸送量，並降低寫入成本。透過多度量記錄，您可以更精簡的方式存放資料，這有助於降低資料儲存成本。多度量記錄的精簡資料儲存會導致查詢處理的資料較少。這旨在改善整體查詢效能，並協助降低查詢成本。 + **查詢簡單** – 使用多度量記錄，您不需要在查詢中寫入複雜的通用資料表表達式 (CTEs)，即可讀取具有相同時間戳記的多個度量。這是因為量值會以資料欄形式儲存在單一資料表列中。因此，多度量記錄可讓您撰寫更簡單的查詢。 + **資料建模彈性** – 您可以使用 TIMESTAMP 資料類型和多度量記錄，將未來的時間戳記寫入 Timestream for Live Analytics。除了記錄中的時間欄位之外，多度量記錄還可以具有 TIMESTAMP 資料類型的多個屬性。在多度量記錄中，TIMESTAMP 屬性可以有未來的時間戳記或過去的時間戳記，並且行為類似於時間欄位，除了即時分析的 Timestream 不會在多度量記錄中的 TIMESTAMP 類型值上編製索引。 **使用案例** 您可以針對任何時間序列應用程式使用多度量記錄，這些應用程式在任何指定時間從同一裝置產生多個度量。以下是一些範例應用程式。 + 在特定時間產生數百個指標的影片串流平台。 + 產生測量結果的醫學裝置，例如含氧量、心率和脈衝。 + 工業設備，例如產生指標、溫度和天氣感應器的油裝備。 + 使用一或多個微服務建構的其他應用程式。 #### 範例：監控影片串流應用程式的效能和運作狀態 考慮在 200 個 EC2 執行個體上執行的影片串流應用程式。您想要使用 Amazon Timestream for Live Analytics 來存放和分析從應用程式發出的指標，因此您可以了解應用程式的效能和運作狀態、快速識別異常狀況、解決問題，以及探索最佳化機會。 我們將使用單一度量記錄和多度量記錄來建立此案例的模型，然後比較/對比這兩種方法。對於每個方法，我們會做出下列假設。 + 每個 EC2 執行個體每秒發出四個度量 (video\$1startup\$1time、rebuffering\$1ratio、Video\$1playback\$1failures 和 average\$1frame\$1rate) 和四個維度 (device\$1id、Device\$1type、os\$1version 和 region)。 + 您想要將 6 小時的資料存放在記憶體存放區，並將 6 個月的資料存放在磁性存放區。 + 為了識別異常，您已設定 10 個每分鐘執行的查詢，以識別過去幾分鐘內的任何異常活動。您也建立了具有八個小工具的儀表板，顯示過去 6 小時的資料，以便您可以有效地監控應用程式。此儀表板由五個使用者在任何指定時間存取，並且每小時自動重新整理。 ##### 使用單一量值記錄 **資料建模**：透過單一量值記錄，我們將為四個量值 （影片啟動時間、重新緩衝比率、影片播放失敗和平均影格率） 中的每一個量值建立一個記錄。每個記錄都會有四個維度 (device\$1id、 device\$1type、os\$1version 和 region) 和時間戳記。 **寫入**：當您將資料寫入 Amazon Timestream for Live Analytics 時，記錄的建構方式如下。 ``` public void writeRecords() { System.out.println("Writing records"); // Specify repeated values for all records List records = new ArrayList<>(); final long time = System.currentTimeMillis(); List dimensions = new ArrayList<>(); final Dimension device_id = new Dimension().withName("device_id").withValue("12345678"); final Dimension device_type = new Dimension().withName("device_type").withValue("iPhone 11"); final Dimension os_version = new Dimension().withName("os_version").withValue("14.8"); final Dimension region = new Dimension().withName("region").withValue("us-east-1"); dimensions.add(device_id); dimensions.add(device_type); dimensions.add(os_version); dimensions.add(region); Record videoStartupTime = new Record() .withDimensions(dimensions) .withMeasureName("video_startup_time") .withMeasureValue("200") .withMeasureValueType(MeasureValueType.BIGINT) .withTime(String.valueOf(time)); Record rebufferingRatio = new Record() .withDimensions(dimensions) .withMeasureName("rebuffering_ratio") .withMeasureValue("0.5") .withMeasureValueType(MeasureValueType.DOUBLE) .withTime(String.valueOf(time)); Record videoPlaybackFailures = new Record() .withDimensions(dimensions) .withMeasureName("video_playback_failures") .withMeasureValue("0") .withMeasureValueType(MeasureValueType.BIGINT) .withTime(String.valueOf(time)); Record averageFrameRate = new Record() .withDimensions(dimensions) .withMeasureName("average_frame_rate") .withMeasureValue("0.5") .withMeasureValueType(MeasureValueType.DOUBLE) .withTime(String.valueOf(time)); records.add(videoStartupTime); records.add(rebufferingRatio); records.add(videoPlaybackFailures); records.add(averageFrameRate); WriteRecordsRequest writeRecordsRequest = new WriteRecordsRequest() .withDatabaseName(DATABASE_NAME) .withTableName(TABLE_NAME) .withRecords(records); try { WriteRecordsResult writeRecordsResult = amazonTimestreamWrite.writeRecords(writeRecordsRequest); System.out.println("WriteRecords Status: " + writeRecordsResult.getSdkHttpMetadata().getHttpStatusCode()); } catch (RejectedRecordsException e) { System.out.println("RejectedRecords: " + e); for (RejectedRecord rejectedRecord : e.getRejectedRecords()) { System.out.println("Rejected Index " + rejectedRecord.getRecordIndex() + ": " + rejectedRecord.getReason()); } System.out.println("Other records were written successfully. "); } catch (Exception e) { System.out.println("Error: " + e); } } ``` 當您存放單一度量記錄時，資料會以邏輯方式表示，如下所示。 | 時間 | device\$1id | device\$1type | os\$1version | region | measure\$1name | measure\$1value::bigint | measure\$1value::double | | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21：48：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1startup\$1time | 200 | | | 2021-09-07 21：48：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | rebuffering\$1ratio | | 0.5 | | 2021-09-07 21：48：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1playback\$1failures | 0 | | | 2021-09-07 21：48：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | average\$1frame\$1rate | | 0.85 | | 2021-09-07 21：53：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1startup\$1time | 500 | | | 2021-09-07 21：53：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | rebuffering\$1ratio | | 1.5 | | 2021-09-07 21：53：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1playback\$1failures | 10 | | | 2021-09-07 21：53：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | average\$1frame\$1rate | | 0.2 | **查詢**：您可以撰寫查詢，擷取過去 15 分鐘內收到具有相同時間戳記的所有資料點，如下所示。 ``` with cte_video_startup_time as ( SELECT time, device_id, device_type, os_version, region, measure_value::bigint as video_startup_time FROM table where time >= ago(15m) and measure_name=”video_startup_time”), cte_rebuffering_ratio as ( SELECT time, device_id, device_type, os_version, region, measure_value::double as rebuffering_ratio FROM table where time >= ago(15m) and measure_name=”rebuffering_ratio”), cte_video_playback_failures as ( SELECT time, device_id, device_type, os_version, region, measure_value::bigint as video_playback_failures FROM table where time >= ago(15m) and measure_name=”video_playback_failures”), cte_average_frame_rate as ( SELECT time, device_id, device_type, os_version, region, measure_value::double as average_frame_rate FROM table where time >= ago(15m) and measure_name=”average_frame_rate”) SELECT a.time, a.device_id, a.os_version, a.region, a.video_startup_time, b.rebuffering_ratio, c.video_playback_failures, d.average_frame_rate FROM cte_video_startup_time a, cte_buffering_ratio b, cte_video_playback_failures c, cte_average_frame_rate d WHERE a.time = b.time AND a.device_id = b.device_id AND a.os_version = b.os_version AND a.region=b.region AND a.time = c.time AND a.device_id = c.device_id AND a.os_version = c.os_version AND a.region=c.region AND a.time = d.time AND a.device_id = d.device_id AND a.os_version = d.os_version AND a.region=d.region ``` **工作負載成本**：此工作負載的成本估計為每月 373.23 USD，具有單一測量記錄 ##### 使用多度量記錄 **資料建模**：使用多度量記錄，我們將建立一個記錄，其中包含所有四個量值 （影片啟動時間、重新緩衝比率、影片播放失敗和平均影格率）、所有四個維度 (device\$1id、Device\$1type、os\$1version 和 region)，以及時間戳記。 **寫入**：當您將資料寫入 Amazon Timestream for Live Analytics 時，記錄的建構方式如下。 ``` public void writeRecords() { System.out.println("Writing records"); // Specify repeated values for all records List records = new ArrayList<>(); final long time = System.currentTimeMillis(); List dimensions = new ArrayList<>(); final Dimension device_id = new Dimension().withName("device_id").withValue("12345678"); final Dimension device_type = new Dimension().withName("device_type").withValue("iPhone 11"); final Dimension os_version = new Dimension().withName("os_version").withValue("14.8"); final Dimension region = new Dimension().withName("region").withValue("us-east-1"); dimensions.add(device_id); dimensions.add(device_type); dimensions.add(os_version); dimensions.add(region); Record videoMetrics = new Record() .withDimensions(dimensions) .withMeasureName("video_metrics") .withTime(String.valueOf(time)); .withMeasureValueType(MeasureValueType.MULTI) .withMeasureValues( new MeasureValue() .withName("video_startup_time") .withValue("0") .withValueType(MeasureValueType.BIGINT), new MeasureValue() .withName("rebuffering_ratio") .withValue("0.5") .withType(MeasureValueType.DOUBLE), new MeasureValue() .withName("video_playback_failures") .withValue("0") .withValueType(MeasureValueType.BIGINT), new MeasureValue() .withName("average_frame_rate") .withValue("0.5") .withValueType(MeasureValueType.DOUBLE)) records.add(videoMetrics); WriteRecordsRequest writeRecordsRequest = new WriteRecordsRequest() .withDatabaseName(DATABASE_NAME) .withTableName(TABLE_NAME) .withRecords(records); try { WriteRecordsResult writeRecordsResult = amazonTimestreamWrite.writeRecords(writeRecordsRequest); System.out.println("WriteRecords Status: " + writeRecordsResult.getSdkHttpMetadata().getHttpStatusCode()); } catch (RejectedRecordsException e) { System.out.println("RejectedRecords: " + e); for (RejectedRecord rejectedRecord : e.getRejectedRecords()) { System.out.println("Rejected Index " + rejectedRecord.getRecordIndex() + ": " + rejectedRecord.getReason()); } System.out.println("Other records were written successfully. "); } catch (Exception e) { System.out.println("Error: " + e); } } ``` 當您存放多度量記錄時，資料會以邏輯方式表示，如下所示。 | 時間 | device\$1id | device\$1type | os\$1version | region | measure\$1name | video\$1startup\$1time | rebuffering\$1ratio | video\$1 playback\$1failures | average\$1frame\$1rate | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21：48：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1metrics | 200 | 0.5 | 0 | 0.85 | | 2021-09-07 21：53：44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1metrics | 500 | 1.5 | 10 | 0.2 | **查詢**：您可以撰寫查詢，擷取過去 15 分鐘內收到具有相同時間戳記的所有資料點，如下所示。 ``` SELECT time, device_id, device_type, os_version, region, video_startup_time, rebuffering_ratio, video_playback_failures, average_frame_rate FROM table where time >= ago(15m) ``` **工作負載成本**：具有多度量記錄的工作負載成本估計為 127.43 美元。 **注意** 在此情況下，使用多度量記錄可減少 2.5 倍的整體估計每月支出，資料寫入成本減少 3.3 倍，儲存成本減少 3.3 倍，查詢成本減少 1.2 倍。 ### 使用過去或未來的時間戳記寫入資料 Timestream for Live Analytics 透過幾個不同的機制，提供寫入時間戳記位於記憶體存放區保留時段之外的資料的能力。 + **磁性存放區寫入** – 您可以透過磁性存放區寫入，直接將延遲抵達的資料寫入磁性存放區。若要使用磁性存放區寫入，您必須先啟用資料表的磁性存放區寫入。然後，您可以使用與將資料寫入記憶體存放區相同的機制，將資料擷取至資料表。Amazon Timestream for Live Analytics 會根據其時間戳記自動將資料寫入磁性存放區。 **注意** 與將資料寫入記憶體存放區不同，磁性存放區的write-to-read延遲最長可達 6 小時，其中write-to-read延遲在 1 秒以下的範圍內。 + **測量的 TIMESTAMP 資料類型** – 您可以使用 TIMESTAMP 資料類型來存放過去、現在或未來的資料。除了記錄中的時間欄位之外，多度量記錄還可以具有 TIMESTAMP 資料類型的多個屬性。在多度量記錄中，TIMESTAMP 屬性可以有未來的時間戳記或過去的時間戳記，並且行為類似於時間欄位，除了即時分析的 Timestream 不會在多度量記錄中的 TIMESTAMP 類型值上編製索引。 **注意** TIMESTAMP 資料類型僅支援多度量記錄。 ## 讀取的最終一致性 Timestream for Live Analytics 支援讀取的最終一致性語意。這表示當您在將一批資料寫入 Timestream for Live Analytics 後立即查詢資料時，查詢結果可能不會反映最近完成的寫入操作的結果。如果您在短時間內重複這些查詢請求，結果應該會傳回最新的資料。 # 使用 WriteRecords API 批次寫入 Amazon Timestream for Live Analytics 可讓您在單一寫入請求中，從單一時間序列和/或多個序列的資料點寫入資料點。從效能和成本角度來看，在單一寫入操作中批次處理多個資料點很有幫助。如需詳細資訊，請參閱計量和定價一節[寫入](metering-and-pricing.writes.md)中的 。 **注意** 隨著 Timestream for Live Analytics 擴展以適應應用程式的資料擷取需求，您對 Timestream for Live Analytics 的寫入請求可能會受到限流。如果您的應用程式遇到限流例外狀況，您必須繼續以相同 （或更高） 輸送量傳送資料，以允許 Timestream for Live Analytics 自動擴展以滿足您的應用程式需求。 # 批次載入 透過 Amazon Timestream for LiveAnalytics 的*批次載入*，您可以將存放在 Amazon S3 中的 CSV 檔案分批擷取到 Timestream。有了這項新功能，您可以在 Timestream for LiveAnalytics 中取得資料，而不必依賴其他工具或撰寫自訂程式碼。您可以使用批次載入，以彈性的等待時間回填資料，例如查詢或分析時不需要的資料。 您可以使用 AWS 管理主控台、 AWS CLI和 SDKs AWS 來建立批次載入任務。如需詳細資訊，請參閱[搭配主控台使用批次載入](batch-load-using-console.md)、[搭配 使用批次載入 AWS CLI](batch-load-using-cli.md)及[搭配 AWS SDKs 使用批次載入](batch-load-using-sdk.md)。 如需批次載入的詳細資訊，請參閱 [在 Timestream for LiveAnalytics 中使用批次載入](batch-load.md)。 # 選擇 WriteRecords API 操作和批次載入 使用 WriteRecords API 操作，您可以將串流時間序列資料寫入系統產生的 Timestream for LiveAnalytics。透過使用 WriteRecords，您可以持續即時擷取單一資料點或較小批次的資料。Timestream for LiveAnalytics 為您提供彈性的結構描述，可根據您在調用寫入資料庫時指定的資料點維度名稱和資料類型，自動偵測 Timestream for LiveAnalytics 資料表的資料欄名稱和資料類型。 相反地，*批次載入*可讓您使用定義的資料模型，將批次時間序列資料從來源檔案 (CSV 檔案） 擷取至 Timestream for LiveAnalytics。將批次載入與來源檔案搭配使用的幾個範例，是透過概念驗證大量匯入時間序列資料，以評估 Timestream for LiveAnalytics、從離線一段時間的 IoT 裝置大量匯入時間序列資料，以及將歷史時間序列資料從 Amazon S3 遷移至 Timestream for LiveAnalytics。如需批次載入的資訊，請參閱 [在 Timestream for LiveAnalytics 中使用批次載入](batch-load.md)。 這兩種解決方案都安全、可靠且高效能。 **在下列情況下使用 WriteRecords：** + 每個請求串流較少量 （少於 10 MB) 的資料。 + 填入現有的資料表。 + 從日誌串流擷取資料。 + 執行即時分析。 + 需要較低的延遲。 **在下列情況下使用批次載入：** + 在 CSV 檔案中擷取源自 Amazon S3 的較大資料負載。如需限制的詳細資訊，請參閱 [配額預設配額](ts-limits.md)。 + 填入新資料表，例如在資料遷移的情況下。 + 使用歷史資料充實資料庫 （擷取至新資料表）。 + 您有緩慢變更或完全不變更的來源資料。 + 您有彈性的等待時間，因為批次載入任務可能處於待定狀態，直到資源可用為止，特別是當您載入非常大量的資料時。批次載入適用於不需要隨時可用於查詢或分析的資料，以增加清晰度。