Google BigQuery ve Amazon Redshift, 2026 yılında bulut veri ambarı pazarına hakim konumda olup, veri analitiği iş yükleri için farklı avantajlar sunmaktadır. Bu karşılaştırma, mimari farklılıkları, fiyatlandırma modellerini, performans özelliklerini ve veri analisti adaylarının sıklıkla karşılaştığı mülakat sorularını kapsamaktadır.

Hızlı Karar Rehberi

Sunucusuz basitlik, sorgu başına ödeme fiyatlandırması ve sıkı GCP entegrasyonu için BigQuery tercih edilmelidir. Ölçekte öngörülebilir maliyetler, karmaşık ETL pipeline'ları ve derin AWS ekosistem entegrasyonu için Redshift tercih edilmelidir.

BigQuery ve Redshift Arasındaki Mimari Farklılıklar

BigQuery, depolama ve hesaplamanın tamamen ayrıldığı sunucusuz, çok kiracılı bir mimari kullanmaktadır. Sorgular, herhangi bir küme yönetimi olmaksızın dinamik olarak tahsis edilen kaynaklar üzerinde çalışmaktadır. Google, tüm altyapı ölçeklendirmesini, yama işlemlerini ve optimizasyonu otomatik olarak yönetmektedir.

Redshift, ayrılmış düğümlerle sağlanan bir küme modeli üzerinde çalışmaktadır. Depolama ve hesaplama düğümler içinde sıkıca bağlıdır, ancak Redshift Serverless artık tüketime dayalı bir alternatif sunmaktadır. RA3 düğüm türü, hesaplama ve depolamanın bağımsız ölçeklendirmesine olanak tanıyan yönetilen depolama ayrımını getirmiştir.

| Özellik | BigQuery | Redshift | |---------|----------|----------| | Dağıtım | Tamamen sunucusuz | Sağlanan kümeler veya Serverless | | Depolama-Hesaplama | Tamamen ayrık | Bağlı (RA3 yönetilen depolamayı ayırır) | | Ölçeklendirme | Otomatik | Manuel yeniden boyutlandırma veya Concurrency Scaling | | Bakım | Sıfır | Bakım pencereleri gerekli | | Soğuk Başlatma | Yok | Duraklatılmış ise küme yeniden başlatma süresi |

Bu mimari fark, operasyonel yükü önemli ölçüde etkiler. BigQuery kapasite planlaması gerektirmezken, Redshift sürekli küme boyutlandırma kararları ve bakım planlaması gerektirmektedir.

Fiyatlandırma Modelleri: Sorgu Başına Ödeme vs Sağlanan Kapasite

BigQuery, 2026 itibarıyla isteğe bağlı modda taranan TB başına 6,25 USD ücretlendirmektedir. Rezerve kapasite (sabit ücret) fiyatlandırması, tutarlı iş yükleri için öngörülebilir aylık maliyetler sunmaktadır. Depolama maliyeti aktif veriler için ayda 0,02 USD/GB ve 90 gün sonrası uzun vadeli depolama için ayda 0,01 USD/GB'tır.

sql

-- BigQuery: Sorgu maliyetini çalıştırmadan önce kontrol etme
SELECT
  total_bytes_billed / POW(10, 12) AS tb_billed,
  (total_bytes_billed / POW(10, 12)) * 6.25 AS estimated_cost_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE job_id = 'your-job-id';

Redshift fiyatlandırması düğüm türüne ve sayısına bağlıdır. DC2 düğümleri (yoğun hesaplama) saat başına 0,25 USD'den başlarken, yönetilen depolamalı RA3 düğümleri saat başına 1,086 USD'den başlamaktadır. Redshift Serverless, tüketilen Redshift İşleme Birimleri (RPU) bazında ücretlendirmektedir.

Maliyet optimizasyonu stratejileri önemli ölçüde farklılaşmaktadır. BigQuery, bölümleme ve kümeleme yoluyla sorgu optimizasyonunu ödüllendirmektedir çünkü daha az veri taramak doğrudan maliyetleri düşürmektedir. Redshift optimizasyonu, kümelerin doğru boyutlandırılmasına ve öngörülebilir iş yükleri için rezerve edilmiş örneklerin kullanılmasına odaklanmaktadır.

