Verileri sorgulama

Verileri sorgulama, Azure Databricks'te neredeyse tüm veri temelli görevleri gerçekleştirmek için temel adımdır. Kullanılan dilden veya araçtan bağımsız olarak, iş yükleri bir tablo veya başka bir veri kaynağında sorgu tanımlayıp verilerden içgörü elde etmek için eylemler gerçekleştirerek başlar. Bu makalede, çeşitli Azure Databricks ürün tekliflerinde sorgu çalıştırmaya yönelik temel kavramlar ve yordamlar özetlenmiştir ve kullanım örneğiniz için uyarlayabileceğiniz kod örnekleri yer almaktadır.

Aşağıdakini kullanarak verileri etkileşimli olarak sorgulayabilirsiniz:

• Notebooks
• SQL düzenleyicisi
• Dosya düzenleyicisi
• Panolar

Delta Live Tables işlem hatlarının veya iş akışlarının parçası olarak da sorgu çalıştırabilirsiniz.

Azure Databricks'te akış sorgularına genel bakış için bkz . Sorgu akışı verileri.

Azure Databricks ile hangi verileri sorgulayabilirsiniz?

Azure Databricks, verileri birden çok biçimde ve kurumsal sistemde sorgulamayı destekler. Azure Databricks kullanarak sorguladığınız veriler iki geniş kategoriden birine ayrılır: Databricks lakehouse'taki veriler ve dış veriler.

Databricks lakehouse'da hangi veriler var?

Databricks Veri Zekası Platformu, tüm verilerinizi varsayılan olarak bir Databricks göl evinde depolar.

Bu, yeni bir tablo oluşturmak için temel CREATE TABLE bir deyim çalıştırdığınızda bir lakehouse tablosu oluşturduğunuz anlamına gelir. Lakehouse verileri aşağıdaki özelliklere sahiptir:

• Delta Lake biçiminde depolanır.
• Bulut nesne depolama alanında depolanır.
• Unity Kataloğu tarafından yönetilir.

Azure Databricks'teki göl evi verilerinin çoğu Unity Kataloğu'nda yönetilen tablolar olarak kaydedilir. Yönetilen tablolar en kolay söz dizimini sağlar ve çoğu ilişkisel veritabanı yönetim sistemindeki diğer tablolar gibi davranır. Yönetilen tablolar çoğu kullanım örneği için önerilir ve veri depolamanın uygulama ayrıntıları konusunda endişelenmek istemeyen tüm kullanıcılar için uygundur.

Yönetilmeyen tablo veya dış tablo, belirtilen ile kaydedilmiş bir LOCATION tablodur. Dış Delta tabloları hala lakehouse verileri olduğundan dış terimi yanıltıcı olabilir. Yönetilmeyen tablolar, diğer Delta okuyucu istemcilerinden tablolara doğrudan erişen kullanıcılar tarafından tercih edilebilir. Tablo semantiğindeki farklılıklara genel bakış için bkz . Tablo nedir?.

Bazı eski iş yükleri yalnızca dosya yolları aracılığıyla Delta Lake verileriyle etkileşime geçebilir ve tabloları hiç kaydetmeyebilir. Bu veriler hala lakehouse verileridir, ancak Unity Kataloğu'na kayıtlı olmadığından daha zor bulunabilir.

Not

Çalışma alanı yöneticiniz Unity Kataloğu'nu kullanmak için veri idarenizi yükseltmemiş olabilir. Unity Kataloğu olmayan bir Databricks lakehouse'un avantajlarından birçoğunu almaya devam edebilirsiniz, ancak bu makalede veya Azure Databricks belgelerinde listelenen tüm işlevler desteklenmez.

Hangi veriler dış olarak kabul edilir?

Databricks lakehouse'ta olmayan tüm veriler dış veriler olarak kabul edilebilir. Bazı dış veri örnekleri şunlardır:

• Lakehouse Federation'a kayıtlı yabancı tablolar.
• Parquet tarafından yedeklenen Hive meta veri deposundaki tablolar.
• JSON tarafından yedeklenen Unity Kataloğu'ndaki dış tablolar.
• Bulut nesne depolama alanında depolanan CSV verileri.
• Kafka'dan okunan akış verileri.

Azure Databricks, birçok veri kaynağına bağlantı yapılandırmayı destekler. Bkz. Veri kaynaklarına Bağlan.

Unity Kataloğu'nu kullanarak birden çok biçimde ve dış sistemde depolanan verilere erişimi yönetebilir ve tablo tanımlayabilirsiniz ancak Delta Lake, verilerin göl evinde dikkate alınmasına yönelik bir gereksinimdir.

Delta Lake, Azure Databricks'te veri bütünlüğünü ve tutarlılığını korumak için çok önemli olan tüm işlem garantilerini sağlar. Azure Databricks verileriyle ilgili işlem garantileri ve bunların neden önemli olduğu hakkında daha fazla bilgi edinmek istiyorsanız bkz . Azure Databricks'te ACID garantileri nelerdir?.

Azure Databricks kullanıcılarının çoğu lakehouse verilerinin ve dış verilerin birleşimini sorgular. Dış verilerle Bağlan, verileri göle getiren veri alımı ve ETL işlem hatları için her zaman ilk adımdır. Verileri alma hakkında bilgi için bkz . Databricks lakehouse'a veri alma.

Tabloları ada göre sorgulama

Databricks, tablo olarak kaydedilen tüm veriler için tablo adını kullanarak sorgulamayı önerir.

Unity Kataloğu kullanıyorsanız, tablolar şu biçimde üç katmanlı bir ad alanı kullanır: <catalog-name>.<schema-name>.<table-name>.

