Büyük Verinin Sonu (2023)

 (motherduck.com)
1 puan yazan GN⁺ 2024-05-28 | 1 yorum | WhatsApp'ta paylaş
  • BigQuery’nin ilk mühendislerinden biri olarak edinilen deneyime bakıldığında, birçok kuruluşta darboğaz veri boyutundan çok veriyi kullanma biçimi ve maliyet yapısına daha yakındı
  • BigQuery müşterileri ve sektör geri bildirimlerine göre veri ambarlarının büyük çoğunluğu 1 TB’ın altındaydı; yoğun kullanan müşterilerde bile medyan değer 100 GB’tan çok daha küçüktü
  • Bulutta depolama ile işlem gücünün ayrılması depolama miktarını büyük ölçüde artırdı, ancak analitik işlem gücü talebi yakın tarihli veriler ve toplulaştırmalar merkezli olduğundan aynı oranda büyümedi
  • BigQuery’de yılda 1.000 doların üzerinde harcama yapan müşterilerin sorgularının %90’ı 100 MB’tan az veri işledi; devasa veri kümelerine sahip müşteriler bile büyük sorguları sık çalıştırmıyordu
  • Eski veriler düzenlemeler, davalar, anlamın aşınması ve özel işleme mantığı nedeniyle yükümlülüğe dönüşebilir; bu yüzden ham veriyi saklamak yerine toplulaştırma, silme veya özetlemenin daha iyi olup olmadığı gözden geçirilmeli

Büyük Veri korkusu ile gerçek darboğaz arasındaki fark

  • 10 yılı aşkın süredir veriden uygulanabilir içgörüler elde etmenin zor olmasının nedeninin veri boyutu olduğu mesajı tekrarlandı
  • Çözüm olarak, büyük ölçekli genişlemeyi yönetecek yeni teknolojiler satın almak önerildi; ancak yeni araçlar alınıp eski sistemler taşındıktan sonra bile birçok kuruluş verilerini anlamakta hâlâ zorlanıyor
  • 2023’teki durum, Büyük Veri uyarılarının başladığı dönemden farklı
    • Öngörülen veri felaketi gerçekleşmedi
    • Veri boyutları bir miktar büyüdü, ancak donanım daha hızlı büyüdü
    • Tedarikçiler hâlâ ölçeklenebilirliği öne çıkarıyor, ancak uygulayıcılar bunun gerçek sorunlarla nasıl bağlantılı olduğunu sorgulamaya başladı

BigQuery deneyiminden müşteri veri ölçekleri

  • Google BigQuery’nin kurucu mühendislerinden olan yazar, halka açık sunumlarda 1 PB sorgu çalıştırarak büyük ölçekli veri işleme kapasitesini gösterdi
  • Daha sonra BigQuery müşteri sorunlarını debug etti, 2 kitabın ortak yazarlığını yaptı ve 2018’den itibaren ürün yöneticisi olarak müşteri görüşmeleri ile ürün metriklerinin analizinden sorumlu oldu
  • En şaşırtıcı gözlem, “BigQuery” kullanıcılarının çoğunun gerçekte Big Dataya sahip olmamasıydı
    • Büyük veriye sahip müşterilerde bile, tüm veri kümesinin küçük bir bölümünü kullanan iş yükleri fazlaydı
    • BigQuery piyasaya çıktığında hızlı işleme hızı bilim kurgu gibi görünüyordu, ancak sonrasında daha geleneksel işleme yöntemleri de arayı kapattı
  • Yazıdaki grafikler kesin sayılar değil, hafızaya dayalı elle çizilmiş taslaklardır; önemli olan kesin değerlerden çok dağılımın şeklidir
  • Dayanaklar sorgu günlükleri, işlem sonrası analizler, benchmark sonuçları, müşteri destek talepleri, müşteri görüşmeleri, servis günlükleri, herkese açık blog yazıları ve sezgilerden geliyor

Çoğu kuruluş o kadar çok veriye sahip değil

  • “Big Data geliyor” diyen satış slaytları, yakında herkesin veri altında ezileceği mesajını veriyordu; ancak 10 yıl sonra bile bu gelecek gerçekleşmedi
  • BigQuery müşteri ölçeklerine bakıldığında, müşterilerin büyük çoğunluğunun toplam depolanan verisi 1 TB’ın altındaydı
    • Yüzlerce PB veriye sahip müşteriler de vardı, ancak boyutlar hızla azalan bir üs yasası dağılımını izliyordu
    • Aylık depolama maliyeti 10 doların altında olan binlerce müşteri vardı; bu da yaklaşık 0,5 TB’a karşılık geliyor
    • Hizmeti yoğun kullanan müşteriler arasında bile medyan depolama miktarı 100 GB’tan çok daha küçüktü
  • Gartner ve Forrester gibi sektör analistleriyle yapılan görüşmelerde de şirket veri ambarlarının büyük çoğunluğunun 1 TB’tan küçük olduğu yönünde geri bildirim alındı
    • Sektörel sezgiye göre bir veri ambarı için uygun ölçek yaklaşık 100 GB’tı
    • BigQuery ekibi benchmark çalışmalarının ana odağı olarak bu ölçeği aldı
  • Bir yatırımcının portföy şirketlerini incelemesi sonucunda, veri boyutlarının görece büyük olma olasılığı yüksek teknoloji şirketlerinde bile en büyük B2B şirketin yaklaşık 1 TB, en büyük B2C şirketin yaklaşık 10 TB olduğu; çoğunun ise çok daha küçük kaldığı görüldü
  • Orta ölçekli işletme örneklerinde de veriler kolayca devasa hâle gelmiyor
    • 1.000 müşteri her gün 1 sipariş ve 100 satır kalemi oluştursa bile günlük veri 1 MB’ın altında kalır; 3 yıl sonra da yaklaşık 1 GB olur
    • Pazarlama veritabanında 1 milyon lead ve onlarca kampanya olsa bile lead tablosu 1 GB’ın altında, kampanya takibi de muhtemelen birkaç GB düzeyindedir
    • SingleStore 2020-2022 arasında hızlı büyüyen Series E unicorn şirketiyken bile finans veri ambarı, müşteri verileri, pazarlama kampanyası takibi ve servis günlüklerinin toplamı birkaç GB civarındaydı

