跳到正文
DEV Community· Serdar Tavukçu·· 3 小時前AI 評分44

如何避免雙來源數據處理中的數據靜默流失

İki Kaynaklı Veri İşinde Sessiz Kayıp Nasıl Önlenir

AI 導讀

作者在合併兩個來源的數據時,發現未能配對或格式不符的行會被程式靜默略過,導致報告內容不完整。為避免數據流失,他加入行數核算,確認輸入行數等於成功處理行數與錯誤行數之和;不相符便停止並拒絕產生報告。錯誤行會記錄在日誌中,附上時間戳記和錯誤原因。

正文

gorsel

Olay nasıl başladı

Bir süre önce elimdeki iki farklı kaynaktan gelen kayıt dosyalarını eşleştirip bir rapor çıkaran bir sistem yazdım. İşin mantığı gayet basitti. Birinci dosyadan veriyi al, ikinci dosyadaki karşılığıyla birleştir ve nihai tabloyu oluştur. Python üzerinden ilerliyordum ve kodun çalışması için gereken her şeyi tamamladım. Kod çalıştı, raporlar üretildi ve işler yolunda gibi görünüyordu. Ancak içimdeki o huzursuzluk hissi bir türlü geçmedi. Rapor her zaman üretiliyordu ama işin içinde kaç veri kayboldu, hangileri eşleşmedi, kimse bunu sorgulamıyordu.

Sistem sessizce ilerliyordu. Ben de ilk etapta her şeyin yolunda olduğunu düşündüm. Sonra bir gün verilerin toplamını kontrol etmeye karar verdim. Girdiğim satır sayısı ile çıktıda yer alan satır sayısını karşılaştırdım. Ortaya çıkan manzara beni çok şaşırttı. Rapor vardı ama içerik eksikti. Bazı kayıtlar eşleşmediği için sistem tarafından sessizce atlanmıştı. Kimse bu hatayı fark etmiyordu çünkü raporun kendisi başarılı bir şekilde oluşuyordu. Eksik rapor, hatalı rapordan çok daha tehlikeliydi çünkü hatalı raporu en azından bir yerde fark edip düzeltebiliyordunuz. Sessizce kaybolan veri ise güven kaybı demekti. O günden sonra veri işleme süreçlerime bakış açım tamamen değişti. Artık bir sistemin çalışıyor olması, doğru çalıştığı anlamına gelmiyor.

Bu nerede karşına çıkar

Bu tür bir problemle genellikle veri entegrasyonu yaptığın her yerde karşılaşabilirsin. Özellikle finansal veriler, borsa takip sistemleri, kripto varlık hareketleri veya yapay zeka modellerine veri besleyen agent sistemlerinde bu durum çok yaygındır. Bir kaynaktan gelen ham veriyi alıp başka bir kaynaktaki bilgilerle zenginleştirmeye çalıştığında, verinin yapısı her zaman beklediğin gibi olmaz. Bazen bir satırda eksik bilgi olur, bazen format değişir, bazen de iki kaynak arasında zaman uyumsuzluğu yaşanır.

Bu sorun sadece teknik bir hata değil, aynı zamanda operasyonel bir risk. Eğer bir trading botu için veri topluyorsan ve bu verilerin bir kısmı sessizce kayboluyorsa, botun aldığı kararlar tamamen yanlış temellere dayanır. Kimse sana verinin eksik olduğunu söylemez. Kodun hata vermez, exception fırlatmaz, sadece sessizce eksik veriyle çalışmaya devam eder. Bu durum, sistemin içinde gizli bir yara gibi büyür. Yapay zeka modelleri eğitirken de benzer bir durum yaşanır. Eğitim setine giren verinin kalitesini denetlemezsen, modelin çıktısı saçmalamaya başlar. Veri işleme sürecinde her satırın akıbetini bilmek zorundasın. Eğer veriyi bir yerden alıp başka bir yere taşıyorsan, arada kaybolan her bir parça senin sorumluluğunda. Sessiz kayıp, veri dünyasındaki en sinsi düşmandır.

Kök neden