Unity Kataloğu olmadan, tablo tanımlayıcıları biçimini <schema-name>.<table-name>kullanır.

Not

Azure Databricks, SQL söz diziminin büyük bir kısmını Apache Spark'tan devralır ve DATABASEile arasında SCHEMA ayrım yapmaz.

Tablo adına göre sorgulama, tüm Azure Databricks yürütme bağlamlarında ve desteklenen dillerde desteklenir.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

spark.read.table("catalog_name.schema_name.table_name")

Yola göre verileri sorgulama

Dosya yollarını kullanarak yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış verileri sorgulayabilirsiniz. Azure Databricks'te çoğu dosya bulut nesne depolaması tarafından desteklenir. Bkz. Azure Databricks'te dosyalarla çalışma.

Databricks, Unity Kataloğu'nu kullanarak bulut nesne depolamasına tüm erişimi yapılandırmanızı ve doğrudan sorgulanan nesne depolama konumları için birimler tanımlamanızı önerir. Birimler, dosya yolu için katalog ve şema adlarını kullanarak bulut nesneleri depolamadaki konumlara ve dosyalara insan tarafından okunabilen diğer adlar sağlar. Bkz. Unity Kataloğu'nu kullanarak bulut nesne depolamaya Bağlan.

Aşağıdaki örneklerde JSON verilerini okumak için Unity Kataloğu birim yollarının nasıl kullanılacağı gösterilmektedir:

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")

Unity Kataloğu birimleri olarak yapılandırılmamış bulut konumları için URI'leri kullanarak verileri doğrudan sorgulayabilirsiniz. URI'lerle verileri sorgulamak için bulut nesne depolamasına erişimi yapılandırmanız gerekir. Bkz. Azure Databricks için bulut nesne depolamasına erişimi yapılandırma.

Aşağıdaki örneklerde Azure Data Lake Storage 2. Nesil, GCS ve S3'teki JSON verilerini sorgulamak için URI'lerin nasıl kullanılacağı gösterilmektedir:

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")

SQL ambarlarını kullanarak verileri sorgulama

Azure Databricks, aşağıdaki arabirimlerde işlem için SQL ambarlarını kullanır:

• SQL düzenleyicisi
• Databricks SQL sorguları
• Panolar
• Eski panolar
• SQL uyarıları

İsteğe bağlı olarak SQL ambarlarını aşağıdaki ürünlerle kullanabilirsiniz:

• Databricks not defterleri
• Databricks dosya düzenleyicisi
• Databricks iş akışları

SQL ambarlarıyla verileri sorguladığınızda, yalnızca SQL söz dizimlerini kullanabilirsiniz. Diğer programlama dilleri ve API'ler desteklenmez.

Unity Kataloğu için etkinleştirilmiş çalışma alanları için SQL ambarları her zaman Unity Kataloğu'nu kullanarak veri kaynaklarına erişimi yönetir.

SQL ambarlarında çalıştırılacak sorguların çoğu tabloları hedefler. Veri dosyalarını hedefleyen sorgular, depolama konumlarına erişimi yönetmek için Unity Kataloğu birimlerinden yararlanmalıdır.

SQL ambarlarında çalıştırılacak sorgularda doğrudan URI'lerin kullanılması beklenmeyen hatalara neden olabilir.

Tüm amaçlı işlem veya işler hesaplamasını kullanarak verileri sorgulama

Databricks not defterlerinden, iş akışlarından ve dosya düzenleyicisinden çalıştırdığınız sorguların çoğu Databricks Runtime ile yapılandırılan işlem kümelerinde çalıştırılır. Bu kümeleri etkileşimli çalışacak şekilde yapılandırabilir veya iş akışlarını destekleyen işler olarak dağıtabilirsiniz. Databricks, etkileşimli olmayan iş yükleri için her zaman iş hesaplaması kullanmanızı önerir.

Etkileşimli ve etkileşimli olmayan iş yükleri

Birçok kullanıcı, dönüştürmeler geliştirme sırasında işlenirken sorgu sonuçlarını görüntülemeyi yararlı bulur. Etkileşimli bir iş yükünü tüm amaçlı işlemden işler işlemine taşırken, sonuçları görüntüleyen sorguları kaldırarak zamandan ve işleme maliyetlerinden tasarruf edebilirsiniz.

Apache Spark gecikmeli kod yürütmeyi kullanır, yani sonuçlar yalnızca gerektiği gibi hesaplanır ve sonuçları zorlamazsanız tek bir sorgu olarak bir veri kaynağına yönelik birden çok dönüştürme veya sorgu iyileştirilebilir. Bu, pandas'ta kullanılan ve sonuçları sonraki yönteme geçirmeden önce hesaplamaların sırayla işlenmesini gerektiren istekli yürütme moduyla karşıttır.

Amacınız temizlenmiş, dönüştürülmüş, toplanmış verileri yeni bir veri kümesi olarak kaydetmekse, çalıştırılacak şekilde zamanlamadan önce kodunuzda sonuçları görüntüleyen sorguları kaldırmanız gerekir.

Küçük işlemler ve küçük veri kümeleri için zaman ve maliyet tasarrufu marjinal olabilir. Yine de büyük işlemlerde, sonuçları el ile incelenemeyecek bir not defterine hesaplamak ve yazdırmak için çok fazla zaman harcanabilir. Aynı sonuçlar büyük olasılıkla kaydedilen çıkıştan depolandıktan sonra neredeyse hiç ücret ödemeden sorgulanabilir.