SQL Sözdizimi ve Fonksiyon Farklılıkları

Her iki platform da ANSI SQL desteklemektedir, ancak gelişmiş özellikler için sözdizimi farklılıkları mevcuttur. Bu farklılıkları anlamak, SQL mülakat soruları ve migrasyon projeleri için önemlidir.

sql

-- BigQuery: Tarih fonksiyonları EXTRACT ve DATE_TRUNC kullanır
SELECT
  DATE_TRUNC(order_date, MONTH) AS order_month,
  EXTRACT(DAYOFWEEK FROM order_date) AS day_of_week,
  COUNT(*) AS order_count
FROM `project.dataset.orders`
WHERE order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 1 YEAR)
GROUP BY 1, 2;

-- Redshift: Benzer ancak string argümanı ile DATE_TRUNC kullanır
SELECT
  DATE_TRUNC('month', order_date) AS order_month,
  EXTRACT(DOW FROM order_date) AS day_of_week,
  COUNT(*) AS order_count
FROM orders
WHERE order_date >= DATEADD(year, -1, CURRENT_DATE)
GROUP BY 1, 2;

Dizi ve struct işleme önemli farklılıklar göstermektedir. BigQuery, UNNEST işlemleriyle iç içe ve tekrarlanan alanları doğal olarak desteklemektedir. Redshift, son sürümlerde tanıtılan SUPER tipi ve PartiQL sözdizimi aracılığıyla yarı yapılandırılmış verileri işlemektedir.

sql

-- BigQuery: İç içe dizilerle çalışma
SELECT
  user_id,
  event.name AS event_name,
  event.timestamp AS event_time
FROM `analytics.events`,
UNNEST(events) AS event
WHERE DATE(event.timestamp) = CURRENT_DATE();

-- Redshift: PartiQL ile SUPER tipi
SELECT
  user_id,
  e.name AS event_name,
  e.timestamp AS event_time
FROM events_table AS t, t.events AS e
WHERE DATE(e.timestamp) = CURRENT_DATE;

Performans Özellikleri ve Sorgu Optimizasyonu

BigQuery, ayar gerektirmeden büyük veri setleri üzerinde ad-hoc analitik sorgularda üstün performans sergiler. Slot tabanlı yürütme modeli, işi otomatik olarak dağıtır. Performans, eşzamanlı kullanıcı sayısından bağımsız olarak tutarlı kalır çünkü her sorgu slot havuzundan ayrılmış kaynaklar alır.

Redshift, düzgün ayarlandığında öngörülebilir, tekrarlayan sorgular için üstün performans sunar. Dağıtım anahtarları, sıralama anahtarları ve materyal görünümler sorgu hızını önemli ölçüde etkiler. Sorgu planlayıcı, tablo istatistiklerine dayalı optimize edilmiş yürütme planları oluşturur.

sql

-- Redshift: Dağıtım ve sıralama anahtarlarını tanımlama
CREATE TABLE sales_fact (
  sale_id BIGINT,
  customer_id BIGINT,
  product_id BIGINT,
  sale_date DATE,
  amount DECIMAL(10, 2)
)
DISTKEY(customer_id)
SORTKEY(sale_date);

-- Redshift: Dashboard sorguları için materyal görünüm
CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT
  sale_date,
  COUNT(*) AS transaction_count,
  SUM(amount) AS total_revenue
FROM sales_fact
GROUP BY sale_date;

BigQuery optimizasyonu bölümleme ve kümelemeye dayanır. Bölümleme, tarih veya tamsayı aralığına göre taranan verileri azaltır. Kümeleme, daha hızlı filtrelenmiş sorgular için bölümler içindeki verileri sıralar.

sql

-- BigQuery: Bölümlenmiş ve kümelenmiş tablo
CREATE TABLE `project.dataset.sales_fact`
PARTITION BY DATE(sale_date)
CLUSTER BY customer_id, product_id
AS SELECT * FROM `project.dataset.raw_sales`;

İlgili konular için performans ayarlama stratejileri hakkında pencere fonksiyonları ve CTE rehberi gelişmiş sorgu optimizasyon tekniklerini kapsamaktadır.

