Lindorm：Akses data berorientasi kolom

Informasi latar belakang

Penyimpanan berorientasi kolom Lindorm adalah layanan penyimpanan terdistribusi berbasis kolom. Penyimpanan berorientasi kolom cocok untuk menyimpan sejumlah besar data semi-terstruktur dan terstruktur dalam skenario seperti Internet of Vehicles (IoV), Internet of Things (IoT), pesanan, dan log. Penyimpanan berorientasi kolom menyediakan kemampuan inti berikut:

• Komputasi dan Analitik

  Mesin komputasi Lindorm dapat mengakses data berorientasi kolom untuk melakukan analitik interaktif dan komputasi online. Penyimpanan berorientasi kolom menyediakan fitur distribusi data dan kemampuan pengindeksan yang kaya, yang secara efektif mempercepat penempatan dan pengaturan data dalam proses komputasi. Anda dapat menambah, menghapus, memodifikasi, dan mengkueri sejumlah besar data kunci utama menggunakan Pernyataan SQL.

• Throughput Tinggi

  Penyimpanan berorientasi kolom mendukung penskalaan horizontal dan menyediakan kemampuan untuk membaca dan menulis data terabyte per menit. Hal ini membuatnya cocok untuk skenario data throughput tinggi seperti impor cepat data IoV, akses set data pelatihan model, dan analisis serta produksi laporan skala besar.

• Efisiensi Biaya

  Lindorm mengimplementasikan teknologi seperti algoritma rasio kompresi tinggi berbasis kolom, media berbiaya rendah berdensitas tinggi, pemisahan data panas dan dingin, pengkodean kompresi, dan penyimpanan arsip data dingin. Dibandingkan dengan penyimpanan yang dikelola sendiri, penyimpanan berorientasi kolom Lindorm secara signifikan mengurangi biaya penyimpanan, memungkinkan Anda mengarsipkan dan menyimpan sejumlah besar data dengan biaya lebih rendah.

• Ketersediaan Tinggi

  Dengan menggunakan teknologi seperti kode penghapusan, penyimpanan berorientasi kolom Lindorm memastikan ketersediaan tinggi dataset terdistribusi dan menghilangkan risiko titik kegagalan tunggal (SPOF).

• Kompatibilitas dengan Layanan Open Source

  Penyimpanan berorientasi kolom kompatibel dengan beberapa API standar open source, seperti API Iceberg. Penyimpanan berorientasi kolom juga dapat terhubung ke mesin komputasi seperti Spark dan Flink. Dengan cara ini, penyimpanan berorientasi kolom dapat diintegrasikan secara mulus ke dalam ekosistem data mainstream.

• Pemisahan Data Panas dan Dingin

  Anda dapat menyimpan data panas dan dingin pada media penyimpanan yang berbeda berdasarkan kebutuhan bisnis Anda. Ini membantu mengurangi overhead kinerja yang disebabkan oleh akses ke data dingin, sambil secara efektif menurunkan biaya penyimpanan.

Prasyarat

• Anda telah membaca Perhatian.

• Bergantung pada mode pekerjaan, pastikan Anda telah menyelesaikan operasi berikut:

  • Pekerjaan JDBC: Gunakan JDBC dalam pengembangan aplikasi.

  • Pekerjaan JAR: Buat pekerjaan di Java.

  • Pekerjaan Python: Buat pekerjaan di Python.

• Jika Anda ingin menggunakan fitur pemisahan data panas dan dingin, pastikan Anda telah mengaktifkan Penyimpanan Kapasitas. Untuk informasi lebih lanjut, lihat Aktifkan Penyimpanan Kapasitas.

Deskripsi fitur

DDL

DML

Penyimpanan data panas dan dingin

Dalam kebanyakan kasus, data yang sering diakses disimpan dalam penyimpanan berperforma tinggi dan data historis yang jarang diakses dipindahkan ke penyimpanan berbiaya rendah. Ini membantu mengurangi biaya penyimpanan dan meningkatkan kinerja. Lindorm mendukung pemisahan data panas dan dingin pada tiga level: L1, L2, dan L3. Anda dapat mengembangkan kebijakan untuk konversi antara data panas dan dingin berdasarkan kebutuhan bisnis Anda. Anda dapat menggunakan layanan danau data untuk secara otomatis membuang data antara penyimpanan data panas dan dingin. Ini membantu Anda mengelola biaya penyimpanan secara efektif tanpa memperpanjang waktu respons layanan utama.

Parameter

Saat Anda membuat tabel berorientasi kolom, Anda dapat menentukan atribut CHS (Cold or Hot Storage) untuk menentukan cara membuang data antara penyimpanan dingin dan panas berdasarkan partisi waktu tabel berorientasi kolom. Tabel berikut menjelaskan cara mengonfigurasi parameter CHS.

Contoh

• Contoh 1:

  Buat tabel bernama table0. Nama bidang partisi adalah tahun, bulan, dan hari. Berdasarkan kebijakan pemisahan data panas dan dingin yang Anda tentkan, data yang disimpan satu bulan (2.592.000 detik) lalu secara otomatis dibuang ke Penyimpanan Kapasitas. Anda dapat mengeksekusi pernyataan berikut untuk membuat tabel:

  CREATE TABLE table0 (col0 INT,year STRING,month STRING,day STRING)
  PARTITIONED BY  (year,month)
  TBLPROPERTIES 
  'CHS'='2592000',
  'CHS_L2'='storagetype=CAPACITY_CLOUD_STORAGE',
  'CHS_EXP'='toSec(year,yyyy,month,MM,day,dd)'
  );

• Contoh 2:

  Ubah kebijakan pemisahan data panas dan dingin dari table0. Setelah perubahan, data yang disimpan satu bulan (2.592.000 detik) lalu secara otomatis dibuang ke Penyimpanan Kapasitas, dan data yang disimpan tiga bulan (5.184.000 detik) lalu secara otomatis dibuang ke penyimpanan arsip. Anda dapat mengeksekusi pernyataan berikut untuk memperbarui tabel:

  ALTER TABLE table0
  SET TBLPROPERTIES (
  'CHS'='2592000,5184000',
  'CHS_L2'='storagetype=CAPACITY_CLOUD_STORAGE',
  'CHS_L3'='storagetype=CLOUD_ARCHIVE_STORAGE',
  'CHS_EXP'='toSec(year,yyyy,month,MM,day,dd)'
  );

• Contoh 3:

  Buat tabel bernama table1. Nama bidang partisi adalah dt. Contoh: 2020/12/1. Berdasarkan kebijakan pemisahan data panas dan dingin yang Anda tentukan, data yang disimpan satu bulan (2.592.000 detik) lalu secara otomatis dibuang ke Penyimpanan Kapasitas, dan data yang disimpan tiga bulan (5.184.000 detik) lalu secara otomatis dibuang ke penyimpanan arsip. Anda dapat mengeksekusi pernyataan berikut untuk membuat tabel:

  CREATE TABLE table1 (col0 INT,dt STRING)
  PARTITIONED BY  (dt)
  TBLPROPERTIES (
  'CHS'='2592000,5184000',
  'CHS_L2'='storagetype=CAPACITY_CLOUD_STORAGE',
  'CHS_L3'='storagetype=CLOUD_ARCHIVE_STORAGE',
  'CHS_EXP'='toSec(dt,yyyy/MM/dd)'
  );

Perhatian

• Anda dapat menentukan parameter CHS saat membuat tabel. Jika Anda ingin mengubah kebijakan pemisahan data panas dan dingin, Anda dapat mengeksekusi pernyataan ALTER TABLE ...SET TBLPROPERTIES....

• Jika Anda menentukan parameter CHS dengan salah, tabel dapat dibuat dan diperbarui sesuai harapan, tetapi data tidak dapat dibuang secara otomatis antara penyimpanan dingin dan panas.

