Kurumsal Veri Türleri

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 4. bölümü olan Kurumsal Veriyi Anlamak bölümündeki 6 modülden 2.‘si. Her modül kendi başına okunabilir. Önceki: Salesforce Pek Çok Sistemden Biridir · Sonraki: Salesforce’u Çevreleyen Sistemler

Bu modülün yanıtladığı soru: Bir kurum ne tür veriler tutar ve bunlar neden farklı yerlere aittir?

Bir müşteri kaydı. Bir ülke listesi. Bir sipariş. Bir alan tanımı. Beş yıllık satış toplamları. Dört milyon teslimat fotoğrafı. Hepsi veridir, ama mimari açıdan aynı şey değildirler. Farklı biçimde değişir, farklı biçimde büyür, farklı biçimde kullanılır ve farklı insanlara aittirler; otomatik olarak aynı yerde yaşamamalıdırlar. Bu yüzden biri “bu veriye Salesforce’ta ihtiyacımız var” dediğinde bir sonraki sorum şudur: bu ne tür bir veri? Yanıt, onunla ne yapacağımı söylemeye başlar.

Nesneyle Değil, Türle Başlayın

Salesforce insanları olarak gereksinimleri neredeyse anında yapılara çeviririz: müşteri, Hesap; fotoğraf, Dosya; durum, seçim listesi. Bu sonunda yararlıdır. Kurum düzeyinde önce ne tür bir bilgiyle uğraştığımı bilmek isterim. Onu sınıflandırmanın pek çok yolu var (standart başvuru kaynağı DAMA bilgi birikimidir) ve ben altı türü yararlı buluyorum: ana veri, referans verisi, işlem verisi, meta veri, analitik veri ve yapılandırılmamış veri. Kategoriler mimarinin kendisi değildir. Daha iyi sorular sormanın bir yoludur.

Ana Veri: İşin Bildiği Şeyler

Ana veri, bir işin etrafında döndüğü kalıcı şeyleri tanımlar: müşteriler, ürünler, fiyatlandırma, çalışanlar, tedarikçiler, konumlar, varlıklar. Bir Salesforce satış org’unda bunlar Hesaplarınız ve Kişileriniz, ürünleriniz ve fiyat defterlerinizdir. Steve Trucking’de bir Perakende Ortağı ana veridir. Keystone bir olay değildir; Steve Trucking’in süregelen bir ilişkisi olduğu bir kuruluştur. Dokuz dağıtım merkezi de ana veridir.

Ana veri, onu kullanan işlemlerden daha uzun yaşar: bir Perakende Ortağının milyonlarca teslimatı olabilir. Bu yüzden onunla ilgili ilk soru her zaman sahibi kim? sorusudur. Salesforce olmayabilir. Ürünlerin sahibi ERP olabilir. Salesforce potansiyel müşterilere sahip olabilirken onlar müşteri olduğunda ERP esas kaynak haline gelebilir. Bir MDM platformu, birkaç sistemden bir araya getirilmiş bir müşterinin kurumsal kimliğine sahip olabilir. 6. bölüm, Ana Veri ve Kimlik, derine iniyor. Şimdilik şekli tanıyın.

Referans Verisi: İşin Paylaştığı Sözcük Dağarcığı

Referans verisi, diğer verileri sınıflandırmak için kullanılan kontrollü sözcük dağarcığıdır: ülke kodları, para birimleri, ürün kategorileri, gerekçe kodları, durumlar. Steve Trucking’in teslimat durumları (planlandı, yüklendi, dağıtımda, yaklaşıyor, teslim edildi, kuruldu, istisna, iade edildi) referans verisidir. Teslimat değildirler; teslimatları tanımlamak için kullanılan sözcüklerdir.

Küçük ve zararsız görünür, çoğu zaman sekiz değerli bir seçim listesidir. Küçüğü önemsizle karıştırmayın. Salesforce Delivered, ERP Complete diyorsa ve bir Perakende Ortağı D gönderiyorsa birinin her birinin ne anlama geldiğini ve nasıl eşlendiğini tanımlaması gerekir. Referans verisi, entegrasyon varsayımlarının saklandığı yerdir.

