Geliştiriciler için Veri Araçları Haritası Rehberi

• Veri alanına yeni katılan yazılım geliştiricilerinin yalnızca araç adlarını ezberlemek yerine, verinin toplanma/depolanma/işlenme/kullanılma aşamalarında her aracın üstlendiği rolü ve aralarındaki bağlantıları kavrayabilmesi için genel tablo düzenleniyor
• Veri rolleri kabaca analiz/bilim/mühendislik/makine öğrenimi türlerine ayrılır; SQL ve BI'dan istatistiksel modellere ve notebook'lara, pipeline altyapısına ve üretimde model dağıtımına kadar farklı problemler ve araçlarla ilgilenir
• Depolar; hızlı analiz ve kullanım kolaylığı sunan veri ambarı, ucuz ve esnek veri gölü ve tablo formatlarıyla ACID ile şema yönetimi ekleyen lakehouse olarak ayrılır
• Veri işleme, dbt gibi SQL dönüşümleri, pandas ve DuckDB'nin yerel işlemesi, Spark'ın dağıtık toplu işlemesi, Kafka ve Flink'in akış işlemesiyle genişler; Airflow gibi orkestratörler ise bağımsız işlerin çalışma sırasını ve hata sonrası kurtarmayı yönetir
• İşlenmiş veriler yalnızca dashboard'larda değil, satış/destek işleri, geçici analizler, makine öğrenimi, ürün içi analiz özellikleri ve veri satışı için de kullanılır; ölçek büyüdükçe katalog/semantik katman/lineage/yönetişim, verinin anlamını ve sorumluluğunu koruyan temel yapı haline gelir

---

Geliştiricilerin bilmesi gereken kapsam

• Bir veri şirketine katılmış ancak ilgili geçmişi olmayan bir yazılım mühendisinin, araçların kullanım amacını ve notebook'larla etkileşimini anlamak için hazırladığı geliştirici odaklı genel bir rehberdir
• Dashboard hazırlama yöntemleri, temel istatistik, Spark cluster işletimi ya da aynı kategorideki ürünlerin ayrıntılı karşılaştırmaları ele alınmaz
• Verinin nerede oluştuğunu ve nasıl işlenip depolanıp gösterildiğini takip ederek, her aracın üstlendiği yaşam döngüsü aşamaları ayrıştırılır

Veri rollerinin dört türü

• Gerçek roller arasındaki sınırlar, özellikle küçük şirket veya ekiplerde bulanık olsa da, genel tabloyu anlamak için dört türe ayrılabilir
• Analiz odaklı rol, veriyi SQL ve elektronik tablolarla yorumlar ve içgörüleri görselleştirir
  • Data analyst ve BI analyst bunun tipik örnekleridir; Tableau, Excel vb. kullanırlar
  • Müşteri verilerini inceleyip bölgelere göre churn oranını hesaplamak ve Tableau dashboard'u ile elde tutma kampanyası önerileri hazırlamak buna örnektir
• Bilim odaklı rol, istatistik, modeller ve deneyler aracılığıyla yüzeysel raporlamadan daha derin sorular veya tahminlerle ilgilenir
  • Data scientist bunun tipik örneğidir; ağırlıklı olarak Python, pandas, scikit-learn ve notebook kullanır
  • Churn nedenlerini araştırabilir, müşteri bazında churn olasılığı modeli kurabilir ve ardından elde tutma kampanyasının A/B testini tasarlayıp analiz edebilir
• Mühendislik odaklı rol, kaynak veriyi toplar, temizler, standartlaştırır, ardından ambar veya göle yükler; ayrıca veri araçlarını ve veritabanlarını işletir
  • Data engineer bunun tipik örneğidir; Python, Apache Spark, veritabanları, ambarlar ve bulut kullanır
  • Analiz sonucunu tekrar çalıştırılabilir bir reverse ETL pipeline'ına dönüştürmek ya da birden çok kaynaktan gelen işlem verisini birleştirip şema, sorgu ve kalite kontrollerini yönetmek buna örnektir
• Makine öğrenimi odaklı rol, sınıflandırma modellerinden LLM'lere kadar yapay zeka modelleri geliştirir ve işletir
  • ML scientist ve ML engineer'ı tek başlık altında toplayan bir kategoridir; ayrı araç ekosistemi büyük olduğu için metinde ayrıntılı ele alınmaz
  • Öneri modeli için eğitim verisini bir araya getirir, modeli eğitip ayarlar, API olarak dağıtır, ardından tahminleri izler ve davranış değişimine göre yeniden eğitir

ETL ve ELT

• ETL(Extract-Transform-Load), kaynak veriyi çıkarıp temizledikten veya başka verilerle birleştirdikten sonra sonucu hedefe yükleyen genel akıştır
• Aşamaların sırası sabit değildir; tekrarlanabilir veya birbiriyle örtüşebilir
• ELT, kaynak veriyi önce ambara yükler, ardından dönüşümü burada yapar ve sonucu ayrı tablolarda saklar
  • Ek depolama alanı ve işlem nedeniyle maliyet artabilir
  • Orijinal veri kaldığı için daha sonra farklı biçimde yeniden işlenebilir

Dosya ve bellek formatları

• CSV, küçük verileri aktarması kolay olduğu ve çoğu ofis yazılımında açılabildiği için teknik olmayan kullanıcılar için uygundur
• Apache Parquet, yüksek sıkıştırma oranı sunan ve büyük veriyi verimli biçimde depolayıp aktarabilen sütun odaklı bir dosya formatıdır
  • Çoğu veri aracı tarafından desteklendiği için araçlar arasında ortak format işlevi görür
  • Apache ORC de benzer sorunları çözer
• Apache Avro, kayıt iletimi için, özellikle de akış işlemede kullanılan satır odaklı ikili bir formattır
• Apache Arrow, işleme ve zero-copy aktarım için optimize edilmiş fiili standart bellek içi formattır
  • Parquet küçük dosyalar ve gerekli alanların taranmasına, Arrow ise CPU·GPU komutları ve cache'den yararlanan gerçek hesaplamaya odaklanır
  • Arrow daha fazla bellek kullanır, ancak pandas ve Rust'ın DataFusion'ı gibi araçlar arasında veriyi verimli biçimde taşır
  • pandas için isteğe bağlı backend olarak kullanılabilir; Polars ve DataFusion ise en baştan Arrow tabanlı olarak geliştirilmiştir

Veri ambarı

• Veri ambarı, PostgreSQL·MySQL gibi veritabanlarına benzer ancak analitik yükler için optimize edilmiştir
• MySQL gibi OLTP veritabanları ID ile tek bir kullanıcı satırını bulmak için uygundur; OLAP ambarları ise yıllık bölgesel satış toplamları gibi sütun bazlı toplulaştırmalar için uygundur
• Geleneksel olarak temizlenmiş yapılandırılmış verinin son deposu olsa da, ELT'de ham verinin ilk yüklendiği yer olarak da kullanılır
• Depolama formatı ile sorgu motoru sıkı biçimde bağlıdır; bu da hızlı BI ve raporlama sorguları sağlar, ancak üç depolama türü arasında maliyeti en yüksek olandır
• Ürünler arasında Snowflake, BigQuery, Redshift bulunur
• Açık kaynak ve self-hosted seçenekler arasında ClickHouse, Apache Doris, StarRocks bulunur
• Küçük projelerde geleneksel veritabanları da yeterli olabilir

Veri gölü

• Veri gölü, CSV, Parquet, JSON, e-posta, görsel gibi yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış verileri minimum işlemle saklayan büyük bir bulut klasörüne benzer
• Amazon S3, Google Cloud Storage, Azure Blob Storage üzerinde adlandırma ve partition kuralları ile erişim politikaları belirlenip dosyalar kaydedilerek kurulabilir
• Doğru yönetilmezse bulunması veya kullanılması zor bir veri bataklığı (data swamp) haline gelebilir
• Yönetilen seçenekler arasında Azure Data Lake ve Snowflake'in veri gölü özellikleri bulunur
• Veriyi doğrudan arayıp indirip parse etmeden sorgulayabilmek için metadata catalog ve sorgu motoru gerekir
  • Catalog; tablo adı, şema ve dosya eşlemelerini kaydeder
  • Sorgu motoru ise bu metadata ile ilgili dosyaları okuyup SQL gibi sorguları çalıştırır