Data Analytics mülakatlarında başarılı olmaya hazır mısın?

İnteraktif simülatörler, flashcards ve teknik testlerle pratik yap.

Data Analytics keşfet

Veri Yükleme ve ETL Entegrasyonu

BigQuery, GB başına 0,05 USD karşılığında gerçek zamanlı veriler için akış eklemeyi, Cloud Storage'dan ücretsiz toplu yüklemeyi ve Dataflow ile Pub/Sub için yerel bağlayıcıları desteklemektedir. BigQuery Data Transfer Service, SaaS uygulamalarından zamanlanmış içe aktarmaları otomatikleştirmektedir.

sql

-- BigQuery: Cloud Storage'dan veri yükleme
LOAD DATA INTO `project.dataset.events`
FROM FILES (
  format = 'PARQUET',
  uris = ['gs://bucket/events/*.parquet']
);

Redshift, küme düğümleri arasında veri yüklemeyi paralelize eden COPY komutu aracılığıyla S3 ile sıkı entegrasyon sağlar. AWS Glue yönetilen ETL sağlarken, Redshift Spectrum yüklemeden doğrudan S3 verilerini sorgular.

sql

-- Redshift: Optimal ayarlarla COPY komutu
COPY events
FROM 's3://bucket/events/'
IAM_ROLE 'arn:aws:iam::123456789:role/RedshiftS3Access'
FORMAT AS PARQUET
COMPUPDATE ON
STATUPDATE ON;

Her iki platform artık harici veri gölleri için Apache Iceberg tablo formatını desteklemektedir. BigQuery BigLake ve Redshift Spectrum, hem veri ambarı hem de veri gölü depolaması üzerinde birleşik analitik imkanı sağlamaktadır.

Mülakat Soruları: BigQuery vs Redshift Karşılaştırması

Veri analisti mülakatları sıklıkla bulut veri ambarı ödünleşimlerinin anlaşılmasını test etmektedir. Bu sorular, bulut platform uzmanlığı gerektiren rollerde karşılaşılmaktadır.

Soru 1: Redshift yerine BigQuery'yi ne zaman önerirsiniz?

Organizasyon altyapı yönetimi olmadan sunucusuz operasyona ihtiyaç duyduğunda, sorgu başına ödeme fiyatlandırması öngörülemeyen veya değişken iş yüklerine uygun olduğunda, veri platformu zaten GCP üzerinde çalışıyorsa veya ekipler küme sağlama gecikmeleri olmadan petabayt ölçekli verilerde anında sorgu sonuçlarına ihtiyaç duyduğunda BigQuery önerilmelidir.

Soru 2: BigQuery'de slot tahsisi nasıl çalışır?

BigQuery, sorgulara dinamik olarak slot (hesaplama kapasitesi birimleri) tahsis eder. İsteğe bağlı sorgular, proje başına 2.000 slotluk bir havuzu paylaşır. Her slot, Colossus'a (dağıtılmış depolama) akış erişimi olan yaklaşık bir sanal CPU'yu temsil eder. Daha fazla paralellik gerektiren karmaşık sorgular, kullanılabilir kapasite tükenene kadar orantılı olarak daha fazla slot alır.

Soru 3: Redshift dağıtım stillerini ve her birinin ne zaman kullanılacağını açıklayın.

Redshift dört dağıtım stili sunar:

KEY: Belirtilen sütunun hash'ine göre satırları dağıtır. Bu sütun üzerinde sıklıkla birleştirilen büyük fact tabloları için kullanılır.
EVEN: Satırları düğümler arasında round-robin dağıtır. Net birleştirme kalıpları olmayan tablolar için kullanılır.
ALL: Tüm tabloyu her düğüme kopyalar. Büyük fact'lerle birleştirilen küçük boyut tabloları için kullanılır.
AUTO: Redshift'in tablo boyutu ve sorgu kalıplarına göre seçmesine izin verir.

Soru 4: BigQuery'de sorgu maliyetlerini nasıl optimize edersiniz?

