使用DataX同步MaxCompute資料到TableStore（原OTS）最佳化指南
概述
現在越來越多的技術架構下會組合使用MaxCompute和TableStore，用MaxCompute作大資料分析，計算的結果會匯出到TableStore提供線上訪問。MaxCompute提供海量資料計算的能力，而TableStore提供海量資料高併發低延遲讀寫的能力。
將 MaxCompute 內資料匯出至TableStore，目前可選的幾種主要途徑包括：
自己編寫工具：使用MaxCompute SDK透過Tunnel讀取表資料，再透過TableStore SDK再寫入資料。
DataX
：自己在伺服器上託管執行DataX任務。
使用資料整合服務：其系統底層也是DataX，額外提供了服務化以及分散式的能力。
其中第二種是我們最常推薦給使用者做臨時的資料匯出使用的，如果沒有需要對資料做特殊處理的需求，我們一般不推薦第一種途徑。
DataX在阿里集團內部已經應用了很多年，經歷了多次雙十一的考驗，是一個穩定、易用、高效的工具。隨著MaxCompute上結果資料越來越龐大，資料匯出的速率越來越被看重，海量的資料需要在基線內完成匯出。本篇文章，主要會介紹幾種最佳化手段，以提高使用DataX來進行MaxCompute向TableStore資料匯出的吞吐量。
最佳化過程
我們會以實際的場景，來演示如何透過一步步的最佳化，提升資料匯出的速度。在資料匯出的整個鏈路上，主要有三個環節，一是MaxCompute資料通道的讀，二是DataX的資料交換，三是TableStore的線上寫，這三個環節任意一個成為瓶頸，都會影響匯出的速度。
MaxCompute資料通道的讀的效能比較高，一般不會成為瓶頸，本文主要是針對後兩個環節來最佳化。最佳化的核心指導方針就是：1. 提高併發，2. 降低寫入延遲。接下來列舉的幾種最佳化手段，也是圍繞這兩點，來不斷進行最佳化。
實驗選擇使用TableStore的測試環境，在MaxCompute上，我們會建立一張表並準備1億行資料。TableStore的測試環境規模以及DataX Job宿主機的規格都較小，所以整個實驗最終達到的速率是比較小的，主要為了演示速率如何提升。而在真實的TableStore生產環境上，規模足夠的情況下，我們幫助過應用最佳化到每秒上百M甚至上G的速度，最佳化手段相同。
資料準備
首先在MaxCompute內建立如下表：
md5 string,
userid string,
name string,
comments string,
attr0 string,
attr1 string,
attr2 string,
attr3 string,
create_time string,
udpate_time string
);
其次在表內倒入1億行資料，每行資料約200個位元組，其中userid列採用隨機值，計算出的md5值取4個位元組作為md5列，資料樣例如下：
測試資料匯入使用的是MaxCompute Tunnel，速度還是比較可觀的。
資料準備完畢後，在TableStore上建立一張表，使用md5和userid作為主鍵列：
TableMeta tableMeta = new TableMeta("DataTable");
tableMeta.addPrimaryKeyColumn("md5", PrimaryKeyType.STRING);
tableMeta.addPrimaryKeyColumn("userid", PrimaryKeyType.STRING);
CapacityUnit capacityUnit = new CapacityUnit(0, 0);
CreateTableRequest request = new CreateTableRequest();
request.setTableMeta(tableMeta);
request.setReservedThroughput(capacityUnit);
ots.createTable(request);
表和資料均準備完畢後，使用如下DataX Job配置類進行一次資料匯出：
"job": {
"setting": {
"speed": {
"channel": "1"
}
},
"content": [
{
"reader": {
"name": "odpsreader",
"parameter": {
"accessId": "accessid",
"accessKey": "accesskey",
"project": "aliyun_ots_dev",
"table": "data_for_ots",
"partition": [],
"column": ["md5","userid","name","comments","attr0","attr1","attr2","attr3","create_time","udpate_time"],
"packageAuthorizedProject": "",
"splitMode": "record",
"odpsServer": "****",
"tunnelServer": "****"
}
},
"writer": {
"name": "otswriter",
"parameter": {
"endpoint":"
"accessId":"accessid",
"accessKey":"accesskey",
"instanceName":"data-import-test",
"table":"DataTable",
"primaryKey":[
{"name":"md5", "type":"string"},
{"name":"userid", "type":"string"}
],
"column":[
{"name":"name","type":"string"},
{"name":"comments","type":"string"},
{"name":"attr0","type":"string"},
{"name":"attr1","type":"string"},
{"name":"attr2","type":"string"},
{"name":"attr3","type":"string"},
{"name":"create_time","type":"string"},
{"name":"update_time","type":"string"}
],
"writeMode":"UpdateRow"
}
}
}
]
}
}
啟動DataX任務，從標準輸出中可以看到當前資料匯出的速度：
2017-02-07 08:41:49.285 [job-0] INFO StandAloneJobContainerCommunicator - Total 271520 records, 55194052 bytes | Speed 1.05MB/s, 5404 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 4.501s | All Task WaitReaderTime 47.815s | Percentage 0.00%
2017-02-07 08:41:59.286 [job-0] INFO StandAloneJobContainerCommunicator - Total 324640 records, 65992457 bytes | Speed 1.03MB/s, 5312 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 5.474s | All Task WaitReaderTime 55.068s | Percentage 0.00%
2017-02-07 08:42:09.288 [job-0] INFO StandAloneJobContainerCommunicator - Total 377600 records, 76758462 bytes | Speed 1.03MB/s, 5296 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 6.479s | All Task WaitReaderTime 62.297s | Percentage 0.00%
2017-02-07 08:42:19.289 [job-0] INFO StandAloneJobContainerCommunicator - Total 431072 records, 87628377 bytes | Speed 1.04MB/s, 5347 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 7.469s | All Task WaitReaderTime 69.559s | Percentage 0.00%
2017-02-07 08:42:29.290 [job-0] INFO StandAloneJobContainerCommunicator - Total 484672 records, 98524462 bytes | Speed 1.04MB/s, 5360 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 8.421s | All Task WaitReaderTime 76.892s | Percentage 0.00%
2017-02-07 08:42:39.292 [job-0] INFO StandAloneJobContainerCommunicator - Total 538144 records, 109394175 bytes | Speed 1.04MB/s, 5347 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 9.428s | All Task WaitReaderTime 83.889s | Percentage 0.00%
可以看到，當前的速度大約是1MB/s，接下來會演示如何進行最佳化，一步一步將速度給提升上去。
一：配置合理的DataX基礎引數
第一步是對DataX的幾個基礎引數進行調優，先大致瞭解下一個DataX Job內部，任務的執行結構：
一個DataX Job會切分成多個Task，每個Task會按TaskGroup進行分組，一個Task內部會有一組Reader->Channel->Writer。Channel是連線Reader和Writer的資料交換通道，所有的資料都會經由Channel進行傳輸。
在DataX內部對每個Channel會有嚴格的速度控制，預設的速度限制是1MB/s，這也是為何我們使用預設配置，速度為1MB/s的原因。所以第一個需要最佳化的基礎引數就是單個Channel的速度限制，更改配置如下：
"core": {
"transport": {
"channel": {
"speed": {
"byte": 5242880
}
}
}
},
"job": {
...
}
}
我們把單個Channel的速度上限配置為5MB。這個值需要針對不同的場景進行不同的配置，例如對於MaxCompute，單個Channel的速度可以達到幾十MB，對於TableStore，在列較小較多的場景下，單個Channel的速度是幾MB，而在列較大的場景下，可能速度就會上到幾十MB。
我們當前預設配置中配置啟動的Job內Channel數為1，要提高速度，併發必須提高，這個是第二步要做的最佳化。但是在做第二個最佳化之前，還需要調整一個基礎引數，那就是DataX Job啟動的JVM的記憶體大小配置。
目前DataX啟動的JVM預設的配置是"-Xms1g -Xmx1g"，當一個Job內Channel數變多後，記憶體的佔用會顯著增加，因為DataX作為資料交換通道，在記憶體中會快取較多的資料，例如Channel中會有一個Buffer，作為臨時的資料交換的緩衝區，而在部分Reader和Writer的中，也會存在一些Buffer。
調整JVM引數的方式有兩種，一種是直接更改datax.py，另一種是在啟動的時候，加上對應的引數，如下：
python datax/bin/datax.py --jvm="-Xms8G -Xmx8G" ots.json
通常我們建議將記憶體設定為4G或者8G，這個也可以根據實際情況來調整。
在最佳化完單Channel的限速和JVM的記憶體引數之後，我們重新跑一下任務：
2017-02-07 08:44:53.188 [job-0] INFO StandAloneJobContainerCommunicator - Total 153920 records, 31289079 bytes | Speed 1.67MB/s, 8608 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 2.873s | All Task WaitReaderTime 12.098s | Percentage 0.00%
2017-02-07 08:45:03.189 [job-0] INFO StandAloneJobContainerCommunicator - Total 256064 records, 52051995 bytes | Speed 1.98MB/s, 10214 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 4.892s | All Task WaitReaderTime 17.194s | Percentage 0.00%
2017-02-07 08:45:13.191 [job-0] INFO StandAloneJobContainerCommunicator - Total 360864 records, 73356370 bytes | Speed 2.03MB/s, 10480 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 9.221s | All Task WaitReaderTime 19.192s | Percentage 0.00%
2017-02-07 08:45:23.192 [job-0] INFO StandAloneJobContainerCommunicator - Total 464384 records, 94400221 bytes | Speed 2.01MB/s, 10352 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 11.754s | All Task WaitReaderTime 22.278s | Percentage 0.00%
2017-02-07 08:45:33.194 [job-0] INFO StandAloneJobContainerCommunicator - Total 570176 records, 115905214 bytes | Speed 2.05MB/s, 10579 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 14.827s | All Task WaitReaderTime 25.367s | Percentage 0.00%
2017-02-07 08:45:43.195 [job-0] INFO StandAloneJobContainerCommunicator - Total 675328 records, 137281049 bytes | Speed 2.04MB/s, 10515 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 18.515s | All Task WaitReaderTime 27.810s | Percentage 0.00%
2017-02-07 08:45:53.197 [job-0] INFO StandAloneJobContainerCommunicator - Total 778752 records, 158304152 bytes | Speed 2.00MB/s, 10342 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 20.403s | All Task WaitReaderTime 32.418s | Percentage 0.00%
當前資料匯出的速度已經從1MB提升到2MB。
二：提升DataX Job內Channel併發
在上一點中指出，當前Job內部，只有單個Channel在執行匯出任務，而要提升速率，要做的就是提升Channel的併發數。
DataX內部對每個Channel會做限速，可以限制每秒byte數，也可以限制每秒record數。除了對每個Channel限速，在全域性還會有一個速度限制的配置，預設是不限。
提升Channel併發數有三種途徑：
1， 配置全域性Byte限速以及單Channel Byte限速，Channel個數 = 全域性Byte限速 / 單Channel Byte限速。（下面示例中最終Channel個數為10）
"core": {
"transport": {
"channel": {
"speed": {
"byte": 1048576
}
}
}
},
"job": {
"setting": {
"speed": {
"byte" : 10485760
}
},
...
}
}
2，配置全域性Record限速以及單Channel Record限速，Channel個數 = 全域性Record限速 / 單Channel Record限速。（下面示例中最終Channel個數為3）
"core": {
"transport": {
"channel": {
"speed": {
"record": 100
}
}
}
},
"job": {
"setting": {
"speed": {
"record" : 300
}
},
...
}
}
3， 全域性不限速，直接配置Channel個數。（下面示例中最終Channel個數為5）
"core": {
"transport": {
"channel": {
"speed": {
"byte": 1048576
}
}
}
},
"job": {
"setting": {
"speed": {
"channel" : 5
}
},
...
}
}
第三種方式最簡單直接，但是這樣就缺少了全域性的限速。在選擇Channel個數時，同樣需要注意，Channel個數並不是越多越好。Channel個數的增加，帶來的是更多的CPU消耗以及記憶體消耗。如果Channel併發配置過高導致JVM記憶體不夠用，會出現的情況是發生頻繁的Full GC，匯出速度會驟降，適得其反。
可以在DataX的輸出日誌中，找到本次任務的Channel的數：
2017-02-07 13:27:45.016 [job-0] INFO JobContainer - DataX Reader.Job [odpsreader] splits to [15] tasks.
2017-02-07 13:27:45.017 [job-0] INFO OtsWriterMasterProxy - Begin split and MandatoryNumber : 15
2017-02-07 13:27:45.025 [job-0] INFO OtsWriterMasterProxy - End split.
2017-02-07 13:27:45.025 [job-0] INFO JobContainer - DataX Writer.Job [otswriter] splits to [15] tasks.
在我們這次實驗中，我們把Channel數直接配置為10，再進行一次匯出：
2017-02-07 08:58:24.366 [job-0] INFO StandAloneJobContainerCommunicator - Total 2465984 records, 501286700 bytes | Speed 9.19MB/s, 47414 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 362.875s | All Task WaitReaderTime 378.978s | Percentage 0.00%
2017-02-07 08:58:34.368 [job-0] INFO StandAloneJobContainerCommunicator - Total 2941792 records, 598009404 bytes | Speed 9.22MB/s, 47580 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 459.910s | All Task WaitReaderTime 379.002s | Percentage 0.00%
2017-02-07 08:58:44.369 [job-0] INFO StandAloneJobContainerCommunicator - Total 3436064 records, 698484741 bytes | Speed 9.58MB/s, 49427 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 556.324s | All Task WaitReaderTime 379.026s | Percentage 0.00%
2017-02-07 08:58:54.371 [job-0] INFO StandAloneJobContainerCommunicator - Total 3905856 records, 793982836 bytes | Speed 9.11MB/s, 46979 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 652.749s | All Task WaitReaderTime 379.050s | Percentage 0.00%
2017-02-07 08:59:04.372 [job-0] INFO StandAloneJobContainerCommunicator - Total 4384512 records, 891284760 bytes | Speed 9.28MB/s, 47865 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 749.464s | All Task WaitReaderTime 379.074s | Percentage 0.00%
2017-02-07 08:59:14.373 [job-0] INFO StandAloneJobContainerCommunicator - Total 4875136 records, 991017582 bytes | Speed 9.51MB/s, 49062 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 846.522s | All Task WaitReaderTime 379.098s | Percentage 0.00%
可以看到在Channel數從1提升到10之後，速度從2MB/s提升到了9MB/s。此時若再提高Channel數到15，速度已經不見漲，而從服務端監控看，每批次匯入的寫入延遲確在漲，說明當前瓶頸在TableStore寫入端。
三：對TableStore表進行預分割槽，並進一步提升DataX Channel併發
在上面幾個最佳化做完後，DataX資料交換這一環節已經不是瓶頸，當前瓶頸在TableStore端的寫入能力上。TableStore是分散式的儲存，一張大表會被切分成很多的分割槽，分割槽會分散到後端的各個物理機上提供服務。一張新建立的表，預設分割槽數為1，當這張表越來越大，TableStore會將其分裂，此時分裂是自動完成的。分割槽的個數，一定程度上與能提供的服務能力相關。某些業務場景，新建表後，就需要對錶進行大規模的資料匯入，此時預設的單個分割槽肯定是不夠用的，當然可以等資料量慢慢漲上來後等表自動分裂，但是這個週期會比較長。此時，我們推薦的做法是在建立表的時候進行預分割槽。
不過目前我們還沒有對外開放透過SDK來進行預分割槽的功能，所以如果需要對錶進行預分割槽，可以先透過工單來聯絡我們幫助進行預分割槽。
我們新建一張表，並將表預分4個分割槽，partition key為md5列，採用md5列的主要原因是在其上資料的分割槽基本是均勻的。如果資料在partition key分佈不均勻，則即使做了預分割槽，匯入效能也不會得到明顯的提升。以相同的Job配置，再跑一下匯出任務：
2017-02-08 13:48:18.692 [job-0] INFO StandAloneJobContainerCommunicator - Total 11395424 records, 2316456451 bytes | Speed 18.79MB/s, 96940 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 666.003s | All Task WaitReaderTime 336.048s | Percentage 0.00%
2017-02-08 13:48:28.693 [job-0] INFO StandAloneJobContainerCommunicator - Total 12340192 records, 2508508780 bytes | Speed 18.32MB/s, 94476 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 716.743s | All Task WaitReaderTime 349.424s | Percentage 0.00%
2017-02-08 13:48:38.694 [job-0] INFO StandAloneJobContainerCommunicator - Total 13197472 records, 2682776109 bytes | Speed 16.62MB/s, 85728 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 776.487s | All Task WaitReaderTime 359.132s | Percentage 0.00%
2017-02-08 13:48:48.695 [job-0] INFO StandAloneJobContainerCommunicator - Total 14085856 records, 2863367678 bytes | Speed 17.22MB/s, 88838 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 826.191s | All Task WaitReaderTime 378.034s | Percentage 0.00%
2017-02-08 13:48:58.696 [job-0] INFO StandAloneJobContainerCommunicator - Total 15063328 records, 3062065378 bytes | Speed 18.95MB/s, 97747 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 867.363s | All Task WaitReaderTime 401.640s | Percentage 0.00%
2017-02-08 13:49:08.697 [job-0] INFO StandAloneJobContainerCommunicator - Total 15908736 records, 3233917750 bytes | Speed 16.39MB/s, 84540 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 921.193s | All Task WaitReaderTime 418.862s | Percentage 0.00%
此時速度從9MB/s提升到18MB/s左右，在TableStore服務端能夠提高更多的服務能力後，我們嘗試再將Channel的併發從10提高到15：
2017-02-08 13:51:54.546 [job-0] INFO StandAloneJobContainerCommunicator - Total 8194848 records, 1665844036 bytes | Speed 20.97MB/s, 108160 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 884.016s | All Task WaitReaderTime 263.742s | Percentage 0.00%
2017-02-08 13:52:04.547 [job-0] INFO StandAloneJobContainerCommunicator - Total 9351040 records, 1900875263 bytes | Speed 22.41MB/s, 115619 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 1,007.206s | All Task WaitReaderTime 263.789s | Percentage 0.00%
2017-02-08 13:52:14.548 [job-0] INFO StandAloneJobContainerCommunicator - Total 10460064 records, 2126318844 bytes | Speed 21.50MB/s, 110902 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 1,140.113s | All Task WaitReaderTime 263.824s | Percentage 0.00%
2017-02-08 13:52:24.549 [job-0] INFO StandAloneJobContainerCommunicator - Total 11662112 records, 2370669233 bytes | Speed 23.30MB/s, 120204 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 1,269.070s | All Task WaitReaderTime 263.863s | Percentage 0.00%
2017-02-08 13:52:34.550 [job-0] INFO StandAloneJobContainerCommunicator - Total 12874240 records, 2617069638 bytes | Speed 23.50MB/s, 121212 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 1,396.991s | All Task WaitReaderTime 263.913s | Percentage 0.00%
此時速度又進一步提升，從18MB/s提升到22MB/s左右。
四：提高每次批次寫行數
我們構建的場景，每行大約是200位元組左右大小。DataX的OTSWriter寫入外掛底層是使用的TableStore SDK提供的BatchWrite介面進行資料寫入，預設一次請求寫入100行資料，也就是說一次請求只會匯入約20KB大小的資料。每次寫過來的資料包都比較小，非常的不經濟。
當前TableStore的BatchWrite的限制比較不靈活，會限制行數和資料大小，其中行數預設上限是200行。在每行都比較小的場景下，200行一次批次寫入是非常不經濟的，在我們的這次實驗中，我們將上限改為1000行，並將DataX TableStore寫入外掛內部一次批次寫入的行數也改為1000行，來驗證將每次寫入的包變大後，對寫入效率的提升。任務配置更改如下（配置項為job.content.writer.parameter.batchWriteCount）：
"job": {
"content": [
{
"reader": {
...
},
"writer": {
"name": "otswriter",
"parameter": {
"batchWriteCount":1000,
...
}
}
}
]
}
}
再次執行任務，速度如下：
2017-02-08 13:55:16.924 [job-0] INFO StandAloneJobContainerCommunicator - Total 11413216 records, 2320073926 bytes | Speed 29.44MB/s, 151849 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 72.662s | All Task WaitReaderTime 1,030.787s | Percentage 0.00%
2017-02-08 13:55:36.925 [job-0] INFO StandAloneJobContainerCommunicator - Total 14462240 records, 2939879188 bytes | Speed 29.55MB/s, 152451 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 85.228s | All Task WaitReaderTime 1,297.655s | Percentage 0.00%
2017-02-08 13:55:46.927 [job-0] INFO StandAloneJobContainerCommunicator - Total 15979552 records, 3248317815 bytes | Speed 29.41MB/s, 151731 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 89.841s | All Task WaitReaderTime 1,432.022s | Percentage 0.00%
2017-02-08 13:55:56.928 [job-0] INFO StandAloneJobContainerCommunicator - Total 17488864 records, 3555129299 bytes | Speed 29.26MB/s, 150931 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 100.300s | All Task WaitReaderTime 1,558.120s | Percentage 0.00%
2017-02-08 13:56:06.929 [job-0] INFO StandAloneJobContainerCommunicator - Total 19018240 records, 3866017412 bytes | Speed 29.65MB/s, 152937 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 106.391s | All Task WaitReaderTime 1,691.072s | Percentage 0.00%
速度再次提升，從22MB/s提升到29MB/s。TableStore後續會最佳化對BatchWrite的行數限制，對於行比較小的場景採用一個比較友好的策略。
五：MaxCompute表分割槽，提高DataX Job併發
以上最佳化策略都是在單個DataX Job的場景下進行的最佳化，單個DataX Job只能夠執行在單臺伺服器上，沒有辦法分散式的執行。D2上的託管伺服器，一般是千兆網路卡，也就是說最多提供100MB/s的速度。若想要進一步的速度提升，則必須採用多個DataX Job分佈在多臺伺服器上執行才行。
DataX內的ODPSReader，可以透過配置一次匯出整張表或者表的某個Partition。我們可以利用Partition，來將一張表拆分成多個Job分散匯出，但是要求表必須是多分割槽的。
在我們的實驗中，建立的MaxCompute表並不是多分割槽的，我們重新建立一張多分割槽的表：
md5 string,
userid string,
name string,
comments string,
attr0 string,
attr1 string,
attr2 string,
attr3 string,
create_time string,
udpate_time string
)
PARTITIONED BY (
partid string
)
增加一列為partid，作為分割槽，我們透過一個SQL將原表的資料匯入到新表，並自動均勻的分散到partid：
attr0, attr1, attr2, attr3, create_time, udpate_time, SUBSTR(md5, 1, 1) from data_for_ots;
以上SQL會將partid的值取自md5列的第一個字元，md5是一個十六進位制的值，字元的取值範圍是：0-f，這樣我們就將原表切成了一個帶16個分割槽的表。我們希望在每個分割槽內，資料都是均勻的，為了避免長尾，這也是為什麼要設計一個md5列的原因。
在將一張表拆成多個分割槽後，我們就可以選擇在不同的伺服器上，為每個分割槽啟動一個任務，配置如下(job.content.reader.parameter.partition)：
"job": {
"content": [
{
"reader": {
"name": "odpsreader",
"parameter": {
...
"partition": ["partid=0"],
...
}
},
"writer": {
...
}
}
]
}
}
由於測試叢集規模的原因，我們不演示多個Job併發後的速度提升。在TableStore服務端能力不是瓶頸的情況下，透過擴充套件DataX Job的併發，速度是能線性提升的。
END
總結下上面的幾個最佳化點：
對DataX的幾個基本引數進行調整，包括：Channel數、單個Channel的限速以及JVM的記憶體引數。
建立TableStore表的時候儘量採取預分割槽，在設計partition key的時候儘量保證在每個partition key上匯入資料的分佈均勻。
如果匯入TableStore的資料行都比較小，則需要考慮提高單批次的匯入行數。
若單個DataX Job已成瓶頸，則需要考慮將任務拆成多個DataX Job並行執行。
希望以上經驗對各位有用，歡迎交流。
本文為雲棲社群原創內容，未經允許不得轉載。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69922229/viewspace-2644337/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 用DataX導資料到Clickhouse遇到的坑
- 資料同步Datax與Datax_web的部署以及使用說明Web
- 使用SeaTunnel從InfluxDB同步資料到DorisUX
- 使用canal.adapter同步資料到MySQLAPTMySql
- 基於DataX的資料同步（下）-應用DataX進行資料同步
- 異構資料來源同步之資料同步 → DataX 使用細節
- 資料同步工具Sqoop和DataXOOP
- flinkcdc同步mysql資料到selectdbMySql
- 基於DataX的資料同步（上）-DataX介紹以及安裝
- 異源資料同步 → 如何獲取 DataX 已同步資料量？
- MaxCompute Mars開發指南
- Logstash7.6.2同步Mysql資料到ElasticSearchMySqlElasticsearch
- mysql 如何毫秒級同步資料到 elasticsearchMySqlElasticsearch
- 異構資料來源同步之資料同步 → datax 改造，有點意思
- MaxCompute安全管理指南-案例篇
- ogg 同步pg資料到oracle--步驟Oracle
- Flink同步Kafka資料到ClickHouse分散式表Kafka分散式
- TDengine可通過資料同步工具 DataX讀寫
- 異源資料同步 → DataX 同步啟動後如何手動終止？
- DataX將MySql資料庫資料同步到Oracle資料庫MySql資料庫Oracle
- docker搭建Elasticsearch、Kibana、Logstash 同步mysql資料到ESDockerElasticsearchMySql
- 從物件儲存服務同步資料到Elasticsearch物件Elasticsearch
- MaxCompute 圖計算開發指南
- DataX將Oracle資料庫資料同步到達夢資料庫Oracle資料庫
- 表格儲存Tablestore權威指南（持續更新）
- Flinkx實時和離線同步Postgresql資料到KafkaSQLKafka
- 阿里的又一款資料高效同步工具DataX，真香！阿里
- 使用dataX遇到的坑
- 比Sqoop功能更加強大開源資料同步工具DataX實戰OOP
- 使用Flume消費Kafka資料到HDFSKafka
- 使用DataLakeAnalytics從OSS清洗資料到AnalyticDB
- KunlunDB 快速入門 4.0（從Oracle實時同步資料到kunlunDB）Oracle
- 異構資料來源資料同步 → 從原始碼分析 DataX 敏感資訊的加解密原始碼解密
- [資料整合/資料同步] 基於資料庫增量日誌的資料同步方案 : Flink CDC/Debezium/DataX/Canal/Oracle Goldengate/Kettle/Sqoop資料庫OracleGoOOP
- ORACLE(Linux版本)實時同步資料到MYSQL(Linux版本)解決方案：OGGOracleLinuxMySql
- 阿里雲大資料計算服務MaxCompute使用教程阿里大資料
- 大資料技術 - DataX大資料
- 使用Data Lake Analytics從OSS清洗資料到AnalyticDB