• Pembuangan data panas dan dingin dipicu dalam mode asinkron. Selama dan setelah pembuangan data, akses data tidak terpengaruh, tetapi kinerja akses mungkin bervariasi berdasarkan media penyimpanan yang berbeda.

• Anda hanya dapat mengimplementasikan kebijakan pemisahan data panas dan dingin berdasarkan partisi waktu dalam tabel berorientasi kolom.

Praktik terbaik

Anda dapat menggunakan metode berikut untuk mempercepat kueri atau komputasi data.

Tentukan kunci utama

Jika sejumlah besar dataset disimpan dalam tabel, Anda dapat menentukan kunci utama untuk mempercepat kueri. Rentang data kunci utama yang lebih kecil memberikan hasil percepatan yang lebih baik.

Dalam contoh ini, tabel sampel dibuat dengan mengeksekusi pernyataan berikut:

USE lindorm_columnar;
CREATE TABLE orders (
o_orderkey       INT NOT NULL,
o_custkey        INT,
o_orderstatus    STRING,
o_totalprice     DOUBLE,
o_orderdate      STRING,
o_orderpriority  STRING,
o_clerk          STRING,
o_shippriority   INT,
o_comment        STRING)
PARTITIONED BY (bucket(1024,o_orderkey))
TBLPROPERTIES(
'primary-key' = 'o_orderkey');           

• Contoh 1:

  USE lindorm_columnar;
  SELECT * FROM orders WHERE o_orderkey=18394;

• Contoh 2:

  USE lindorm_columnar;
  SELECT count(*) FROM orders WHERE o_orderkey>100000 AND o_orderkey<200000;

• Contoh 3:

  USE lindorm_columnar;
  SELECT count(*) FROM orders WHERE o_orderkey>100000;

Tambahkan partisi

Dalam mesin penyimpanan berorientasi kolom Lindorm, partisi secara fisik terisolasi satu sama lain. Anda dapat menambahkan partisi untuk mempercepat kueri data.

Dalam contoh ini, tabel sampel dibuat dengan mengeksekusi pernyataan berikut:

USE lindorm_columnar;
CREATE TABLE orders (
o_orderkey       INT NOT NULL,
o_custkey        INT,
o_orderstatus    STRING,
o_totalprice     DOUBLE,
o_orderdate      STRING NOT NULL,
o_orderpriority  STRING,
o_clerk          STRING,
o_shippriority   INT,
o_comment        STRING)
PARTITIONED BY (o_orderdate, bucket(1024,o_orderkey))
TBLPROPERTIES(
'primary-key' = 'o_orderdate,o_orderkey');

• Contoh 1:

  USE lindorm_columnar;
  SELECT o_orderdate, count(*) FROM orders WHERE o_orderdate='2022-01-01' GROUP BY o_orderdate;

• Contoh 2:

  USE lindorm_columnar;
  SELECT o_orderdate, count(*) FROM orders WHERE o_orderdate>='2022-01-01' AND o_orderdate<='2022-01-07' GROUP BY o_orderdate;

CREATE TABLE mydb.mytable (
  id INT NOT NULL, 
  city STRING NOT NULL, 
  name STRING, 
  score INT)
partitioned by (city, bucket(4, id))
tblproperties('primary-key' = 'id,city');

ALTER TABLE mydb.mytable SET TBLPROPERTIES ('read.scan-major-rewritten-files-only' = true);

USE lindorm_columnar;
CREATE TABLE orders (
o_orderkey       INT NOT NULL,
o_custkey        INT,
o_orderstatus    STRING,
o_totalprice     DOUBLE ,
o_orderdate      STRING ,
o_orderpriority  STRING,
o_clerk          STRING,
o_shippriority   INT,
o_comment        STRING)
PARTITIONED BY (bucket(1024,o_orderkey))
TBLPROPERTIES(
'primary-key' = 'o_orderkey',
'read.scan-major-rewritten-files-only' = 'true');

ALTER TABLE orders WRITE ORDERED BY o_shippriority,o_totalprice;

CALL lindorm_columnar.system.rewrite_data_files(table => 'orders');