Depolama ile işlem gücünün ayrılmasının yarattığı yanılsama

  • Modern bulut veri platformlarının tümü depolama ile işlem gücünün ayrılması yaklaşımını benimsiyor; böylece müşteriler tek bir form faktörüne bağlı kalmıyor
  • Bu değişim, son 20 yılın veri mimarisinde scale-out’tan daha önemli bir değişim olabilir
    • Yönetimi zor shared-nothing mimariler yerine shared disk mimarisi, depolama ve işlem gücünü bağımsız olarak büyütmeyi mümkün kılıyor
    • S3 ve GCS gibi ölçeklenebilir ve yeterince hızlı nesne depoları, veritabanı tasarım kısıtlarını gevşetiyor
  • Gerçekte veri boyutu, işlem gücü boyutundan çok daha hızlı artıyor
    • Veri zaman içinde üretilir; durağan bir işletmede bile depolama miktarı zamanla doğrusal olarak artar
    • Analizler çoğunlukla yakın tarihli verileri hedeflediğinden işlem gücü talebinin depolama miktarı gibi büyümesine daha az ihtiyaç vardır
    • Eski veriler değişmediği için onları sürekli taramak israfa yakındır; önemli yanıtlar toplulaştırmalarla üretilebilir
  • On-premises ortamdan depolama-işlem ayrımına sahip buluta geçen müşterilerde, depolama miktarı çok büyüse bile işlem gücü talebinin çoğu zaman fazla değişmediği görüldü
    • BigQuery’nin büyük bir perakende müşterisinde on-premises veri ambarı yaklaşık 100 TB’tı; buluta geçişten sonra 30 PB’a çıktı
    • Depolama miktarı 300 kat arttı, ancak işlem gücü maliyeti aynı oranda artmadı ve analitik için milyarlarca dolar harcanmadı
  • Bu yapı, ölçeklenebilir nesne depoları kullanıldığında beklenenden çok daha az işlem gücünün yeterli olabileceğini ve dağıtık işleme gerekmeyebileceğini gösteriyor

Gerçek sorgu iş yükleri toplam veriden çok daha küçük

  • Analitik iş yüklerinin işlediği veri miktarı sezgisel olarak beklenenden daha küçük olabilir
    • Dashboard’lar çoğu zaman toplulaştırılmış verilerle oluşturulur
    • Kullanıcılar çoğunlukla son 1 saat, 1 gün veya 1 haftalık veriye bakar
    • Küçük tablolar daha sık sorgulanır, dev tablolar ise daha seçici biçimde sorgulanır
  • BigQuery’de yılda 1.000 doların üzerinde harcama yapan müşterilerin sorguları analiz edildiğinde, sorguların %90’ı 100 MB’tan az veri işliyordu
    • Belirli bir müşterinin sorgu hacminin sonuçları çarpıtmaması için analiz birkaç farklı şekilde bölündü
    • Veri okumayan, yalnızca metadata sorguları hariç tutuldu
    • GB aralığındaki sorgular ancak yüksek yüzdelik dilimlere çıkıldığında görülüyordu; TB aralığındaki sorgular ise çok nadirdi
  • Devasa veri boyutlarına sahip müşteriler bile devasa verileri neredeyse hiç sorgulamıyordu
    • Büyük sorgular çalıştırdıklarında bu çoğunlukla rapor üretme amacı taşıyordu ve performans öncelik değildi
    • Büyük bir sosyal medya şirketi, pazartesi günü üst yönetim raporu için hafta sonu çok büyük sorgular çalıştırıyordu; ancak bu, hafta içi çalıştırılan yüz binlerce sorgunun çok küçük bir kısmıydı
  • Modern analitik veritabanları gerçekten okunan veri miktarını azaltmak için çeşitli teknikler kullanır
    • Sütun projeksiyonu ile yalnızca gerekli alanlar okunur
    • Partition pruning ile yalnızca dar tarih aralıkları okunur
    • Clustering veya otomatik mikro partitioning üzerinden segment eleme ile veri yerelliğinden yararlanılır
    • Sıkıştırılmış veri üzerinde hesaplama, projeksiyon ve predicate pushdown da sorgu anındaki I/O’yu azaltır
  • I/O’nun azalması gereken hesaplama miktarını düşürür; maliyeti ve gecikmeyi azaltır

