Veri ambarınızda (data warehouse) yüzlerce tablo, binlerce kolon ve sayısız view olabilir. Peki şirkete yeni katılan bir veri analisti veya entegre ettiğiniz bir AI agent, geçen ayki aktif kullanıcı churn oranının kaç olduğunu hangi tablonun hangi kolonunda bulacağını nereden bilecek veya sorgusunu nasıl yazacak?
Eğer ellerinde bir veri katalogu veya metadata havuzu yoksa veri mühendisliği ekibinin en büyük kabusu veriyi depolamak değil; devasa veri göllerinde (data lake) kaybolan o veriyi bulmak, anlamlandırmak, güvenliğini sağlamak ve son kullanıcıya veya yapay zekaya doğru bağlamla sunmak olsa gerek.
Google Cloud’un bu ihtiyaçla ilgili bir çözümü var: Knowledge Catalog.
Nedir, ne değildir?
Knowledge Catalog; verinizin fiziksel olarak saklandığı, taşındığı veya sorgulandığı bir veritabanı (database) değildir. BigQuery veya Cloud Storage'ın yerini almaz. Aksine, onların üzerine inşa edilen, sistemdeki tüm veri varlıklarını tek bir merkezden keşfetmenizi, etiketlemenizi ve yönetmenizi sağlayan bütünleşik bir veri yönetişimi (data governance) ve metadata katmanıdır.
Karmaşayı çözelim
Knowledge Catalog ile haşir neşir olmaya başladığınızda lake, zone, data product ve business glossary gibi terimleri birbirine karıştırabilirsiniz. Bunlar aynı zamanda en çok zaman harcayacağınız kısımlardır. Özellikle bir business glossary teriminin neden bir lake ile değil de spesifik bir kolon ile bağlandığı sorusu mimariyi yeni kurgulayan herkesin aklına gelir. Bu yapıyı anlamak için bir süpermarkete girdiğinizi hayal edelim.
- Lake ve Zone (Mantıksal Altyapı - Depo): Süpermarketin deposu ve lojistik koridorlarıdır. Ürünlerin toptan geldiği, ayrıştırıldığı (raw-zone) ve paketlenip işlendiği (curated-zone) arka plandaki operasyonel alandır. Burası mühendis ekiplerinin dünyasıdır.
- Data Product (Veri Ürünleri - Reyon): Süt almak istediğinizde “süt ürünleri” reyonuna gidersiniz. Mantıksal olarak birbiriyle ilişkili, işlenmiş ve tüketime hazır veriler (örneğin üyelik tabloları) burada bir araya getirilir, etrafı düzenlenir ve son kullanıcıya şeffaf bir vitrin olarak sunulur.
- Business Glossary (İş Sözlüğü - İçindekiler): Raftaki spesifik bir süt kabının arkasında yazan “içindekiler" etiketidir. Takip ettiğiniz KPI’ların tanımının yer aldığı bağlamsal ağdır. Burada bir tanım ne lake ile ne de data product ile ilişkilendirilir.
Neden içindekiler etiketi doğrudan bir reyona bağlanmaz?
Eğer içindekiler (business glossary) etiketini koca bir reyona (data product) yapıştırsaydınız, müşteri o reyondaki onlarca ürün arasında hangi sütün o içeriğe sahip olduğunu bulmak için yine tek tek paketleri incelemek zorunda kalırdı. İşte bu yüzden Knowledge Catalog mimarisinde “aktif kullanıcı" veya “churn" gibi bir iş terimi (business glossary), geniş veri kümelerine değil, nokta atışı olarak ilgili tablonun spesifik bir kolonuna bağlanır. Bu sayede veriyi arayan bir iş birimi veya SQL yazmaya hazırlanan bir AI agent, hedefini tereddütsüz bulur.
Bir süt paketinin -içindekiler etiketi ve sütün kendisi haricinde- hangi reyonda yer aldığı veya reyona gelmeden önce nerede depolandığı önemli değilse, bir business glossary için de lake, zone veya data product önemli değildir. Bunların yeri değişebilir ama verinin kaynağı, yani tablo değişmez.
AI agent bu katalogu nasıl okur?
Knowledge Catalog veri varlıklarını keşfetmek için bir katmandır dedik. Biz, yani insanlar yukarıda özetlemeye çalıştığım bölümler arasında dolaşarak neyin nerede olduğunu anlayabilir ama sisteme bir AI agent bağladığımızda hangi yollardan geçerek amacına ulaşır?
- Sözlüğe Bak (Business Glossary) Farz edelim kullanıcı “iptal edenleri analiz et” dedi. AI agent, “iptal" teriminin iş sözlüğünde (business glossary)
churn_flagkolonuna, bu kolonun da üyelikle ilgili açtığımız bir ürüne (data product) ait olduğunu keşfeder. - Bağlamı Kur (Context Window) Agent doğru tabloyu bulur ama hemen SQL yazmaz. Tablonun
metadata typesdetaylarını (aspects) okur. Verinin büyük oranda kaliteli olduğunu, tablonun ne sıklıkla güncellendiğini ve tüm açıklama alanlarındaki hesaplama kurallarını öğrenerek bağlamı (context window) tamamlar. - İzinleri Doğrula (Policy Tags): Agent, sistemin güvenlik duvarına çarpar. Yetkisi olduğu tablolarda istediği gibi at koştururken yetkisi olmayan tablolarla ilgili bir sorgulama yapamaz. Nereye ulaşıp nereye ulaşamayacağı belli olduktan sonra bağlam tamamlanır.
- Aksiyon ve Sonuç (SQL): Agent artık tablonun kesin adresini, semantik anlamını, güvenilirliğini ve kısıtlarını biliyordur. Sadece bu aşamada fiziksel veri ambarına (BigQuery) inerek kusursuz SQL'ini çalıştırır.
Geliştiriciler için pratik ipuçları
Bu mimariyi arayüz (UI) üzerinden tıklayarak oluşturmak görsel olarak rahatlatıcı olsa da, CI/CD süreçleri, otomasyonlar, toplu yüklemeler ve hızlı altyapı kurulumları için Cloud Shell üzerinden resmi gcloud CLI komutlarını kullanabilirsiniz.
Veriyi sadece "depoladığınız" değil, "vitrine çıkardığınız" günler dileriz.