• Catalog'lar arasında Hive Metastore, AWS Glue Data Catalog, Unity Catalog bulunur
• Sorgu motorları arasında Apache Spark, Trino, Amazon Athena bulunur

Veri lakehouse

• Veri lakehouse, ucuz ve esnek bir lake üzerine warehouse’a yakın işlevler ekler
• Temel bileşen olan tablo formatı, sorgu motoru ile ham veri arasındaki depolama biçimini yönetir
  • ACID ile eşzamanlı yazma, yazım sırasındaki hatalar ve veri bozulmasını ele alır
  • Yarı yapılandırılmış verilerde de şema tanımlanmalıdır; tamamen yapılandırılmamış veriler tablo formatının avantajlarından yararlanamaz
  • Şema evrimi ve sürüm yönetimini destekler
  • İndeks ve bölümleme optimizasyonuyla sorgular hızlandırılabilir
  • Bazı uygulamalar, belirli bir zamandaki snapshot’ı sorgulayan time travel desteği sunar
• Lake tabanlı olduğu için warehouse’dan daha ucuz olabilir ve belirli bir sorgu motoruna bağlı kalmaz, ancak ayrı işlem maliyetleri de hesaba katılmalıdır; bu yüzden bire bir fiyat karşılaştırması zordur
• Başlıca tablo formatları Apache Iceberg, Delta Lake, Apache Hudi’dir
• Yönetilen hizmetler arasında Google’ın Lakehouse for Apache Iceberg’i, Databricks ve IBM watsonx.data bulunur

Veri kaynakları ve toplama

• Veri; PostgreSQL ve Mongo gibi uygulama veritabanlarından, Stripe gibi harici API’lerden, tarayıcı analiz etkinliklerinden ve IoT cihazlarından gelir
• Çıkarıldıktan hemen sonra işlenebilir; ELT’de ise biçim, boyut ve altyapıya göre kaynak veri önce lake, lakehouse veya warehouse’a kaydedilebilir
• Özel betikler esnektir, ancak kimlik doğrulama, sayfalama ve hata işleme gibi tekrarlayan bağlantı kodlarını yeniden yazmayı gerektirir
• Veri toplama araçları, kaynak ve hedef bağlayıcılarını ayarlayarak bu tekrarlı işleri üstlenir
  • Çıkarılan verinin önce bir yere yüklenmesi gerektiğinden ELT akışına kayma eğilimindedir
  • Önde gelen ürünler Fivetran, Airbyte ve dlt’dir
• Change Data Capture (CDC), tabloları tekrar tekrar sorgulamak yerine veritabanı replikasyon loglarından ekleme, güncelleme ve silme işlemlerini yakalar
  • Toplama araçları bunu veritabanı kaynaklarında dahili olarak kullanır
  • Bağımsız açık kaynak bir bileşen olarak Debezium yaygın biçimde kullanılır

Veri işleme dilleri

• Python, geniş topluluğu ve yerel kütüphane ekosistemiyle veri işleri için fiili standart dildir
  • Başka dillerle yazılmış araçlar da çoğu zaman Python binding’leri sunar; Rust tabanlı Apache DataFusion buna bir örnektir
• numpy, yüksek performanslı çok boyutlu diziler sunar ve birçok kütüphanenin temelini oluşturur
• pandas, 1 boyutlu Series ve 2 boyutlu DataFrame sunan fiili standarttır
  • seaborn ve Plotly ile görselleştirme yapılabilir, streamlit ile etkileşimli uygulamalar geliştirilebilir
  • DuckDB ile SQL sorguları çalıştırılabilir veya scikit-learn’ün makine öğrenimi teknikleri uygulanabilir
• R akademide, Java ve Scala Spark gibi büyük veri framework’lerinde kullanılır; Julia ve Rust da veri işleri için kullanılır, ancak Python kadar yaygın değildir
• SQL, warehouse sorguları ve dönüşümler için yaygın biçimde kullanılır, ancak söz dizimi çalışma ortamına göre biraz değişir

Batch ve gerçek zamanlı işleme