Veri işleme maliyeti küçük sorgular yazmaya zorlar

  • Scale-out ile hızlı işleme yapabilmek, bunun ucuz olacağı anlamına gelmez
  • Sonucu almak için 1.000 node kullanılıyorsa maliyet çok yüksek olabilir
  • BigQuery demolarında çalıştırılan 1 PB sorgu, perakende fiyatla 5.000 dolardı
  • Bu tür verimsizlik, PB ölçeğinde çalışmayan ekipler için yük oluşturan big data tax kapsamının bir parçasıdır
  • Veri işleme miktarını azaltmaya yönelik finansal teşvik, bayt tarama üzerinden ücretlendirme modeli olmasa da geçerlidir
    • İster BigQuery’nin tarama maliyeti ister Snowflake instance’ının atıl kalma maliyeti olsun, başlıca bulut veri ambarları faturayı büyütebilir
    • Sorguları küçültmek daha küçük instance kullanmayı sağlar, sorgular hızlanır ve daha fazla eşzamanlı çalıştırma mümkün olur

Verilerin çoğu neredeyse hiç sorgulanmaz

  • İşlenen verilerin büyük bir kısmı 24 saatten daha yeni verilerdir
  • Veri yaklaşık 1 hafta yaşlandığında, sorgulanma olasılığı en son bir günlük veriye kıyasla yaklaşık 20 kat düşer
  • Bir ay geçtikten sonra veri çoğunlukla olduğu gibi kalır ve ancak nadir rapor çalıştırmalarında sorgulanır
  • Depolanan verinin yaş dağılımı, erişim örüntüsünden çok daha yumuşaktır
    • Birçok veri hızla atılsa da, birçok veri tablonun sonuna eklenmeye devam eder
    • Son 1 yılın verisi toplam verinin yalnızca %30’u olsa bile veri erişimlerinin %99’unu oluşturabilir
    • Son 1 ayın verisi toplam verinin yalnızca %5’i olsa bile veri erişimlerinin %80’ini oluşturabilir
  • Veri zamanla sakinleştiğinde gerçek çalışma kümesi beklenenden daha yönetilebilir bir boyuta iner
    • 10 yıllık 1 PB’lık bir tablonuz olsa bile, gerçekte sık erişilen kısım yalnızca o günün verisi olabilir
    • O günün verisi sıkıştırılmış olarak 50 GB’ın altında olabilir

Tek makinenin sınırları sürekli ileri taşınıyor

  • Big Data “tek makineye sığmayan şey” olarak tanımlanırsa, bu kapsama giren iş yüklerinin sayısı her yıl azalıyor
  • Google MapReduce makalesi 2004’te yazıldığında, tipik veri iş yüklerinin tek bir genel amaçlı makineye sığmaması yaygındı
  • AWS 2006’da EC2’yi çıkardığında sunulan instance tek çekirdek ve 2 GB RAM’den ibaretti; birçok iş yükü bu makineye sığmıyordu
  • Bugün AWS’nin standart instance’ları fiziksel sunucu bazında 64 çekirdek ve 256 GB RAM kullanıyor
    • RAM miktarı, 2006’daki ilk EC2 instance’larına göre iki basamaklı katlarla büyüdü
    • Bellek optimize instance’lara daha fazla ödeme yaparsanız RAM’i ayrıca iki basamaklı katlara kadar büyütebilirsiniz
    • Kaç iş yükünün 24 TB RAM’den veya 445 CPU çekirdeğinden fazlasına gerçekten ihtiyaç duyduğu sorusu ortaya çıkıyor
  • Bulutta büyük VM’lerin maliyeti, işlem gücüyle neredeyse doğrusal biçimde artar
    • Tüm sunucuyu kullanan bir VM, sunucunun 1/8’ini kullanan bir VM’den yalnızca 8 kat pahalıdır
    • Özgün Dremel makalesindeki 3.000 paralel node’luk benchmark’a benzer performansın bugün tek node’da elde edilebileceği düşünülüyor

Veri varlık değil, yükümlülük olabilir

  • Big Data’nın bir başka tanımı, “neyi atacağınıza karar vermenin maliyetinin veriyi tutmaya devam etme maliyetinden daha yüksek olduğu durum”dur
  • Birçok kuruluşun data lake’i, ihtiyaçtan değil silinmediği için büyümüş devasa bir bataklığa daha yakındır
    • İçinde ne olduğu bilinmez
    • Temizlemenin güvenli olup olmadığı bilinmez
  • Veri saklama maliyeti, fiziksel baytları depolama maliyetinden daha büyüktür
    • GDPR ve CCPA gibi düzenlemelerde belirli verilerin kullanımının takip edilmesi gerekir
    • Bazı veriler belirli bir süre içinde silinmelidir
    • Data lake’teki parquet dosyalarında telefon numaraları çok uzun süre kalırsa yasal gereklilikler ihlal edilebilir
  • Eski veriler davalarda da kuruluşun aleyhine kullanılabilir
    • Birçok kuruluşun potansiyel sorumluluğu azaltmak için e-posta saklama süresini sınırlaması gibi, veri ambarındaki veriler de aleyhte delil olabilir
    • 5 yıl önceki günlükler kodda bir güvenlik açığını veya SLA’nın karşılanmadığını gösteriyorsa, veriyi ne kadar uzun tutarsanız yasal maruziyet de o kadar uzayabilir
  • Veri de koddaki bit rot gibi anlamını yitirebilir
    • Özel alanların tam anlamı insanlar tarafından unutulabilir
    • Geçmişteki veri hataları hafızadan silinebilir
    • Örneğin kısa bir dönem tüm customer id değerleri null olarak ayarlanmış olabilir ya da devasa bir dolandırıcılık işlemi 2017 3. çeyrek sonuçlarını gerçekte olduğundan iyi göstermiş olabilir
    • Eski dönemlere ait verileri çıkaran iş mantığı, “2019 öncesi revenue, 2019-2021 arası revenue_usd, 2022 sonrası revenue_usd_audited” gibi giderek karmaşıklaşabilir

