Di mana Azure Databricks menulis data?
Artikel ini merinci lokasi Azure Databricks menulis data dengan operasi dan konfigurasi sehari-hari. Karena Azure Databricks memiliki serangkaian alat yang mencakup banyak teknologi dan berinteraksi dengan sumber daya cloud dalam model tanggung jawab bersama, lokasi default yang digunakan untuk menyimpan data bervariasi berdasarkan lingkungan eksekusi, konfigurasi, dan pustaka.
Informasi dalam artikel ini dimaksudkan untuk membantu Anda memahami jalur default untuk berbagai operasi dan bagaimana konfigurasi dapat mengubah default ini. Pengurus dan administrator data yang mencari panduan tentang mengonfigurasi dan mengontrol akses ke data akan melihat Tata kelola data dengan Unity Catalog.
Untuk mempelajari tentang mengonfigurasi penyimpanan objek dan sumber data lainnya, lihat Menyambungkan ke sumber data.
Apa itu penyimpanan objek?
Dalam komputasi cloud, penyimpanan objek atau penyimpanan blob mengacu pada kontainer penyimpanan yang mempertahankan data sebagai objek, dengan setiap objek yang terdiri dari data, metadata, dan pengidentifikasi sumber daya (URI) yang unik secara global. Operasi manipulasi data penyimpanan objek sering kali terbatas pada pembuatan, pembacaan, pembaruan, dan penghapusan (CRUD) melalui antarmuka REST API. Beberapa penawaran penyimpanan objek mencakup fitur seperti penerapan versi dan manajemen siklus hidup. Penyimpanan objek memiliki manfaat berikut:
- Ketersediaan tinggi, durabilitas, dan keandalan.
- Biaya penyimpanan yang lebih rendah dibandingkan dengan sebagian besar opsi penyimpanan lainnya.
- Dapat diskalakan tanpa batas (dibatasi oleh jumlah total penyimpanan yang tersedia di wilayah cloud tertentu).
Sebagian besar data lake berbasis cloud dibangun di atas format data sumber terbuka dalam penyimpanan objek cloud.
Bagaimana Azure Databricks menggunakan penyimpanan objek?
Penyimpanan objek adalah bentuk utama penyimpanan yang digunakan oleh Azure Databricks untuk sebagian besar operasi. Anda mengonfigurasi akses ke penyimpanan objek cloud menggunakan kredensial penyimpanan Katalog Unity dan lokasi eksternal. Lokasi ini kemudian digunakan untuk menyimpan tabel dan volume cadangan file data. Lihat Menyambungkan ke penyimpanan objek cloud menggunakan Katalog Unity.
Kecuali Anda secara khusus mengonfigurasi tabel terhadap sistem data eksternal, semua tabel yang dibuat di Azure Databricks menyimpan data di penyimpanan objek cloud.
File Delta Lake yang disimpan dalam penyimpanan objek cloud menyediakan fondasi data untuk databricks lakehouse.
Apa itu penyimpanan blok?
Dalam komputasi cloud, penyimpanan blok atau penyimpanan disk mengacu pada volume penyimpanan yang sesuai dengan hard disk drive (HDD) tradisional atau solid-state drive (SSD), juga dikenal sebagai "hard drive." Saat menyebarkan penyimpanan blok di lingkungan komputasi cloud, partisi logis dari satu atau beberapa drive fisik biasanya disebarkan. Implementasi sedikit berbeda antara penawaran produk dan vendor cloud, tetapi karakteristik berikut biasanya ditemukan di seluruh implementasi:
- Semua komputer virtual (VM) memerlukan volume penyimpanan blok yang terpasang.
- File dan program yang diinstal ke volume penyimpanan blok bertahan selama volume penyimpanan blok tetap ada.
- Volume penyimpanan blok sering digunakan untuk penyimpanan data sementara.
- Volume penyimpanan blok yang terpasang pada VM biasanya dihapus bersama VM.
Bagaimana Azure Databricks menggunakan penyimpanan blok?
Saat Anda mengaktifkan sumber daya komputasi, Azure Databricks mengonfigurasi dan menyebarkan VM dan melampirkan volume penyimpanan blok. Penyimpanan blok ini digunakan untuk menyimpan file data sementara selama masa pakai sumber daya komputasi. File-file ini mencakup sistem operasi, pustaka yang diinstal, dan data yang digunakan oleh cache disk. Meskipun Apache Spark menggunakan penyimpanan blok di latar belakang untuk paralelisasi dan pemuatan data yang efisien, sebagian besar kode berjalan di Azure Databricks tidak secara langsung menyimpan atau memuat data untuk memblokir penyimpanan.
Anda dapat menjalankan kode arbitrer, seperti perintah Python atau Bash yang menggunakan penyimpanan blok yang terpasang pada simpul driver Anda. Lihat Bekerja dengan file dalam penyimpanan sementara yang terpasang pada simpul driver.
Di mana Unity Catalog menyimpan file data?
Katalog Unity bergantung pada administrator untuk mengonfigurasi hubungan antara penyimpanan cloud dan objek relasional. Lokasi yang tepat tempat data berada tergantung pada bagaimana administrator telah mengonfigurasi hubungan.
Data yang ditulis atau diunggah ke objek yang diatur oleh Unity Catalog disimpan di salah satu lokasi berikut:
- Lokasi penyimpanan terkelola yang terkait dengan metastore, katalog, atau skema. Data yang ditulis atau diunggah ke tabel terkelola dan volume terkelola menggunakan penyimpanan terkelola. Lihat Menentukan lokasi penyimpanan terkelola di Katalog Unity.
- Lokasi eksternal yang dikonfigurasi dengan kredensial penyimpanan. Data yang ditulis atau diunggah ke tabel eksternal dan volume eksternal menggunakan penyimpanan eksternal. Lihat Menyambungkan ke penyimpanan objek cloud menggunakan Katalog Unity.
Di mana Databricks SQL menyimpan tabel cadangan data?
Saat Anda menjalankan CREATE TABLE
pernyataan dengan Databricks SQL yang dikonfigurasi dengan Unity Catalog, perilaku defaultnya adalah menyimpan file data di lokasi penyimpanan terkelola yang dikonfigurasi dengan Katalog Unity. Lihat Di mana Unity Catalog menyimpan file data?.
Katalog warisan hive_metastore
mengikuti aturan yang berbeda. Lihat Bekerja dengan Unity Catalog dan metastore Apache Hive warisan.
Di mana Tabel Langsung Delta menyimpan file data?
Databricks merekomendasikan penggunaan Unity Catalog saat membuat alur DLT. Data disimpan dalam direktori di lokasi penyimpanan terkelola yang terkait dengan skema target.
Anda dapat secara opsional mengonfigurasi alur DLT menggunakan metastore Apache Hive. Saat dikonfigurasi dengan metastore Apache Hive, Anda dapat menentukan lokasi penyimpanan di DBFS atau penyimpanan objek cloud. Jika Anda tidak menentukan lokasi, lokasi pada akar DBFS ditetapkan ke alur Anda.
Di mana Apache Spark menulis file data?
Databricks merekomendasikan penggunaan nama objek dengan Unity Catalog untuk membaca dan menulis data. Anda juga dapat menulis file ke volume Unity Catalog menggunakan pola berikut: /Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>
. Anda harus memiliki hak istimewa yang memadai untuk mengunggah, membuat, memperbarui, atau menyisipkan data ke objek yang diatur Katalog Unity.
Anda dapat secara opsional menggunakan indikator sumber daya universal (URI) untuk menentukan jalur ke file data. URI bervariasi tergantung pada penyedia cloud. Anda juga harus memiliki izin tulis yang dikonfigurasi untuk sumber daya komputasi Anda saat ini untuk menulis ke penyimpanan objek cloud.
Azure Databricks menggunakan Databricks Filesystem untuk memetakan perintah baca dan tulis Apache Spark kembali ke penyimpanan objek cloud. Setiap ruang kerja Azure Databricks memiliki lokasi penyimpanan akar DBFS yang dikonfigurasi di akun cloud yang dialokasikan untuk ruang kerja, yang dapat diakses semua pengguna untuk membaca dan menulis data. Databricks tidak merekomendasikan penggunaan akar DBFS untuk menyimpan data produksi apa pun. Lihat Apa itu DBFS? dan Rekomendasi untuk bekerja dengan Akar DBFS.
Di mana panda menulis file data di Azure Databricks?
Dalam Databricks Runtime 14.0 ke atas, direktori kerja default saat ini (CWD) untuk semua operasi baca dan tulis Python lokal adalah direktori yang berisi buku catatan. Jika Anda hanya menyediakan nama file saat menyimpan file data, panda menyimpan file data tersebut sebagai file ruang kerja sejajar dengan buku catatan yang sedang berjalan.
Tidak semua versi Databricks Runtime mendukung file ruang kerja, dan beberapa versi Databricks Runtime memiliki perilaku yang berbeda tergantung pada apakah Anda menggunakan notebook atau folder Git. Lihat Apa direktori kerja default saat ini?.
Di mana saya harus menulis file sementara di Azure Databricks?
Jika Anda harus menulis file sementara yang tidak ingin Anda simpan setelah kluster dimatikan, menulis file sementara untuk $TEMPDIR
menghasilkan performa yang lebih baik daripada menulis ke direktori kerja (CWD) saat ini jika CWD berada di sistem file ruang kerja. Anda juga dapat menghindari melebihi batas ukuran cabang jika kode berjalan di Repo. Untuk informasi selengkapnya, lihat Batas ukuran file dan repositori.
Tulis jika /local_disk0
jumlah data yang akan ditulis besar dan Anda ingin penyimpanan diskalakan otomatis.