• Batch işleme, geçen ayın satışlarını toplulaştırmak gibi büyük veri kümelerini düzenli olarak işler ve sonucun saatler ya da günler sonra alınabildiği işler için uygundur
• Gerçek zamanlı işleme, veri gelir gelmez işleyen stream yaklaşımını ya da 20 saniyelik aralıklar gibi microbatch kullanımını içerir
• Bot tespiti gibi sonucun hızı önemli olan pipeline’lar, kullanıcıları mümkün olduğunca hızlı tespit edip engellemek için gerçek zamanlı işlemeyi kullanır

SQL tabanlı dönüşüm

• dbt ve SQLMesh, dönüşümleri SQL select ifadeleriyle tanımlar ve gerçek sorgu motorunda çalışacak şekilde derler
• Bu iki araç veriyi doğrudan işlemez; dönüşüm orkestrasyonu yapar
• Kullanıcı tanımlı Python betiklerine kıyasla dönüşüm yaklaşımını standartlaştırır ve karmaşık işleri bağımlılıkları olan küçük modellere ayırmayı sağlar
• dbt’deki ref, sabit kodlanmış tablo adları yerine modellere referans verir ve bağımlılık grafiğine göre doğru sırada çalıştırır
• Sonuçlar genellikle kaynakla aynı warehouse, lakehouse veya lake’e kaydedilir, ancak sorgu motoru yapılandırmasına göre farklı hedeflere de gönderilebilir

Yerel DataFrame ve DuckDB

• DataFrame, tablo biçimli verileri işleyen 2 boyutlu dizi soyutlamasıdır; Python’da en yaygın kullanılan uygulama pandas’tır
• Diğer uygulamalar arasında Python ve Rust için Polars, Rust için DataFusion, Julia için DataFrames.jl, R için data.frame ve Java için tablesaw bulunur
• pandas, data.frame ve tablesaw, çağrılır çağrılmaz işlem yapan anında yürütme (eager) yaklaşımını kullanır
• DataFusion ve Polars’ın LazyFrame yapısı, işlemleri mantıksal bir plan olarak biriktirir ve .collect() aşamasında çalıştırır
  • Çalıştırmadan önce plan optimize edilebildiği için daha hızlı olabilir
• Yerel kütüphaneler bellek ve CPU ile sınırlıdır
  • pandas tüm veriyi bellekte işlediği için RAM kapasitesiyle sınırlıdır
  • Polars’ın streaming özelliği RAM’den büyük verileri de işleyebilir, ancak bazı işlemler çalışma kümesini belleğe almak zorundadır
• DuckDB, “analitik için SQLite” diye anılan in-process bir OLAP veritabanıdır
  • Ayrı bir altyapı gerektirmeden yereldeki CSV, Parquet ve pandas DataFrame’lerini SQL ile sorgular

Büyük ölçekli dağıtık işleme

• Tek bir makinenin sınırları aşıldığında veri birden çok parçaya bölünür, cluster üzerinde paralel işlenir ve iş yüküne göre yatay ölçeklenir
• Apache Hadoop erken dönemin temsilî araçlarından biridir, ancak bugün legacy kabul edilir ve eski ortamlarda görülebilir
• Apache Spark, bugün fiili standarttır; veri yükleme, dönüştürme, paralelleştirme ve optimizasyondan sorumludur
  • PySpark, DataFrame API’si ve pandas uyumlu bir katman sunar
  • SparkR yakın zamanda kullanımdan kaldırıldı; Java ve Scala binding’leri de sunulur
  • Farklı depolama sistemlerini okuyup yazabildiği için hem veri lake sorgu motoru hem de büyük ölçekli dönüşüm işleri için kullanılır
• Dask, tanıdık pandas ve numpy API’lerine yakın biçimde Python kodunu cluster’a taşır
• Ray, genel amaçlı bir dağıtık hesaplama framework’üdür; özellikle ML eğitimi için sık kullanılır
• Apache Flink batch işleme de yapar, ancak asıl gücü stream işlemedir

Olay akışı ve Kafka

