HADOOP NEDİR?

Tek bir sunucuya sığmayan veri elinizde birikmeye başladığında ne yaparsınız? Disk ekleyip büyütmenin sınırına gelen, sorguları gece boyunca süren, yedekleme penceresi yetmeyen sistemler için yıllarca tek isim konuşuldu: Hadoop. Peki bugün hâlâ aynı cevap geçerli mi, yoksa Hadoop artık sadece kurumsal arşivlerde anılan bir kelime mi? Bu yazı; ne olduğunu, hangi gerçek problemi çözmek için doğduğunu, küçük şirketlerin buna gerçekten ihtiyacı olup olmadığını ve yerini almaya başlayan modern alternatifleri ayık bir gözle ele alıyor.

1. Hadoop Aslında Neyi Çözmek İçin Doğdu

2000'lerin başında Google, web ölçeğinde veriyi tek makineye sığdırmanın imkânsız olduğunu fark etti ve iki temel makale yayımladı: GFS (dağıtık dosya sistemi) ve MapReduce (dağıtık hesaplama modeli). Doug Cutting ve ekibi bu fikirleri açık kaynak olarak hayata geçirdi; ortaya Hadoop çıktı. Yani Hadoop bir veritabanı değil, ürün de değil — sıradan donanımdan oluşan kümeler üzerinde devasa veriyi saklayıp işlemeye yarayan bir çerçevedir.

Çözmeye çalıştığı asıl problem şu: Bir sunucunun diski 10 TB ise ve veriniz 500 TB'a ulaştıysa, dikey büyüme bir noktada para ve fizik açısından imkânsızlaşır. Hadoop, "100 ucuz makineye böl, paralel işle, biri çökerse diğeri devam etsin" mantığını kurar.

2. Hadoop'un Üç Temel Bileşeni

Hadoop'u öğrenirken kafa karışıklığının çoğu, ekosistemin tek bir şey sanılmasından gelir. Aslında üç ana parça vardır:

• HDFS (Hadoop Distributed File System): Veriyi 128 MB veya 256 MB'lık bloklara böler, her bloğu varsayılan olarak 3 kopya halinde farklı düğümlere yazar. Disk arızasına karşı dayanıklılık buradan gelir.
• YARN (Yet Another Resource Negotiator): Küme üzerindeki CPU ve bellek kaynaklarını işlere paylaştıran katman. Kim, ne zaman, ne kadar kaynak kullanacak — YARN karar verir.
• MapReduce: Veriyi "map" (parçala-eşle) ve "reduce" (topla-özetle) adımlarıyla işleyen programlama modeli. Bugün çoğu yeni iş yükü için Spark tarafından gölgede bırakılmış olsa da kavramsal temeli hâlâ önemlidir.

Bunların üzerine Hive (SQL arayüzü), HBase (NoSQL), Pig, Sqoop, Oozie, Zookeeper gibi araçlar oturur. "Hadoop ekosistemi" derken kastedilen budur; her bir alt projenin sürüm notlarını ve yapılandırma ayrıntılarını projenin resmi dokümantasyonu üzerinden takip etmek en güvenilir yoldur.

3. Küçük ve Orta Ölçekli Şirketler Hadoop'a İhtiyaç Duyar mı

Kısa cevap: Büyük ihtimalle hayır. Hadoop, terabyte'lardan petabyte'lara uzanan veriler için tasarlandı. Eğer toplam veriniz birkaç yüz GB ise:

1. Bir PostgreSQL veya MySQL sunucusu işinizi büyük olasılıkla görür.
2. İhtiyaç analitikse, DuckDB veya ClickHouse tek makinede inanılmaz hız sunar.
3. Bulut tarafında BigQuery, Snowflake veya Redshift küme yönetmeden sorgulama imkânı verir.

Hadoop'un getirdiği operasyonel maliyet — küme yönetimi, NameNode izleme, sürüm güncellemeleri, güvenlik (Kerberos), kapasite planlama — küçük ekipler için ciddi yüktür. "Big data" kelimesi pazarlama hevesiyle çok kullanıldı; oysa veriniz "büyük" değilse Hadoop kurmak, çekiç bulup her sorunu çivi gibi görmektir. Veri mühendisliği konusunda kendinizi geliştirmek isterseniz data engineering eğitimi sayfasını inceleyebilirsiniz; orada hangi aracın ne zaman doğru seçim olduğuna dair daha kapsamlı bir yol haritası bulunur.

4. Hadoop'un Hâlâ Anlamlı Olduğu Senaryolar

Hadoop modası geçmiş olsa da bazı durumlarda hâlâ rakipsizdir:

• Petabyte ölçeğinde geçmişe dönük log veya işlem arşivi tutulan kurumlar (telekom, bankacılık, sigorta).
• Veri egemenliği nedeniyle bulut kullanamayan, on-premise zorunluluğu olan kamu ve savunma projeleri.
• Halihazırda 10+ yıllık Hive/HDFS yatırımı olan kurumlar — geçiş maliyeti, kalmanın maliyetinden yüksek olabilir.
• Soğuk veri (cold storage) için ucuz disk ekonomisi gerektiren senaryolar.

5. Modern Alternatifler ve Hadoop'un Dönüşümü

Son on yılda büyük veri manzarası çok değişti. MapReduce'un yerine in-memory işleyen Apache Spark geçti; aynı işi 10-100 kat hızlı yapıyor. HDFS yerine bulut nesne depolama (S3, Azure Blob, GCS) kullanmak hem ucuz hem yönetimsiz. Üzerine Delta Lake, Apache Iceberg, Apache Hudi gibi tablo formatları geldi; bunlar HDFS'in sağladığı tutarlılığı nesne depolama üzerinde de mümkün kıldı.

Bugün konuşulan mimari "lakehouse": Veri gölünün esnekliği + veri ambarının disiplini bir arada. Databricks, Snowflake, BigQuery bu yönde ilerliyor. Hadoop sahnenin merkezinden kenara doğru kaydı, ama kavramsal mirası — dağıtık dosya sistemi, paralel hesaplama, hata toleransı — modern araçların DNA'sında.

6. Hadoop Öğrenmek Hâlâ Mantıklı mı

Bir kariyer kararı olarak bakıldığında: Sıfırdan başlayan biri için bugün Spark, SQL, bulut depolama ve modern tablo formatları daha öncelikli. Ancak Hadoop'un kavramları — bloklama, replikasyon, shuffling, partitioning — modern araçlarda da geçerli olduğu için temelde yatan fikirleri anlamak değerlidir. Yani "HDFS komutlarını ezberlemek" değil, "neden 128 MB blok boyutu seçildiğini" anlamak işe yarar. Veri mühendisliğine yönelmek isteyenler için bu temelleri yapılandırılmış öğrenmek isterseniz data engineering eğitimi içeriklerinden yararlanabilirsiniz.

Sonuç olarak Hadoop, büyük verinin demokratikleştiği bir dönemin kahramanıydı; bugün yerini daha çevik araçlara bırakıyor ama bıraktığı miras üzerinden inşa ediliyor. Şirketinizin ihtiyacı gerçekten "petabyte ölçekli, on-premise, geçmiş yıllık veri" değilse Hadoop'a karar vermeden önce bir kez daha düşünmek gerekir.