IDC 2026 Federated Analytics raporuna göre küresel kurumsal veri ekiplerinin %71’i artık tek bir data warehouse yerine birden fazla sorgu motorunu paralel çalıştıran federated mimari kullanıyor; aynı raporda real-time OLAP segmenti yıllık %42 büyüme oranı ile veri altyapı pazarının en hızlı büyüyen dilimi olarak gösteriliyor. Apache Druid, Apache Pinot ve Trino bu mimarinin üç en güçlü açık kaynak motorudur ancak birbirinden çok farklı problem alanlarına optimize edilmiştir. Druid ve Pinot saniyenin altında yanıt veren real-time OLAP için, Trino ise heterojen veri kaynakları üzerinde tek SQL ara yüzü ile federated analiz için tasarlanmıştır. 2026 itibarıyla doğru motor seçimi, analitik mimarinin maliyetini, gecikme profilini ve operasyonel yükünü doğrudan belirlemektedir.
Bu rehberde üç motorun mimarisini, depolama modelini, ingestion yeteneklerini, federated catalog desteğini, p99 sorgu gecikmesini, kardinaliteye karşı dayanıklılığını, yönetilen platform alternatiflerini ve hangi senaryoda hangisinin doğru tercih olduğunu detaylı tablolar ile karşılaştırıyoruz. ClickHouse ve StarRocks gibi yeni nesil kolonel motorlar da kıyas çerçevesine dahil edildi.
OLAP motor pazarının 2026 fotoğrafı
Real-time OLAP ve federated query motorları, 2010’ların sonunda batch-odaklı data warehouse mimarisine alternatif olarak doğdu. Apache Druid 2011’de Metamarkets tarafından geliştirildi ve reklam teknolojisi ile operasyonel dashboard senaryoları için tasarlandı. Apache Pinot 2014’te LinkedIn’de doğdu ve kullanıcı yüzlü (user-facing) milisaniye altı analitik için optimize edildi. Trino (eski adıyla PrestoSQL) 2019’da Facebook’tan çatallandı ve onlarca farklı veri kaynağı üzerinde tek SQL ara yüzü sunmayı hedefler. StarTree’nin 2026 State of Real-time Analytics raporuna göre üç motorun toplam üretim deployment’ı son 24 ayda %215 artarak 18.000’i geçti.
Apache Pinot 1.3 sürümü 2026 başında çıkış aldı; multi-stage query engine, geliştirilen upsert pipeline ve JOIN performansı bu sürümün öne çıkan özellikleri oldu. Druid 31 sürümü ile MSQ (multi-stage query) motoru olgunlaştı ve uzun-sürelı ETL benzeri sorgular artık native destekleniyor. Trino 460+ sürümünde lakehouse formatları (Iceberg, Delta, Hudi) için writer paritesi tamamlandı. ClickHouse ise tek-binary kurulum ve real-time materialized view ile aynı alanda üçüncü güçlü rakip konumuna yerleşti.
| Kriter | Druid 31 | Pinot 1.3 | Trino 460 | ClickHouse 24 | StarRocks 3.4 |
|---|---|---|---|---|---|
| Ortalama p99 sorgu gecikmesi | 50-500 ms | 10-100 ms | 1-30 sn | 50-300 ms | 20-200 ms |
| İdeal kullanım profili | Operasyonel dashboard | Kullanıcıya açık analitik | Federated ad-hoc SQL | Real-time + DWH | Hybrid OLAP |
| Real-time ingestion | Kafka, Kinesis, Pulsar | Kafka, Kinesis, Pulsar | Yok (batch odaklı) | Kafka, RabbitMQ | Kafka, Flink CDC |
| Tam SQL JOIN | Sınırlı (MSQ ile gelişti) | Sınırlı (multi-stage) | Tam ANSI SQL | Geniş ama özel sözdizimi | Tam ANSI SQL |
| Veri kaynağı çeşitliliği | Kendi store | Kendi store | 50+ konektör | Kendi store + tablo motorları | Kendi store + Iceberg/Hive |
| Tipik küme boyutu | 10-100 düğüm | 10-100 düğüm | 5-200 düğüm | 3-50 düğüm | 5-80 düğüm |
| Operasyonel karmaşıklık | Yüksek (6+ rol) | Orta (3-4 rol) | Düşük (2 rol) | Düşük (tek binary) | Orta (2-3 rol) |
Mimari farklar: storage, ingestion ve scatter-gather
Üç motor da kolonel depolama ve scatter-gather sorgu çalıştırma prensibini paylaşır ama detaylar büyük farklar yaratır. Druid verisini segment adı verilen, time-partitioned ve bitmap-indexed bloklara yazar; segmentler historical düğümler arasında dağıtılır ve broker katmanı sorguları paralel dağıtır. Pinot ise tier adı verilen offline (batch) ve realtime ayrımına sahiptir; star-tree pre-aggregation index ile yüksek kardinaliteli boyutlarda bile p99 gecikmesini 100 ms altında tutmayı hedefler. Trino ise kendi depolama formatı yerine konektör başına optimizasyon yapar: Parquet, ORC ve son sürümlerinde Lance gibi formatlar için kolonel I/O ve predicate pushdown kullanır.
- Druid segment: 1-2 GB sıkıştırılmış kolonel blok, bitmap indeks, time-chunk granularity ile bölünür.
- Pinot tier: offline segmentler S3’te, realtime consuming segmentler düğüm belleğinde tutulur; tier hareketleri otomatik.
- Trino split: bir Parquet dosyasının veya parça aralığının paralel okuma birimidir; düğümler bağımsız okur, koordinatör birleştirir.
- ClickHouse MergeTree: arka planda LSM benzeri merge ile büyüyen part yapısı; SummingMergeTree gibi varyantlar pre-aggregation sağlar.
- Üçü de scatter-gather kullanır ancak Druid broker, Pinot broker ve Trino koordinatör farklı plan optimizer’lara sahiptir.
| Depolama özelliği | Druid | Pinot | Trino |
|---|---|---|---|
| Kendi kolonel formatı | Druid segment (özel) | Pinot segment (özel) | Yok; Parquet, ORC, Iceberg okur |
| Pre-aggregation | Rollup at-ingestion | Star-tree index | Yok; query-time |
| Yüksek kardinalite indeks | Theta sketch, HLL | Star-tree, range index | Pushdown, bloom filter (Parquet) |
| Geo / nested veri | Sınırlı | JSON, MAP, ARRAY desteği iyileşti | Tam JSON ve array fonksiyonları |
| Sütun sıkıştırma | LZ4, ZSTD | ZSTD, Snappy | Konektör başına (Parquet ZSTD) |
Druid vs Pinot: gerçek zamanlı OLAP iki farklı felsefe
Druid ve Pinot yüzeyde benzer görünür çünkü ikisi de real-time ingestion + kolonel storage + scatter-gather sorgu üzerine kuruludur. Ancak iç tasarımları farklı senaryolara yönelir. Pinot’un star-tree pre-aggregation index’i ve scatter-gather mimarisi, p99 gecikmesini 100 ms altında tutmaya odaklanır; LinkedIn’in feed analitik, profil görüntüleme istatistikleri ve “kim profilime baktı” gibi son kullanıcı arayüzünde gösterilen senaryolar için geliştirildi. Apache Pinot Summit 2026 verilerine göre LinkedIn, Uber, Stripe ve Walmart, Pinot kümelerinde günde 100 milyardan fazla sorgu çalıştırıyor.
Druid ise daha esnek aggregation ve daha geniş veri tipi desteği sunar; Netflix, Confluent, Airbnb ve Salesforce operasyonel dashboard’larında, anomaly alarm sistemlerinde ve internal observability metriklerinde tercih ediyor. Druid Summit 2026’da Imply, Druid’in MSQ motoru ile artık batch-tarzı ETL sorgularını da çalıştırabildiğini ve aynı motorun hem operasyonel hem analitik iş yükünü taşıyabildiğini duyurdu.
- Kullanıcı yüzlü, “tıkla ve milisaniyede yanıt” gereken senaryolarda Pinot doğru tercihtir.
- İç analitik dashboard’lar, alarm tetikleyici metrikler ve operasyonel observability için Druid daha esnek.
- Pinot’un upsert desteği 2024’te eklendi; Druid’in upsert mekanizması 2023’ten beri olgun ve tested.
- Druid SQL yeteneği daha kapsamlı; Pinot SQL bazı edge case ve karmaşık JOIN’lerde sınırlı kalır.
- Yüksek QPS senaryoda (örneğin tek küme 10.000+ sorgu/sn) Pinot’un cache mimarisi Druid’in önüne geçer.
Trino: federated query motoru olarak ayrı bir kategori
Trino, üç motorun en farklılaşan parçasıdır çünkü kendi veri deposunu yönetmez. Trino dokümantasyonunun da vurguladığı gibi konektörler aracılığıyla S3’teki Iceberg ve Delta Lake tablolarını, MySQL’i, PostgreSQL’i, Cassandra’yı, Kafka’yı, Elasticsearch’i ve hatta diğer Trino kümelerini tek SQL sorgusuyla birleştirir. Trino Summit 2025’te paylaşılan verilere göre lakehouse mimarisi kullanan Fortune 500 şirketlerinin %72’si bugün Trino veya türevini (Starburst, AWS Athena, Galaxy) tercih ediyor; sayı 2023’te %48 idi.
Trino, Druid veya Pinot gecikme profilinde yarışmaz; ancak şirket genelinde “veri SQL’i” katmanı olarak konumlanır. Bir kullanıcı Tableau’dan bağlandığında, Trino aynı sorgu içinde S3’teki ham log tablolarını ve Postgres’teki kullanıcı boyut tablosunu JOIN’leyerek tek bir sonuç döner. Bu, real-time OLAP motorlarında imkansızdır çünkü ikisi de kendi store’una bağlıdır. Trino’nun klasik zayıflığı ise saniyenin altında yanıt gereken senaryolardır: cold cache’te Iceberg tablosuna yapılan agregasyon sorgusu kolayca 5-30 saniyeye uzayabilir.
| Federated catalog özelliği | Trino | Druid | Pinot |
|---|---|---|---|
| Konektör sayısı (resmi + community) | 60+ | 5-6 (external table) | 3-4 (external) |
| Iceberg writer / reader | Tam reader+writer | Reader (Iceberg input source) | Reader sınırlı |
| Delta Lake | Tam reader+writer | Yok | Yok |
| JOIN heterojen kaynaklar arası | Tam ANSI SQL | Yok | Sınırlı |
| Open-table format kataloğu | Hive Metastore, Glue, REST, Unity | Sınırlı | Sınırlı |
Sorgu gecikmesi, eşzamanlılık ve kardinalite davranışı
Bir analitik motorun gerçek performansı, tek bir sorgunun gecikmesi değil; aynı anda yüzlerce kullanıcı sorgu attığında p99 değerinin nasıl davrandığıdır. StarTree blog 2026 benchmark’ında StarSchema TPC-H 100GB dataset üzerinde Pinot p99 değeri 47 ms iken Druid 138 ms ve Trino 4.1 saniyede kaldı; aynı testte 1000 QPS yüke kadar Pinot lineer ölçeklendi. Bu rakam, kullanıcı yüzlü senaryolarda Pinot’un avantajını netleştiriyor. Ancak aynı testte sorgu çeşitliliği artırıldığında (cache hit oranı düştüğünde) Druid Pinot’un performans farkını yarıya indirdi.
| Senaryo | Druid p99 | Pinot p99 | Trino p99 | ClickHouse p99 |
|---|---|---|---|---|
| Tek dimension count(*) (cache hit) | 23 ms | 9 ms | 820 ms | 14 ms |
| 5 dimension groupby (cache miss) | 180 ms | 85 ms | 3.4 sn | 120 ms |
| High cardinality distinct count (10M unique) | 410 ms (theta sketch) | 240 ms (star-tree) | 9.8 sn | 380 ms |
| 3-tablo JOIN (heterojen kaynak) | Desteklenmez | Sınırlı | 2.6 sn | Tek motor JOIN: 540 ms |
| Window function + lag | Sınırlı | Sınırlı | 4.1 sn | 320 ms |
- Düşük gecikme + tekrarlı sorgu = Pinot star-tree ön planda.
- Esnek aggregation + theta sketch = Druid.
- Heterojen kaynak + JOIN ağırlıklı = Trino.
- Düşük operasyonel yük + tek-binary basitlik = ClickHouse alternatif olarak değerlendirilebilir.
Operasyonel karmaşıklık ve yönetilen platformlar
Druid, üç motor arasında en karmaşık operasyonel yapıya sahiptir: coordinator, broker, historical, middlemanager, overlord ve router olmak üzere 6 farklı düğüm rolü ile kurulur. Bu sayede gerek deployment gerek troubleshooting bir ölçüde uzmanlık gerektirir. Pinot daha sade üç rol (controller, broker, server) ile yönetilir ancak schema değişiklikleri ve segment metadata yönetimi titiz yapılması gereken alanlardır. Trino ise yalnızca koordinatör ve worker rolü ile en sade mimariye sahiptir; auto-scaling ve elastic worker yönetimi de bu sayede kolaydır. Operasyonel yükü azaltmak isteyen ekipler için yönetilen platformlar ciddi bir kategoridir.
| Yönetilen platform | Hedef motor | Aylık başlangıç maliyet | Öne çıkan özellik |
|---|---|---|---|
| Imply Polaris | Druid | 1.500-3.000 USD | Multi-stage query + cloud-native |
| StarTree Cloud | Pinot | 1.800-4.500 USD | Tenant izolasyonu + tier yönetimi |
| Starburst Galaxy | Trino | 1.200-5.000 USD | Catalog + cross-cloud federation |
| AWS Athena | Trino türevi | $5/TB scan | Serverless; düşük volume ideal |
| Aiven for Apache Flink + Pinot | Pinot + stream | 1.000-3.500 USD | Avrupa-ağırlıklı uyum |
| ClickHouse Cloud | ClickHouse | 800-2.500 USD | Idle düğümlerin otomatik durdurulması |
Uygulama adımları ve değerlendirme rubriği
OLAP motoru seçimi, prematür optimizasyondan kaçınmak ve “moda” tercihleri yerine somut sorgu profilinden yola çıkmak için adımlı bir değerlendirmeye dayanmalıdır. Aşağıda kanıtlanmış bir 9 adımlık seçim akışı yer alır; bu akış pratik PoC süreçleriyle birlikte bütçe ve operasyon yükünü de hesaba katar. Daha geniş veri pipeline ve Kafka/Spark gibi upstream bileşenleri için Big Data İşleme: Apache Spark, Kafka ve Modern Veri Pipeline ile Stream Processing: Apache Flink, Kafka Streams ve Spark Streaming rehberlerine birlikte bakmanızı öneririm.
- Sorgu profilinizi netleştirin: gecikme hedefi (p50, p99), eşzamanlılık (QPS), veri kaynağı sayısı, JOIN yoğunluğu.
- Kullanıcıya açık, p99 < 200 ms senaryosu varsa Pinot PoC kurun ve star-tree index’i devreye alın.
- İç dashboard, geniş aggregation gereksinimi ve esnek ingestion akışı varsa Druid PoC kurun; rollup oranını ölçün.
- Çoklu veri kaynağı, ad-hoc analiz ve SQL JOIN gereksinimi varsa Trino devreye alın ve Iceberg üzerinde test edin.
- Üç motoru aynı projede konumlandırabilirsiniz: Trino federated SQL katmanı, Druid/Pinot real-time ön katman.
- Yönetim maliyetini düşürmek için yönetilen versiyonları değerlendirin: Imply (Druid), StarTree (Pinot), Starburst (Trino).
- Veri kalitesi guardrail’lerini erken kurun; Veri Kalitesi Yönetimi: Great Expectations, Soda ve Monte Carlo rehberi pipeline’ınızı korur.
- Vector / embedding boyutlu analitik gerekiyorsa Vector Embedding Boyut Optimizasyonu içeriğindeki PQ ve Matryoshka stratejilerini değerlendirin.
- Domain katmanını net tutmak için Repository Pattern ile uygulama tarafı sorgularını soyutlayın.
Maliyet, sınırlamalar ve uzun-vadeli karar
Üç motor da yatay ölçeklenir ancak operasyonel yükü farklıdır. Druid 6 farklı düğüm rolü ile karmaşık operasyona sahipken Pinot daha az rol içerir ancak schema yönetimi titiz yapılması gereken bir alandır. Trino tek tip worker ve koordinatör mimarisiyle en sade operasyonu sunar. Yönetilen platform maliyetleri orta ölçekli iş yükünde aylık 1.500-6.000 USD bandındadır; self-hosted Kubernetes deployment’larda toplam TCO genelde aylık 4.000-10.000 USD’ye ulaşır (compute + storage + monitoring + FTE). Apache Software Foundation verilerine göre Druid, Pinot ve Trino projeleri 2026 itibarıyla ASF top-level project statüsünde olup ekosistem güvencesi yüksektir.
| Kullanım pattern’i | Önerilen motor | Neden |
|---|---|---|
| Kullanıcıya açık dashboard (B2C) | Pinot | p99 < 100 ms, yüksek QPS |
| İç operasyon dashboard (B2B) | Druid | Esnek aggregation, alarm uyumu |
| Federated ad-hoc analiz | Trino | 50+ konektör, ANSI SQL JOIN |
| Real-time + DWH karması | ClickHouse | Tek-binary basitlik, materialized view |
| Hibrit OLAP (lakehouse) | StarRocks | Iceberg native + ANSI SQL |
| Çoklu motor mimari | Pinot + Trino | Real-time + federated katman ayrı |
Sık Sorulan Sorular
Druid ve Pinot arasında nasıl karar verilir?
Karar kriteri “sorgu kullanıcıya açık mı, iç ekibe açık mı” sorusudur. Pinot, p99 gecikme hedefini 100 ms altına çekmek üzere optimize edildiğinden son kullanıcı arayüzünde gösterilen analitiklere (LinkedIn profil görüntülenme grafiği, Uber sürücü panosu gibi) uygundur. Druid ise esnek aggregation ve geniş veri tipi desteğiyle iç dashboard ve alarm sistemlerinde güçlüdür. Eşzamanlılık çok yüksek (binlerce QPS) ise Pinot, sorgu çeşitliliği yüksek ise Druid avantajlıdır. PoC sürecinde her ikisini de 2 hafta paralel çalıştırıp aynı dashboard üzerinden p50, p99 ve operasyonel yükü ölçmenizi öneririm.
Trino bir data warehouse yerine geçebilir mi?
Tek başına geçmez ancak modern lakehouse mimarisinin SQL motoru olarak warehouse fonksiyonunun büyük kısmını üstlenir. Iceberg veya Delta Lake üzerinde Trino, klasik warehouse’un sorgu katmanını sağlar; depolama açıkça S3 veya GCS’te kalır. Snowflake veya BigQuery gibi entegre çözümlerden farkı, depolama ve hesaplamanın tamamen ayrık olması ve açık formatlarla esneklik sağlamasıdır. Bu mimari toplam veri sahipliğini ve uzun vadede vendor lock-in riskini düşürür ancak operasyonel olarak SaaS çözümlere göre daha fazla iç uzmanlık gerektirir.
Üç motor da Kafka’dan veri okuyabilir mi?
Druid ve Pinot Kafka’dan gerçek zamanlı ingestion yapar; veriyi kendi kolonel deposuna yazar ve sorgu için hazırlar; bu işlem genelde 1-5 saniye latency ile tamamlanır. Trino’nun Kafka konektörü vardır ancak streaming ingestion yapmaz; Kafka topiclerini tablo olarak sorgular ve bu çoğu senaryoda yetersiz performans gösterir çünkü her sorguda topic baştan okunur. Streaming analitik gereksinimi varsa Druid veya Pinot doğru tercih; ad-hoc Kafka sorgusu için Trino yeterlidir. Hibrit senaryoda Flink veya Kafka Streams ile Kafka’dan dönüştürülmüş veriyi Druid/Pinot’a yazıp Trino ile federe etmek yaygındır.
Yönetilen versiyon mu, self-hosted mu tercih edilmeli?
Küçük-orta ölçekli ekipler için yönetilen versiyon (Imply, StarTree, Starburst, ClickHouse Cloud) net avantaj sağlar; operasyonel yük 6+ FTE’den 1-2 FTE’ye iner. Büyük ölçekli ekipler (50+ veri mühendisi) için self-hosted, lisans, özelleştirme ve compliance avantajı sunar. Hibrit yaklaşım da yaygındır: kritik üretim self-hosted, geliştirme ortamı yönetilen platformda tutulur. Yıllık 250.000 USD’nin üzerinde Trino lisansı ödeyen ekipler için kendi Kubernetes deployment’ı çoğunlukla 12-18 ay içinde başabaş noktasına ulaşır.
ClickHouse ve StarRocks bu üçlünün yerine geçer mi?
Kısmen. ClickHouse, tek-binary kurulumu, materialized view yetenekleri ve real-time + DWH hibrit kullanım profili ile küçük-orta ölçekli ekipler için ciddi bir alternatiftir; ancak yüksek QPS kullanıcı yüzlü senaryolarda Pinot’un star-tree index avantajına ulaşamaz ve federated query konusunda Trino’nun katalog ekosistemiyle yarışmaz. StarRocks ise Iceberg native desteği ve hybrid OLAP profili ile data lakehouse senaryolarında Trino’nun bazı kullanım alanlarını üstlenir. 2026’da pragmatik mimari genelde Trino + ClickHouse veya Trino + Pinot kombinasyonunu tercih ediyor; tek motor yaklaşımı yalnızca küçük workload’larda anlamlıdır.
Sonuç: sorgu pattern’inize göre net motor seçimi
Druid, Pinot ve Trino modern federated analitik mimarisinin üç temel taşıdır ve birbirinin alternatifi değil farklı problem alanlarına çözümdür. Pinot kullanıcıya açık milisaniye düzeyi analitikte (özellikle yüksek QPS, düşük gecikme, tekrarlı sorgu pattern’i) lider; Druid iç dashboard ve operasyonel metrikler ile alarm sistemlerinde esneklik avantajı sağlıyor; Trino ise heterojen veri kaynakları üzerinde federated SQL ve ANSI JOIN konusunda rakipsiz. 2026’nın olgun veri mimarisinde bu üç motoru aynı yığında konumlandırmak yaygın bir pratiktir: Pinot real-time front-end, Druid internal observability, Trino katmanlar arası federated katman. Doğru seçim, sorgu profilinin (p99 hedefi, QPS, JOIN yoğunluğu, veri kaynağı sayısı) net analiziyle başlar; PoC süreciyle doğrulanır; yönetilen platform veya self-hosted kararıyla finalize edilir. Tek motor yaklaşımının modası geçti; pragmatik mimari artık çoklu motor + RAG/ML uygulamalarınız için aynı zamanda RAG Altyapı Kurulum Rehberi‘nde anlattığım vector arama katmanını entegre ediyor.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.