MLOps Feature Store: Feast, Tecton ve Hopsworks Karşılaştırması 2026
Feature store nedir sorusunun en yalın cevabı şudur: makine öğrenimi özniteliklerini (feature) merkezi olarak tanımlayan, depolayan, sürümleyen ve hem eğitim hem de çevrimiçi tahmin (online inference) süreçlerine düşük gecikmeyle servis eden uçtan uca veri katmanıdır. Bir feature store; offline (Parquet, BigQuery, Snowflake, S3) ile online (Redis, DynamoDB, Cassandra, RonDB) depoları aynı tanım üzerinden senkron tutar, eğitim-servis çarpıklığını (training-serving skew) ortadan kaldırır ve veri bilimcisinin ürettiği niteliği üretim ortamında milisaniyeler içinde geri okunabilir hale getirir. 2026 itibarıyla pazar üç ciddi seçenek etrafında konsolide olmuş durumdadır: açık kaynak Feast (Linux Foundation AI & Data sandbox, GitHub’da 6.000+ yıldız), kurumsal yönetilen Tecton (eski Uber Michelangelo ekibi tarafından kurulmuş, 2024 başında 100M USD Seri C) ve veri-yoğun ML platformu Hopsworks (Logical Clocks AB, RonDB üzerine kurulu, Avrupa kökenli). Bu yazı; mimari farklar, gerçek throughput/latency rakamları, fiyat modelleri ve hangi senaryoda hangi aracın seçilmesi gerektiğini sayısal kanıtlarla karşılaştırır.
Anketler, Stack Overflow Developer Survey 2024 verilerine göre profesyonel veri ekiplerinin yaklaşık %32’sinin ML feature yönetimi için ayrı bir araç kullandığını, kalanının ise notebook artıkları veya ad-hoc SQL’lere bel bağladığını gösteriyor. Gartner, 2025 ML Engineering trend raporunda feature store benimsenmesinin 2023’e kıyasla iki yılda yaklaşık 2,3 kat arttığını tahmin ediyor. McKinsey’nin 2024 State of AI raporunda da ölçeklenmiş üretim ML kullanan şirketlerin %61’inin merkezi bir feature katmanına sahip olduğu raporlanıyor.
Feature Store Neden Gerekli: Eğitim-Servis Çarpıklığının Maliyeti
Bir veri bilimcisi notebook’ta users.groupby("user_id").agg(avg_basket_30d) yazdığında pandas, ham olayları toplulaştırır. Aynı feature üretimde Java tabanlı bir gRPC servisinde Redis’ten okunmak istendiğinde aynı tanımı kim yeniden yazacak? Yeniden yazıldığında zaman penceresi (rolling window) inclusive mi, dakika mı saat mi, NaN’lar nasıl ele alınacak? İşte bu nokta-tarihinde-tutarlılık (point-in-time correctness) sorunu, modeli üretimde sessizce bozar. Google Research’ün 2017’de yayınladığı klasik “Hidden Technical Debt in Machine Learning Systems” makalesi bu problemi formalize etmişti; 2026’da feature store mimarisi tam olarak bu borcu kapatmaya tasarlanmıştır.
| Problem | Feature Store Yokken | Feature Store Varken |
|---|---|---|
| Training-serving skew | %15-30 model accuracy düşüşü tipik | Tek tanım, sıfır skew (point-in-time join) |
| Feature yeniden kullanım | Her ekip sıfırdan yazar, ortalama 3-5 kez kopyalanır | Registry’de tanımlanır, paylaşılır |
| Online latency | 50-500 ms (DB’ye join’le sorgu) | 1-15 ms (key-value lookup) |
| Backfill iş yükü | Manuel SQL, 1-3 hafta | Bildirimli, dakikalar–saatler |
| Compliance/lineage | Excel takip, GDPR riski | Otomatik metadata + audit log |
Bir e-ticaret örneğinde — diyelim 30 günlük sepet ortalaması — eğitim verisi her satırda olayın o anki gerçek değerini taşımalıdır; geleceğe sızan tek bir agregasyon (data leakage) öğrenilen ilişkileri çarpıtır. Feature store’lar bu point-in-time join’i materyalize ederek skew’u sıfıra indirir.
Feast Mimarisi: Açık Kaynak ve Bring-Your-Own-Infra
Feast (Feature Store), Gojek mühendisleri tarafından 2018’de başlatılmış, 2020’de açık kaynak yapılmış ve 2022’de Linux Foundation AI & Data Sandbox projesi olmuştur. Tasarım felsefesi “sen altyapını getir, biz koordine edelim”dir. Feast bir SDK + registry + materialization motoru sağlar; offline store olarak BigQuery, Snowflake, Redshift, Spark veya yerel Parquet kullanır; online store olarak Redis, DynamoDB, Datastore, PostgreSQL, Bigtable veya SQLite seçenekleri vardır.
Feast’in kalbi feature_store.yaml ve Python feature_view tanımlarıdır. Repo şuna benzer:
- Entity: birincil anahtar (user_id, item_id, transaction_id).
- Data source: Parquet, SQL view, Kafka topic veya stream pushed source.
- Feature view: entity + kaynak + TTL + feature listesi.
- Feature service: bir model için seçilmiş feature view birleşimi (servable kontrat).
Çevrimdışı tarafta get_historical_features() point-in-time correct join üretir; çevrimiçi tarafta get_online_features() Redis’ten 1-5 ms’de yanıt döner. Feast 0.40+ sürümüyle gelen Feast feature server bir gRPC/REST mikro servisi olarak çalışır; container başına ~250 MB RAM, 1 vCPU ile saniyede 5.000-15.000 lookup destekler.
Feast Avantaj ve Dezavantaj Tablosu
| Yön | Detay |
|---|---|
| Avantaj: Lisans | Apache 2.0, vendor lock-in yok |
| Avantaj: Esneklik | 15+ offline/online provider, kendi storage’ını seç |
| Avantaj: Maliyet | Sadece altyapı bedeli (S3 + Redis ~ aylık 200-800 USD küçük workload) |
| Dezavantaj: Ops yükü | K8s, monitoring, scaling, upgrade ekibe ait |
| Dezavantaj: Stream | Native streaming materialization sınırlı (push API var ama enterprise değil) |
| Dezavantaj: Governance | Yerleşik RBAC/ACL minimal, kurum çapı yönetim eklenti gerektirir |
| Ne zaman seç: | Mühendis-yoğun ekip, AWS/GCP zaten varsa, vendor bağımsızlığı şartsa |
Tecton Mimarisi: Yönetilen Enterprise Platform
Tecton, 2019’da Uber Michelangelo platformunun kurucu mühendisleri tarafından kurulmuştur. Şirket 2024 başında Sequoia liderliğinde 100M USD Seri C turunu kapatmış ve toplam funding 160M USD seviyesine ulaşmıştır. Tecton, Feast’in açık kaynak çekirdeğini de yönetir (Tecton 2022’de Feast’i benimsemiş, 2024’te ortak yönetimi LF AI & Data’ya devretmişti) ve kendi enterprise platformuna pre-built konnektörler, stream processing, monitoring, RBAC ve SLA ekler.
Tecton’un ayrıştırıcı özelliği, tek bir Python deklarasyonundan hem batch hem streaming hem on-demand transformation üretmesidir. Örnek:
- Batch feature: 30 günlük spend ortalaması (Snowflake’ten gece çalışır).
- Streaming feature: son 5 dakikadaki kart işlem sayısı (Kinesis/Kafka’dan).
- On-demand feature: request anında hesaplanan euclidean distance (haritalama vb.).
Bu üç farklı feature türü tek @batch_feature_view, @stream_feature_view, @on_demand_feature_view dekoratörüyle tanımlanır ve aynı registry’den servis edilir. Online store olarak Tecton, DynamoDB veya Redis Enterprise kullanır; tipik p99 latency 5-20 ms, p50 1-3 ms civarındadır (vendor benchmark, küçük entity payload). Aynı amaçlı modern stream processing motorları (Flink, Kafka Streams) Tecton’un altyapısında da kullanılır.
Tecton Fiyatlandırma Yapısı
| Tier | Hedef | Yaklaşık Yıllık Maliyet (USD) | Özellikler |
|---|---|---|---|
| Starter | Tek ekip, <50 feature view | ~50K-90K | Batch + on-demand, single region |
| Enterprise | Çoklu ekip, streaming şart | ~150K-400K | Stream + RBAC + multi-region |
| Mission Critical | Bankacılık, fraud detection | 500K+ | SLA 99.99, dedicated VPC, FedRAMP path |
Rakamlar vendor public listing yerine soğuk satış görüşmelerinden elde edilen sektör tahminleridir; gerçek anlaşmada %20-40 indirim mümkündür. Tecton’un avantajı, kurum güvenlik ve uyum (SOC 2 Type II, ISO 27001, HIPAA-eligible) sertifikalarına sahip olmasıdır.
Hopsworks Mimarisi: RonDB ve Veri-Yoğun ML
Hopsworks; İsveç merkezli Logical Clocks AB tarafından geliştirilen, 2014’te akademik bir projeden ürünleşmiş bir ML platformudur. 2025 itibarıyla Hopsworks 4.0 sürümü stabildir. Diğer iki rakipten farklı olarak Hopsworks, online store için RonDB kullanır — MySQL Cluster’ın (NDB) bir fork’u olan, in-memory dağıtık ilişkisel veritabanı. Bu seçim, Hopsworks benchmark sonuçlarına göre çok büyük entity payload’larında (500+ feature/satır) Redis’e kıyasla 3-7 kat throughput avantajı sağlar.
| Bileşen | Hopsworks Karşılığı | Açıklama |
|---|---|---|
| Offline store | Apache Hudi tabloları (S3/HDFS) | ACID transaction, time travel |
| Online store | RonDB cluster | ~100K-1M lookup/sec/node, p99 <5 ms |
| Streaming engine | Spark Structured Streaming + Flink | Pluggable |
| Feature view | Python + SQL | Hem deklaratif hem ad-hoc |
| Vector search | Yerleşik (OpenSearch backed) | RAG/recommend için, ek bağımlılık yok |
Hopsworks aynı zamanda model serving, experiment tracking ve veri governance modüllerini tek platformda birleştirir; bu yüzden bazı analistler onu “feature store değil, ML platformu” olarak konumlar. Avrupa veri yerleşim (data residency) gereksinimleri olan bankalar için on-prem deploy seçeneği popülerdir. Data lakehouse mimarisini benimseyen kurumlar için Hudi entegrasyonu doğal bir uzantıdır.
Performans Karşılaştırması: Latency, Throughput ve Maliyet
Aşağıdaki rakamlar üç vendor’ın 2024-2025 public benchmark’larından, bağımsız topluluk testlerinden ve uygulamalı projelerden derlenmiş tahmini değerlerdir. Gerçek rakam payload boyutu, network round-trip, cluster büyüklüğü, batch boyutu ve cache durumuna göre ±%30 oynar.
| Metrik | Feast (Redis) | Tecton (DynamoDB) | Hopsworks (RonDB) |
|---|---|---|---|
| p50 online latency (single key) | ~1-3 ms | ~2-4 ms | ~1-2 ms |
| p99 online latency | ~10-15 ms | ~8-15 ms | ~3-7 ms |
| Throughput (single node) | ~10K-30K rps | Auto-scale (DynamoDB capacity) | ~100K-300K rps |
| Batch retrieval (1M satır) | ~2-5 dk (Spark on EMR) | ~1-3 dk (managed) | ~1-4 dk (Hudi + Spark) |
| Streaming end-to-end | 10-60 sn (DIY) | 1-10 sn (yönetilen) | 2-15 sn (Flink) |
| Tipik aylık altyapı (orta yük) | ~600-1.500 USD | ~5.000-15.000 USD | ~3.000-8.000 USD |
| Vendor lock-in riski | Düşük (OSS) | Yüksek (proprietary control plane) | Orta (kendi data formatlarınız taşınabilir) |
Burada “orta yük” tanımı yaklaşık şudur: 200 feature view, 50 milyon entity, online tarafa saniyede 2.000 lookup, batch tarafına günde 5 milyar olay materializasyonu.
Veri Modelleme: Entity, Feature View ve Servis Tasarımı
Üç araçta da temel kavramlar benzerdir, ama tasarım disiplini farklılaşır. İyi bir feature store implementasyonu için aşağıdaki kontrol listesi önerilir:
- Entity netliği: user, session, transaction, organization gibi her birinci anahtar tek tanımla yönetilsin. Aynı user_id’yi 5 farklı tipte taşımayın.
- TTL doğruluğu: 30d window’lu bir feature için TTL minimum 30 gün olmalı, yoksa point-in-time join’de NaN üretir.
- Naming convention:
{entity}_{aggregation}_{window}_{unit}örnekleuser_avg_basket_30d_eur. - Versiyonlama: Feature view tanımı değişirse yeni versiyon yaratın; eski tanımı arkadan deprecate edin.
- Backfill stratejisi: Önce küçük örneklemde validate edin, sonra full backfill — Tecton/Hopsworks bunu UI’dan yönetir, Feast’te Airflow/Prefect orkestrasyonu lazımdır.
- Veri kalitesi: Feature üretimi sonrası null oranı, dağılım drift’i ve cardinality alarmları tanımlayın; veri kalitesi araçları (Great Expectations, Soda) doğal entegrasyon noktalarıdır.
- Feature store + vector store sınırı: Embedding’ler >100 boyutsa vector veritabanına ayırın; structured numeric/categorical feature’ları feature store’da tutun. Hibrit kurulum standart hale geliyor.
Ömer Önal danışmanlığında yürüttüğümüz orta ölçekli e-ticaret projelerinde, doğru entity granülaritesi seçildiğinde feature view sayısının %40 azaldığı ve bakım yükünün belirgin biçimde düştüğü gözlenmiştir.
Streaming Feature Üretimi: Gerçek Zamanlı Karar Sistemleri
Fraud detection, dynamic pricing, real-time recommendation gibi uygulamalar saniyeler içinde güncellenen feature’lar gerektirir. Üç araç da streaming destekler ama olgunluk farklı:
| Yetenek | Feast | Tecton | Hopsworks |
|---|---|---|---|
| Native stream feature view | Push API (manuel pipeline) | Yerleşik (@stream_feature_view) | Yerleşik (Spark Streaming/Flink) |
| Tipik freshness (event → online) | 15-90 sn (DIY) | 1-10 sn | 2-15 sn |
| Aggregation engine | Spark/Flink kendi yazılır | Tecton-managed Spark + custom DSL | Spark + Flink |
| Late-arriving event handling | Manuel | Watermark + auto-correction | Watermark + Hudi upsert |
| Stateful aggregation maliyeti | Spark cluster bedeli | Vendor billing içinde | RonDB + Spark karışık |
Streaming özellikle fraud kullanım durumunda belirleyicidir; ödeme risk raporları, dolandırıcılık tespitinde 30 saniyenin altında karar veren modellerin loss rate’i %20-35 düşürdüğünü belgeliyor. Feast ile bu freshness’i yakalamak Kafka + Flink + custom push işçiliği ister; Tecton out-of-the-box çözer ama bedeli aylık 5-15 bin USD’den başlar.
Yönetişim, Güvenlik ve Uyum
Bankacılık, sağlık ve telekomda feature store seçimi sadece teknik değil hukuki bir karardır. KVKK, GDPR ve sektör regülasyonları feature lineage, retention, silme hakkı (right to be forgotten) ve tahmin gerekçelendirmesi (model explainability) için somut belge ister. Aşağıdaki tablo üç aracın 2026 itibarıyla uyum kabiliyetini özetler:
| Yetenek | Feast | Tecton | Hopsworks |
|---|---|---|---|
| RBAC / ABAC | Manuel (Keycloak/OPA entegrasyonu) | Yerleşik fine-grained | Yerleşik (project-based) |
| Audit log | Custom logger | Otomatik, immutable | Otomatik, exportable |
| SOC 2 Type II | Yok (sizin mesuliyetiniz) | Var | Var |
| HIPAA-eligible | Yok | Var (Enterprise+) | Var (on-prem deploy) |
| EU data residency | Self-host | EU region var | EU şirketi, on-prem opsiyon |
| PII masking | Manuel | Tag-based otomatik | Tag-based otomatik |
Genel veri yönetişimi ve GDPR/KVKK katalog stratejiniz feature store seçiminden bağımsız oluşturulmalı; ardından seçilen platformun lineage API’si ile entegre edilmelidir. Atlan, Collibra veya Apache Atlas gibi katalogların üçü de OpenLineage event’lerini tüketebilir.
MLOps Akışına Entegrasyon: CI/CD ve Model Registry
Feature store yalıtık bir bileşen değildir; üç entegrasyon noktası vardır:
- Eğitim pipeline: Airflow/Prefect/Dagster DAG’ı feature view’leri günceller, sonra training job
get_historical_featuresile dataset üretir. - Model registry: MLflow, Vertex AI Model Registry veya SageMaker Model Registry; deploy edilen modelin hangi feature service versiyonunu kullandığını metadata’ya yazar.
- Inference servisi: KServe, BentoML, NVIDIA Triton veya custom FastAPI; feature server’a gRPC çağrısı atar, dönen vektörü modele besler.
İdeal bir CI/CD akışında her feature view tanımı pull request olarak gelir, otomatik test (schema check, sample backfill, latency smoke test) çalışır, merge sonrası feast apply veya tecton apply registry’yi günceller. Feast topluluğunda yaygın bir yöntem feast plan komutuyla terraform-benzeri diff göstermektir. Modern dbt tabanlı analytics engineering akışları feature store’a girdi sağlayan upstream tabloları yönetmek için ideal bir paradigmadır; dbt model çıktıları Feast offline source olabilir.
Pratik Karar Çerçevesi: Hangi Senaryoda Hangisi?
İki yıllık alan deneyimimiz ve raporlarda toplanan vaka çalışmaları üzerinden basit bir karar matrisi:
| Senaryo | Önerilen | Gerekçe |
|---|---|---|
| Startup, <5 ML mühendisi, AWS/GCP zaten var | Feast | Düşük TCO, hızlı PoC, lock-in yok |
| Orta-büyük kurum, fraud/recommendation kritik | Tecton | Streaming + SLA + uyum sertifikaları |
| Avrupa banka, on-prem zorunlu, vector + classical | Hopsworks | EU vendor, on-prem, RonDB throughput |
| Akademik araştırma / Kaggle takımı | Feast | OSS, dokümantasyon zengin, community Slack |
| Çoklu cloud, vendor neutrality politik şart | Feast veya Hopsworks | Tecton tek control plane’e bağlar |
| 500+ feature view, 10+ ekip, governance ağır | Tecton veya Hopsworks | Yerleşik RBAC, lineage, audit |
| Embedding-yoğun RAG sistemi | Hopsworks (vector dahil) veya Feast + ayrı vector DB | Hopsworks tek platformda birleştirir |
Veri pipeline’larınız Spark + Kafka pipeline’ı üzerine kuruluysa, Feast ve Hopsworks doğal entegre olur; Tecton da Spark cluster’ınızı kullanabilir ama kendi job runner’ını tercih eder.
Sıkça Sorulan Sorular
Feature store ile veri ambarı arasındaki fark nedir?
Veri ambarı (Snowflake, BigQuery) genel analitik için optimize edilmiştir; saniyede binlerce ML inference çağrısına 1-5 ms latency ile yanıt vermez. Feature store offline depoda ambarı kullanabilir ama online tarafta key-value store ile çalışır ve point-in-time correct join, TTL, feature service gibi ML’e özgü kavramlar sunar.
Feast yeterince enterprise mi, yoksa Tecton şart mı?
Mühendis-yoğun ekibi olan, Kubernetes ve Spark’ı zaten yöneten kurumlar için Feast ölçeklenir. SLA garantisi, sertifika (SOC 2, HIPAA), built-in stream feature view ve white-glove destek istiyorsanız Tecton daha hızlı time-to-production sağlar. Karar büyük ölçüde ekibin DevOps kapasitesi ve regülasyon yüküyle ilgilidir.
Hopsworks neden RonDB kullanıyor?
Çok sayıda feature içeren satırların düşük p99 latency ile okunması Redis’in tek-thread mimarisini zorlar. RonDB (NDB Cluster fork’u) shared-nothing dağıtık in-memory veritabanıdır ve geniş satırlarda 2-7 ms p99 hedefini tutarken yatay ölçeklenir. Ayrıca ACID transaction desteği multi-feature update’leri tutarlı kılar.
Feature store olmadan üretime ML çıkarılabilir mi?
Çıkarılır, küçük ölçekte yaygındır da. Fakat 5+ model, 3+ ekip ve günde milyon ölçekte tahmin yapan kurumlarda training-serving skew, feature kopyalanması ve lineage eksikliği teknik borcu hızla katlar. Feature store olmaksızın ölçeklenmiş ML üretimi tipik olarak 12-18 ay içinde ya kendi feature store’unu yazar ya da hazır bir çözüme geçer.
Bir feature store başka bir feature store’a göç ederken nelere dikkat etmeli?
Önce feature view tanımlarını platform-bağımsız bir IaC formatında (YAML + Python) toplayın; sonra entity ve TTL semantiğini hedef platforma map edin. En kritik adım offline veri formatının dönüştürülmesidir (Parquet → Hudi gibi). Online store’u sıfırdan materialize etmek genellikle 1-3 günlük backfill ile çözülür. Geçiş sırasında dual-write fazını 2-4 hafta tutmak production riskini azaltır.
Sonuç
2026 itibarıyla feature store sorusu artık “kullanmalı mıyız” değil “hangisini, nasıl yönetiriz” sorusudur. Feast mühendislik kasını rahatça kıvıran ekipler için en düşük TCO ve maksimum esneklik sunar; Tecton uçtan uca yönetilen, regülasyonlu sektörlerde hızla üretime çıkmak isteyen kurumlar için tasarlanmış SLA ağırlıklı bir platformdur; Hopsworks Avrupa veri yerleşim ve on-prem ihtiyacı olan, geniş feature satırları ile çalışan ML-yoğun organizasyonlar için RonDB tabanlı throughput avantajı sağlar.
Karar kriterleri sırasıyla şu sorularla netleştirilebilir: streaming şart mı, regülasyon hangi sertifikaları zorunlu kılıyor, bütçe altyapı maliyeti mi yoksa vendor lisansı mı, ekibin DevOps olgunluğu hangi seviyede, vector store ile birleşik bir platform isteniyor mu? Bu beş soru genellikle üç adaydan ikisini eler ve net bir kazanan bırakır.
Türkiye’de finans, e-ticaret ve telekom sektörlerinde feature store benimsenmesi 2024-2025 döneminde hızlandı; pratikte gözlemlediğimiz başarılı kurulumların ortak özelliği, mimari kararı bir vendor seçimine değil bir ürün-veri-MLOps üçgeninin uyumuna bağlamak oldu. Kuruluşunuzun ML olgunluğunu, regülasyon yükünü ve ekip kapasitesini birlikte değerlendiren bir mimari değerlendirme için iletişim sayfası üzerinden ulaşabilir, kurumunuza özel bir yol haritası talep edebilirsiniz.
Ömer ÖNAL
Mayıs 16, 2026Veri mühendisliği projelerinde sıkça gördüğüm darboğaz: pipeline mimarisine yatırım yapmadan önce veri kalitesi metriklerinin baseline’ı yok. Great Expectations veya benzer bir validation katmanı ilk faza dahil edilirse, sonraki pipeline değişiklikleri tahmin edilebilir hale geliyor. Yorumlarınız ne yönde?