Veri Ambarı mı, Veri Gölü mü? Üretim Şirketi İçin Veri Mimarisi
Veri ambarı ve veri gölü farkı, lakehouse yaklaşımı ve üretim şirketinde ERP, MES, SCADA ve kamera verisi için hangi mimarinin seçileceğine dair karar tablosu.
Yazar: CX Teknoloji Uzman Ekibi
Veri ambarı, raporlama için önceden modellenmiş ve temizlenmiş yapılandırılmış veriyi tutan bir depodur; veri gölü ise ham veriyi kendi biçiminde, sonradan yorumlanmak üzere saklayan bir depodur. Üretim şirketlerinin çoğunda doğru cevap ikisinden birini seçmek olmaz: ERP ve finans verisi ambar mantığıyla, makine sinyalleri, kamera olayları ve dokümanlar göl mantığıyla tutulur ve iki katman ortak bir tanım setiyle birleştirilir.
Soru genelde bir yatırım toplantısında gündeme gelir. BT ekibi bir iş zekâsı lisansı ve veri ambarı önerir, bir tedarikçi bulutta veri gölü kurmayı teklif eder, üretim tarafı ise makine verisinin zaten SCADA'da durduğunu söyler. Hangi teklifin doğru olduğu, şirketin hangi soruları cevaplamak istediğine ve verinin bugün hangi sistemlerde, hangi kalitede durduğuna bağlıdır. Bu yazı o kararı vermek için gereken çerçeveyi veriyor; kendi sistem envanterinizle birlikte değerlendirmek isterseniz veri ve iş zekâsı danışmanlığı sayfamıza göz atabilirsiniz.
Veri ambarı nedir, ne işe yarar?
Veri ambarı (data warehouse), farklı kaynaklardan gelen veriyi önceden belirlenmiş bir şemaya göre düzenleyen ve sorgulamaya hazır tutan bir veritabanıdır. Veri ambara yazılmadan önce temizlenir, birimleri eşitlenir ve iş kurallarına göre dönüştürülür. Bu yaklaşıma yazarken şema (schema-on-write) denir. Sipariş, sevkiyat, stok hareketi, maliyet ve fatura gibi satır ve sütunlarla ifade edilen verinin raporlanmasında güçlüdür. Yönetim panelindeki brüt marj ya da zamanında teslimat oranı gibi göstergelerin tek doğru hesabı genelde ambarda durur.
Ambarda veri genelde olgu ve boyut tabloları olarak modellenir. Olgu tablosu ölçülen olayı tutar (bir sevkiyat satırı, bir üretim kaydı), boyut tabloları ise bu olayı anlamlandıran bilgileri (müşteri, ürün, makine, tarih). Bu düzen sayesinde aynı sevkiyat verisi müşteri, ürün grubu ya da bölge kırılımında tutarlı biçimde raporlanabilir. Ambarın zayıf tarafı esnekliktir. Yeni bir veri türü eklemek için önce model tasarlanır, dönüşümler yazılır, testler yapılır. Saniyede yüzlerce değer üreten bir sensörün ham akışını ya da binlerce PDF teknik dokümanı ambara sığdırmaya çalışmak hem pahalı hem de gereksizdir.
Veri gölü nedir, hangi veriler için uygundur?
Veri gölü (data lake), yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış veriyi ilk geldiği biçimde, genelde ucuz nesne depolamada saklayan bir mimaridir. Veri okunurken yorumlanır; buna okurken şema (schema-on-read) denir. Fabrikada göle uygun veriler şunlardır: SCADA ve historian sistemlerinden gelen zaman serileri, PLC sinyalleri, görüntü analitiği olay kayıtları ve klipler, kalite laboratuvarı cihaz çıktıları, bakım raporları, teknik şartnameler ve tedarikçi sertifikaları.
Gölün riski de tam bu esneklikten doğar. Kim neyi, hangi adla, hangi tarihle attı belli değilse göl birkaç yıl içinde kimsenin güvenmediği bir dosya yığınına döner. Sektörde buna veri bataklığı denir. Katalog, adlandırma kuralı, sahiplik ve saklama süresi baştan belirlenmezse gölün getirdiği esneklik kullanılamaz hale gelir. Bu konuları veri yönetişimi yazısında ayrıntılı ele aldık.
Lakehouse nedir, ikisinin arasında bir yol var mı?
Lakehouse, veri gölünün ucuz ve esnek depolamasını, ambarın tablo yapısı ve tutarlılık özellikleriyle birleştiren bir mimaridir. Göldeki dosyaların üzerine Delta Lake, Apache Iceberg gibi açık tablo biçimleri eklenir; böylece aynı veri hem SQL ile raporlanabilir hem de veri bilimi ve yapay zekâ çalışmalarında ham haliyle kullanılabilir. Yaygın bir düzen, veriyi üç katmanda tutmaktır: ham katman (kaynaktan geldiği gibi), temiz katman (birimleri ve kodları eşitlenmiş) ve iş katmanı (tanım kartlarına göre hesaplanmış göstergeler).
Orta ölçekli bir üretim şirketi için lakehouse her zaman gerekli değildir. Raporlama ihtiyacı ağırlıklı olarak ERP verisiyse iyi kurgulanmış bir ambar yeterli olabilir. Makine verisi, görüntü ve doküman tarafı büyüdükçe ve yapay zekâ projeleri gündeme geldikçe göl katmanının değeri artar. Mimariyi ihtiyaca göre aşamalı büyütmek, baştan büyük bir platform kurmaktan genelde daha az risklidir. Örneğin ilk yıl ERP verisini ambarda toplamak, ikinci aşamada darboğaz hatların makine verisini göle eklemek, doküman asistanı gündeme geldiğinde teknik arşivi aynı göle almak bu tür bir büyüme yoludur.
Karar tablosu: hangi veri hangi katmana gitmeli?
| Veri türü | Örnek kaynak | Uygun katman | Not |
|---|---|---|---|
| Sipariş, stok, maliyet, fatura | ERP | Ambar | Tanımı netleşmiş, finansal kapanışa bağlı veri |
| İş emri, üretim adedi, duruş kaydı | MES, vardiya formları | Ambar (özet), göl (ayrıntı) | Duruş nedeni kodları ERP ile eşleştirilmeli |
| Makine sinyalleri, sıcaklık, basınç | SCADA, historian, PLC | Göl | Ambar için saatlik ya da vardiyalık özetler üretilir |
| Kamera olayları ve klipler | Görüntü analitiği sistemi | Göl (olay kayıtları ambarda özetlenir) | Kişisel veri içerebilir; saklama süresi belirlenmeli |
| Müşteri etkileşimi, şikâyet | CRM, e-posta | Ambar (yapısal alanlar), göl (metin) | Serbest metin yapay zekâ ile sınıflandırılabilir |
| Teknik doküman, prosedür, şartname | Dosya sunucusu, doküman yönetimi | Göl | Kurumsal yapay zekâ asistanının bilgi kaynağıdır |
| Kalite laboratuvarı ölçümleri | Cihaz çıktıları, LIMS | Göl ve ambar | Parti numarası üzerinden ERP ile bağlanır |
Üretim şirketinde veri mimarisi seçerken sorulacak sorular
- Bugün yönetim raporlarının ne kadarı ERP verisinden, ne kadarı makine ve saha verisinden besleniyor?
- Makine verisi şu an bir historian ya da SCADA sisteminde tutuluyor mu, yoksa hiç toplanmıyor mu?
- Önümüzdeki dönemde yapay zekâ projeleri (doküman asistanı, kalite tahmini, görüntü analitiği) planlanıyor mu?
- Verinin şirket dışına çıkmasına dair bir kısıt var mı; mimari tamamen şirket içinde mi, hibrit mi olacak?
- Veriyi yönetecek iç ekip kaç kişi ve hangi becerilere sahip; SQL bilen bir analist mi, veri mühendisi mi var?
- Kaynak sistemlerde ortak anahtarlar (malzeme kodu, makine kodu, parti numarası) tutarlı mı?
Son soru çoğu zaman en çok vakit alan sorudur. ERP'de makine kodu bir biçimde, MES'te başka biçimde, bakım Excel'inde üçüncü bir biçimde yazılıyorsa hangi mimari seçilirse seçilsin önce eşleştirme tablosu kurulması gerekir. Bu iş ERP ve MES entegrasyonu projesinin de temelidir. Eşleştirme tablosunun bir sahibi olmalı; yeni bir makine ya da malzeme kodu açıldığında tabloya kimin ekleyeceği yazılı değilse birkaç ay içinde aynı dağınıklık geri gelir.
Şirket içi mi, bulut mu, hibrit mi?
Veri ambarı ve göl, şirket içindeki sunucularda, bulutta ya da ikisinin karışımında kurulabilir. Karar verirken bakılacak noktalar şunlardır:
- Veri hassasiyeti: kişisel veri, müşteri çizimleri ve reçete bilgisi gibi verinin nerede tutulabileceği sözleşmeler ve KVKK ilkeleri çerçevesinde ayrıca değerlendirilmelidir.
- Saha bağlantısı: fabrikanın internet bağlantısı kesildiğinde üretim verisinin kaybolmaması için yerel tampon gerekir.
- Maliyet yapısı: şirket içi kurulum donanım yatırımı ve bakım ekibi ister; bulutta maliyet depolama ve sorgu hacmiyle değişir, bu yüzden kullanım izlenmelidir.
- Ekip yetkinliği: bulut hizmetleri işletme yükünü azaltır ama yetki ve maliyet yönetimi bilgisi ister.
Pek çok fabrikada makul düzen, makine ve görüntü verisinin sahada ön işlenip özetlerinin merkezi katmana gönderilmesidir. Sahada ve merkezde işleme dengesini edge ve bulut karşılaştırmasında, dil modellerini veriyi şirket içinde tutarak çalıştırmayı ise on-premise yapay zekâ yazısında anlattık.
Veri mimarisi projesi nasıl başlatılmalı?
Mimari seçimi bir teknoloji kararı gibi görünse de doğru başlangıç noktası kullanım senaryolarıdır. İlk adımda yönetimin cevaplamak istediği beş on soru yazılır: hangi ürün grubu gerçekten kâr ediyor, hangi makine darboğaz, hangi tedarikçinin malzemesi kalite sorununu artırıyor. Ardından her sorunun hangi veriye ihtiyaç duyduğu ve bu verinin bugün nerede durduğu çıkarılır. Bu harita çıktığında ambar, göl ya da lakehouse tercihi çoğu zaman kendiliğinden belirginleşir. İlk sürüm, birkaç soruya güvenilir cevap veren dar bir kapsamla canlıya alınmalı; yeni kaynaklar bu çekirdeğe eklenerek büyütülmelidir. Bu sorulardan beslenen ilk ekranı kurmak için yönetim paneli rehberine bakabilirsiniz.
CX Teknoloji olarak veri mimarisini kâğıt üzerinde bırakmıyoruz; keşif sırasında ERP, MES, SCADA ve görüntü analitiği kaynaklarını yerinde inceliyor, ilk veri hattını ve ilk raporu çalışır halde teslim ediyoruz. Mevcut durumunuzu görmek için ücretsiz dijital olgunluk ön değerlendirmesi talep edebilirsiniz.
Sık sorulan sorular
Veri ambarı ile veri gölü arasındaki temel fark nedir?
Temel fark, verinin ne zaman yapılandırıldığıdır. Veri ambarında veri yazılmadan önce temizlenir ve bir şemaya oturtulur; veri gölünde ham haliyle saklanır ve okunurken yorumlanır. Ambar tanımı net raporlama için, göl ise çeşitli ve ham veri için uygundur.
Küçük ya da orta ölçekli bir fabrika veri gölüne ihtiyaç duyar mı?
Her zaman duymaz. Raporlama ağırlıklı olarak ERP verisine dayanıyorsa iyi kurgulanmış bir veri ambarı yeterli olabilir. Makine sinyalleri, görüntü analitiği ve doküman tabanlı yapay zekâ projeleri gündeme geldiğinde göl katmanı eklemek mantıklı hale gelir.
Lakehouse yeni bir ürün mü, yoksa bir yaklaşım mı?
Lakehouse bir mimari yaklaşımdır. Veri gölündeki dosyaların üzerine açık tablo biçimleri eklenerek ambar benzeri sorgulama ve tutarlılık sağlanır. Birçok ticari ve açık kaynak platform bu yaklaşımı destekler; tercih mevcut altyapıya ve ekip yetkinliğine göre yapılmalıdır.
Kamera ve görüntü analitiği verisi nerede tutulmalı?
Klipler ve ayrıntılı olay kayıtları genelde göl katmanında, özetlenmiş olay sayıları ambarda tutulur. Görüntü kişisel veri içerebileceği için saklama süresi, erişim yetkisi ve maskeleme ihtiyacı KVKK ilkelerine göre baştan belirlenmelidir. Bu genel bilgidir, hukuki danışmanlık yerine geçmez.
Veri ambarı kurmadan önce ne yapılmalı?
Önce yönetimin cevaplamak istediği sorular ve bu soruların ihtiyaç duyduğu veriler listelenmelidir. Ardından kaynak sistemlerdeki ortak anahtarların (malzeme, makine, parti kodu) tutarlılığı kontrol edilmelidir. Bu iki adım atlanırsa ambar kurulsa bile güvenilir rapor üretmek zorlaşır.