• Akış işleme, kredi kartı dolandırıcılığı tespiti gibi sonucun anında gerektiği durumlar veya web analitik olaylarını gelir gelmez doğrulayıp IP coğrafi bilgisiyle zenginleştirerek ClickHouse'a yazma işleri için uygundur
• Veri gelir gelmez işlenirse, bir sonraki batch çalışmasına kadar ham payload'ı ayrıca saklamak gerekmeyebilir
• Apache Kafka, üreticilerden gelen olayları alıp depolayan ve tüketicilerin okumasını sağlayan dağıtık, hata toleranslı bir olay akışı platformudur
  • Mesaj kuyruğundan farklı olarak, tüketici onay verse bile olaylar silinmez; saklama kuralı sona erene kadar birden çok tüketici bunları tekrar tekrar okuyabilir
  • Kafka veriyi kendisi işlemez; işleme, tüketici olarak çalışan ayrı worker'lar tarafından yapılır
• Kafka Connect, Kafka'yı veritabanı gibi dış sistemlere bağlar
• Kafka Streams, Kafka üzerinde durum tabanlı dönüşümler, pencere toplulaştırmaları ve join işlemleri yapan bir Java/Scala kütüphanesidir
  • Uygulamanın içine gömülü olarak çalışır ve yalnızca Kafka ile çalışır
• Diğer olay akışı platformları arasında Apache Pulsar, Redpanda ve AWS Kinesis Data Streams bulunur

Akış işleme motorları

• Apache Flink, olay kaynakları ve işleme adımları tanımlandığında küme dağıtımı, ölçekleme ve hata kurtarmayı üstlenir
• Pipeline; filtreleme, alan eşleme, pencere toplulaştırmaları, tekrar eden kayıtların kaldırılması ve başka Kafka topic'lerine ya da veritabanlarına çıktı verilmesini içerebilir
• Dağıtılan işler, sona eren bir batch değil, yeni olayları sürekli işleyen süreçlerdir
• Diğer seçenekler arasında Spark Structured Streaming, Google Cloud Dataflow ve Azure Stream Analytics yer alır

İş orkestrasyonu

• dbt dönüşümleri, Spark işleri ve özel script'ler arttıkça, bir orkestratör tek tek adımları tek bir pipeline içinde birleştirir
• Her iş ve bağımlılıkları çoğunlukla Python ile kod olarak tanımlanırsa, yönlendirilmiş döngüsüz grafik olan bir DAG oluşur
• Orkestratör veriyi doğrudan işlemez; Spark script'lerini çalıştırma, dbt dönüşümlerini çağırma, HTTP istekleri gönderme gibi işleri koordine eder
• Tetikleyici olarak zamanlama, Kafka olayları, UI üzerinden manuel çalıştırma, HTTP istekleri veya eklentilerle oluşturulmuş tetikleyiciler kullanılabilir
• Bağımsız işler paralel çalıştırılabilir, yalnızca başarısız adımlar yeniden denenebilir ve süreç o noktadan devam ettirilebilir
• Başlangıçtan bitişe çalışan batch işleme için uygun olduğundan, sürekli yaşayan akış pipeline'larına pek uymaz; bu durumda Flink gibi işleme motorlarının kendisine dayanılır
• Öne çıkan ürünler Apache Airflow, Dagster, Prefect ve Luigi'dir
  • Luigi daha eskidir ve bugün daha az popülerdir

Gözlemlenebilirlik ve kalite izleme

• Veri gözlemlenebilirliği, pipeline durumu ve verinin kendi kalitesi olarak ikiye ayrılır
  • Pipeline izleme, çalışıp çalışmadığını, hataları ve süreyi kontrol eder
  • Veri izleme, güncellik, veri hacmindeki anormallikler ve haber verilmeden yapılan şema değişiklikleri gibi unsurları kontrol eder
• Pipeline'lar için Prometheus, Grafana, ELK gibi genel uygulama gözlemlenebilirlik araçları ve orkestratörün kendi özellikleri kullanılabilir
• Veri kalitesi kontrolleri, beklenen formatı doğrudan tanımlayan Great Expectations ve dbt tests ile uygulanabilir
• Otomasyon ürünleri, normal veri desenlerini öğrenip anormallikleri tespit eder; Monte Carlo, Bigeye ve Metaplane buna örnektir

Pipeline'da tekrarlanan yükleme