İşlem Verisi: Ne Oldu

İşlem verisi faaliyeti kaydeder: verilen bir sipariş, yapılan bir ödeme, tamamlanan bir teslimat, açılan bir vaka. Aynı satış org’unda bunlar teklifler ve teklif satırları, siparişler ve sipariş kalemleri, ödemelerdir: her biri bir müşteriyi ve bir ürünü işaret eder. Steve Trucking’in yılda bir milyon teslimatı işlem verisidir, durum güncellemeleri de öyle: teslimat başına yaklaşık sekiz, yani yılda %30 büyüyen bir işte yılda sekiz milyon durum değişikliği.

Bu, ana veriden bambaşka bir büyüme eğrisidir. En üstte üç Perakende Ortağı; altında milyonlarca satır. Steve’in Sıfır Sayısı’nın önemli olduğu yer burasıdır: Perakende Ortağı → Teslimat → Durum zincirine bakıp her kutuya aynı ağırlığı veremezsiniz. İşlem verisinde hemen hacmi, hızı, saklamayı, geçmişi, arşivlemeyi, entegrasyonu ve insanların ona gerçekte nasıl ulaşması gerektiğini düşünürüm. 2. Kısım orada çok zaman geçiriyor.

Meta Veri: Veri Hakkında Veri

Kurs boyunca meta veriyle çalışıyordunuz: bir nesnenin tanımı, bir alanın türü, açıklaması, ilişkileri. Bütün kurumda vardır: ambar şemaları, entegrasyon eşlemeleri, veri katalogları, API sözleşmeleri ve her alan için bir sahip, bir hassasiyet düzeyi, bir tanım, köken ve bir saklama kuralı. Değerler veridir; ne anlama geldiklerinin tanımı meta veridir. 3. bölümün söylediği gibi Flag2__c kimseye hiçbir şey söylemez ve yapay zekâ verinin ne anlama geldiğini çözmek için meta veriyi okuduğuna göre bu artık daha da önemli.

Analitik Veri: Başka Veriden Ürettiğimiz Veri

“Son beş yılda Perakende Ortağına göre zamanında teslimat oranımız ne?” bir işlem değildir. Milyonlarca teslimattan yeni veri türetilerek yanıtlanan analitik bir sorudur: zamanında teslimat yüzdesi, hasar oranı, ortak başına gelir, kurulum kalitesi, ekip eğilimleri. Ve farklı bir iştir. “217 numaralı kamyonun bir sonraki durağı ne?” diye soran sevk görevlisinin beş yıllık geçmişi taraması gerekmez. Bölgelere göre beş yıllık zamanında teslimat performansını karşılaştıran üst yönetimin gerekir. Analitik verinin genellikle bu iş için inşa edilmiş bir ambarda, bir lakehouse’ta ya da bir analitik platformunda yaşamasının nedeni budur. Salesforce’un bir şeyi saklayabiliyor olması, operasyonel platformu onun üzerinde her analizin çalıştırılacağı yer yapmaz.

Yapılandırılmamış Veri: Satırlara Sığmayanlar

Belgeler, PDF’ler, görüntüler, ses, video, e-postalar, dökümler, bilgi makaleleri. Steve Trucking’de teslimat fotoğrafları: teslimat başına yaklaşık dört, kurulumlarda daha fazla, yılda dört beş milyon. Bir fotoğraf sadece bir alan daha değildir. Büyüktür, birinin evinin içini gösterebilir, kendi saklama kuralları vardır ve farklı biçimde aranır, tabii aranırsa.

Bu tür her yıl daha önemli hale geliyor, çünkü yapay zekâ artık eskiden yapılandırılmış modelin dışında duran bilgilerle yararlı şeyler yapabiliyor. Bir döküm veridir. Bir PDF kılavuz veridir. Bir kurulum fotoğrafı veridir. Bu, onun Salesforce’un çekirdeğine ait olduğu anlamına gelmez. Haritaya ait olduğu anlamına gelir.

Click to enlarge

Altı tür, her biri için dört soru. Yanıtlar türden türe değişir ve asıl mesele de bu.

Tür Sorunun Yalnızca Yarısıdır: İş Yükü

