6 Ekim 2010’daki Web 2.0 Expo’da Kevin Weil tarafından yapılan “Analyzing Big Data at Twitter” sunumunun yorumlanmış çevirisidir. Yakın zamanda değişen #newTwitter arayüzünün yanında altyapıda ve özellikle arama bölümünde büyük değişiklikler oldu. 2008’de Twitter’da arama yapabilen bir ürün olan Summize’ı aldıktan sonra twitter’ın fenomen haline gelen saniyede 1,000 tweet ve 12,000+ sorgu yükü günde 1 milyar sorguyu beraberinde getiriyor. Bu yüzden Twitter mühendislik takımı eski MySQL tabanlı sistemde aramaya alternatif olarak Lucene kullanmaya başladılar.

Lucene’in güçlü yanlarının yanında gerçek zamanlı arama konusunda eksik yanları vardı. Fakat Twitter takımı Lucene mimarisinin bir kısmını kendi ihtiyaçlarına göre tekrar yazdılar. Yeni arama sistemi daha hızlı, ölçeklenebilir ve müsait sistem kaynaklarının %5’ini kullanıyor.

Detaylı bilgi için Kevin Weil’ın Web 2.0 Expo 2010’daki “Twitter’da Büyük Verileri Analiz Etmek” sunumunun çevirisini aşağıda bulabilirsiniz.

Üç Büyük Sorun

  • Veriyi toplamak,

  • Büyük ölçekli depolama alanları ve bu verilerin analizi,

  • Büyük veriler üzerinde hızlıca öğrenme (rapid learning)

Veri, Heryerde

  • Twitter’da günde 12 TB data üretiliyor. (Yılda 4+ Petabayt)

  • 20,000 CD

  • 10 milyon disket :)

  • Ben bu konuşmayı verirken 450 GB!

Sistem Kütüğü (Syslog)

  • Sistem olaylarını loglamak için başta syslog-ng kullandık.

  • Hacim büyüdükçe ölçeklendirmek mümkün olmadı.

  • Sistem kaynaklarını zorladı

  • Kayıp veriler oluştu

Scribe

  • Sürpriz! Facebook da aynı sorunu yaşıyordu. Scribe‘ı üretti ve açık kaynaklı olarak sundu. :)

  • Scribe, Thrit üzerinde çalışan sistem kütüğü (log) toplama yapısı.

  • Loglayacağınız satırları “scribe” ediyorsunuz, o geri kalanını yapıyor.

  • Yerel ağınızda çalışıyor, ağ bağlantısı kesintilerinde çalışabiliyor.

  • Alt loglayıcılar sistemin kalanından bağımsız, bu yüzden hiyerarşik ve ölçeklenebilir.

  • İsterseniz dosyaya isterseniz HDFS’e yazdırabiliyorsunuz.

Twitter’da Scribe Kullanımı

  • Sorunumuzu çözdü, yeni bakış açıları getirdi.

  • Şimdilik JavaScript, Ruby, Scala, Java vb. kaynaklardan gelen 40 farklı loglama kategorisi mevcut.

  • Twitter’ın çökme anlarında durum gözetlemelerini kaydedip incelememizi sağlıyor.

  • Facebook’la geliştirmek için birlikte çalışıyoruz.

Günde 12 TB’ı nasıl saklarsınız?

  • Tek makina mı?

  • Harddisk’in yazma hızı ne kadar olacak?

  • Saniyede 80 MB veri girişi

  • 12 TB’ı yazmak için 42 saat gerekiyor! :(

Günde 12 TB’ı nereye koyabilirim?

  • Dağıtık bir bilgisayar kümesine ihtiyacımız var

  • Bu da sisteme yeni karmaşıklık katmanları ekliyor

Hadoop

  • Dağıtık işleme yapmak için popüler bir çatı

    • Dağıtık dosya sistemi var (HDFS)

    • Otomatik replikasyon, hata toleransı

    • Birden fazla makine arasında saydam okuma-yazma işlemleri yapabilme

  • MapReduce tabanlı paralel işleme

    • Anahtar-değer tabanlı işleme arayüzü geniş uygulanabilirlik sağlıyor.

  • Açık kaynaklı: Üst düzey bir Apache Foundation projesi.

  • Ölçeklenebilir: Yahoo! 4000 makineli Hadoop kurulumuna (cluster) sahip

  • Güçlü: 1 TB rastgele sayıyı 62 saniyede küçükten büyüğe sıralayabiliyor.

  • Kolay Kurulum: CloudEra üzerinde kurulum paketleri mevcut.

İki Analiz Sorunu

  • Sosyal ilgi grafları için birbirlerini takip eden Twitter kullanıcılarını bulmak

    • grep, awk kullanılamayacak kadar büyük dosyalar.

    • Veri MySQL’de ise milyarlık bir tabloya SELF JOIN yapmak:

    • Milyar x Milyar= ?

  • Büyük ölçekli sayım ve gruplama işlemleri

    • select count(*) from users? bir tablodan bütün kullanıcıların sayısını almak… yavaş da olsa çalışır.

    • select count(*) from tweets? toplam tweet sayısını almak? ölüm…

    • Bu iki sorguyu birleştirdiğinizi düşünün.

    • ve grupladığınızı

    • ve yeniden eskiye göre sıraladığınızı…

Hadoop’a Dönelim

  • Zaten büyük bir bilgisayar kümemiz yok mu?

  • Hadoop hesabı dağıtma işlemini kolaylaştırıyor

  • Amacı paralel hesaplama

Ölçeklenebilir analizler

  • Büyüyoruz

  • Toplam tweet sayısını almak: 20+ milyar kayıtta 5 dakika sürüyor.

  • Kendi geliştridiğimiz graf veritabanı olan FlockDB‘ye yapılan paralel ağ çağrıları sayesinde kullanıcıların ilgi graflarını çıkarabiliyoruz.

  • Kullanıcılar ve ilgi ağları arasında PageRank algoritması çalıştırıp skorlama yapıyoruz.

Büyük Veriler Üzerinde Hızlı Öğrenme: Pig

  • Veritabanı sorgularını çok daha okunabilir ve basit kılan bir kütüphane

  • Eski SQL sorgularının sadece %5’i kadar. Yazması %5’i kadar zaman alıyor.

  • Çalışırken %20 daha hızlı.

  • Okunabilir, tekrar kullanılabilir.

Öğrendiğim Bir Şey

  • Soruları cevaplamak kolaydır.

  • Zor olan doğru soruları sormaktır.

  • Yenilik ve iterasyon getiren bir sistemin değerini bilmek.

  • Daha çok kullanıcı katkısı verilerinize değer katar

Büyük Verileri Saymak

  • Günde kaç sorgu oluyor?

  • Ortalama gecikme süresi?

  • Saate göre HTTP yanıt kodlarının dağılımı?

  • Günde kaç arama yapılıyor?

  • Yapılan her arama birbirinden farklı mı?

  • Gün içinde tweet’lenen linkler, alan adına göre gruplama?

  • Yukarıdakilerin hepsinin coğrafi dağılımı.

Büyük Veriler Arasındaki İlişkiyi Kurmak

  • Kullanıcıların kaçı mobilden, kaçı webden giriyor?

  • Hangi özellikler ve trendler kullanıcılarda bağımlılık yapıyor?

  • Hangi özellikler kullanıcılar tarafından daha az kullanılıyor?

Büyük Veriler Üzerinde Araştırma Yapmak

  • Bir kullanıcının attığı tweet’lerden ne çıkarımlar yapabiliriz?

  • …peki ya bu kullanıcının takip ettiklerinin attıkları tweet’lerden?

  • …peki ya takipçilerinin attığı tweet’lerden?

  • Retweet tesirini ve retweet ağacının derinliğini gözlemlemek

  • Çift kopyaların (spam) tespiti

  • Dil algılama (arama)

  • Makine öğrenmesi (machine learning)

  • Doğal dil işleme (natural language processing)