BigQuery maliyetleri, sık filtrelenen tarih sütunlarında tabloları bölümleyerek, yüksek kardinaliteli filtre sütunlarında kümeleyerek, SELECT * sorgularından kaçınarak, keşifsel analiz için yaklaşık toplama fonksiyonları (APPROX_COUNT_DISTINCT) kullanarak, tekrarlanan hesaplamalar için ara sonuçları materyalize ederek ve özel kotalarla maliyet kontrolleri kurarak optimize edilir.

Soru 5: Redshift performansı için hangi izleme araçları mevcuttur?

Redshift, performans izleme için sistem tabloları ve görünümleri sağlar: STL_QUERY sorgu yürütme detaylarını kaydeder, STL_WLM_QUERY iş yükü yönetimi istatistiklerini gösterir, SVL_QUERY_REPORT adım düzeyinde metrikleri görüntüler ve CloudWatch metrikleri küme düzeyinde sağlığı izler. Vacuum işlemleri gecikmişse veya tablo istatistikleri eskimişse sorgu performansı düşebilir.

Güvenlik ve Uyumluluk Yetenekleri

Her iki platform da sütun düzeyinde şifreleme, VPC izolasyonu ve denetim kaydını desteklemektedir. BigQuery, IAM ve sütun düzeyinde güvenlik politikaları aracılığıyla ayrıntılı erişim kontrolünü uygular. Veri maskeleme ve satır düzeyinde güvenlik, çok kiracılı mimarilere olanak tanır.

Redshift, IAM entegrasyonu, sütun düzeyinde erişim kontrolü ve dinamik veri maskeleme aracılığıyla benzer kontroller sunar. Bölgeler arası anlık görüntü replikasyonu, felaket kurtarma gereksinimlerini destekler.

Her iki platform da SOC 1/2/3, ISO 27001, HIPAA ve PCI DSS uyumluluk sertifikalarını sürdürmektedir. Çoğu kurumsal güvenlik gereksinimi için özellik paritesi mevcuttur; bu da seçimin güvenlik yeteneklerinden ziyade mevcut bulut sağlayıcı ilişkilerine bağlı olmasını sağlar.

Migrasyon Değerlendirmeleri ve Hibrit Yaklaşımlar

Platformlar arası migrasyon, SQL lehçe farklılıkları, veri tipi eşlemeleri ve ETL iş akışı yeniden yazımlarının ele alınmasını gerektirir. BigQuery Migration Service, Redshift iş yüklerini değerlendirir ve SQL çevirisini otomatikleştirir. AWS Database Migration Service ters yönü yönetir.

Birçok organizasyon, federe sorgu yetenekleri aracılığıyla her iki platformda sorgulama yapan hibrit stratejiler benimsemektedir. BigQuery Omni, AWS altyapısında çalışarak S3 verilerine karşı BigQuery SQL kullanımına olanak tanır. Redshift veri paylaşımı, AWS içinde hesaplar arası sorgu federasyonunu destekler.

Veri analitiği ekipleri giderek teknik üstünlükten ziyade mevcut bulut yatırımlarına dayalı seçim yapmaktadır. Her iki platform da tarihsel sınırlamaları ele alan özellikler eklemeye devam ederek fonksiyonel açığı daraltmaktadır.

Sonuç

BigQuery, sorgu başına faturalandırma ile sunucusuz basitliği ve değişken iş yüklerini önceliklendiren ekiplere uygundur
Redshift, sağlanan kapasitenin maliyet avantajı sağladığı öngörülebilir, yüksek hacimli sorgulara sahip organizasyonlara uygundur
SQL sözdizimi farklılıkları, migrasyon planlaması ve ekip eğitimi sırasında dikkat gerektirir
Performans optimizasyon yaklaşımları temelden farklıdır: BigQuery bölümleme ve kümelemeyi vurgular, Redshift dağıtım anahtarları ve sıralama anahtarları gerektirir
Mülakat soruları mimari ödünleşimler, maliyet optimizasyon stratejileri ve platforma özgü ayarlama tekniklerine odaklanır
Güvenlik ve uyumluluk yetenekleri karşılaştırılabilir düzeydedir; bulut ekosistem entegrasyonu genellikle platform seçimini belirler