Ne tür bir verimiz olduğunu bilmek yeterli değildir. Onunla ne yaptığımızı da bilmek isterim. Burada üç iş yükü önemlidir ve bunları karıştırmak kötü mimari üretir.

Operasyonel: işi yürütmek. Bir sevk görevlisi bir teslimatı günceller, bir ekip bir durağı tamamlar, bir temsilci bir vaka açar. Çok sayıda küçük okuma ve yazma: şunu bul, bunu güncelle, bugünün duraklarını göster. Bu OLTP’dir, çevrim içi işlem işleme (online transaction processing), ve Salesforce bunda çok iyidir; yöneticilerin ve geliştiricilerin yaşadığı yer burasıdır.

Analitik: işi anlamak. Beş yıllık her teslimat, ortağa ve DC’ye göre gruplanmış, yıldan yıla karşılaştırılmış, finansla birleştirilmiş. Artık tarıyor ve topluyoruz. Bu OLAP’tır, çevrim içi analitik işleme (online analytical processing), ve ambarlar, lakehouse’lar ve analitik platformlar bunun için inşa edilir. Basitçe söylersek: org işi yürütür; ambarlar ve göller onu analiz eder. Klasik bir hata, bu iş yükünü operasyonel platforma koyup sıfırlar arttıkça şaşırmaktır. Biri çok büyük miktarda geçmişi tekrar tekrar taramak istiyorsa bunu “sadece bir rapor daha” olarak ele almayın. Doğru platform olup olmadığını sorun. 2. Kısım buna Ölçek İçin Tasarlamak (coming soon) bölümünde geri dönüyor (çekirdeği ambarınız yapmayın) ve 3. Kısım analitik yapıların nasıl kurulduğunu İlişkiselin Ötesinde (coming soon) bölümünde gösteriyor.

Akış: hareket halindeki veri. Olaylar, telemetri, durum değişiklikleri, sensör okumaları. Steve Trucking’in kamyonları günde yaklaşık 200.000 GPS okuması gönderiyor. Sevk görevlisi 217 numaralı kamyonun şu an nerede olduğunu önemser. Salesforce’un her kamyonun dakika dakika her okumasını tutması gerekiyor mu? Belki hayır. “Şu an nerede?” ve “geçen çeyreğin rota verimliliği eğilimleri neydi?” aynı kaynaktan gelir ve bambaşka depolama kararlarına yol açar.

Ne Kadar Hızlı Hareket Etmesi Gerekiyor?

Sonra gecikme. Derste şöyle anlatırım: gerçek zaman, birinin geri gelmesini kapıda beklemektir. Onu gönderir ve orada durursunuz, çünkü o dönene kadar devam edemezsiniz. Bu eşzamanlıdır. Gerçeğe yakın zaman, onun gidişini izleyip başka bir işe koyulmaktır; kısa süre sonra geri geldiğinde onunla ilgilenirsiniz. Bu eşzamansızdır. Bir de toplu iş (batch) var: kimse kapıdan tek tek çıkmaz. Veri bekler ve bir takvime göre grup halinde taşınır: saatlik, birkaç saatte bir ya da günlük. Toplu işin yeterli olduğu pek çok durum vardır, yetmediği bazı durumlar da. Hangisinin hangisi olduğunu bilmek işin kendisidir. Bu üçü yalnızca entegrasyon terimleri değil; mimari seçimlerdir.

Yaygın ERP entegrasyonunu ele alın. ERP’de saat 11’de yeni bir ürün oluşturuluyor. Satışın gerçekten öğlene kadar onu satması gerekiyor mu? İki yanıtı da gördüm. Bazı müşteriler onu mümkün olan en kısa sürede istiyor; diğerleri diyor ki, o SKU’yu size göndermediysek henüz satmanızı bekleyemeyiz. Bu yüzden ürünler genellikle günlüktür, bazen daha hızlı. Müşteriler en az günlük; saatlik gördüm, uç durumlarda gerçeğe yakın zaman da. Siparişler farklıdır: karşılama başlamak zorundadır, yani gerçeğe yakın zaman. Satışçı anlaşmayı kapatır ve devam eder, sipariş de saniyeler ile bir iki dakika içinde ERP’ye ulaşır. “Kurumsal veri” için tek bir doğru gecikme yoktur. İşin gerçekte neye ihtiyaç duyduğunu sorun ve kulağa etkileyici geliyor diye her şeyi gerçek zamanlı yapmayın. Gerçek zamanın bir bedeli vardır.