• ETL'nin son yükleme hedefi warehouse, lake veya lakehouse olsa da veri pipeline'ın sonunda yalnızca bir kez saklanmaz; farklı biçimlerde birden fazla kez saklanır
• Madalyon mimarisi, aynı depodaki arıtma düzeyini üç katmana ayırır
  • Bronze, kaynaktan geldiği haliyle ham veridir
  • Silver, tip düzeltme, yinelenen kayıtları kaldırma ve kaynak birleştirme gibi işlemlerden geçmiş temizlenmiş ve standartlaştırılmış veridir
  • Gold, dashboard veya rapor gibi belirli amaçlara uygun şekilde toplulaştırılmış ve modellenmiş veridir
• Analistler çoğunlukla Gold tablolarını sorgular; mühendisler ise pipeline hata ayıklaması için Bronze katmanına kadar inebilir

Boyutsal modelleme

• Madalyon yapısı verinin arıtma düzeyini gösterirken, boyutsal modelleme warehouse tablolarının biçimini kurgular
• Ralph Kimball'un popülerleştirdiği The Data Warehouse Toolkit yaklaşımı, fact tabloları ile dimension tablolarını ayırır
• Fact tablosu, sipariş, ödeme veya sayfa görüntüleme gibi her satırda tek bir olay ya da ölçüm değeri saklar
  • Uzun ve dardır; çok sayıda sayısal değer ve dimension tablosu foreign key'i içerir ve sürekli büyür
• Dimension tablosu, müşteri, ürün veya tarih gibi olayın gerçekleştiği bağlamı saklar
  • Daha geniştir ve görece daha yavaş değişir
• Merkezdeki fact tablosunu dimension tabloları çevrelediğinde star schema oluşur
  • Daha normalize bir snowflake schema da vardır ve Snowflake ürünüyle ilgisi yoktur
• Grain, bir satırın tek bir siparişi mi, tek bir sipariş kalemini mi, yoksa müşteri başına günlük tek bir siparişi mi temsil ettiğini tanımlar
• Data mart, pazarlama veya finans gibi belirli bir ekip ya da konuya yönelik warehouse bölümüdür ve genellikle Gold katmanında yer alır
• Her ekip bunu sıkı biçimde izlemez; hızlı modern warehouse'lar ve ucuz depolama maliyetlerinden yararlanarak amaca göre geniş ölçüde denormalize edilmiş tek büyük tablo da oluşturulabilir

Uygulamalar için gerçek zamanlı OLAP

• İç dashboard'lar için warehouse'daki Gold tablolar yeterli olabilir, ancak çok sayıda kullanıcıya milisaniye düzeyinde hizmet verirken sorgu gecikmesi ve sorgu başına maliyet uygun olmayabilir
• Kullanıcıya dönük analitik, gerçek zamanlı iç izleme, liderlik tabloları, popüler öğeler ve kullanım ölçümü gibi yüksek eşzamanlılık ve hızlı yanıt gerektiren veriler gerçek zamanlı OLAP veritabanlarına taşınır
• Buna Apache Druid, Apache Pinot, ClickHouse ve Apache Doris dahildir; ClickHouse yaygın olarak kullanılır

Reverse ETL

• Reverse ETL, warehouse'da işlenmiş veriyi CRM gibi operasyonel araçlara geri gönderir
• Stripe verileriyle müşteri yaşam boyu değeri hesaplanıp HubSpot'a yazılırsa satış ekibi yüksek değerli müşterileri hemen görebilir
• Özel araçlar tablo ve sütunları hedef alanlarla eşler; hata, yeniden deneme, hız sınırı, uyarı ve artımlı senkronizasyonu yönetir
• Seçenekler arasında Airbyte Data Activation, Fivetran Activations, Hightouch ve RudderStack bulunur
  • Fivetran Activations, satın alma öncesinde Census adıyla biliniyordu

Veri kataloğu ve semantik katman

• İnsanlar için olan veri kataloğu, verinin kaynağı, sahibi, erişim politikası ve arama bilgilerini içererek tablolara ve sütunlara iş bağlamı kazandırır
  • Sorgu motorları için kullanılan metastoredan farklı bir amaca sahiptir
  • Unity Catalog, DataHub ve OpenMetadata başlıca örneklerdir
