Mengkueri data
Mengkueri data adalah langkah dasar untuk melakukan hampir semua tugas berbasis data di Azure Databricks. Terlepas dari bahasa atau alat yang digunakan, beban kerja dimulai dengan menentukan kueri terhadap tabel atau sumber data lainnya lalu melakukan tindakan untuk mendapatkan wawasan dari data. Artikel ini menguraikan konsep dan prosedur inti untuk menjalankan kueri di berbagai penawaran produk Azure Databricks, dan menyertakan contoh kode yang dapat Anda adaptasi untuk kasus penggunaan Anda.
Anda bisa mengkueri data secara interaktif menggunakan:
- Buku Catatan
- Editor teks SQL
- Editor file
- Dashboard
Anda juga dapat menjalankan kueri sebagai bagian dari alur atau tugas DLT.
Untuk gambaran umum kueri streaming di Azure Databricks, lihat Mengkueri data streaming.
Data apa yang dapat Anda kueri dengan Azure Databricks?
Azure Databricks mendukung kueri data dalam beberapa format dan sistem perusahaan. Data yang Anda kueri menggunakan Azure Databricks termasuk dalam salah satu dari dua kategori luas: data di lakehouse Databricks dan data eksternal.
Data apa yang ada di lakehouse Databricks?
Platform Intelijen Data Databricks menyimpan semua data Anda di lakehouse Databricks secara default.
Ini berarti bahwa ketika Anda menjalankan pernyataan CREATE TABLE dasar untuk membuat tabel baru, Anda telah membuat tabel lakehouse. Data Lakehouse memiliki properti berikut:
- Disimpan dalam format Delta Lake.
- Disimpan di penyimpanan objek cloud.
- Diatur oleh Sistem Katalog Unity.
Sebagian besar data lakehouse di Azure Databricks terdaftar di Unity Catalog sebagai tabel terkelola. Tabel terkelola menyediakan sintaks yang paling mudah dan bertingkah seperti tabel lain di sebagian besar sistem manajemen database relasional. Tabel terkelola direkomendasikan untuk sebagian besar kasus penggunaan dan cocok untuk semua pengguna yang tidak ingin khawatir tentang detail implementasi penyimpanan data.
Tabel tidak terkelola atau tabel eksternal adalah tabel yang didaftarkan dengan spesifikasi tertentu LOCATION. Istilah eksternal dapat menyesatkan, karena tabel Delta eksternal tetap merupakan data lakehouse. Tabel yang tidak dikelola mungkin lebih disukai oleh pengguna yang langsung mengakses tabel dari klien pembaca Delta lainnya. Untuk gambaran umum perbedaan dalam semantik tabel, lihat Apa itu tabel?.
Beberapa beban kerja warisan mungkin secara eksklusif berinteraksi dengan data Delta Lake melalui jalur file dan tidak mendaftarkan tabel sama sekali. Data ini masih merupakan data lakehouse, tetapi bisa lebih sulit ditemukan karena tidak terdaftar di Unity Catalog.
Catatan
Administrator ruang kerja Anda mungkin belum memutakhirkan tata kelola data Anda untuk menggunakan Katalog Unity. Anda masih dapat memperoleh banyak manfaat dari Databricks Lakehouse tanpa Unity Catalog, tetapi tidak semua fitur yang tercantum dalam artikel ini atau di seluruh dokumentasi Azure Databricks didukung.
Data apa yang dianggap eksternal?
Data apa pun yang tidak ada di lakehouse Databricks dapat dianggap sebagai data eksternal. Beberapa contoh data eksternal meliputi yang berikut ini:
- Tabel asing terdaftar di Lakehouse Federation.
- Tabel-tabel di metastore Hive yang didukung oleh Parquet.
- Tabel eksternal di Unity Catalog yang didukung oleh JSON.
- Data CSV disimpan dalam penyimpanan objek cloud.
- Streaming data yang dibaca dari Kafka.
Azure Databricks mendukung konfigurasi koneksi ke banyak sumber data. Lihat Menyambung ke sumber data.
Meskipun Anda dapat menggunakan Unity Catalog untuk mengatur dan mengontrol akses serta menentukan tabel terhadap data yang disimpan dalam beberapa format dan sistem eksternal, Delta Lake diperlukan agar data dipertimbangkan di "lakehouse".
Delta Lake menyediakan semua jaminan transaksi di Azure Databricks, yang sangat penting untuk menjaga integritas dan konsistensi data. Jika Anda ingin mempelajari selengkapnya tentang jaminan transaksional pada data Azure Databricks dan mengapa itu penting, lihat Apa itu jaminan ACID di Azure Databricks?.
Sebagian besar pengguna Azure Databricks mengkueri kombinasi data lakehouse dan data eksternal. Menyambungkan dengan data eksternal selalu merupakan langkah pertama untuk penyerapan data dan alur ETL yang membawa data ke lakehouse. Untuk informasi tentang mengimpor data, lihat mengimpor data ke dalam lakehouse Azure Databricks.
Kueri tabel menurut nama
Untuk semua data yang terdaftar sebagai tabel, Databricks merekomendasikan kueri menggunakan nama tabel.
Jika Anda menggunakan Unity Catalog, tabel menggunakan namespace tiga tingkat dengan format berikut: <catalog-name>.<schema-name>.<table-name>.
Tanpa Unity Catalog, pengidentifikasi tabel menggunakan format <schema-name>.<table-name>.
Catatan
Azure Databricks mewarisi banyak sintaks SQL-nya dari Apache Spark, yang tidak membedakan antara SCHEMA dan DATABASE.
Kueri menurut nama tabel didukung dalam semua konteks eksekusi Azure Databricks dan bahasa yang didukung.
SQL
SELECT * FROM catalog_name.schema_name.table_name
Python
spark.read.table("catalog_name.schema_name.table_name")
Resolusi Pengidentifikasi dari Unity Catalog
Databricks merekomendasikan penggunaan pengidentifikasi yang sepenuhnya memenuhi syarat saat kueri atau beban kerja berinteraksi dengan objek database yang disimpan di beberapa skema atau katalog.
Tabel berikut menguraikan perilaku pengidentifikasi yang memenuhi syarat sebagian dan tidak memenuhi syarat sepenuhnya.
| Pola pengidentifikasi | Perilaku |
|---|---|
catalog_name.schema_name.object_name |
Mengacu pada objek database yang ditentukan oleh pengidentifikasi. |
schema_name.object_name |
Mengacu pada objek database yang terkait dengan schema_name dan object_name yang ditentukan dalam katalog saat ini. |
object_name |
Mengacu pada objek database yang terkait dengan object_name yang ditentukan dalam katalog dan skema saat ini. |
Apa katalog dan skema saat ini?
Di lingkungan komputasi interaktif, gunakan current_catalog() dan current_schema() untuk mengonfirmasi katalog dan skema Anda saat ini.
Semua ruang kerja yang dikonfigurasi dengan Katalog Unity memiliki katalog default yang ditetapkan di tingkat ruang kerja. Lihat Mengelola katalog default.
Tabel berikut ini menjelaskan konfigurasi untuk produk Databricks yang mungkin mengambil alih katalog default ruang kerja:
| Produk | Konfigurasi |
|---|---|
| Komputasi serbaguna atau untuk berbagai pekerjaan | Atur konfigurasi Spark spark.databricks.sql.initial.catalog.namespace ketika mengonfigurasi komputasi. |
| DLT | Katalog dan skema yang ditentukan selama konfigurasi pipeline menggantikan pengaturan default ruang kerja untuk semua logika pipeline. |
Catatan
Katalog atau skema default mungkin juga diatur oleh konfigurasi JDBC saat menyambungkan ke sistem eksternal atau metastores. Hubungi administrator yang bertanggung jawab untuk mengonfigurasi komputasi Databricks dan sistem terintegrasi jika Anda mengalami perilaku default yang tidak terduga.
Gunakan sintaks USE CATALOG atau USE SCHEMA untuk menentukan katalog atau skema saat ini untuk sesi Anda saat ini. Katalog atau skema saat ini digunakan ketika kueri atau pernyataan menggunakan pengidentifikasi yang berkualifikasi sebagian atau tidak berkualifikasi.
| Pernyataan | Hasil |
|---|---|
USE CATALOG catalog_name |
Mengatur katalog saat ini dengan menggunakan catalog_nameyang disediakan. Mengatur skema saat ini ke default. |
USE SCHEMA schema_name |
Mengatur skema saat ini menggunakan schema_name yang disediakan dalam katalog saat ini. |
USE SCHEMA catalog_name.schema_name |
Atur katalog saat ini menggunakan catalog_name yang disediakan dan skema saat ini menggunakan schema_nameyang disediakan . |
Catatan
Kueri dan perintah yang menggunakan pengidentifikasi yang sepenuhnya memenuhi syarat untuk berinteraksi dengan objek seperti tabel, tampilan, fungsi, atau model tidak mengubah katalog atau skema saat ini dan selalu merujuk ke objek yang ditentukan.
Mengkueri data menurut jalur
Anda dapat mengkueri data terstruktur, semi terstruktur, dan tidak terstruktur menggunakan jalur file. Sebagian besar file di Azure Databricks didukung oleh penyimpanan objek cloud. Lihat Bekerja dengan file di Azure Databricks.
Databricks merekomendasikan untuk mengonfigurasi semua akses ke penyimpanan objek cloud menggunakan Unity Catalog dan menentukan volume untuk lokasi penyimpanan objek yang langsung dikueri. Volume menyediakan alias yang dapat dibaca manusia ke lokasi dan file di penyimpanan objek cloud menggunakan nama katalog dan skema untuk jalur file. Lihat Menyambungkan ke penyimpanan dan layanan objek cloud menggunakan Unity Catalog.
Contoh berikut menunjukkan cara menggunakan jalur volume Katalog Unity untuk membaca data JSON:
SQL
SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`
Python
spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")
Untuk lokasi cloud yang tidak dikonfigurasi sebagai volume Unity Catalog, Anda dapat mengkueri data secara langsung menggunakan URI. Anda harus mengonfigurasi akses ke penyimpanan objek cloud untuk mengkueri data dengan URI. Lihat Mengonfigurasi akses ke penyimpanan objek cloud untuk Azure Databricks.
Contoh berikut menunjukkan cara menggunakan URI untuk mengkueri data JSON di Azure Data Lake Storage Gen2, GCS, dan S3:
SQL
SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;
SELECT * FROM json.`gs://bucket_name/path/to/data`;
SELECT * FROM json.`s3://bucket_name/path/to/data`;
Python
spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")
spark.read.format("json").load("gs://bucket_name/path/to/data")
spark.read.format("json").load("s3://bucket_name/path/to/data")
Mengkueri data menggunakan gudang SQL
Azure Databricks menggunakan gudang SQL untuk komputasi di antarmuka berikut:
- Editor teks SQL
- Kueri Databricks SQL
- Dashboard
- Dasbor lama
- Pemberitahuan SQL
Anda dapat secara opsional menggunakan gudang SQL dengan produk berikut:
- Buku catatan Databricks
- Editor File Databricks
- Pekerjaan Databricks
Saat Anda mengkueri data dengan gudang SQL, Anda hanya dapat menggunakan sintaks SQL. Bahasa pemrograman dan API lainnya tidak didukung.
Untuk ruang kerja yang diaktifkan untuk Unity Catalog, gudang SQL selalu menggunakan Unity Catalog untuk mengelola akses ke sumber data.
Sebagian besar kueri yang dijalankan pada tabel target gudang SQL. Kueri yang menargetkan file data harus memanfaatkan volume Katalog Unity untuk mengelola akses ke lokasi penyimpanan.
Menggunakan URI langsung dalam kueri yang dijalankan di gudang SQL dapat menyebabkan kesalahan yang tidak terduga.
Mengambil data menggunakan komputasi serbaguna atau komputasi tugas
Sebagian besar kueri yang Anda jalankan dari notebook Databricks, alur kerja, dan editor file berjalan terhadap kluster komputasi yang dikonfigurasi dengan Databricks Runtime. Anda dapat mengonfigurasi kluster ini untuk berjalan secara interaktif atau menyebarkannya sebagai pekerjaan komputasi yang mengoperasikan alur kerja. Databricks merekomendasikan agar Anda selalu menggunakan jobs compute untuk beban kerja non-interaktif.
Beban kerja interaktif versus non-interaktif
Banyak pengguna merasa berguna untuk menampilkan hasil kueri saat transformasi diproses selama pengembangan. Memindahkan beban kerja interaktif dari komputasi serba guna ke komputasi pekerjaan, Anda dapat menghemat waktu dan biaya pemrosesan dengan menghapus kueri yang menampilkan hasil.
Apache Spark menggunakan eksekusi kode malas, yang berarti bahwa hasil dihitung hanya seperlunya, dan beberapa transformasi atau kueri terhadap sumber data dapat dioptimalkan sebagai kueri tunggal jika Anda tidak memaksa hasil. Ini berbeda dengan mode eksekusi langsung yang digunakan dalam Pandas, yang memerlukan perhitungan untuk diproses secara berurutan sebelum meneruskan hasilnya ke metode berikutnya.
Jika tujuan Anda adalah menyimpan data yang dibersihkan, diubah, dan dikumpulkan sebagai himpunan data baru, Anda harus menghapus kueri yang menampilkan hasil dari kode Anda sebelum menjadwalkannya untuk dijalankan.
Untuk operasi kecil dan himpunan data kecil, penghematan waktu dan biaya mungkin marjinal. Namun, pada operasi besar, waktu yang signifikan dapat terbuang untuk menghitung dan mencetak hasil di buku catatan yang mungkin tidak diperiksa secara manual. Hasil yang sama kemungkinan dapat diminta dari output yang disimpan dengan biaya hampir nol setelah output tersebut disimpan.