Kodun içindeki mantık hatasını bulmak çok vaktimi almadı. Eşleştirme işlemi sırasında kodum, beklenmeyen biçimdeki satırları sadece atlayıp bir sonraki satıra geçiyordu. Python tarafında bir try-except bloğu kurmuştum ve hata aldığında sadece pas geçiyordu. Bu aslında çok kötü bir pratikti. Kodun hata aldığını sanmıyordum ama sistemin kendisi hatayı yutuyordu. Rapor yine çıkıyordu, sadece eksik çıkıyordu.

Sorunun kök nedeni, veri doğrulama mekanizmasının eksikliğiydi. Kodum, girdinin ne kadar olduğuna bakmıyor, sadece çıktıyı üretiyordu. Giren satır sayısı ile çıktıda yer alan satır sayısı arasındaki farkı hiçbir zaman denetlemedim. Kodun içindeki döngü, eşleşmeyen veya formatına uymayan her satırı sessizce görmezden geliyordu. Bu durum, veri kaybının ana kaynağıydı. Bir veri satırı sisteme girdiğinde, ya işlenmeli ya da neden işlenmediği kaydedilmeliydi. Benim kodum ise sadece başarılı olanları alıp geri kalanını çöpe atıyordu. Bu çok büyük bir hataydı. Veri işleme sürecinde her zaman bir muhasebe mantığı olmalı. Giren her birim, ya çıktıda görünmeli ya da hata kütüğüne düşmeli. Bunu yapmadığım için sistemin ne kadar veri kaybettiğini göremiyordum. Kök neden, sistemin kendi başarısını sadece üretilen dosya üzerinden ölçmesi ve kaybolan veriyi hiç hesaba katmamasıydı.

Çözüm

Çözüm olarak satır muhasebesi denilen bir yapı kurdum. Bu yapı oldukça basit ama çok etkili. Artık kodum, işlem yapmaya başlamadan önce girdi dosyasındaki satır sayısını sayıyor. İşlem bittiğinde ise çıktı dosyasındaki satır sayısını ve hata kütüğüne giden satır sayısını topluyor. Eğer bu iki toplam birbirine eşit değilse, sistem hata veriyor ve raporu kesinlikle üretmiyor.

gorsel

girdi_sayisi = len(kaynak_veriler)
basarili_sayisi = 0
hata_sayisi = 0

for satir in kaynak_veriler:
    try:
        yeni_veri = isle(satir)
        cikti_dosyasina_yaz(yeni_veri)
        basarili_sayisi += 1
    except:
        hata_dosyasina_yaz(satir)
        hata_sayisi += 1

if girdi_sayisi != (basarili_sayisi + hata_sayisi):
    raise Exception(farkli_sayilar_hatasi)

Bu kod bloğu, sistemin temel güvenlik mekanizması oldu. Girdi toplamı ile çıktı toplamı tutmuyorsa iş durur ve rapor üretilmez. Neyin neden elendiği ise ayrı bir dosyaya yazılır. Böylece sadece hatayı tespit etmekle kalmıyorum, aynı zamanda hatanın kaynağını da görebiliyorum. Artık sistemim sessizce veri kaybetmiyor. Eğer bir satır işlenemiyorsa, bu durum açıkça görünür hale geliyor. Bu basit kontrol, sistemin tüm güvenilirlik seviyesini değiştirdi. Artık raporu açtığımda içindeki verinin tam olduğundan emin olabiliyorum.

Yolda çıkan hatalar

Bu sistemi kurarken bazı zorluklar yaşadım. İlk hata, hata kütüğüne yazılan verilerin formatının bozulmasıydı. Başlangıçta hatalı satırları sadece metin olarak yazıyordum ancak bu durum daha sonra bu hataları analiz etmemi zorlaştırdı. Hata kütüğünü düzenli bir log dosyasına çevirdim ve her hatanın yanına zaman damgası ile hata sebebini ekledim.