• Semantik katman, iş varlıkları, ilişkiler ve metrikler için standart tanımları saklar
  • Müşteri modelinin hangi tablo ve sütunlardan geldiğini, EMEA'ya hangi pazarların dahil olduğunu, gelirden iadelerin düşülüp düşülmediğini gibi konuları standartlaştırır
  • BI araçları veya yapay zeka ajanları doğru varlıkları ve metrikleri seçtiğinde bunu gerekli sorgulara dönüştürür ya da sorgu üretimi için gereken bilgiyi sağlar
• Looker'ın LookML'i, Cube, dbt Semantic Layer ve Unity Catalog'un semantik özellikleri buna örnektir

Veri soyağacı

• Veri soyağacı (data lineage), verinin pipeline'lar boyunca nasıl dönüştürüldüğünü izler
• Orchestrator DAG'lerinden, dönüşüm SQL'inin parse edilmesinden ve işleme görevlerinin dışa aktardığı event ile metadata'dan otomatik olarak toplanabilir
• Tablo düzeyinde, gold.orders tablosunun silver.orders ve silver.customers tablolarından üretildiği ilişkisini kaydeder
• Sütun düzeyinde ise customers.life_time_value değerinin orders.total ve subscription_payments.amount üzerinden hesaplandığı ilişkiye kadar izler
• Sütun silmenin aşağı akış etkisini değerlendirmek, hatalı metriklerin kök neden analizini yapmak ve kişisel olarak tanımlanabilir bilgi kullanımında uyumluluğu sağlamak için kullanılır
• Unity Catalog, DataHub ve OpenMetadata soyağacı görselleştirmesini destekler, ancak tüm pipeline'ın connector'lar veya manuel event'ler aracılığıyla izleme verisi sağlaması gerekir
• Sağlayıcıya özgü biçimler yerine, birden fazla katalog ve işleme aracı tarafından desteklenen OpenLineage standardı kullanılabilir

BI dashboard'ları ve raporlar

• Dashboard'lar ve raporlar, veri pipeline'larının en yaygın tüketim noktasıdır; küçük şirketlerde fiilen tek kullanım alanı bile olabilir
• BI araçları, warehouse, lakehouse ve uygulama veritabanlarına bağlanarak kod yazmadan grafikler ve dashboard'lar oluşturmayı sağlar
• Temel nokta, teknik olmayan kullanıcıların her seferinde analistlerden talepte bulunmak yerine arayüz üzerinden doğrudan grafik oluşturabilmesi veya veriyi keşfedebilmesi olan self-service yaklaşımıdır
• Zamanlanmış raporlar e-posta veya Slack ile gönderilebilir ya da metrikler eşikleri aştığında uyarı verilebilir
• Tableau ve Power BI, büyük şirketlerde yaygın olarak kullanılır ve güçlü, esnek görselleştirmelere odaklanır
• Looker, LookML semantik katmanını merkeze alır ve teknik ekipler için uygundur
• Metabase, self-hosting dahil hızlıca kurulabilir ve teknik olmayan kullanıcılar için erişimi kolaydır
• Looker Studio, LookML kullanmayan ve Looker'dan daha az özelliğe sahip ayrı bir üründür; yakın zamanda adı yeniden Data Studio olarak değiştirilmiştir

Operasyonel analiz

• Operasyonel analiz, yönetici raporları için değil, analitik dışı ekiplerin her gün kullandığı uygulamaların içine veri sunar
• Kullanım örnekleri şunlardır
  • Kullanım özetlerini HubSpot'a senkronize ederek satış ekibinin doğru müşterilere upsell yapmasını sağlamak
  • Son siparişleri, destek ticket'larını ve plan bilgilerini Zendesk'e senkronize ederek destek ekibinin müşteri bağlamını görmesini sağlamak
  • Müşteri başarı ekibi için müşteri bazında ürün benimseme durumunu gösteren bir iç uygulama oluşturmak
• Reverse ETL bunun için tipik bir aktarım yöntemidir, ancak warehouse'u doğrudan sorgulayan iç Customer 360 uygulamaları da operasyonel analiz kapsamına girer

Ad-hoc ve keşifsel analiz ile notebook'lar

