All Products
Search

This Product

    AnalyticDB:Optimalkan kinerja impor data

    Document Center

    AnalyticDB:Optimalkan kinerja impor data

    Last Updated:Mar 25, 2026

    AnalyticDB for MySQL menyediakan berbagai metode impor data untuk berbagai skenario. Namun, kinerja impor dapat terpengaruh oleh beberapa faktor, seperti pemodelan tabel yang tidak tepat sehingga menyebabkan data skew atau pemanfaatan resource yang tidak efisien akibat konfigurasi impor yang suboptimal. Topik ini menjelaskan cara mengoptimalkan kinerja impor data dalam berbagai skenario.

    Optimalkan impor data dari tabel eksternal

    Bagian ini menggunakan contoh—mengimpor data TPC-H lineitem sebesar 1 TB (sekitar 6 miliar record) dari tabel eksternal—untuk menunjukkan cara menyetel pekerjaan impor agar mencapai kinerja optimal. Untuk informasi lebih lanjut tentang impor data, lihat INSERT OVERWRITE SELECT.

    Distribution key

    Distribution key menentukan bagaimana data di-shard saat diimpor, dan sebuah tabel diimpor secara konkuren di seluruh shard-nya. Jika data didistribusikan secara tidak merata, shard dengan data terbanyak dapat menjadi bottleneck, menyebabkan data skew dan menurunkan kinerja seluruh pekerjaan impor. Untuk mencegah masalah ini, pastikan data didistribusikan secara merata selama impor. Untuk informasi lebih lanjut tentang cara memilih distribution key, lihat Select a distribution key.

    Untuk menentukan apakah distribution key yang dipilih sesuai:

    • Sebelum mengimpor data, evaluasi logika bisnis dari distribution key yang Anda pilih. Misalnya, pada tabel Lineitem, jika Anda memilih kolom l_discount sebagai distribution key, kardinalitas nilai diskon pesanan sangat rendah—hanya terdapat 11 nilai unik. Data dengan nilai l_discount yang sama akan didistribusikan ke shard yang sama, sehingga menyebabkan data skew parah dan menurunkan kinerja impor. Memilih kolom l_orderkey merupakan pilihan yang lebih baik karena ID pesanan bersifat unik, sehingga menghasilkan distribusi data yang lebih merata.

    • Setelah mengimpor data, periksa Diagnostik Pemodelan Data untuk mendeteksi data skew. Skew menunjukkan bahwa distribution key yang dipilih mendistribusikan data secara tidak merata. Untuk informasi tentang cara melihat diagnostik distribution key, lihat Storage space diagnostics.

    Partition key

    Pernyataan INSERT OVERWRITE SELECT menimpa data yang sudah ada. Saat Anda mengimpor data, data baru untuk suatu partisi akan menimpa data yang ada di partisi target dengan nama yang sama. Di dalam setiap shard, data diimpor ke partisi masing-masing berdasarkan definisi partition key. Untuk menghindari penurunan kinerja akibat external sorting, jangan mengimpor terlalu banyak partisi sekaligus. Untuk informasi lebih lanjut tentang cara memilih partition key, lihat Select a partition key.

    Untuk menentukan apakah partition key yang dipilih sesuai:

    • Sebelum mengimpor data, evaluasi apakah partition key tersebut sesuai berdasarkan kebutuhan bisnis dan distribusi data Anda. Misalnya, jika tabel Lineitem dipartisi berdasarkan kolom l_shipdate dan datanya mencakup tujuh tahun, mempartisi berdasarkan tahun akan menghasilkan 7 partisi. Mempartisi berdasarkan hari akan menghasilkan lebih dari 2.000 partisi, dengan sekitar 30 juta record per partisi. Dalam kasus ini, mempartisi berdasarkan bulan atau tahun lebih sesuai.

    • Setelah mengimpor data, periksa Diagnostik Pemodelan Data untuk mendeteksi masalah partisi. Masalah tersebut menunjukkan bahwa partition key yang dipilih tidak sesuai. Untuk informasi tentang cara melihat diagnostik partition key, lihat Partitioned table diagnostics.

    Index

    Secara default, AnalyticDB for MySQL membuat index pada semua kolom saat tabel dibuat. Membangun index penuh untuk tabel lebar mengonsumsi resource. Saat Anda mengimpor data ke tabel lebar, kami menyarankan Anda menggunakan primary key index. Primary key index digunakan untuk deduplikasi data. Menggunakan terlalu banyak kolom dalam primary key dapat menurunkan kinerja deduplikasi. Untuk informasi lebih lanjut tentang cara memilih primary key, lihat Select a primary key.

    Untuk menentukan apakah index yang digunakan sesuai:

    • Dalam skenario impor batch, Anda tidak perlu menentukan primary key index karena data biasanya telah dideduplikasi selama komputasi batch.

    • Pada tab Monitoring Information > Table Information Statistics, lihat ukuran data tabel, data index, dan data primary key index. Jika data index lebih besar daripada data tabel, periksa apakah tabel berisi kolom dengan nilai string panjang. Membuat index pada kolom semacam itu memakan waktu lama dan mengonsumsi ruang penyimpanan yang signifikan. Anda dapat menghapus index tersebut. Untuk informasi lebih lanjut, lihat ALTER TABLE.

      Catatan

      Primary key index tidak dapat dihapus. Anda harus membuat ulang tabel tersebut.

    Percepat impor dengan hints

    Anda dapat menambahkan hint direct_batch_load=true ke pernyataan impor untuk mempercepat proses impor.

    Catatan

    Hanya klaster elastis Data Warehouse Edition (V3.0) yang menjalankan kernel versi 3.1.5 atau lebih baru yang mendukung hint ini. Jika Anda menggunakan hint ini tetapi kinerja impor tidak meningkat secara signifikan, Submit a ticket.

    Contoh:

    SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;

    Percepat dengan elastic import

    Catatan

    • Elastic import hanya didukung untuk klaster yang menjalankan kernel versi 3.1.10.0 atau lebih baru.

    • Elastic import didukung untuk klaster Enterprise Edition, Basic Edition, dan Data Lakehouse Edition (V3.0) yang telah memiliki job resource group.

    • Elastic import hanya mendukung data dari MaxCompute dan data yang disimpan di OSS dalam format CSV, Parquet, atau ORC.

    • Saat menggunakan elastic import, pastikan job resource group memiliki resource yang cukup untuk mencegah waktu tunggu yang lama, eksekusi yang berkepanjangan, atau kegagalan pekerjaan.

    Elastic import memungkinkan Anda menjalankan beberapa pekerjaan impor secara konkuren. Anda juga dapat mempercepat satu pekerjaan impor dengan mengalokasikan lebih banyak resource kepadanya. Untuk informasi lebih lanjut, lihat Data import methods.

    Contoh:

    /*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;

    Untuk informasi lebih lanjut tentang parameter tersebut, lihat Hint parameters.

    Optimalkan impor data dari DataWorks

    Optimalkan konfigurasi pekerjaan

    • Optimalkan Data Records Per Write

      Parameter ini menentukan ukuran batch untuk setiap operasi write. Kami menyarankan untuk mempertahankan nilai default ini.

      Namun, jika ukuran satu record besar, misalnya 512 KB, kami menyarankan Anda mengatur parameter ini ke 16. Hal ini memastikan setiap batch tidak melebihi 8 MB dan mencegah penggunaan memori tinggi pada node frontend.

    • Optimalkan channel control

      • Kinerja sinkronisasi data secara langsung berkaitan dengan nilai Expected Maximum Concurrency. Kami menyarankan untuk menaikkan nilai ini sebanyak mungkin sesuai dengan beban kerja Anda.

        Penting

        Semakin tinggi nilai Expected Maximum Concurrency, semakin banyak resource DataWorks yang dikonsumsi. Pilih nilai yang sesuai dengan beban kerja Anda.

      • Aktifkan Distributed Execution untuk kinerja sinkronisasi yang lebih baik.

    Permasalahan umum dan solusi

    • Tekanan write sisi client tidak mencukupi: Jika client tidak mengirim data cukup cepat, resource klaster seperti utilisasi CPU dan penggunaan I/O disk tetap rendah. Meskipun server database dapat memproses data yang diterima dengan cepat, TPS write keseluruhan mungkin tidak memenuhi ekspektasi karena volume data total yang rendah.

      Solusi: Tingkatkan nilai Data Records Per Write dan Expected Maximum Concurrency. Kinerja impor data meningkat seiring dengan meningkatnya tekanan write sisi client.

    • Data skew pada tabel target: Jika tabel target mengalami data skew, beberapa node klaster menjadi kelebihan beban, sehingga menurunkan kinerja impor. Dalam kasus ini, utilisasi CPU dan penggunaan I/O disk rendah, tetapi waktu respons write tinggi. Anda juga dapat mengidentifikasi tabel yang skew pada halaman Diagnostics and Optimization > Data Modeling Diagnostics.

      Solusi: Rancang ulang skema tabel, lalu impor ulang data tersebut. Untuk informasi lebih lanjut, lihat Design a table schema.

    Optimalkan impor data JDBC

    Optimasi sisi client

    • Bundel data di sisi client untuk bulk inserts

      • Saat Anda mengimpor data secara programatik menggunakan JDBC, kami menyarankan untuk mengelompokkan record guna mengurangi overhead jaringan dan koneksi. Hindari memasukkan satu record kecuali benar-benar diperlukan.

      • Kami menyarankan ukuran batch sebanyak 2.048 record. Jika ukuran satu record besar, misalnya ratusan kilobita, pastikan ukuran total batch tetap di bawah 8 MB. Anda dapat menghitung jumlah record per batch dengan membagi 8 MB dengan ukuran satu record. Batch yang terlalu besar dapat mengonsumsi terlalu banyak memori pada node frontend dan menurunkan kinerja impor.

    • Konfigurasi konkurensi sisi client

      • Saat Anda mengimpor data dari aplikasi client, kami menyarankan menggunakan beberapa thread konkuren. Satu proses tidak dapat memanfaatkan resource sistem secara maksimal dan sering kali kesulitan mengimbangi kecepatan ingestion database karena pemrosesan dan pengelompokan data di sisi client. Menggunakan beberapa thread konkuren dapat mempercepat kecepatan impor secara signifikan.

      • Jumlah optimal thread konkuren bergantung pada berbagai faktor seperti pengelompokan, sumber data, dan beban mesin client. Tidak ada nilai terbaik tunggal. Kami menyarankan menentukan tingkat konkurensi optimal melalui pengujian. Jika kecepatan impor tidak memuaskan, coba gandakan jumlah thread konkuren. Jika kecepatan kemudian menurun, kurangi secara bertahap hingga Anda menemukan jumlah optimal.

    Permasalahan umum dan solusi

    Jika Anda mengalami kinerja buruk saat mengimpor data secara programatik ke AnalyticDB for MySQL, pertama-tama periksa sisi client untuk mengidentifikasi bottleneck.

    • Pastikan sumber data dapat menghasilkan data dengan laju tinggi. Jika sumber data adalah sistem lain atau kumpulan file, periksa adanya bottleneck output di sisi client.

    • Pastikan kecepatan pemrosesan data tinggi. Periksa apakah produksi dan konsumsi data tersinkronisasi, serta pastikan cukup banyak data siap untuk diimpor ke AnalyticDB for MySQL.

    • Periksa beban mesin client. Pastikan resource sistem, seperti utilisasi CPU dan penggunaan I/O disk, mencukupi.