Delta Lake Dive: Penguatkuasaan dan Evolusi Skim

Hello, Habr! Saya membentangkan kepada anda terjemahan artikel "Menyelam ke Tasik Delta: Penguatkuasaan Skema & Evolusi" pengarang Burak Yavuz, Brenner Heintz dan Denny Lee, yang disediakan untuk menjangkakan permulaan kursus Jurutera Data daripada OTUS.

Data, seperti pengalaman kami, sentiasa terkumpul dan berkembang. Untuk mengikuti perkembangan, model mental dunia kita mesti menyesuaikan diri dengan data baharu, beberapa daripadanya mengandungi dimensi baharu—cara baharu untuk memerhati perkara yang kami tidak tahu sebelum ini. Model mental ini tidak jauh berbeza daripada skema jadual yang menentukan cara kami mengkategorikan dan memproses maklumat baharu.

Ini membawa kita kepada isu pengurusan skema. Apabila cabaran dan keperluan perniagaan berubah mengikut masa, begitu juga struktur data anda. Delta Lake memudahkan untuk memperkenalkan ukuran baharu apabila data berubah. Pengguna mempunyai akses kepada semantik mudah untuk mengurus skema jadual mereka. Alat ini termasuk Penguatkuasaan Skema, yang melindungi pengguna daripada mencemarkan jadual mereka secara tidak sengaja dengan ralat atau data yang tidak diperlukan, dan Evolusi Skema, yang membenarkan lajur baharu data berharga ditambahkan secara automatik ke lokasi yang sesuai. Dalam artikel ini, kita akan menyelami lebih mendalam menggunakan alat ini.

Memahami Skema Jadual

Setiap DataFrame dalam Apache Spark mengandungi skema yang mentakrifkan bentuk data, seperti jenis data, lajur dan metadata. Dengan Delta Lake, skema jadual disimpan dalam format JSON di dalam log transaksi.

Apakah penguatkuasaan skim?

Penguatkuasaan Skema, juga dikenali sebagai Pengesahan Skema, ialah mekanisme keselamatan di Delta Lake yang memastikan kualiti data dengan menolak rekod yang tidak sepadan dengan skema jadual. Seperti tuan rumah di meja depan restoran tempahan sahaja yang popular, dia menyemak sama ada setiap lajur data yang dimasukkan ke dalam jadual berada dalam senarai sepadan lajur dijangka (dengan kata lain, sama ada terdapat "tempahan" untuk setiap lajur ), dan menolak sebarang rekod dengan lajur yang tiada dalam senarai.

Bagaimanakah penguatkuasaan skema berfungsi?

Delta Lake menggunakan semakan skema atas tulisan, yang bermaksud bahawa semua tulisan baharu pada jadual disemak untuk keserasian dengan skema jadual sasaran pada masa tulis. Jika skema tidak konsisten, Delta Lake membatalkan transaksi sepenuhnya (tiada data ditulis) dan menimbulkan pengecualian untuk memberitahu pengguna tentang ketidakkonsistenan itu.
Delta Lake menggunakan peraturan berikut untuk menentukan sama ada rekod serasi dengan jadual. DataFrame Boleh Tulis:

• tidak boleh mengandungi lajur tambahan yang tiada dalam skema jadual sasaran. Sebaliknya, semuanya baik-baik saja jika data masuk tidak mengandungi sama sekali semua lajur daripada jadual - lajur ini hanya akan diberikan nilai nol.
• tidak boleh mempunyai jenis data lajur yang berbeza daripada jenis data lajur dalam jadual sasaran. Jika lajur jadual sasaran mengandungi data StringType, tetapi lajur yang sepadan dalam DataFrame mengandungi data IntegerType, penguatkuasaan skema akan membuang pengecualian dan menghalang operasi tulis daripada berlaku.
• tidak boleh mengandungi nama lajur yang berbeza hanya dalam kes. Ini bermakna anda tidak boleh menetapkan lajur bernama 'Foo' dan 'foo' dalam jadual yang sama. Walaupun Spark boleh digunakan dalam mod sensitif huruf besar atau kecil (lalai), Tasik Delta memelihara huruf besar tetapi tidak sensitif dalam storan skema. Parket adalah sensitif huruf besar apabila menyimpan dan memulangkan maklumat lajur. Untuk mengelakkan kemungkinan ralat, kerosakan data atau kehilangan data (sesuatu yang kami alami secara peribadi di Databricks), kami memutuskan untuk menambah had ini.

Untuk menggambarkan perkara ini, mari kita lihat apa yang berlaku dalam kod di bawah apabila kita cuba menambah beberapa lajur yang baru dijana pada jadual Tasik Delta yang belum dikonfigurasikan untuk menerimanya.

# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
            SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
            CAST(rand(10) * 10000 * count AS double) AS amount
            FROM loan_by_state_delta
            """)

# Вывести исходную схему DataFrame
original_loans.printSchema()

root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
 
# Вывести новую схему DataFrame
loans.printSchema()
 
root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
  |-- amount: double (nullable = true) # new column
 
# Попытка добавить новый DataFrame (с новым столбцом) в существующую таблицу
loans.write.format("delta") 
           .mode("append") 
           .save(DELTALAKE_PATH)

Returns:

A schema mismatch detected when writing to the Delta table.
 
To enable schema migration, please set:
'.option("mergeSchema", "true")'
 
Table schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
 
Data schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
-- amount: double (nullable = true)
 
If Table ACLs are enabled, these options will be ignored. Please use the ALTER TABLE command for changing the schema.

Daripada menambah lajur baharu secara automatik, Delta Lake mengenakan skema dan berhenti menulis. Untuk membantu menentukan lajur (atau set lajur) yang menyebabkan percanggahan, Spark mengeluarkan kedua-dua skema daripada surih tindanan untuk perbandingan.

Apakah faedah menguatkuasakan skema?

Oleh kerana penguatkuasaan skema adalah semakan yang agak ketat, ia merupakan alat yang sangat baik untuk digunakan sebagai penjaga pintu kepada set data yang bersih dan berubah sepenuhnya yang sedia untuk pengeluaran atau penggunaan. Biasanya digunakan pada jadual yang menyuap data secara langsung:

• Algoritma pembelajaran mesin
• papan pemuka BI
• Alat analisis dan visualisasi data
• Mana-mana sistem pengeluaran yang memerlukan skema semantik yang sangat berstruktur dan ditaip kuat.

Untuk menyediakan data mereka untuk halangan terakhir ini, ramai pengguna menggunakan seni bina "multi-hop" mudah yang secara beransur-ansur memperkenalkan struktur ke dalam jadual mereka. Untuk mengetahui lebih lanjut mengenai perkara ini, anda boleh menyemak artikel tersebut Pembelajaran mesin gred pengeluaran dengan Delta Lake.

Sudah tentu, penguatkuasaan skema boleh digunakan di mana-mana dalam saluran paip anda, tetapi ingat bahawa penstriman ke jadual dalam kes ini boleh mengecewakan kerana, sebagai contoh, anda terlupa bahawa anda menambah lajur lain pada data masuk.

Mencegah pencairan data

Sekarang anda mungkin tertanya-tanya, apa yang menjadi kekecohan? Lagipun, kadangkala ralat "ketakpadanan skema" yang tidak dijangka boleh menyebabkan anda tersandung dalam aliran kerja anda, terutamanya jika anda baru di Delta Lake. Mengapa tidak biarkan sahaja skema berubah mengikut keperluan supaya saya boleh menulis DataFrame saya tidak kira apa pun?

Seperti kata pepatah lama, "satu auns pencegahan bernilai satu paun penawar." Pada satu ketika, jika anda tidak berhati-hati untuk menguatkuasakan skema anda, isu keserasian jenis data akan menimbulkan masalah - sumber data mentah yang kelihatan homogen mungkin mengandungi kes tepi, lajur rosak, pemetaan yang tidak betul atau perkara menakutkan lain untuk diimpikan. mimpi ngeri. Pendekatan terbaik adalah untuk menghentikan musuh-musuh ini di pintu masuk - dengan penguatkuasaan skema - dan menangani mereka dalam keadaan terang, bukannya kemudian apabila mereka mula mengintai dalam kedalaman gelap kod pengeluaran anda.

Menguatkuasakan skema memberi anda jaminan bahawa skema jadual anda tidak akan berubah melainkan anda meluluskan perubahan itu. Ini menghalang pencairan data, yang boleh berlaku apabila lajur baharu ditambah dengan begitu kerap sehingga jadual mampat yang berharga sebelum ini kehilangan makna dan kegunaannya disebabkan oleh banjir data. Dengan menggalakkan anda untuk bersungguh-sungguh, menetapkan standard yang tinggi dan mengharapkan kualiti yang tinggi, penguatkuasaan skema melakukan apa yang direka untuk dilakukan—membantu anda kekal teliti dan hamparan anda bersih.

Jika setelah pertimbangan lanjut anda memutuskan bahawa anda benar-benar perlu tambah lajur baharu - tiada masalah, di bawah ialah pembetulan satu baris. Penyelesaiannya ialah evolusi litar!

Apakah evolusi skema?

Evolusi skema ialah ciri yang membolehkan pengguna menukar skema jadual semasa dengan mudah mengikut data yang berubah dari semasa ke semasa. Ia paling kerap digunakan apabila melakukan operasi tambah atau tulis semula untuk menyesuaikan skema secara automatik untuk memasukkan satu atau lebih lajur baharu.

Bagaimanakah evolusi skema berfungsi?

Mengikuti contoh daripada bahagian sebelumnya, pembangun boleh menggunakan evolusi skema dengan mudah untuk menambah lajur baharu yang sebelum ini ditolak kerana ketidakkonsistenan skema. Evolusi litar diaktifkan dengan menambah .option('mergeSchema', 'true') kepada pasukan Spark anda .write или .writeStream.

# Добавьте параметр mergeSchema
loans.write.format("delta") 
           .option("mergeSchema", "true") 
           .mode("append") 
           .save(DELTALAKE_SILVER_PATH)

Untuk melihat graf, jalankan pertanyaan Spark SQL berikut

# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10

Sebagai alternatif, anda boleh menetapkan pilihan ini untuk keseluruhan sesi Spark dengan menambah spark.databricks.delta.schema.autoMerge = True kepada konfigurasi Spark. Tetapi gunakan ini dengan berhati-hati, kerana penguatkuasaan skema tidak lagi akan memaklumkan anda tentang ketidakkonsistenan skema yang tidak disengajakan.

Dengan memasukkan parameter dalam permintaan mergeSchema, semua lajur yang terdapat dalam DataFrame tetapi tidak dalam jadual sasaran ditambahkan secara automatik pada penghujung skema sebagai sebahagian daripada transaksi tulis. Medan bersarang juga boleh ditambah dan ini juga akan ditambahkan pada penghujung lajur struktur yang sepadan.

Jurutera tarikh dan saintis data boleh menggunakan pilihan ini untuk menambah lajur baharu (mungkin metrik yang dijejaki baru-baru ini atau lajur prestasi jualan bulan ini) pada jadual pengeluaran pembelajaran mesin sedia ada mereka tanpa memecahkan model sedia ada berdasarkan lajur lama.

Jenis perubahan skema berikut dibenarkan sebagai sebahagian daripada evolusi skema semasa penambahan atau penulisan semula jadual:

• Menambah lajur baharu (ini ialah senario yang paling biasa)
• Menukar jenis data daripada NullType -> sebarang jenis lain atau mempromosikan daripada ByteType -> ShortType -> IntegerType

Perubahan lain yang tidak dibenarkan dalam evolusi skema memerlukan skema dan data ditulis semula dengan menambah .option("overwriteSchema", "true"). Sebagai contoh, dalam kes di mana lajur "Foo" pada asalnya adalah integer dan skema baharu ialah jenis data rentetan, maka semua fail Parquet(data) perlu ditulis semula. Perubahan tersebut termasuk:

• memadamkan lajur
• menukar jenis data lajur sedia ada (di tempat)
• menamakan semula lajur yang berbeza hanya dalam kes (contohnya, "Foo" dan "foo")

Akhir sekali, dengan keluaran Spark 3.0 yang seterusnya, DDL eksplisit akan disokong sepenuhnya (menggunakan ALTER TABLE), membolehkan pengguna melakukan tindakan berikut pada skema jadual:

• menambah lajur
• menukar komen ruangan
• menetapkan sifat jadual yang mengawal tingkah laku jadual, seperti menetapkan tempoh masa log transaksi disimpan.

Apakah faedah evolusi litar?

Evolusi skema boleh digunakan pada bila-bila masa anda berniat tukar skema jadual anda (berbanding apabila anda secara tidak sengaja menambah lajur pada DataFrame anda yang tidak sepatutnya ada). Ini ialah cara paling mudah untuk memindahkan skema anda kerana ia secara automatik menambahkan nama lajur dan jenis data yang betul tanpa perlu mengisytiharkannya secara eksplisit.

Kesimpulan

Penguatkuasaan skema menolak sebarang lajur baharu atau perubahan skema lain yang tidak serasi dengan jadual anda. Dengan menetapkan dan mengekalkan piawaian tinggi ini, penganalisis dan jurutera boleh mempercayai bahawa data mereka mempunyai tahap integriti tertinggi, menyampaikannya dengan jelas dan jelas, membolehkan mereka membuat keputusan perniagaan yang lebih baik.

Sebaliknya, evolusi skema melengkapkan penguatkuasaan dengan memudahkan didakwa perubahan skema automatik. Lagipun, tidak sukar untuk menambah lajur.

Penggunaan paksa skema adalah yang, di mana evolusi skema adalah yin. Apabila digunakan bersama, ciri ini menjadikan penindasan hingar dan penalaan isyarat lebih mudah berbanding sebelum ini.

Kami juga ingin mengucapkan terima kasih kepada Mukul Murthy dan Pranav Anand atas sumbangan mereka kepada artikel ini.

Artikel lain dalam siri ini:

Menyelam ke dalam Delta Lake: Membongkar Log Transaksi

artikel berkaitan

Pembelajaran mesin gred pengeluaran dengan Delta Lake

Apakah tasik data?

Ketahui lebih lanjut tentang kursus

Sumber: www.habr.com