Big Data %1’inde olup olmadığınızı kontrol etmek

  • Big Data gerçekten var, ancak çoğu insanın bunun için endişelenmesine gerek olmayabilir
  • Big Data One-Percenter olup olmadığınızı anlamak için şu soruları sorabilirsiniz
    • Gerçekten muazzam miktarda veri üretiyor musunuz
    • Öyleyse, gerçekten tek seferde muazzam miktarda veriyi kullanmanız gerekiyor mu
    • Öyleyse, gerçekten tek makineye sığmayacak kadar büyük mü
    • Öyleyse, sadece veriyi yığan biri değil misiniz
    • Öyleyse, özetlemek daha iyi olmaz mı
  • Bu sorulardan herhangi birinin yanıtı “hayır” ise, sahip olduğunuz gerçek veri boyutuna uygun yeni nesil veri araçları için aday olabilirsiniz
  • İlgili örnek olarak modern BigQuery alternatifleri anılıyor
  • Kuruluşlar, bir gün sahip olabilecekleri veri boyutundan korkmak yerine, gerçekten sahip oldukları veri boyutuna ve gerçek sorgu örüntülerine göre araçlarını ve saklama politikalarını seçmeli

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-28
Hacker News yorumları

  • Eski iş yerimde veri bilimci işe alırken kullanmayı sevdiğim tuzak soru şuydu: “En fazla 6TiB veri olduğu yönünde bir gereksinim varsa nasıl bir stack/mimari kurardınız?”
    BigQuery, Hadoop gibi büyük lafları dinleyip donanım/yazılım/lisans maliyetlerini de sorunca genelde yıllık on binlerce dolarlık tahminler çıkardı
    Sonunda kabul edilen kişi, 6TiB'nin odadaki 6 kişinin akıllı telefonlarına bölüştürüp taşıyabileceği bir miktar olduğunu; 199 dolarlık tek bir kurumsal HDD'nin ya da yedeklilik için üç tanesinin yeterli olacağını; CSV olarak belleğe birkaç kez alınıp awk betikleriyle bile işlenebileceğini anlayan kişiydi
    Ben de çekiç kullanmayı öğrenince her şeyi çivi gibi görme hatasına kolayca düşebilirim, ama işe alımda “gerçek big data”nın ölçek hissini bilmemek elenme sebebiydi

    • İş görüşmesi bağlamının kendisi yanıtları etkilemiş olabilir. Aday teknik mülakattan geçtiği için mülakatçının teknoloji stack'i anlayışını ölçmeye çalıştığını bekler
      Sırf bu tür yanıtlardan yola çıkarak kişinin her işi aşırı tasarladığı sonucuna varmaktansa, mülakatçının üstün konumda olduğu yapay bir durumda tuzak soruya yakalandığını düşünmek daha doğru
      Yakın zamanda benzer kıdem ve deneyimde bir mülakatçıyla teknik mülakata girdim ve cevabı batırdım; mülakatçı da kötü cevabıma yargılayıcı yaklaştı. Roller değişseydi, daha iyi bildiğim bir konuda onu aynı şekilde zor duruma düşürebilirdim
      Mülakatçıysanız üstün konumunuzu kötüye kullanmamaya özellikle dikkat etmelisiniz. Bu şirket için de ters teper, karşınızdaki kişi için de iyi bir şey değildir
    • https://x.com/garybernhardt/status/600783770925420546 Gary Bernhardt'ın 2015 tarihli paylaşımı:
      “Danışmanlık hizmeti: Siz bana big data probleminizi getirirsiniz, ben de ‘veri setiniz RAM'e sığıyor’ derim; siz 500 bin dolar tasarruf ettiğiniz için bana 10 bin dolar ödersiniz”
    • Bazı insanlar verilerinin aslında big data olmadığını söylediğinizde epey rahatsız oluyor
      Birkaç yıl önce bir direktör Hadoop, API gateway, birden fazla geliştirici ve yılda yüz binlerce dolar maliyetle BT'nin yaptığı bir sistemi göstermişti; mevcut ölçek ve öngörülebilir gelecek ölçeği için dizüstüne takılı bir USB disk ve birkaç Python betiğiyle bile rahatça çalıştırılabileceğini söyleyince çok sinirlendi ve ondan sonra o projeye bir daha dahil olamadım
      Bunu şirkete yayılmış gösteriş döngüsünün bir parçası olarak görüyorum. “Basit bir iş yapıyoruz” diye kabul edemeyen bir yapı
    • Dikey ölçekleme çözümlerini anlıyorum ama dürüst olmak gerekirse neredeyse tüm kullanım senaryoları için yanlış çözüm. Veri tüketicisi awk istemez; istese bile partitioning veya kolon odaklı depolama olmadan 6TB'yi her sorguda tek CPU ile taramak her zaman yavaştır
      Bu tür işler için genelde BigQuery iyi bir seçenekti. Konsol arayüzü geçici analizler için yeterli, Metabase, Tableau gibi birçok araç da bağlanabiliyor
      Doğru şekilde partitioning yapılırsa maliyet de aşırı olmaz; sorun olursa rollup tabloları eklenebilir
    • .parquet dosyaları tamamen hafife alınıyor ve hâlâ bu formatı bilmeyen çok kişi var
      CSV'den farklı olarak veri tiplerini korur, CSV'den 10 kat küçük olduğu için 6TB 600GB olur ve okuma 50 kat daha hızlıdır. Ayrıca Apache Foundation'ın açık standardıdır
      CSV gibi kolayca içine bakılamaz ama bu ödün buna değer. CSV'yi indirme olarak sunan her yerin .parquet de birlikte sunmasını isterim

  • Genel olarak yazının birçok kısmına katılıyorum ama birkaç çekincem var. Birincisi, MongoDB bir referans noktası olarak uygun değil. MongoDB'nin yaptığı işlerden PostgreSQL'in daha iyi yapamadığı bir şey görmedim; big data çözümü de NoSQL/MongoDB değil, genelde kolon odaklı veritabanları, mapreduce, Cassandra gibi şeylerdir
    İkincisi, başarıyı planlamak gerekir. Şirketlerin %95'i unicorn olamaz ama kalan %5'i hedefliyorsanız hazırlıksız oraya varamazsınız. 5 müşteriniz varken ölçeklenebilirliği düşünerek tasarlamanızın nedeni, üstel büyüme anı geldiğinde onu yakalayabilmektir
    Yine de temel ders doğru. Verilerin çoğu büyük değildir; dünyadaki herkes hakkındaki veri bile 100 dolarlık bir Chromebook'a sığabilir. Çoğu veri nadiren sorgulanır ve sorgular da küçüktür; big data işlerinin ilk adımı çoğu zaman terabaytları gerçekten ihtiyaç duyulan GB, MB, hatta bazen KB ölçeğine indirmektir. Regülasyonlar nedeniyle veri maliyeti de artıyor

    • “Başarıyı planlayın” sözü, her yerde mimari astronotlarının söylediği şeyle birebir aynı. Benim deneyimime göre bu tamamen doğru değil; aksine çoğu zaman üretkenliği ve startup'lar için daha önemli olan çevikliği ciddi biçimde azaltıyor
      İnsanlar sadece plan yapmakla kalmıyor, genellikle uygulamayı da yapıyor. Önümüzdeki 3 ayı planlarsanız çok daha çevik ve üretken olabilirsiniz. Uygulayamıyorsanız unicorn olamazsınız
    • Ani başarıyı kaldıramayıp paniğe kapılma durumlarından çok daha fazla, başarıya hazırlığı fazla yapıp başarısızlığı garanti altına alan vakalar gördüm
      Bu, ikinci sistem sendromu ile hayatta kalan yanlılığının birleşimi gibi. İyi bir MVP'nin dağınıklığını temizleyen insanlar “Bunu eskiden yapmalıydık” diye yakınır; ama gerçekten baştan planlayıp tasarlayan şirketler hayatta kalmadığı için şikâyetin konusu bile olmazlar
    • Küçük bir düzeltme ama 8 bit ile kişi başına benzersiz tamsayı ID bile tutulamaz. Bunun için kişi başına 8 bayt gerekir ve o zaman zaten 60GB seviyesine gelirsiniz
      Geri kalanına neredeyse tamamen katılıyorum ama bu kısım yanlış göründüğü için geçemedim
    • “Unicorn olma ihtimalini yaratmak için işin her bölümünü hem bugün hem sonrası için planlamalısınız” fikrinin pratikte ters teptiğini düşünüyorum
      Startup'ın runway'i sınırlıdır; mühendisler ancak yıllar sonra karşılığını alacak işlere para harcıyorsa, o zaman gelmeden başarısız olma olasılığını artırıyorlar demektir
    • 5 müşteriniz varken ölçeklenebilirliği tasarlamanız gerektiği, böylece üstel büyüme geldiğinde onu yakalayabileceğiniz sözünden şüpheliyim
      Bir ürünün bu kadar güçlü traction elde etmesi genelde kullanıcı tabanının varlığı ve ihtiyacından doğan bileşik etkiler sayesindedir. Büyüme sırasında yeni kullanıcı eklemede tökezleseniz bile mevcut kullanıcıların eski ürüne dönmesi veya başka yere gitmesi pek olası değildir
      Eski Twitter'da her gün fail whale görmek sıradan bir şeydi ama çoğu kişi ayrılmadı ve daha iyi ölçeklenen bir alternatife kitlesel geçiş de yaşanmadı. Zaten böyle üstel büyüme yaşayan ürünler nadirdir; bu süreçte ölçeklenmede zorlanıp erişilebilirliğin kötüleşmesi yaygındır. Ölçeklenemediği için başarısız olmuş üstel büyüme ürünleri gerçekte hangileriydi, merak ediyorum

  • “Büyük veri”nin moda olduğu dönemde Large Hadron Collider’da araştırmacıydım. Bizim için tüm veriyi analiz etmek anlamlı bir kullanım senaryosuydu; frekansçı istatistikte de veri ne kadar çoksa o kadar iyiydi.
    Ama dünyanın dört bir yanındaki süper bilgisayar ağlarını kullanırken bile, devasa bir işin bitmesini beklemektense hızlı yerel depolamanın daha iyi olduğunu fark ettik. Sonunda tüm doktora öğrencileri, analiz esnekliğini fazla kaybetmeden ilgili veriyi tam olarak 1~5 TB’a indirdi.
    Burada Amdahl’ın ölçekleme yasasına denk düşen bir kolaylık yasası var gibi görünüyor.

    • Bir tane uyduracak olursak: “1~5 TB veri ile istatistiksel analiz yapamıyorsanız metodolojiniz yanlıştır” gibi bir şey olabilir.
      Bu matematikten çok insanın sınırlarına daha yakın görünüyor. Kullanabileceğimiz esnekliğin açık bir üst sınırı var. Yeni tür analizleri daha kolay çalıştırmanın bir yolu bulunursa bu değişir; ama yapmak istediğimiz işlerin sayısına göre logaritmik artacak gibi.
    • Bence kolaylık yasası var. Birçok teknolojinin sabit bir üstel hızla gelişmesini de açıklıyor.
      İnsanlar her yıl biraz daha iyi hale getirmenin pratik yollarını bulmakta çok iyiler; ama herhangi bir fikri hayata geçirmek için asgari bir süre gerekiyor.
    • 80’ler ve 90’larda NASA, Cray gibi büyük makinelerde sonlu elemanlar analizi simülasyonları çalıştıran National Aerodynamic Simulator’ı kurmuştu. Bugünün ölçütleriyle belki ucuz bir ekran kartı seviyesindedir.
      Yanlış hatırlamıyorsam o makinenin kuyruğu, işi ucuz donanımda çalıştırma süresi kadar ya da daha uzundu; Beowulf gibi büyük ölçekli paralel işleme sistemleri de bu tür çabalardan doğdu.
    • Kolaylık yasasının doğru olduğunu düşünüyorum. Ticari sistem geliştiricileriyle konuştuğunuzda, müşterilerin sistemi her zaman olabildiğince ucuza kurmaları için baskı yaptığını görüyorsunuz.
      Saklanan veritabanını ve hesaplama boyutunu küçültmek, müşterinin aylık faturasını en aza indirmenin harika bir yolu.

  • Deneyimlerime göre veri üstel olarak büyümeye devam ediyor, ama bilgi miktarı aynı şekilde artmıyor.
    Finansta isterseniz tek bir zaman serisi için günde 100 milyon veri noktasını kolayca elde edebilirsiniz; binlerce zaman serisiyle de uğraşabilirsiniz. Ama bu örnekleme hızı ve zaman serisi sayısı çoğu zaman %99,99 oranında tekrar içerir. Çünkü özdeğerler kabaca 10 boyuttan sonra, hatta bazen çok daha erken bir noktada neredeyse sıfıra düşer.
    Asla sorgulamayacağınız tik verilerini petabaytlarca saklamak için pek neden yok. Çoğu durumda toplama anında cesur ve kayıplı bir boyut indirgeme yapmak, yalnızca ilk birkaç ana bileşeni ve aykırı değerleri saklamak, ayrıca daha önce göz ardı edilebilir olan yeni bir faktörün önem kazanıp kazanmadığını anlamak için özdeğer kararlılığını izlemek çok daha mantıklı.
    Sonuçta veri kümesi çok daha küçük ve yönetilebilir hale gelir; gerçekten kullanılabildiği için çoğu zaman daha fazla içgörü sağlar.

    • İlginç; zaman içinde özvektörler değişirse bunu nasıl ele aldığınızı merak ediyorum.
    • Özdeğerler ve boyut konusunu açıklayan kaynaklar önerebilirseniz iyi olur.
      İlginç geliyor ama benim için tamamen yeni bir konu.

  • “Büyük veri”nin komik yanı, yazılım düzeyinde en temel ve bariz optimizasyonlardan bile kaçınmaya iten çarpık teşvikler yaratmasıydı. Çünkü donanım gereksinimleri ne kadar büyükse, kişinin ne kadar önemli olduğunu o kadar kanıtlıyordu.
    Örneğin “Patron, tüm veri kümesini hesaplamak yerine bir örneklem okursak bu rapordaki ortalamaları yalnızca dizüstü bilgisayarla hesaplayabiliriz” derseniz, patron bunu “Örneklem ne demek? O matematikçi/mühendis zırvalarıyla ne ima etmeye çalışıyorsun? Milyonlarca doları boşa harcadığımı söylemiyorsundur herhalde?” diye algılıyordu.

    • O furyada Google’dan çıkanların hisse opsiyonlarını paraya çevirdiği bir akım da vardı.
      Büyük veriyle ilgili satış abartısı ve gürültü, ayrıca kimin verisi yeterince büyük diye yapılan gösteriş yarışı bir süre çok şiddetliydi.
    • Bu epey alaycı bir dış gözlem ve aslında doğru değil. Kariyerimin başlarında bir veri mühendisi olarak hesaplama maliyetlerini azaltmaya çalıştım.
      Uzun süre tek bir makinede 64 GB’tan fazla bellek elde etmek çok zordu; sert bir üst sınır olduğunda uygulama karmaşıklığı hızla fırlar.
      Veri biraz büyüdüğü için 50 seferde 1 kez başarısız olan bir süreç çok yıkıcıdır. Ekipler bu tür düzenli cron işlerinden onlarcasını çalıştırır; her biri sık sık bozulursa nöbette yaptığınız tek şey parçaları kesip atmaktır.
      Hadoop ve MapReduce aşırı verimli değildi, ama doğru kullanıldığında fena değildi ve istikrarlı çalışmaları çok daha önemliydi. Yani kimsenin güvenemediği ya da bakımını yapamadığı, her perşembe tuhaf bir segmentation error ile ölen bit düzeyinde optimize edilmiş C++ kodundan daha iyiydi.
      Bugün olsa sadece Snowflake kullanırdım; ama o dönem için makul araçlardı.

  • Bu yazı tamamen doğru değil. Aslında büyük veri üç boyutla tanımlanıyordu: hacim, hız, çeşitlilik
    Hacim büyük ölçüde çözüldü; hız da çözüldü ama pahalı. Çeşitlilik ise hâlâ çözülmüş değil
    Günümüzde büyük veri, “depolama alanı ya da işlem gücü yetmiyor”dan çok, “bunu birleştirip anlamak için bilişsel kapasite yetmiyor”a daha yakın

    • Bu 3V kavramını ilk kez Michael Stonebraker’ın bir konuşmasında duydum. Kendisi DBMS alanında bir efsane ve Turing Award sahibi
      İlgili konuşmaları da şiddetle öneririm. Çoğu YouTube’da var
      [1] https://www.youtube.com/watch?v=KRcecxdGxvQ
      [2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
    • Burada “çeşitlilik” ile ne kastedildiğini merak ediyorum
    • Benim için depolama alanı ve işlem gücü hâlâ yetersiz. Yılda altı kez, ikişer haftalığına sahaya çıkıp veri topluyorum; sahada iki uçakla dört bantta ve çift polarizasyonda sentetik açıklıklı radar verisi toplanıyor
      Her uçakta bir radar sistemi var; bunun içinde her biri 20TiB’lık 16 sürücülü RAID-0 SSD depolama biriminden 8 adet bulunuyor. Genelde RAID’i tamamen doldurmayız; bu da günde yaklaşık 176TiB, iki haftada 7 uçuşla parti başına 1,2PiB, yılda yaklaşık 7,2PiB üretmek demek
      Uçuşlar arasında bir gün ara vermemizin nedeni, verileri fiber üzerinden aprona bitişik hangarın köşesine kabaca sıkıştırılmış depolama sunucusuna indirmek zorunda olmamız. Sonra güvenlik için ikinci bir sunucuya kopyalıyoruz; görev bitince hepsini merkeze gönderip depoluyor ve işliyoruz
      Bu veri değerli, ama “on milyarlarca dolar” seviyesinde değil. Kaynak çıkarma, haritalama, çevresel ve jeodezik araştırmalar için kullanılıyor; 2008’den beri her baytı sakladık. Çünkü yeni algoritmalar çıktığında eski verileri yeni standartla yeniden işleyebiliyoruz
      Dosyaları 800GiB–2TiB parçalar hâlinde GPU işleme sunucularına aktarıyoruz ve sıkıştırılamıyorlar. Çünkü yakaladığımız şeylerin çoğu olan kozmik mikrodalga arka plan ışıması epey rastgele. Bir ara teybe yazarsak altyapıyı yarıya indirebileceğimizi sanmıştık; ama teyp kapasitesi sanki sadece sıfırlardan oluşan gigabayt ölçeğinde metin dosyaları saklarken geçerliymiş gibi hesaplanıyordu
      GPU da yavaş, CPU da yavaş, PCIe veri yolu da yavaş, RAM de yavaş, benim yazma hızım da yavaş. Her şeyin her zaman daha hızlı olması gerekiyor
      Her şey çok yavaş, çok zor ve çok küçük. Sabit diskler çok küçük; Linux çekirdeği ayarlarını yapmak ve işleme kümesine giden hızlı, güvenilir ağı kurmak çok zor. Basit bir iç davranış değişikliği olan çekirdek/paket güncellemeleri bile sistemi yalnızca bizim yaşadığımız türden şekillerde bozuyor
      Varsayılan ayarlar, RAM’in kıt olduğu hayaliyle ağ işleri için bellekten kısmaya ayarlı. Ama dosya sunucusunda 0,5TB RAM var; ağ ve dosya sistemini hızlandırmak için hepsini kullanmasını istiyorum. Sonunda ağ yığını belgelerini 6 saat okuyup G/Ç’yi 2024 seviyesindeki sağduyuya çekmek gerekiyor
      Muhtemelen dünyadaki neredeyse herkesten daha iyi sysctl.conf biliyorumdur
      Kendini büyük veriye yönelik dağıtık kalıcı nesne deposu diye pazarlayan sistemler bizim iş yükümüzde tamamen çöküyor ya da yüz milyonlarca dolara mal oluyor. Nesne boyutunun yaklaşık 1TB olduğunu söyleyince dağıtık dosya sistemi satışçıları cevap vermeyi bırakıyor. Bir satıcı gereksinimleri okuyup bizi istihbarat kurumları müşterilerinden sorumlu kişiye bile yönlendirmişti. Ben NSA değilim ve NSA bütçem de yok
      Bazen Bloomberg’de bulut makalesi okumuş bir MBA ya da PMP, şirket içi veri merkezi maliyetlerini görüp AWS’ye veya Azure’a taşınmayı soruyor; para ve zaman tarafındaki rakamları gösterince kusacakmış gibi bir yüz ifadesi takınıp konuyu değiştiriyor
      Üstelik satıcıların hepsi yapay zeka/bulut furyasına atlayıp bize uygun ürün ailelerini sonlandırıyor. Artık müşteri verilerini kazıyıp reklam göstermek isteyen hedge fonlarla ve yapay zeka girişimleriyle GPU için rekabet etmek zorundayız
      Depolama alanı ve işlem gücü yetersiz; elimizdeki depolama ve işlem gücü de fazla yavaş. DPU/IPU ilginç, ama nesneler SQL veritabanı sorgularından ya da sıkıştırılmış video akışı parçalarından büyüyünce hemen sınıra dayanıyor

  • Eskiden günde 20GB analiz verisi üreten bir şirkette çalışmıştım; muhtemelen uğraşacağım en büyük veri buydu
    Junior projesi olarak batch ve gerçek zamanlı toplama yapan bir veri işleme işi yazdım, sonuçları Azure’daki Parquet blob’larına kaydettim
    Yöneticim, neyin saklanıp neyin atılacağını tartışmak için düzenli olarak paydaş toplantıları yaptıracak kadar akıllıydı; iyi algoritmalar sayesinde veriyi günde yaklaşık 200MB’a sıkıştırabiliyorduk
    Son 2 ay SQL Server’a konuyor, son 2 yıl daha da özetlenip başka bir sunucuya aktarılıyordu; şirketin tamamı Excel ile makul sürede sorgu çalıştırabiliyordu. Ham büyük veri ise bir gün gerekebilir diye teyp depolamada çürümeye bırakılmış durumda
    Yöneticim kötü bir yöneticiydi ama veriden iyi anlardı; geriye dönüp bakınca birçok şeyi doğru yaptığını ve benim de çok şey öğrendiğimi görüyorum

  • Yıllar boyunca “büyük” veri araçları ve pipeline’larında aşırı mühendislik gördüm. Birçok kullanım senaryosunda veri ambarları ve data lake’ler GB ya da tek haneli TB aralığında; bu yüzden düzgün bir EC2 instance üzerinde DuckDB çalıştırmak gibi yollarla çok daha basitleştirilebilir
    Deneyimime göre böyle yapınca, diğer sistemler sorgu çalıştırmaya daha başlamadan sonuçlar geliyor. Athena’ya bakarak söylüyorum
    Bugünlerde birçok sorgunun tarayıcıda bile çalıştırılabileceğini düşündüğüm için DuckDB WASM(https://github.com/duckdb/duckdb-wasm) ve perspective.js(https://github.com/finos/perspective) yardımıyla https://sql-workbench.com/ sitesini yaptım

  • Görünüşe göre o hype döngüsü sonunda “ölüm platosu”na ulaşmış. Hype’tan aşırı etkilenen bu sektörde pek de nadir bir son değil

    • Sadece adı AI olarak değişti
      AI da tüm veriyi kullanıyor ve anlamını çözmek için üstüne sihirli sinir ağları takıyor

  • Kişisel olarak büyük verinin ana itici gücünün şirket kurucularının egosu olduğunu düşünüyorum. Doğal olarak şirketimiz patlayıcı biçimde büyüyüp küresel ölçekte başarıya ulaşacak, o yüzden ölçeğe uygun tasarlamalıyız gibi bir yaklaşım
    Ürün Series C aşamasına gelene kadar tek bir SQLite DB yeterliyken bile bu hataya düşmek trajik. Tüm enerji henüz ölçeğe değil, ürüne odaklanmalı

    • Hayır. Büyük veri gerçekten büyük veri sorunları olan kişiler tarafından yönlendirildi
      Hadoop, Google’daki çalışmalardan esinlenerek başladı ve veriyi Oracle’dan daha ucuz ve daha iyi bir şekilde ele almak isteyen dünyanın dört bir yanındaki şirketlerde popülerlik kazandı
      Spark, Hive/Pig gibi araçların karmaşıklığına bir çözüm olarak ortaya çıktı; şirketler güvenilir veri hatları kurabilir hale gelince bunun üzerine yapay zekayı ekleyebildiler
    • Ele alınan veri türüne bağlı. Coğrafi-uzamsal, algılama, uzaktan ölçüm gibi önemli veri modelleri “Hello, world” aşamasında bile petabayt ölçeğine ulaşabilir
      Bağlantı tıklama, mesaj gönderme, satın alma gibi bilinçli insan eylemlerinden üretilen veri modelleri genellikle küçüktür. Çünkü insan sayısının ve insanların saniyede üretebileceği bilinçli olay sayısının bir sınırı vardır
      Buna karşılık makinelerin ürettiği veri modellerinin hızı ve hacmi birkaç mertebe daha büyük olabilir ve veri modeli boyutunun da bir sınırı yoktur. Bu tür veriler, dünyaya dair pek çok gerçeğe insanın bilinçli veri modelleriyle ulaşılamamasını sağladığı için çoğu zaman en ilginç ve en az yararlanılan veridir
    • Genel olarak doğru, ancak IoT veya GIS gibi 10 TB üzeri veri kümelerinin çok yaygın olduğu istisnalar da var