Bir diğer sorun ise performans kaybıydı. Her satırı tek tek saymak ve hata kütüğüne yazmak, işlemi biraz yavaşlattı. Ancak veri bütünlüğü hızın önüne geçti. Eğer sistemim çok hızlı çalışıp yanlış veri üretiyorsa, bu hız hiçbir şey ifade etmiyordu. Performans kaybı, güvenlik kazanımı karşısında çok küçük bir bedeldi. Ayrıca büyük dosyalarda bellek sorunu yaşamamak için dosyayı satır satır okuyup işlemeye başladım. Böylece sistem hem güvenli hem de kaynak yönetimi açısından daha verimli hale geldi. İlk denemelerde bazı satırların neden hata verdiğini anlamak için hata kütüğünü sürekli kontrol etmem gerekti. Bu da bana verinin ne kadar kirli olabileceğini gösterdi. Beklenmedik karakterler, boş satırlar veya yanlış formatlar sürekli karşıma çıktı. Her birini tek tek ayıklamak yerine, genel bir hata yakalama mekanizması kurup detayları log dosyasına bıraktım. Bu sayede kodum daha stabil hale geldi.

Alternatifler

Alternatif olarak veritabanı seviyesinde kontrol yapmayı düşündüm. Veriyi önce bir veritabanına yükleyip, oradaki sorgularla eksik kayıtları bulabilirdim. Ancak bu yöntem, benim ihtiyacım olan hızlı raporlama süreci için çok ağır geldi. Her seferinde veritabanına yükleme yapmak, ekstra bir katman oluşturuyordu. Benim ihtiyacım olan şey, kodumun kendi içinde veriyi doğrulamasıydı.

Bir diğer alternatif ise daha gelişmiş veri doğrulama kütüphaneleri kullanmaktı. Ancak bu kütüphaneler genellikle çok fazla bağımlılık getiriyor ve sistemimi gereksiz yere karmaşıklaştırıyordu. Ben, sistemin içindeki mantığın basit ve anlaşılır kalmasını istedim. Kendi satır muhasebesi sistemimi kurmak, herhangi bir dış kütüphaneye bağımlı kalmadan sorunu çözmemi sağladı. Bu yöntemin en büyük avantajı, kontrolün tamamen bende olmasıydı. Hata kütüğünü nasıl formatlayacağıma, hatayı nasıl loglayacağıma kendim karar verdim. Alternatif yöntemler genellikle hazır çözümler sunuyor ama benim spesifik durumumda verinin kaybolma nedenini anlamak için daha esnek bir yapıya ihtiyacım vardı. Kendi yazdığım bu basit kontrol mekanizması, hem öğretici oldu hem de sistemin güvenliğini en üst seviyeye çıkardı. Veri işleme sürecinde en iyi çözüm, genellikle en basit ve en şeffaf olanıdır.

Bundan sonra ne yapmalı

Veri işinde sessizce kaybolan satır, en pahalı hatadır. Bunu acı bir şekilde öğrendim. Bundan sonra yapman gereken ilk şey, mevcut tüm veri işleme scriptlerini gözden geçirmek. Kodların içinde sadece başarılı olanları işleyen döngülerin varsa, onları hemen değiştir. Giren satır sayısı ile çıkan satır sayısını karşılaştıran bir kontrol mekanizmasını her işin sonuna ekle.

Somut adımlar olarak şunları yapabilirsin. Önce mevcut veri işleme kodlarına bir sayaç ekle. Giren veri sayısını bir değişkene ata. İşlem sırasında başarılı olanları ve hata alanları ayrı ayrı say. İşlem bittiğinde bu sayıları kıyasla. Eğer fark varsa, sistemi durdur ve hata dosyasını incele. Bu sana verinin kalitesini anlama imkanı verir. Ayrıca hata kütüğünü düzenli olarak kontrol etmeyi alışkanlık haline getir. Hangi verilerin neden hata verdiğini anlamak, sistemini daha sağlam hale getirmeni sağlar. Veri işleme sürecini bir kara kutu gibi görme. İçinde ne olup bittiğini, kaç verinin kaybolduğunu ve neden kaybolduğunu her zaman bilmelisin. Bu disiplini kazandığında, artık verine daha çok güvenebilirsin. Unutma, sistemin çıkardığı raporun doğruluğu, senin yaptığın kontrollerin kalitesiyle doğru orantılıdır. Bir sonraki projenin başlangıcında, daha kodun ilk satırlarını yazarken bu muhasebe mantığını kurmayı unutma. Veri kaybı, geri dönüşü en zor hatadır.

來源:DEV Community · dev.to