Düzenle

Share via

Çevrimiçi eğlence ve seyahat rezervasyonlarında geçici sorguları desteklemek için delta gölü oluşturma

Azure Event Hubs
Azure Data Lake Storage
Azure Databricks
Azure Synapse Analytics

Bu mimari, büyük miktarda ham belgenin yüksek sıklıkta oluşturulduğu seyahat rezervasyonu için örnek bir delta lake sağlar.

Apache® ve Apache Spark™, Apache Software Foundation'ın Birleşik Devletler ve/veya diğer ülkelerdeki kayıtlı ticari markaları veya ticari markalarıdır. Bu işaretlerin kullanılması Apache Software Foundation tarafından onaylanmamaktadır.

Mimari

Delta Lake mimarisinin diyagramı.

Bu mimarinin bir Visio dosyasını indirin.

Boş zaman ve seyahat rezervasyon senaryoları yüksek sıklıkta büyük miktarda ham belge üretebilir. Ancak, bu belgelerin tüm içeriğini dizine almanız gerekmeyebilir. Örneğin, kullanıcıların ilgi çekici bir dizi belgeyi almak için bilinen bir işlem kimliğine veya belirli bir tarihte müşteri adına göre arama gerçekleştirmesi gerekebilir.

Veri akışı

Bu mimarinin ardındaki kavram, çıplak verilerden arama yapmak için yararlı olan meta verilerin ayrıştırılmasından oluşur:

  • Yalnızca meta veriler sorgulanabilir bir hizmette (Spark gibi) dizinlenirken gerçek veriler bir veri gölünde depolanır.
  • Veri gölündeki ham belgeler, dizine alınan meta verilere kendi yollarıyla bağlanır.
  • Belgeler sorgulanırken, hizmet belgelerin meta verilerini arar ve bu durumda gerçek belgeler veri gölünden kendi yolları ile alınır.

Meta veriler tüm veri varlığının bir bölümünü oluşturduğundan bu çözüm maliyetleri önemli ölçüde düşürür ve performansı artırır (örneğin, petabaytlar halinde ham belgeler onlarca gigabaytlık kısa meta verilerle açıklanabilir).

Buna ek olarak, geçmiş derinlik ve gerçek zamanlı gereksinimlerin tekdüzen, bakımı kolay, yüksek performanslı bir sistemle harmanlanması, bu tür senaryoların tipik bir zorluğudur. Delta Lake mimarisi bu zorluğun yanıtını verir.

Bileşenler

Azure Uygulaması Hizmeti, yönetilen sanal makinelerde uygulama oluşturmaya ve barındırmaya yönelik bir hizmet olarak platformdur (PaaS). App Service, uygulamalarınızın üzerinde çalıştığı temel işlem altyapısını yönetir ve kaynak kullanım kotalarının ve uygulama ölçümlerinin izlenmesini, tanılama bilgilerinin günlüğe kaydedilmesini ve ölçümlere dayalı uyarıları sağlar.

Azure Data Factory , Azure'ın genişleme sunucusuz veri tümleştirmesi ve veri dönüşümü için bulut ayıklama, dönüştürme ve yükleme (ETL) hizmetidir. Sezgisel yazma işlemleri ve tek bölmede izleme ve yönetim için kod içermeyen bir kullanıcı arabirimi sunar. Ayrıca mevcut SQL Server Integration Services (SSIS) paketlerini Azure'a kaldırabilir ve kaydırabilir ve bunları Azure Data Factory'de tam uyumlulukla çalıştırabilirsiniz.

Azure Data Lake Storage 2. Nesil, Azure Blob Depolama üzerine oluşturulmuş, büyük veri analizine ayrılmış bir özellik kümesidir. Data Lake Storage 2. Nesil, Azure Data Lake Storage 1. Nesil özelliklerini Azure Blob Depolama ile yakınsıyor. Örneğin, Data Lake Storage 2. Nesil dosya sistemi semantiği, dosya düzeyi güvenlik ve ölçeklendirme sağlar. Bu özellikler Blob Depolama üzerine oluşturulduğundan, yüksek kullanılabilirlik/olağanüstü durum kurtarma özelliklerine sahip düşük maliyetli, katmanlı depolama da elde edersiniz.

Azure Event Hubs basit, güvenilir ve ölçeklenebilir tam olarak yönetilen, gerçek zamanlı bir veri alımı hizmetidir. Dinamik veri işlem hatları oluşturabilmek ve iş zorluklarının anında üstesinden gelmek için istediğiniz kaynaktan saniyede milyonlarca olay akışı oluşturun.

Azure Databricks , Microsoft Azure Cloud Services için iyileştirilmiş Apache Spark tabanlı bir veri analizi platformudur. Azure Databricks yoğun veri gerektiren uygulamalar geliştirmek için üç ortam sunar: Databricks SQL, Databricks Veri Bilimi ve Mühendislik ve Databricks Machine Learning.

Alternatifler

Yalnızca meta verileri dizine eklemeye alternatif olarak Azure Databricks, Azure Synapse Analytics, Azure Bilişsel Arama veya Azure Veri Gezgini gibi sorgu özellikleri sunan bir hizmetteki tüm ham verileri dizine ekleyebilirsiniz. Bu yaklaşım daha hızlıdır, ancak özellikle maliyet açısından veri boyutunun, performans gereksinimlerinin ve güncelleştirme sıklığının birleşik etkisine dikkat edin.

Delta gölü kullanmanın aksine, Lambda mimarisi kullanmak gerçek zamanlı verileri geçmiş verilerden farklı bir depoda tutar ve istemciniz heterojen sorguları kullanıcıya saydam hale getirmek için mantığı çalıştırır. Bu çözümün avantajı, kullanabileceğiniz daha büyük hizmet kümesidir (Azure Stream Analytics ve Azure SQL Veritabanı gibi), ancak mimari daha karmaşık hale gelir ve kod tabanının bakımı daha pahalı olur.

Spark, Azure Databricks, Azure Synapse Analytics ve Azure HDInsight ile dağıtılır. Bu nedenle bu mimari, tercihen Delta Lake 0.8 veya 1.0'ı destekleyen yeni bir Spark sürümüyle bu Azure veri hizmetlerinden herhangi biriyle uygulanabilir.

Senaryo ayrıntıları

Boş zaman ve seyahat rezervasyon senaryolarında ham verilerin görünürlüğü birden çok aktör için önemlidir. Teknik destek ekipleri, işlem işlemeyi sürekli izlemek ve istenmeyen sorunlara hızlı bir şekilde tepki vermek için gerçek zamanlı tanılamaları denetlemektedir. Veri mühendisleri, paydaşların gözden geçirmesi ve gerçek zamanlı olarak akış analizi için verileri dışarı aktarmayı denetlemektedir. Müşteri destek ekipleri, müşteri sorgularını ve şikayetlerini işlemek için geçmişe dönük ve son verilere ihtiyaç duyar. Son olarak, hukuk ekipleri uyumluluk görevlerinin yerine getirildiğinden ve yasal işlemlerin gerçekleştirildiğinden emin olunmasını sağlar. Bu tür gereksinimler, dış sağlayıcıları toplayan ve kullanıcı satın almalarını yöneten marketlerde tipiktir. Örneğin, boş zaman ve seyahat rezervasyon sistemleri, hizmet arama, sağlayıcılardan anlamlı teklifler toplama ve kullanıcı rezervasyonlarını yönetme konusunda kullanıcıları ve hizmet sağlayıcılarını dağıtır.

Hizmet sağlayıcıları ve B2B ve B2C kullanıcılarının olduğu bir marketin diyagramı.

Olası kullanım örnekleri

Bu mimari seyahat ve konaklama sektörleri için idealdir. Aşağıdaki senaryolar için geçerlidir:

  • Gerçek zamanlı (örneğin, tanılama için) veya geçmiş (uyumluluk için) ham belgeleri özgün biçimlerinde hızla alma.
  • Petabaytlarlık verileri yönetme.
  • Gerçek zamanlı tanılama için saniye aralığı performansını garanti etme.
  • Gerçek zamanlı tanılama, geçmiş sorgular ve besleme analizi için birleşik bir yaklaşım elde etme.
  • Aşağı akış gerçek zamanlı analiz besleme.
  • Maliyetleri denetleme.
  • Verileri ham belgeler olarak kaynak oluşturma (örneğin, json, xml veya csv dosyaları gibi).
  • Sorguları açıklamak için verinin bir bölümü yeterli olduğunda.
  • Kullanıcılar tam ham belgeleri almak istediğinde.
  • Toplam veri boyutunun sistemin hedef fiyatınızın üzerinde ölçeklendirileceği durumlarda.

