Basit, verimli ve düşük gecikme süreli veri işlem hatları oluşturma

Günümüzün veri odaklı işletmeleri sürekli olarak veri üretir ve bu da bu verileri sürekli olarak alan ve dönüştüren mühendislik veri işlem hatlarını zorunlu kılmaktadır. Bu işlem hatlarının verileri tam olarak bir kez işleyebilmesi ve sunabilmesi, 200 milisaniyeden kısa gecikme süreleriyle sonuç üretmesi ve maliyetleri her zaman en aza indirmeye çalışması gerekir.

Bu makalede mühendislik veri işlem hatlarına yönelik toplu ve artımlı akış işleme yaklaşımları, artımlı akış işlemenin neden daha iyi bir seçenek olduğu ve Databricks'in artımlı akış işleme tekliflerini kullanmaya başlamanın sonraki adımları, Azure Databricks'te Akış ve DLT Nedir?. Bu özellikler, teslim semantiği, gecikme süresi, maliyet ve daha fazlasını garanti eden işlem hatlarını hızlı bir şekilde yazmanızı ve çalıştırmanızı sağlar.

Yinelenen toplu işlerin tuzakları

Veri işlem hattınızı ayarlarken, başlangıçta verilerinizi içeri aktarmak için tekrarlayan toplu işlem yazabilirsiniz. Örneğin, saatte bir kaynağınızdan okuyan ve Delta Lake gibi bir havuza veri yazan bir Spark işi çalıştırabilirsiniz. Bu yaklaşımın zorluğu kaynağınızı artımlı olarak işlemektir çünkü saatte bir çalışan Spark işinin son işin sona erdiği yerden başlaması gerekir. İşlediğiniz verilerin en son zaman damgasını kaydedebilir ve ardından bu zaman damgasından daha yeni zaman damgalarına sahip tüm satırları seçebilirsiniz, ancak bazı tuzaklar vardır:

Sürekli veri işlem hattını çalıştırmak için kaynağınızdan artımlı olarak okuyan, dönüştürmeler yapıp sonucu Delta Lake gibi bir havuza yazan saatlik bir toplu iş zamanlayabilirsiniz. Bu yaklaşımda tuzaklar olabilir:

• Bir zaman damgasının ardından tüm yeni verileri sorgulayan bir Spark işi, geç gelen verileri kaçıracaktır.
• Başarısız olan bir Spark işi, dikkatli bir şekilde işlenmediği takdirde tam olarak bir kez garantilerin bozulmasına neden olabilir.
• Yeni dosyaları bulmak için bulut depolama konumlarının içeriğini listeleyen bir Spark işi pahalıya patlar.

Ardından yine de bu verileri tekrar tekrar dönüştürmeniz gerekir. Yinelenen toplu işler yazabilir, bu işler verilerinizi toplar veya diğer işlemler uygular, böylece işlem hattını daha karmaşık hale getirir ve verimliliğini düşürür.

Toplu iş örneği

İşlem hattınıza yönelik toplu alım ve dönüştürme tuzaklarını tam olarak anlamak için aşağıdaki örnekleri göz önünde bulundurun.

Eksik veriler

Müşterilerinize ne kadar ücret kesileceğini belirleyen kullanım verilerine sahip bir Kafka konusu olduğunu varsayarsak ve iş hattınız veriyi toplu halde aldığında, olay dizisi şöyle görünebilir:

1. İlk toplu işleminiz 08:00 ve 08:30'da iki kayda sahip.
2. En son zaman damgasını 08:30'a güncelleştirirsiniz.
3. Saat 8:15'te yeni bir kayıt daha alırsınız.
4. İkinci toplu işleminiz 08:30'da her şeyi sorgular, böylece kaydı08:15'te kaçırabilirsiniz.

Buna ek olarak, kullanıcılarınızı fazla veya eksik ücretlendirmek istemezsiniz; bu nedenle, her kaydı tam olarak bir kez aldığınızı garanti etmeniz gerekir.

Gereksiz işleme

Ardından, verilerinizin kullanıcı satın alma satırlarını içerdiğini ve mağazanızdaki en popüler zamanları bilmek için saatlik satışları toplamak istediğinizi varsayalım. Aynı saat için satın alma işlemleri farklı partiler halinde gelirse, aynı saat için çıktı üreten birden fazla partiniz olur.

08:00 ile 09:00 arasında iki öğe (1. partinin çıktısı), bir öğe (2. partinin çıktısı) ya da üç öğe (hiçbir partinin çıktısı değil) var mı? Belirli bir zaman penceresi oluşturmak için gereken veriler, birden çok dönüştürme toplu işleminde görüntülenir. Bu sorunu çözmek için, bir sonucu hesaplamanız gerektiğinde verilerinizi güne göre bölümleyip bölümün tamamını yeniden işleyebilirsiniz. Ardından, sonuçları veri deposunuza yazabilirsiniz.

