Veri mühendisliği nedir, neden gerekir?
Veri mühendisliği, farklı sistemlerde duran veriyi toplayan, temizleyen, birleştiren ve raporlama ya da yapay zekâ için güvenilir biçimde hazır tutan altyapının tasarlanıp işletilmesidir. ERP'deki siparişler, CRM'deki müşteri kayıtları, üretim hattındaki sensör ölçümleri ve tablolarda tutulan hedefler ayrı ayrı doğru olabilir; ama bir yönetici "bu çeyrek hangi müşteri kârlı?" diye sorduğunda bu kaynakların aynı tanımla, aynı zamanda ve aynı kurallarla birleşmesi gerekir.
Büyük veri bu işin ölçek tarafıdır: veri hacmi, hızı veya çeşitliliği tek bir veritabanının ve elle yapılan aktarımların taşıyamayacağı noktaya geldiğinde, dağıtık depolama ve işleme gerekir. Her kurumun "büyük veri" sorunu yoktur, ama neredeyse her kurumun bir veri entegrasyonu ve veri kalitesi sorunu vardır. Hatson Tech olarak Ankara'dan, Türkiye genelindeki kurumlar için veri hatları, veri ambarları ve yapay zekâya hazır veri altyapıları kuruyoruz.
Hizmetin kapsamı
- Veri entegrasyonu: ERP, CRM, muhasebe, üretim ve web sistemlerinden verinin düzenli ve izlenebilir biçimde toplanması; API, veritabanı bağlantısı veya dosya aktarımıyla.
- ETL ve ELT hatları: Verinin çekilmesi, dönüştürülmesi ve yüklenmesi için zamanlanmış, hata durumunda uyaran ve yeniden çalıştırılabilen hatlar.
- Veri ambarı ve veri gölü: Raporlama için tutarlı tanımlara sahip tablolar; ham veri için uygun maliyetli saklama.
- Değişiklik verisi yakalama (CDC): Kaynak sistemdeki değişikliklerin dakikalar içinde hedefe akması; gece toplu aktarımının yetmediği durumlar için.
- Veri kalitesi ve gözlemlenebilirlik: Eksik, tekrarlı veya geç gelen verinin otomatik kurallarla yakalanması ve sorumlusuna bildirilmesi.
- Yapay zekâ için veri hazırlığı: Model eğitimi, değerlendirme ve RAG için etiketli, sürümlü ve kökeni izlenebilir veri kümeleri.
- Raporlama ve paneller: Yönetim, operasyon ve satış için tek doğru kaynağa bağlı göstergeler.
ETL nedir, ELT'den farkı ne?
ETL (extract, transform, load), veriyi kaynaktan çekip dönüştürdükten sonra hedefe yükleme yaklaşımıdır. ELT'de ise veri önce olduğu gibi hedefe yüklenir, dönüşüm hedef sistemin içinde yapılır. Hangisinin uygun olduğu verinin hacmine, dönüşümlerin karmaşıklığına ve hedef platforma bağlıdır:
| Durum | Daha uygun yaklaşım |
|---|---|
| Hassas alanlar hedefe gitmeden maskelenmeli | ETL |
| Hedef, büyük hacimli dönüşümleri ucuz çalıştırabiliyor | ELT |
| Ham veriyi saklayıp sonradan farklı biçimde işlemek gerekiyor | ELT |
| Kaynak sistem yavaş, yalnızca gerekli alanlar çekilmeli | ETL |
| Değişikliklerin dakikalar içinde yansıması gerekiyor | CDC ile akış |
| Günlük rapor yeterli, veri hacmi orta | Zamanlanmış toplu iş |
Veri ambarı nedir, mimarisi nasıl kurulur?
Veri ambarı (data warehouse), farklı kaynaklardan gelen verinin raporlama ve analiz için ortak tanımlarla, tarihçesiyle birlikte saklandığı veritabanıdır. Operasyonel sistemler günlük işi yürütmek için tasarlanır; veri ambarı ise "geçen yılın aynı dönemiyle karşılaştır" gibi soruları hızlı ve tutarlı yanıtlamak için. Kurduğumuz mimari genellikle üç katmanlıdır:
- Ham katman: Kaynaktan gelen veri değiştirilmeden, yükleme zamanı ve kaynağıyla saklanır. Bir hata olduğunda geriye dönüp yeniden işlemek bu katman sayesinde mümkündür.
- Temizlenmiş katman: Tipler düzeltilir, tekrarlar ayıklanır, müşteri ve ürün kimlikleri sistemler arasında eşleştirilir.
- İş katmanı: "Net satış", "aktif müşteri" gibi tanımlar tek bir yerde hesaplanır; raporlar ve yapay zekâ uygulamaları buradan beslenir.
Bu ayrım, aynı göstergenin iki raporda farklı çıkması gibi en sık yaşanan sorunu önler: tanım tek yerde yazılır ve sürümlenir.
Örnek: üç sistemden tek satış görünümü
Örneğin bir üretici firmada siparişler ERP'de, teklifler CRM'de, iadeler ise destek sisteminde tutuluyor olsun. Satış ekibi her ay sonunda üç sistemden dışa aktarılan tabloları elle birleştiriyor ve bu iş yaklaşık iki iş günü sürüyor. Müşteri adları sistemlerde farklı yazıldığı için aynı müşteri bazen iki ayrı satır olarak görünüyor.
Kurulan hat, üç sistemden veriyi her gece çeker; müşteri kimliklerini vergi numarası ve eşleştirme kurallarıyla birleştirir; iadeleri ilgili siparişe bağlar. Eşleşmeyen kayıtlar otomatik bir listeye düşer ve sorumlusu tarafından çözülür. Ay sonu raporu artık elle hazırlanmaz, sabah panelde hazırdır; tartışma "hangi tablo doğru?" sorusundan "bu müşteri neden kâr kaybediyor?" sorusuna geçer. Bu örnekteki süreler varsayımsaldır ve her kurumda farklıdır.
Veri kalitesi ve yapay zekâ için veri hazırlığı
Yapay zekâ projelerinin çoğu modelde değil veride takılır. Bir modelin veya RAG asistanının güvenilir olması için verinin şu özellikleri baştan tasarlanmalıdır:
- Kalite kuralları: Zorunlu alanlar, değer aralıkları, beklenen satır sayısı ve gecikme sınırı; kural bozulunca hat durur ve haber verir.
- Köken (lineage): Bir rapordaki ya da yapay zekâ yanıtındaki değerin hangi kaynaktan, hangi dönüşümle geldiği izlenebilir.
- Sürümleme: Model eğitimi ve değerlendirme için kullanılan veri kümesi sabitlenir; sonuçlar yeniden üretilebilir.
- Tekrar ve sızıntı kontrolü: Aynı kaydın eğitim ve test kümesine birlikte düşmesi engellenir.
Bu tarafı yapay zekâ için veri hazırlığı yazımızda ayrıntılandırıyoruz. Belgelerden oluşan veri kümelerinde parçalama ve dizinleme adımları için ölçekte belge parçalama ve vektör veritabanı yazılarımıza bakabilirsiniz. Hazırlanan veri, üzerine kurulacak RAG ve anlamsal arama çözümlerinin de temelidir.
Güvenlik, KVKK ve barındırma
Veri altyapısı, kişisel verinin en çok kopyalandığı yerdir. Bu yüzden hangi alanın maskeleneceği, kimin hangi tabloyu görebileceği ve verinin ne kadar süre saklanacağı tasarım aşamasında belirlenir. Altyapıyı bulutta, özel bulutta ya da kurumun kendi veri merkezinde kurabiliyoruz; tercih maliyeti, işletim yükünü ve KVKK kapsamındaki aktarım kurallarını etkilediği için baştan konuşulur. Çerçeve için yapay zekâ ve veri gizliliği yazımıza bakabilirsiniz.
Teslim süreci
- Keşif: Kaynak sistemler, veri sahipleri, mevcut raporlar ve en çok tartışılan göstergeler çıkarılır.
- Tanımlar: Kritik göstergelerin iş tanımı yazılı hale getirilir ve sahibine onaylatılır.
- İlk hat: En değerli tek bir akış (örneğin satış veya stok) uçtan uca kurulur ve rapora bağlanır.
- Kalite ve izleme: Kurallar, uyarılar ve köken kayıtları devreye alınır.
- Genişletme: Yeni kaynaklar aynı mimariye eklenir; yapay zekâ kullanım senaryoları bu temelin üzerine kurulur.
Maliyeti ve süreyi ne belirler?
- Kaynak sistemlerin sayısı ve bu sistemlerin API veya veritabanı erişimi sunup sunmadığı.
- Veri hacmi ve güncellik beklentisi: gece toplu iş mi, dakikalık akış mı?
- Verinin mevcut kalitesi ve sistemler arası kimlik eşleştirme ihtiyacı.
- Barındırma tercihi: bulut, özel bulut veya kurum içi.
- Güvenlik, maskeleme ve saklama gereksinimleri.
- Raporlama ve yapay zekâ tarafında kaç kullanım senaryosunun hedeflendiği.
Keşif sonunda bu etkenler kalem kalem yazılır; teklifin hangi varsayıma dayandığını görürsünüz.