Bu mimari aşağıdaki durumlarda uygun olmayabilir:

  • Veriler kayıt kümeleri olarak kaynaklanır.
  • Kullanıcıların analiz çalıştırması gerekir.
  • Kullanıcılar kendi paketlenmiş BI araçlarını kullanmaya isteklidir.
  • Maliyet açısından bakıldığında verilerin boyutu zor değildir.

Ham belgeler gerekli olmayabilir.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Performans verimliliği

Performans verimliliği, kullanıcılar tarafından anlamlı bir şekilde yerleştirilen talepleri karşılamak amacıyla iş yükünüzü ölçeklendirme becerisidir. Daha fazla bilgi için bkz . Performans verimliliği sütununa genel bakış.

Kullanıcılar verilere erişmek için bir çift atlama gerçekleştirir. Önce meta verileri sorgular ve sonra istenen belge kümesini alır. Mevcut veya paketlenmiş istemci varlıklarını yeniden kullanmak zor olabilir.

Azure Data Lake Storage 2. Nesil üç erişim katmanı sağlar: sık erişimli, seyrek erişimli ve arşiv. Belgelerin zaman zaman alındığı senaryolarda seyrek erişimli performans katmanı, sık erişimli performans katmanına benzer performansı garanti etmeli ancak maliyetlerin daha düşük olmasını sağlamalıdır. Daha yeni verilerle alma olasılığının daha yüksek olduğu senaryolarda seyrek erişimli ve sık erişimli katmanları karıştırmayı göz önünde bulundurun. Arşiv katmanı depolamanın kullanılması, sabit silmeye bir alternatif sağlamanın yanı sıra yalnızca anlamlı bilgileri veya daha fazla toplanmış veriyi tutarak verilerin boyutunu küçültebilir.

Veri gölü petabaytlarca veriyi yöneteceğinden veri saklama ilkeleri genel olarak geçerlidir. Veri idaresi çözümleri, sık erişimli ve seyrek erişimli depolama katmanları arasında eski verilerin ne zaman taşınacağı, eski verilerin ne zaman silineceği veya arşivlenmesi gerektiği ve bilgileri aşağı akış analizi çözümünde ne zaman toplanacakları gibi veri yaşam döngüsünü yönetmek için kullanılmalıdır.

Bu yaklaşımın aşağı akış analizi senaryolarında nasıl çalışabileceğini düşünün. Bu örnek iş yükü analiz için tasarlanmamış olsa da, aşağı akış gerçek zamanlı analizi beslemek için uygundur, ancak bunun yerine toplu iş senaryoları veri gölünden beslenebilir.

Ölçeklenebilirlik

Azure Event Hubs, tanılama ve uyumluluk sisteminden ham belgeler oluşturan bir işlem sistemini ayırma konusunda çok yönlüdür; önceden oluşturulmuş mimarilerde uygulanması kolaydır; ve son olarak kullanımı kolaydır. Ancak işlem sistemi, gelen belgeleri işlemek için akış düzenini zaten kullanabilir. Bu durumda, tanılama ve uyumluluğu yönetmek için mantığı bir alt akış olarak akış uygulamasıyla tümleştirmeniz gerekebilir.

DevOps

Bu örnek iş yükünde kullanılan hizmetleri otomatik olarak dağıtmak için en iyisi sürekli tümleştirme ve sürekli dağıtım (CI/CD) işlemlerini kullanmaktır. Azure DevOps veya GitHub Actions gibi bir çözüm kullanmayı göz önünde bulundurun.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış.

Genel olarak, maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer önemli noktalar hakkında bilgi edinmek için Microsoft Azure İyi Tasarlanmış Çerçeve'deki maliyet bölümüne bakın.

Bu senaryoyu dağıtın

Aşağıdaki örnek mimaride, bir veya daha fazla Azure Event Hubs ad alanının yapılandırılmış ham belgeler (json veya xml dosyaları gibi) içereceğini varsayıyoruz. Bununla birlikte, belgelerin ve kaynak hizmetlerin gerçek türü ve biçimi ile bunların tümleştirme türü, belirli senaryoya ve mimariye büyük ölçüde bağlıdır.

