paint-brush
Veri Boru Hattınız Karmaşık - İşte Yinelenen Verilerin Milyonlarca Dolar Harcamasını Nasıl Durduracağınızile@emailnareshe
578 okumalar
578 okumalar

Veri Boru Hattınız Karmaşık - İşte Yinelenen Verilerin Milyonlarca Dolar Harcamasını Nasıl Durduracağınız

ile Naresh Erukulla10m2025/01/28
Read on Terminal Reader

Çok uzun; Okumak

Gerçek zamanlı veri işlemede, yinelenen kayıtlar yanlış içgörülere, gereksiz hesaplama maliyetlerine ve alt akış sistemlerinde verimsizliklere yol açabilir. Bu, yinelenen verileri kaldırmayı akış veri hatlarının kritik bir bileşeni haline getirir. Etkili stratejilerin uygulanması, temiz ve güvenilir verileri korumak için anahtardır.
featured image - Veri Boru Hattınız Karmaşık - İşte Yinelenen Verilerin Milyonlarca Dolar Harcamasını Nasıl Durduracağınız
Naresh Erukulla HackerNoon profile picture
0-item


Veri Mühendisleri genellikle verilerin uygunsuz biçimde olması, özellikle önemsiz karakterler ve veriler, boş veya geçersiz değerler ve en önemlisi raporlama ve veri bilimi modelleri dahil olmak üzere tüm alt akış uygulamalarını etkileyen yinelenen verilerle başa çıkma konusunda zorluklarla karşılaşırlar. Bu, mühendisler ve destek ekipleri için günlük olarak zorlu bir görev haline gelir ve üretken olmadan kaynaklarını hızla tüketir. Genellikle kötü tasarlanmış çerçeveler, geliştiricilerin daha sonra bu veri düzeltmelerini hafifletmesi için zor zamanlar geçirir. Birçok kuruluş, etkisiz veri hattı mimarileri nedeniyle yedekli verilere sahiptir ve bu da onlara milyonlarca dolarlık depolama maliyeti, verilerin birkaç kez yeniden işlenmesi ve zayıf kaynak kullanımı anlamına gelir.


Gelelim şu anki rolünüzde, akış veya toplu veri hatlarında kopyaları işleme konusunda hiç zorlukla karşılaştınız mı? Veri mühendislerinin, veri bilimcilerinin ve veri analistlerinin çoğu "EVET" derdi. Bir veri gölündeki kopya verileri düzeltmek için, günümüz dünyasında çok sayıda araç var ama maliyeti ne? Bunları mimari tasarım aşamanızda halledebilir misiniz? Aklınıza birçok soru takılabilir.


Akış verilerini çoğaltmanıza yardımcı olabilecek araçların neler olduğunu, artılarını ve eksilerini, kurulumlarını ve bakımlarını ayrıntılı olarak tartışalım. Ardından, akış hattındaki çoğaltmaları ele almak için en iyi uygulamaları ve standartları derinlemesine inceleyeceğiz.




Akışlı veri hatlarında veri çoğaltmayı önlemeye yönelik üç temel yaklaşımı inceleyelim:

Pub/Sub Mesaj Niteliklerini Kullanarak Yinelenenleri Kaldırma

Tüm akış hatları, IoT cihazları, sensörler, oyun istatistikleri, trafik kameraları ve hız dedektörü cihazları ve otonom araçlardan araç kullanım verilerini akışa alan akıllı sistemler gibi farklı uygulamalardan veri çıkarır. Bu sistemlerin çoğu genellikle olayları akışa almak için bir örüntü izler ve her olayın normalde benzersiz bir tanımlayıcısı olur, örneğin satış işlemi için bir Perakende Mağazası işlem kimliği ve olay zaman damgası. Bazı sistemler genellikle benzersiz bir tanımlayıcıya sahip değildir, hız sensörü cihazları gibi örnekler genellikle kendi Sensör Kimliğine sahiptir ancak tüm akış olayları olay zaman damgası dışında benzersiz bir tanımlayıcıya sahip değildir. Bu durumlarda, aynı sensör cihazı için yinelenen akış olayları olma olasılığı yüksektir.


Yoğun bir günde, eyaletler arası bir yolda bir cihazdan araç hız verilerinin akışının normalde dakikada büyük hacimlerde olacağı bir kullanım durumunu düşünün. Başka bir örnek ise, bayram indirimi etkinlikleri sırasında perakende işletmelerinin günde milyarlarca işlemle uğraşması gerektiğidir. Bu kadar büyük bir olay hacmini gerçek zamanlı olarak ele almak ve verileri çoğaltmak, aykırı değerleri ve yinelenenleri kaldırarak doğru raporlama ve veri bilimi modellerinin verimli bir şekilde çalışması için çok önemlidir.


Teknik terimlerle konuşalım, Google Cloud, mesajları üreten servisleri bu mesajları işleyen servislerden ayıran eşzamansız ve ölçeklenebilir bir mesajlaşma hizmeti olan Pub/Sub'ı sağlar. Verileri yüklemek ve dağıtmak için akış analitiği ve veri bütünleştirme hatları için yoğun olarak kullanılır. Genellikle kullanıcı etkileşimi olaylarını, sunucu olaylarını, gerçek zamanlı olayları almak, veriyi veritabanları arasında çoğaltmak, iş olaylarını kuruluş genelinde paylaşmak için bir kurumsal olay veri yolu görevi görmek ve diğer Google Cloud ürünleriyle birlikte kullanılan sensörler ve uygulama olayları gibi uygulamalardan veri akışı sağlamak için kullanılır.


Pub/Sub, özniteliklerini kullanarak yinelenen verileri işlemek için basit ama güçlü bir yöntem sunar. Pub/Sub konusundaki her mesaj, meta verilerde anahtar-değer çiftleri içerebilir. Bu veriler, yükü genellikle daha yüksek kaynak maliyetlerine sahip olan ve veri hattını büyük ölçüde yavaşlatan veri işleme hizmetlerine yüklemeden yinelenen olayları belirlemek ve veri hattında yinelenenleri kaldırmayı etkinleştirmek için kullanılabilir.


transaction_id gibi benzersiz bir alan içeren iletiler için, iletiler yayınlanırken bu değer bir öznitelik olarak ayarlanabilir. Dataflow'da Pub/Sub'dan iletileri okurken, bu özniteliği kullanarak veri hattını çoğaltmayı kaldıracak şekilde yapılandırabilirsiniz.


Bu çözüm, kopyalar Pub/Sub konusu içindeki benzersiz tanımlayıcıyı kullanarak kaynak uygulamadan veya cihazdan aktığında etkilidir. Bu çözümün sınırlaması, yalnızca birbirinden 10 dakikalık bir zaman aralığında yayınlanan kopya mesajlar için iyi çalışmasıdır. Uygulanması basit olsa da Pub/Sub'daki zaman aralığı sınırlaması nedeniyle ölçeklenebilirlikten yoksundur. Bu, hız kamerası veya sensör cihazlarının her mesajdan 10 dakikalık bir zaman aralığında kopya olaylar üretmesi gibi durumlarda çok faydalıdır, harika çalışır.


Pub/Sub gibi yayıncının kendisinde oluşturulan yinelemelerin, alt akış tarafından iletilerin tüketilmesindeki gecikmeden veya Pub/Sub'un iletilen iletiler için hiçbir zaman bir onay almamasından kaynaklandığı durumlar olabilir, Pub/Sub aynı iletiyi aynı Message_id'yi kullanarak göndermeyi yeniden dener ve böylece yayıncıda yinelenen olaylar oluşturur. Bunu ele almak için Pub/Sub'ı kullanarak yükün message_id'sini belirleyebilir ve bunu bir tanımlayıcı olarak kullanabiliriz. Google Cloud platformunda (GCP) akış işleme verileri için tamamen yönetilen bir hizmet olan Cloud DataFlow , her kaydın tam olarak bir kez işlenmesini sağlar. Bu bizim için ne anlama geliyor? - Yinelenen olayları message_id'ye göre belirler ve veri hatlarında işlenirken bunları ortadan kaldırır ancak nadir durumlarda bu yinelenen olaylar veri akışı içindeki farklı çalışan düğümlerinde işlendiğinde, etkisiz bir şekilde alt akışa ulaşır. Veri gölünüzde yinelenenler olacaktır.


Bu tür durumların nasıl ele alınacağı hakkında bu makalenin sonuna doğru daha fazla tartışacağız. Akış verilerini çoğaltmak için kalan seçeneklere odaklanalım.



Apache Beam'in Deduplicate PTransform'unu kullanarak çoğaltma


Artık Pub/Sub'un yinelenen olayları nasıl işlediğini biliyoruz, sıradaki adım bu mesajların Cloud DataFlow kullanılarak işlenmesi ve bir Pub/Sub abonesinin kaynak uygulamadan akış mesajlarını okumasıdır. Dataflow, gelişmiş akış yeteneklerini etkinleştirmek için açık kaynaklı Apache Beam SDK kullanan tam olarak yönetilen bir hizmettir. Dataflow, iş başına 4000 çalışan düğüme kadar ölçeklenebilir ve hem toplu hem de akış hatlarında daha iyi kaynak kullanımı için otomatik ölçekleme özellikleriyle petabaytlarca veriyi işleyebilir.


Apache Beam, yinelenenleri kaldırmak için daha yapılandırılabilir ve sağlam bir yöntem sağlayan yerleşik bir Deduplicate PTransform sunar. Bu yöntem, gözlemlenen her anahtar için bir durum sürdürmek ve kullanıcı tanımlı bir zaman penceresi içinde yinelenenleri kaldırmak için Beam'in Stateful API'sini kullanır. Bu yaklaşım, verilerinizdeki belirli alanlara veya tüm mesaj içeriğine dayalı olarak yinelenenleri kaldırma mantığını tanımlamanıza ve yinelenenleri olay zamanına veya işlem zamanına göre yapılandırma olanağına olanak tanır.


Bu işlevselliği denemek için GitHub'daki örnek veri hattı kodumu inceleyin.


Burada dikkat edilmesi gereken bir şey, toplu veri hatları her zaman tam olarak bir kez işleme kullanırken, akış veri hatları varsayılan olarak tam olarak bir kez işleme kullanır ancak en azından bir kez işleme kullanacak şekilde yapılandırılabilir. Buradaki püf noktası, veri akışının şu anda işlediği pencerenin, yinelenen bir iletiyi işleme penceresini geçtiğinde, veri akışının kayıt kimliklerini bellekte saklamaması nedeniyle, bunu zaten işlenenle karşılaştırmayacağıdır. Veri akışı, geç gelen verilere dayanarak veya veri hattının işlenmemiş iletileri yakalamak ve Cloud Bigquery'deki bir tabloya yazmak için başka bir ayağı varsa bu iletiyi atabilir - GCP'de tamamen yönetilen, bulut tabanlı bir veri ambarı veya bir bulut depolaması - yapılandırılmamış verileri daha fazla yeniden işleme ve sorun giderme amacıyla bir dosya olarak depolamak için yönetilen bir hizmettir.



Bu çözüm, karmaşık tekilleştirme oturum açma işlemlerini işlemek ve tekilleştirme penceresinin Pub/Sub'ın sunduğundan daha büyük veya daha karmaşık olduğu senaryolar için uygun hale getirmek için esnek bir seçenek sunar. Karşılıklı ödünler, kayıt benzersizliğini belirlemek için her bir durumu sürdürmek için daha yüksek kaynak kullanımını içerir



Lavaboda Veri Çoğaltma


Şimdiye kadar Pub/Sub gibi Publisher'ların ve Cloud DataFlow entegrasyon hizmetlerinin yinelenenleri gerçek zamanlı olarak nasıl işlediğini gördük. Bu çözümlerin, işleme yükü ve hacim sorunları nedeniyle pencereleme söz konusu olduğunda %100 etkili olmadığını düşünüyorum; bu tür senaryolarda, yinelenen bir mesajın geç gelmesi ve veri akışının, mesajların benzersizliğini çapraz kontrol etmek için kayıt kimliklerini tutmadığı için benzersiz bir kayıt olduğunu düşünmesi ve başka bir senaryoda, veri akışının, ağ arızaları ve/veya çalışan düğümü arızaları nedeniyle bu mesajları farklı çalışan düğümlerinde işlemesi, veri akışında işlenirken benzersiz bir kayıt olduğunu düşünmesine neden olur ve Google bulut bigquery tablosu gibi alt akış sistemlerine girer.


Bu gibi durumları azaltmak ve veri tekilleştirmenin son kontrolü olarak, BigQuery veya diğer veri ambarları gibi havuz düzeyinde gerçekleşebilir. Bu yaklaşım, gerçek zamanlı veri tekilleştirmenin kritik olmadığı ve periyodik veri tekilleştirmenin yeterli olduğu durumlarda sıklıkla yararlıdır. Bu, gelişmiş SQL sorguları kullanılarak tüm yinelenen iletileri etkili bir şekilde filtreleyecek ve ortadan kaldıracaktır.


Kullanım durumuna göre, kopyaları düzeltmek için iki tür çözüm mevcuttur.


Öncelikle, bölümleri kullanarak periyodik olarak (Günlük veya saatlik) veri kaldırma tablosu oluşturmak için bir Composer DAG veya BigQuery konsolu üzerinden zamanlanmış sorguları kullanın; bu, herkesin süreci oluşturmasını ve veri kaldırma verilerini bir hazırlama tablosunda depolamasını ve ayrı verileri son tabloya yüklemesini basit bir seçenek haline getirir.


İkincisi, gerçek zamanlı verileri elde etmek için somutlaştırılmış bir görünüm kullanabiliriz, bu da onu işletme içgörülerini hızlı bir şekilde elde etmek için ideal bir çözüm haline getirir.



Bigquery SQL sorgusu Github dedup_sql bağlantımda sunulmaktadır.


Aşağıdaki bigquery sql kodu daha önce tartıştığımız iki seçeneği açıklıyor:

 -- Use below SQL queries to periodically deduplicate data in BigQuery tables. CREATE OR REPLACE TABLE Transactions AS SELECT DISTINCT * FROM raw_transactions; --OR use below incremental steps to drop the necessary partitions and re-insert the deduped data into the original table -- Step 1: Insert distinct records from the original table based on the max timestamp available CREATE OR REPLACE TABLE STAGE_TRANSACTIONS AS SELECT DISTINCT * FROM raw_transactions WHERE event_timestamp > ( SELECT MAX(event_timestamp) FROM raw_transactions ); -- Step 2: Drop the partition after deduplication DELETE FROM raw_transactions WHERE event_timestamp = > ( SELECT MAX(event_timestamp) FROM raw_transactions ); -- Step 3: Insert deduplicated data into the main table INSERT INTO raw_transactions SELECT DISTINCT * FROM STAGE_TRANSACTIONS; --OR Use below SQL query to Merge new data without duplicates the table MERGE INTO raw_transactions AS target USING ( SELECT * FROM STAGE_TRANSACTIONS ) AS source ON target.transaction_id = source.transaction_id AND target.event_timestamp <= source.event_timestamp WHEN MATCHED THEN UPDATE SET target.product = source.product, target.price = source.price, target.location = source.location, target.store = source.store, target.zipcode = source.zipcode, target.city = source.city, target.promotion = source.promotion, target.event_timestamp = source.event_timestamp WHEN NOT MATCHED THEN INSERT (transaction_id, product, price, location, store, zipcode, city, promotion, event_timestamp) VALUES (source.transaction_id, source.product, source.price, source.location, source.store, source.zipcode, source.city, source.promotion, source.event_timestamp); --OR to get the real-time data without duplicates, use following materialized view and a finest solution to retrieve dedup records quickly CREATE MATERIALIZED VIEW raw_transactions_mv AS SELECT transaction_id, product, price, location, store, zipcode, city, promotion, event_timestamp FROM ( SELECT transaction_id, product, price, location, store, zipcode, city, promotion, event_timestamp, ROW_NUMBER() OVER ( PARTITION BY transaction_id ORDER BY event_timestamp DESC ) AS row_num FROM raw_transactions ) WHERE row_num = 1;

Teknik Karşılıklar

Her bir çoğaltma önleme stratejisinin kendine özgü bir dizi takası vardır. Doğru yaklaşımı seçmenize yardımcı olacak bir özet:

Yöntem

Avantajları

Dezavantajları

Yayınla/Abone Ol Mesaj Nitelikleri

Düşük gecikme, Pub/Sub'a özgü

10 dakikalık veri tekilleştirme penceresiyle sınırlıdır

Apache Beam'in Tekrarını Kaldırma

Son derece esnektir, karmaşık veri çoğaltma mantığını destekler

Devlet yönetimi nedeniyle daha yüksek kaynak tüketimi

Lavabo Tabanlı Veri Çoğaltma

Toplu veya periyodik güncellemeler için uygundur, minimum mantık

Gecikmeye neden olabilir; orkestrasyon araçlarına ihtiyaç duyulabilir

Özetle

Yinelenen veri kaldırma, akış hatlarında etkili veri işlemenin temel taşıdır. Strateji seçimi, hattınızın gerçek zamanlı ihtiyaçlarına, karmaşıklığına ve kaynak kısıtlamalarına bağlıdır. Pub/Sub niteliklerinin, Apache Beam Deduplicate PTransform'un veya havuz tabanlı yinelenen veri kaldırmanın güçlü yönlerinden yararlanarak, akış aşağısı sistemleri için temiz ve güvenilir veriler sağlayabilirsiniz. Bu yaklaşımları keşfedin, sağlanan örnekleri uygulayın ve en iyi sonuçlar için bunları kullanım senaryonuza uyarlayın.


Veri analitiği ve makine öğrenimi hakkında daha derinlemesine kılavuzlarla ilgileniyor musunuz? Beni takip edin Orta veya Linkedin En son makaleler için, düşüncelerinizi veya sorularınızı aşağıdaki yorumlarda paylaşmaktan çekinmeyin. Bu makaleyi yararlı bulduysanız, ağınızla paylaşın ve başkalarının perakendede gerçek zamanlı analizlerin potansiyelini ortaya çıkarmasına yardımcı olun.