Ancak bu, gecikme süresi ve maliyete neden olur, çünkü ikinci toplu işlemin önceden işlenmiş olabilecek verileri işlemeye ilişkin gereksiz işleri yapması gerekir.

Artımlı akış işleme ile ilgili tuzak yok

Artımlı akış işleme, verileri almak ve dönüştürmek için yinelenen toplu işlerin tüm tuzaklarından kaçınmayı kolaylaştırır. Databricks Yapılandırılmış Akış ve DLT, akışın uygulama karmaşıklıklarını yöneterek yalnızca iş mantığınıza odaklanmanızı sağlar. Yalnızca hangi kaynağa bağlanılacağını, verilere hangi dönüştürmelerin yapılması gerektiğini ve sonucun nereye yazılacağını belirtmeniz gerekir.

Artımlı alım

Databricks'te artımlı veri işleme, artımlı olarak bir veri kaynağını tüketip bir çıkışa yazabilen Apache Spark Yapılandırılmış Akışı tarafından desteklenir. Yapılandırılmış Akış motoru verileri kesin olarak bir kez kullanabilir ve motor sırasız verileri işleyebilir. Motor, ya not defterlerinde çalıştırılabilir ya da DLT'de akış tabloları kullanılarak çalıştırılabilir.

Databricks'teki Yapılandırılmış Akış altyapısı, bulut dosyalarını artımlı olarak uygun maliyetli bir şekilde işleyebilen AutoLoadergibi özel akış kaynakları sağlar. Databricks ayrıca Apache Kafka, Amazon Kinesis, Apache Pulsarve Google Pub/Subgibi diğer popüler ileti otobüsleri için bağlayıcılar sağlar.

Artımlı dönüştürme

Databricks'te Yapılandırılmış Akış ile artımlı dönüşüm, bir toplu iş sorgusuyla aynı API'yi kullanarak DataFrame'lere dönüşümleri belirtmenize olanak tanır. Ancak, siz yapmak zorunda kalmadan verileri toplu işlemler arasında ve zaman içinde birikimli değerlerle takip eder. Verileri hiçbir zaman yeniden işlemesi gerekmeyecek, bu nedenle yinelenen toplu işlerden daha hızlı ve daha uygun maliyetlidir. Yapılandırılmış Akış, Delta Lake, Kafka veya desteklenen diğer bağlayıcılar gibi havuzunuza ekleyebileceğiniz bir veri akışı oluşturur.

DLT'de Gerçekleştirilmiş Görünümler Enzim motoru tarafından desteklenir. Enzim hala kaynağınızı artımlı olarak işler, ancak bir akış üretmek yerine, gerçekleştirilmiş bir görünüm oluşturur ve bu, verdiğiniz sorgunun sonuçlarını depolayan önceden hesaplanmış bir tablodur. Enzim, yeni verilerin sorgunuzun sonuçlarını nasıl etkilediğini verimli bir şekilde belirleyebilir ve önceden hesaplanan tabloyu up-to-date olarak tutar.

Gerçekleştirilmiş Görünümler, toplu verileriniz üzerinde her zaman etkin bir şekilde güncellenen bir görünüm oluşturur; böylece, örneğin yukarıda açıklanan senaryoda, 08:00 ile 09:00 zaman aralığında üç bileşen olduğunu bilirsiniz.

Yapılandırılmış Akış mı yoksa DLT mi?

Yapılandırılmış Akış ile DLT arasındaki önemli fark, akış sorgularınızı çalışır hale getirme yönteminizdir. Yapılandırılmış Akış'ta birçok yapılandırmayı el ile belirtirsiniz ve sorguları el ile birleştirmeniz gerekir. Sorguları açıkça başlatmanız, sonlandırılmalarını beklemeniz, hata durumunda iptal etmeniz ve diğer eylemleri gerçekleştirmeniz gerekir. DLT'de, işlem hatlarınızı çalıştırması için DLT'ye deklaratif bir şekilde verirsiniz ve o da onları çalışır durumda tutar.

DLT ayrıca verilerinizin dönüşümlerini verimli ve artımlı olarak önceden hazırlayan Gerçekleştirilmiş Görünümlergibi özelliklere de sahiptir.

Bu özellikler hakkında daha fazla bilgi için bkz. azure databricks akışı ve DLT nedir?.

Sonraki adımlar

• DLT ile ilk işlem hattınızı oluşturun. Bkz: Öğretici Eğitim: İlk DLT işlem hattınızı çalıştırma.
• Databricks'te ilk Yapılandırılmış Akış sorgularınızı çalıştırın. bkz. ilk Yapılandırılmış Akış iş yükünüzü çalıştırma.

• Malzemeleşmiş bir görünüm kullanın. Bkz. Databricks SQL'de materyalleştirilmiş görünümleri kullanma.