Akışlar

Spark Yapılandırılmış Akışı ile ham veriler çekilir, açılır, ayrıştırılır ve akış DataFrame'deki tablosal verilere çevrilir.

Event Hubs'dan akış DataFrame'i yüklemek için aşağıdaki PySpark kod parçacığı kullanılır:

# Code tested in Databricks with Delta Lake 1.0
eh_connstr = <your_conn_str>
eh_consumergroup = <your_consumer_group>
ehConf = {}
ehConf['eventhubs.connectionString'] = 
sc._jvm.org.apache.spark.eventhubs.EventHubsUtils.encrypt(eh_conn
str)
ehConf['eventhubs.consumerGroup'] = eh_consumergroup

streaming_df = spark \
  .readStream \
  .format("eventhubs") \
  .options(**ehConf) \
  .load()

Akış DataFrame'i işlemek için aşağıdaki kod parçacığı kullanılır. Gerekirse önce Event Hubs iletisinin sıkıştırmasını açar ve ardından json yapısını tablo biçiminde ayrıştırılır. Bu kod bir örnektir ve özel senaryonuza uyarlanmalıdır:

# Code tested in Databricks with Delta Lake 1.0

# defines an UDF to unzip the Event Hubs Body field, assuming it 
is gzipped

import zlib
def DecompressFunction(data):
  decoded_data = zlib.decompress(bytes(data), 15+32)
  return decoded_data.decode()

Decompress = udf(lambda body: DecompressFunction(body), 
StringType())
decoded_body_df = streaming_df.withColumn("DecodedBody", 
Decompress(col("body"))).select("DecodedBody")

# Parse json message from Event Hubs body, assuming the raw 
document is stored in the data field, and the others fields hold 
some metadata about it

schema = StructType([ \
    StructField("transactionId", LongType(),True), \
    StructField("timestamp",TimestampType(),True), \
    StructField("providerName", StringType(),True), \
    StructField("document", StringType(),True), \
    StructField("documentType", StringType(),True)
  ])

parsed_body_df = decoded_body_df.withColumn("jsonBody", 
from_json(col("DecodedBody"), schema)).select("jsonBody")

Gerçek veri işleme iki adımdan oluşur. İlki, işlendikten sonra ham belgelerde arama yapmaya yardımcı olacak meta verileri ayıklamaktır. Gerçek meta veriler kullanım örneğine bağlıdır, ancak genelleştirilebilir örnekler ilgili tarihler ve tanımlayıcılar, belge türleri, kaynak hizmet ve herhangi bir kategori türü olabilir:

# Code tested in Databricks with Delta Lake 1.0

df = parsed_body_df \
    .withColumn("transactionId", 
parsed_body_df.jsonBody.transactionId) \
    .withColumn("timestamp", parsed_body_df.jsonBody.timestamp) \
    .withColumn("providerName", 
parsed_body_df.jsonBody.providerName) \
    .withColumn("data", parsed_body_df.jsonBody.data)
    .withColumn("documentType", 
parsed_body_df.jsonBody.documentType)

İkinci işleme adımı, ham belgeleri depoladığınız Azure Data Lake Storage 2. Nesil yolu oluşturmaktır:

# Code tested in Databricks with Delta Lake 1.0

# A function to generate a path
def GetPathFunction(timeStamp, transactionId, providerName, 
Suffix='', Extension=".gz"):
  yy = timeStamp.year
  mm = timeStamp.month
  dd = timeStamp.day
  hh = timeStamp.hour
  mn = timeStamp.minute
  Suffix = f"{Suffix}_" if Suffix != '' else ''
  Name = f"{Suffix}{providerName}{Extension}"
  path = f"/{yy}/{mm}/{dd}/{hh}/{mn}/{transactionId}/{Name}"
  return path

GetPath = udf(lambda timestamp, transactionId, providerName, 
suffix, extension: GetPathFunction(timestamp, transactionId, 
providerName, suffix, extension), StringType())

df = df.withColumn("path", GetPath(col("timestamp"), 
col("transactionId"), col("providerName"), col('documentType')))