Kategorilerin Arkasındaki Dört Soru

Etrafta “bu işlem verisi!” diye ilan ederek dolaşmanız gerekmez. Sınıflandırma, her önemli veri kümesi hakkında dört soruyu tetiklemek için vardır:

• Sahibi kim? Esas kaynak hangi sistem? Bunu üçe ayırırım: nerede oluşturuluyor, nerede düzenleniyor ve nerede başvuruluyor? 6. bölüm bunları derinlemesine ele alıyor (Oluşturulan, Düzenlenen, Başvurulan; ve Ne Hızla?).
• Ne hızla değişiyor? Yılda bir mi, günlük mü, saniyede onlarca ila yüzlerce kez mi?
• Ne kadar büyüyor? On kayıt mı, on bin mi, on milyon mu, on milyar mı?
• Yaşam döngüsü ne? Sonsuza kadar mı yaşıyor, arşivleniyor mu, silinmesi mi gerekiyor, zamanla değer mi kaybediyor?

Bu dördü bana “Salesforce bunu saklayabilir mi?” sorusundan çok daha fazlasını söyler. Ve şimdiye kadar öğrendiklerimizi bir araya getirir: sahiplik, yaşam döngüsü, Sıfır Sayısı, verinin nerede yaşadığı.

Tek Bir İş Her Türü Üretir

Steve Trucking’de Perakende Ortağı ana veridir; durum sözcük dağarcığı referans verisidir; her teslimat işlem verisidir; alanlarının tanımları meta veridir; beş yıllık zamanında teslimat karnesi analitik veridir; kurulum fotoğrafı yapılandırılmamış veridir; GPS akışı da akış verisidir. Hepsi “Steve Trucking verisi”. Hiçbiri aynı veritabanına ait oldukları anlamına gelmez. Zihinsel geçiş budur.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Tek bir soruyu yanıtlamak için bir ajanın yapılandırılmış bir müşteri kaydına, yakın tarihli bir işleme, bir PDF kılavuza, bir servis dökümüne ve canlı telemetriye ihtiyacı olabilir. Yapılandırılmamış ve akış verisi, CRM veritabanına ait olmasalar bile mimarinin birinci sınıf parçaları haline gelir ve mimar yine her kaynağın sahibini, ne kadar güncel olduğunu ve ajanın ona güvenmesi gerekip gerekmediğini bilmek zorundadır.

Mimarın Burada Karar Verdikleri

• Her önemli veri kümesinin ne tür bir veri olduğu ve sahibinin kim olduğu.
• İş yükünün operasyonel mi, analitik mi, akış mı yoksa bir karışım mı olduğu.
• Ne hızla değiştiği ve diğer sistemlerin değişikliği gerçekte ne hızla görmesi gerektiği.
• Hacmin ve yaşam döngüsünün verinin nerede ve ne kadar süre yaşayacağını nasıl şekillendirdiği.
• Salesforce’un ona sahip olması mı, bir kopyasını tutması mı, ona başvurması mı yoksa onu iş yüküne daha uygun bir yerde bırakması mı gerektiği.

Biri size bir gereksinim verdiğinde hangi nesne, hangi alan, hangi API sorusuna atlamayın. Önce ne tür bir veri olduğunu, sahibinin kim olduğunu, ne hızla değiştiğini, ne kadar büyüdüğünü, ne kadar yaşadığını ve onunla ne yapmaya çalıştığımızı sorun. Bir Hesap, bir teslimat olayı, beş yıllık bir toplam ve bir fotoğraf aynı iş için önemli olabilir, ama aynı mimari sorun değildirler.

Daha Fazlası

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. baskı (2017, İngilizce): veri kategorileri ve veri yönetimi için standart başvuru kaynağı.
• Steve Trucking senaryo özeti, 4. kısım (hacimler, İngilizce).