• Ad-hoc analiz (ad-hoc analysis), mevcut verilerle kayıt düşüşünün nedeni veya iadeye yol açan cohort gibi tek seferlik soruları araştırır
• Keşifsel analiz, önceden tanımlanmış bir soru olmadan veriyi inceleyip içgörü bulmaya çalışır
• Sonuçlara göre sonraki işlemler değiştiği ve basit filtreleme ile agregasyondan daha karmaşık olduğu için yalnızca genel raporlama araçları yeterli olmayabilir
• Python ve pandas·Polars, warehouse SQL arayüzleri, Spyder, RStudio gibi araçlar kullanılabilir
• Notebook'lar, Markdown, kod ve SQL gibi hücreleri tek bir dosyada birleştirir; görselleri, etkileşimli grafikleri ve tablo çıktılarını kodun yanına yerleştirir
  • Çalıştırma sonuçlarını görerek adım adım keşif yapmaya ve sonuçları sunmaya uygundur
  • Jupyter, Google Colab, Deepnote ve marimo başlıca örneklerdir
  • Databricks ve Snowflake gibi platformlar da kendi notebook'larını sunar

Makine öğreniminde veri tüketimi

• ML, feature store, eğitim, izleme ve dağıtım araçlarına sahip ayrı bir alan olsa da verinin başlıca tüketim alanlarından biridir
• LLM'lerin dışında da churn tahmini, öneri sistemleri, talep tahmini ve müşteri segmentasyonu gibi uzmanlaşmış modeller vardır; bunlar production'a alınmadan önce temizlenmiş eğitim verisi gerektirir
• Data scientist veya ML engineer, son 30 gündeki sipariş sayısı ya da son girişten bu yana geçen gün sayısı gibi feature'ları warehouse'dan alıp modeli eğitir ve dağıtır
• Tahmin sonuçları daha sonra CRM'deki churn skoru gibi operasyonel analize veya kullanıcıya dönük ürün önerilerine yeniden bağlanır

Gömülü analiz

• Gömülü analiz, marketplace satıcılarına popüler ürünler, müşteri bölgeleri ve arama sıralamaları gibi analizleri uygulamanın içinde sunar
• Önceden tanımlanmış 5 grafik ve sınırlı filtreler yeterliyse, sorguları, arayüzü ve grafik kütüphanesini doğrudan kendiniz geliştirebilirsiniz
• Kullanıcıların karmaşık sorgular yapması gerekiyorsa Metabase, Looker, Tableau gibi BI araçları ya da Sisense ve Luzmo gibi gömme odaklı ürünler kullanılabilir
• Host uygulama kimlik doğrulama ve yetkilendirmeyi üstlenir, gömülü araç ise sorgu arayüzünü ve grafiklerin render edilmesini yönetir

Verinin kendisini ürün olarak satmak

• Veri, bir özelliğin hammaddesi olmanın ötesinde doğrudan ürünün kendisi olabilir
• Birden çok kripto para blokzincirinden veri toplayıp dönüştürerek ve indeksleyerek analistlere erişim satabilir ya da Google arama sonuçlarını toplayıp SEO uzmanlarına pazarlayabilirsiniz
• Veriyi ve sorgu erişimini satmak için zamanında veri toplayan sağlam pipeline'lar ve yüksek performanslı sorgu yetenekleri gerekir

Veri yönetişimi

• Veri yönetişimi, kişisel olarak tanımlanabilir bilgiler, sağlık verileri gibi hassas verilere kimin erişebileceğini ve erişim kayıtlarını yönetir
• Veri sahipliği, unutulma hakkı gibi gizlilik işlemleri, fiziksel depolama konumu ve saklama süresi de buna dahildir
• Warehouse'daki rol ve erişim denetimi, katalogdaki sahiplik bilgileri ve soyağacı üzerinden PII kullanımının izlenmesi gibi teknolojiler bunu destekleyebilir
• Bu yalnızca teknik bir konu değildir; insan ve süreç boyutu büyüktür ve hukuk, uyumluluk ile güvenlik ekipleriyle yakından bağlantılıdır
• Veri ekosisteminin bütünü, kaynaktan toplanıp depolanarak işlendiği ve kullanıldığı bir akış olarak görülebilir; her kategorinin altında da daha fazla araç ve ayrıntılı seçim seçeneği ortaya çıkmaya devam eder