Delta gölünde meta veri alımı

Meta veriler, gerçek zamanlı sorgu özelliklerini etkinleştiren bir delta tablosuna yazılır. Yazma işlemleri bir arabellekte akışı yapılır ve tabloya yapılan sorgular arabellekteki sonuçları tablonun geçmiş bölümündekilerle birleştirebilir.

Aşağıdaki kod parçacığında meta veri deposunda delta tablosunu tanımlama ve tarihe göre bölümleme gösterilmektedir:

# Code tested in Databricks with Delta Lake 1.0

DeltaTable.create(spark) \
   .tableName("metadata") \
   .addColumn("transactionId", LongType()) \
   .addColumn("date", TimestampType()) \
   .addColumn("providerName", StringType()) \
   .addColumn("documentType", StringType()) \
   .addColumn("path", StringType()) \
   .partitionedBy("date") \
   .execute()

transactionId alanının sayısal olduğunu unutmayın. Dağıtılmış sistemlerden geçen tipik iletiler, bunun yerine işlemleri benzersiz olarak tanımlamak için GUID'leri kullanabilir. Ancak, sayısal veri türleri çoğu veri platformunda daha yüksek sorgu performansı sağlar.

Bulut veri platformlarının (Spark gibi) dağıtılmış yapısı göz önünde bulundurulduğunda benzersiz bir işlem tanımlayıcısı atamak zor olabilir. Bu tür bir işlem tanımlayıcısını bölüm tanımlayıcısına (Event Hubs bölüm numarası gibi) ve bölüm içi artımlı sayıya dayandırmak yararlı bir yaklaşımdır. Azure Databricks'te monotonically_increasing_id() bu yaklaşıma örnek olarak verilmiştir.

Aşağıdaki kod parçacığında, delta tablosuna ham belgelerin meta verileriyle akışın nasıl ekli olduğu gösterilmektedir:

# Code tested in Databricks with Delta Lake 1.0

df.withColumn("date", col("timeStamp").cast(DateType())) \
    .select("transactionId", "date", "providerName", 
"documentType", "path") \
    .writeStream.format("delta") \
    .outputMode("append") \
    .option("checkpointLocation", 
"/delta/metadata/_checkpoints/metadata_checkpoint") \
    .table("metadata")

Akış tablo şemasına göre yazılırken bölümlemenin yönetildiğini unutmayın.

Veri gölünde veri alımı

Gerçek ham belgeler, Azure Data Lake 2. Nesil'de uygun bir depolama performansı katmanına yazılır.

Aşağıdaki kod parçacığı, Azure Data Lake Store 2. Nesil'e dosya yüklemek için basit bir işlev gösterir; sınıfında bir foreach yöntemi DataStreamWriter kullanmak, akış DataFrame'in her kaydında barındırılan dosyayı karşıya yüklemenize olanak tanır:

# Code tested in Databricks with Delta Lake 1.0

from azure.storage.filedatalake import DataLakeServiceClient

def upload_data(storage_account_name, storage_account_key, 
file_system_name, file_path, data):

  service_client = 
DataLakeServiceClient(account_url="{}://{}.dfs.core.windows.net".
format("https", storage_account_name), 
credential=storage_account_key)

  file_system_client = 
service_client.get_file_system_client(file_system_name)
  file_client = 
service_client.get_file_client(file_system_client.file_system_nam
e, file_path)
    
  if not file_client.exists:
    file_client.create_file()      

  file_client.upload_data(data, overwrite=True)
  
# Process a row to upload data to ADLS
def Row2ADLS(row):
  upload_data(adls_name, adls_key, adls_container, row['path'], 
row['data'])

df.writeStream.foreach(Row2ADLS).start()

İstemci

İstemci, standart SQL deyimleriyle delta tablosundan belge yollarını almak için meta verileri kullanan özel bir web uygulaması ve buna karşılık, standart Azure Data Lake Storage 2. Nesil API'leri olan veri gölünden gerçek belge olabilir.

Örneğin aşağıdaki kod parçacığı, belirli bir işlemdeki tüm belgelerin yollarının nasıl alınacaklarını gösterir:

select * from metadata where transactionId = '123456'

Sonraki adımlar

İlgili mimari kılavuza bakın:

Şu ilgili mimarilere bakın: