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   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'ı  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.    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. transaction_id  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.   (GCP) akış işleme verileri için tamamen yönetilen bir hizmet olan   , her kaydın   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. Google Cloud platformunda Cloud DataFlow tam olarak bir kez  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   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ı   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. Cloud DataFlow Apache Beam SDK  Apache Beam, yinelenenleri kaldırmak için daha yapılandırılabilir ve sağlam bir yöntem sağlayan yerleşik bir   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   veya   göre yapılandırma olanağına olanak tanır. Deduplicate olay zamanına işlem zamanına  Bu işlevselliği denemek için   örnek veri hattı kodumu inceleyin. GitHub'daki  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   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   - 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. Cloud Bigquery'deki bulut depolaması  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   bağlantımda sunulmaktadır. Github dedup_sql  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   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. Deduplicate  Veri analitiği ve makine öğrenimi hakkında daha derinlemesine kılavuzlarla ilgileniyor musunuz? Beni takip edin  veya  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.   Orta   Linkedin

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

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

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps