Veri operasyonları omurgası
Kaynaktan karara, güvenilir veri.
Orbit, veriyi üretildiği sistemlerden ona ihtiyaç duyan ekiplere ve ürünlere taşır; yol boyunca her adımı izlenebilir kılar. Veri alımı, dönüşüm, kalite kontrolleri, lineage ve erişim politikaları tek bir platformda bir araya gelir; diğer tüm VARDA ürünleri de bu platformun üzerinde çalışır.
VARDA Orbit
Problem
Veri sorunlarını çoğu zaman raporu okuyan kişi fark ediyor.
Pipeline’lar her yeni taleple biraz daha büyür: bir yerde bir betik, başka bir yerde zamanlanmış bir dışa aktarım. Zincirin bütününün bir sahibi yoktur; şema değişiklikleri sessizce bir şeyleri bozar ve bir rakam sorgulandığında nereden geldiğini bulmak günler sürer.
- 01
Gece çalışan batch işleri, operasyon ekiplerini dünün verisiyle çalışmak zorunda bırakıyor.
- 02
Kaynakta adı değişen bir sütun, ona bağlı raporları bozuyor ve kimse uyarılmıyor.
- 03
Kişisel veriler, maskeleme ya da saklama kuralı olmadan analitik ortamlara kopyalanıyor.
- 04
Raporlanan bir rakamın nereden geldiğini sütun sütun gösterebilen kimse yok.
- core_banking.oracle
- erp.sap_s4
- crm.api
- iot.mqtt
- stg_transactions
- stg_customers
- stg_telemetry
- dim_customer
- fct_transactions
- fct_machine_hourly
- feature_store
- lumen.metrics
- api.v1
- ✓not_null(customer_id)
- ✓unique(transaction_id)
- ✓tazelik < 15 dk8 dk
- !şema değişimi · erp.sap_s4.MARA +1 koloninceleme
- ✓PII · TCKN, IBAN maskelendi
- Tazelik
- 8 dk
- Bugünkü hacim
- 18,4 M satır
- Başarılı çalıştırma
- 99,6%
Yetenekler
Yıldızları bir arada tutan yörünge.
CDC, batch ve streaming veri alımı
Operasyonel veritabanlarından log tabanlı değişiklik yakalama (CDC), zamanlanmış batch yüklemeler ve Kafka ya da MQTT üzerinden gelen akışlar. Şemalar veri geldiği anda kaydedilir; ham veri saklandığı için her yükleme yeniden işlenebilir.
Dönüşüm ve orkestrasyon
Dönüşümler SQL ve Python ile yazılır, Git üzerinde incelenir ve CI sürecinde test edilir. Orkestratör bunları bağımlılık sırasına göre çalıştırır; yeniden deneme, geçmişe dönük yükleme (backfill) ve her veri seti için bir hizmet seviyesi tanımlanır.
Veri sözleşmeleri ve kalite kontrolleri
Veriyi üreten ve kullanan ekipler; her veri setinin şemasını, anahtarlarını, güncellik beklentisini ve geçerli değerlerini bir sözleşmede belirler. Kontroller her yüklemede çalışır; kontrolden geçemeyen veri yayımlanmaz, bekletilir.
Lineage ve gözlemlenebilirlik
Sütun düzeyinde lineage, her rakamı kaynaktan dashboard’a kadar izler. Güncellik, hacim ve şema değişiklikleri her veri seti için ayrı izlenir; bir sorun çıktığında lineage, bundan hangi raporların ve modellerin etkilendiğini tam olarak gösterir.
Yönetişim ve veri kataloğu
Kişisel veriler alım sırasında etiketlenir; maskeleme, satır düzeyi politikalar ve saklama kuralları bir kez tanımlanır ve her araçta aynı şekilde uygulanır. Veri kataloğu, her veri setinin sahibini, tanımını ve hassasiyet düzeyini kayıt altında tutar.
Veri sunumu
Güvenilir veri; veri ambarına, REST ve GraphQL API’lerine ve çevrimiçi ile çevrimdışı feature store’a yayımlanır. Raporlar, uygulamalar ve modeller aynı denetimli kaynaktan beslenir.
Nasıl çalışır
Verinin Orbit içindeki yolculuğu
Bağlantı
Kaynaklar CDC, batch veya streaming bağlayıcılarıyla bağlanır; şemalar ve ham veri, geldiği anda kayıt altına alınır.
Sözleşme
Veriyi üreten ve kullanan ekipler, her veri setinin nasıl olması gerektiğinde uzlaşır: şema, anahtarlar, güncellik ve geçerli değerler.
Dönüşüm ve test
SQL ve Python modelleri incelenir, CI sürecinde test edilir ve orkestratör tarafından bağımlılık sırasına göre çalıştırılır.
Yönetişim
Hassas sütunlar etiketlenir, maskeleme ve saklama kuralları uygulanır; lineage her adımı kaydeder.
Sunum ve izleme
Veri yalnızca kontrollerden geçtiğinde yayımlanır; ardından güncellik, hacim ve şema değişiklikleri açısından izlenir.
Mimari
VARDA Orbit · Mimari
01 Kaynaklar
- Operasyonel veritabanları
- Uygulamalar ve dosyalar
- Olay akışları ve IoT
02 İşleme
- CDC ve batch alımı
- Streaming alımı
03 VARDA Orbit
- Dönüşüm ve orkestrasyon
- Sözleşme, kalite ve lineage
04 Çıktılar
- Veri ambarı ve lakehouse
- Veri API’leri
- Feature store
- Diğer VARDA ürünleri
Kullanım senaryoları
Kullanım senaryoları
Örnek bir senaryo: Stok ve satış verileri geceleri bir kez gelen bir perakende zinciri, dışa aktarım betiklerinin yerine ERP ve satış noktası veritabanlarından CDC ile veri alır. Mağaza operasyonları artık dünün değil, bugünün verisiyle çalışır.
- İşlem loglarından değişiklik yakalama; kaynak sistemlere asgari yük
- Denetim ve yeniden işleme için eksiksiz değişiklik geçmişi
- Bağlı tablolar gece bir kez değil, sürekli güncellenir
Örnek bir senaryo: Bir sağlık grubu, analistlerinin hasta düzeyindeki eğilimleri kimlikleri görmeden incelemesini istiyor. Orbit kişisel alanları veri alımı sırasında etiketler ve veriyi role göre takma adlandırılmış olarak sunar.
- Kişisel alanlar otomatik etiketlenir, veri sahiplerince onaylanır
- Maskeleme ve takma adlandırma role göre uygulanır
- Saklama ve silme kuralları otomatik işletilir ve kayıt altına alınır
Örnek bir senaryo: Bir kredi kuruluşunun risk ekibi, model eğitiminde ve gerçek zamanlı skorlamada aynı özelliklere ihtiyaç duyar. Orbit bu özellikleri bir kez hesaplar ve feature store üzerinden her ikisine de sunar.
- Eğitim ve canlı kullanım için tek özellik tanımı
- Geleceğe ait bilgi sızdırmayan, zamana göre doğru eğitim setleri
- Her özellikten kaynak sütunlarına kadar lineage
Kurulum seçenekleri
Kurulum seçenekleri
Kurum içi
Kaynak sistemlere yakın konumda, veri merkezinizdeki Kubernetes veya sanal makineler üzerinde çalışır. Veriyi yurt içinde ve kendi denetiminde tutması gereken bankalar ve düzenlemeye tabi sektörler için uygundur.
Özel bulut
Kendi bulut hesabınızda ya da Türkiye’deki bir bulut bölgesinde çalışır; lakehouse için nesne depolamayı kullanır ve kurum içindeki kaynaklara özel bağlantılarla erişir.
Hibrit
Veri alım bileşenleri kurum içinde, kaynakların yanında çalışır ve buluttaki analitik ortama yalnızca izin verilen, maskelenmiş veri setlerini aktarır. Lineage ve politikalar her iki ortamda tek bir sistem olarak kalır.
Teknik özellikler
VARDA Orbit
- Veri alım modları
- Log tabanlı CDC, zamanlanmış batch, streaming (Kafka, MQTT)
- Teslim garantisi
- En az bir kez teslim; idempotent yazma sayesinde fiilen tam bir kez sonuç
- Dönüşümler
- SQL ve Python modelleri; Git’te sürümlenir, CI sürecinde test edilir
- Orkestrasyon
- Bağımlılıkları gözeten zamanlama, yeniden deneme, backfill ve veri seti bazında SLA
- Kalite kontrolleri
- Sözleşme bazında şema, güncellik, hacim, tekillik ve özel kurallar
- Lineage
- OpenLineage tabanlı, sütun düzeyinde, kaynaktan dashboard’a
- Yönetişim
- Kişisel veri etiketleme, dinamik maskeleme, satır düzeyi güvenlik, saklama politikaları
- Veri sunumu
- Veri ambarı tabloları, REST ve GraphQL API’leri, çevrimiçi ve çevrimdışı feature store
Entegrasyonlar
- PostgreSQL
- Oracle Database
- Microsoft SQL Server
- SAP S/4HANA
- Debezium
- Apache Kafka
- MQTT
- Apache Airflow
- dbt
- Apache Spark
- Apache Iceberg
- ClickHouse
- OpenLineage
- Feast
Uyum ve yönetişim
- Kişisel veriler alım sırasında etiketlenir, role göre maskelenir ve kayıtlı kurallara göre saklanır ya da silinir. KVKK yükümlülüklerini desteklemek üzere tasarlanmıştır.
- Yurt içi kurulum, erişim kayıtları ve izlenebilir veri değişiklikleriyle bankalar için BDDK bilgi sistemleri yönetmeliği gereksinimlerini desteklemek üzere tasarlanmıştır.
- Tüm pipeline’larda erişim yönetimi, değişiklik kontrolü ve kayıt tutma için ISO/IEC 27001 tarzı kontrolleri desteklemek üzere tasarlanmıştır.
- AB’de yerleşik kişilere ait veriler işlendiğinde, işleme faaliyeti kayıtları ve silme talepleriyle birlikte GDPR gereksinimlerini desteklemek üzere tasarlanmıştır.
Sık sorulan sorular
Sık sorulan sorular
01Mevcut veri ambarımızı veya ETL araçlarımızı değiştirmemiz gerekir mi?
Hayır. Orbit mevcut altyapınıza bağlanır: veriyi kullandığınız veri ambarına yazabilir, mevcut SQL modellerinizi devralabilir ve zamanlamaları kademeli olarak üstlenebilir. Eski işler pipeline pipeline taşınır; her geçişten önce eski ve yeni çıktılar karşılaştırılır.
02Bir kaynak sistem şemasını değiştirdiğinde ne olur?
Değişiklik, veri geldiği anda tespit edilir ve veri setinin sözleşmesiyle karşılaştırılır. Yeni bir alan eklenmesi gibi mevcut kullanımı bozmayan değişiklikler otomatik olarak ilerleyebilir; kullanımı bozan değişiklikler ise ilgili veri setinin yayımını durdurur, sahibini uyarır ve lineage üzerinden hangi rapor ve modellerin etkileneceğini gösterir.
03Kişisel veriler nasıl ele alınıyor?
Sütunlar veri alımı sırasında, kurallar ve veri sahiplerinin incelemesiyle kişisel veya hassas olarak etiketlenir. Maskeleme, takma adlandırma ve satır düzeyi politikalar role göre uygulanır; saklama süresi dolan veriler zamanlanmış işlerle silinir ya da anonim hâle getirilir ve her erişim ile silme işlemi kayıt altına alınır.
04Raporlarımızdaki rakamların doğru olduğundan nasıl emin olabiliriz?
Yayımlanan her veri seti, sözleşmesindeki kontrollerden geçmiştir; lineage da her rakamın arkasındaki kaynak sütunları ve dönüşümleri tam olarak gösterir. Bir kontrol başarısız olduğunda veri seti bekletilir ve işaretlenir; böylece rapor, güncel ama hatalı rakamlar yerine son doğru veriyi bir uyarıyla birlikte gösterir.
05Diğer VARDA ürünlerini kullanmak için Orbit gerekli mi?
Tüm VARDA ürünleri Orbit üzerine kuruludur ve ihtiyaç duydukları Orbit bileşenleriyle birlikte gelir; ayrıca kurulması gereken bir şey yoktur. Olgun bir veri platformunuz zaten varsa bu bileşenler onun yanında çalışır: veri ambarınızdan okur, sözleşme, lineage ve veri sunumunu yalnızca ürünlerin ihtiyaç duyduğu yerlere ekler.
VARDA Orbit’i kendi verinizle görün.
VARDA ürünlerinin dayandığı veri omurgası: CDC, batch ve streaming veri alımı, test edilen dönüşümler, lineage, gözlemlenebilirlik ve KVKK odaklı yönetişim.