Büyük veri ne kadar büyük?


86

Çok sayıda insan büyük veri terimini oldukça ticari bir şekilde kullanıyor, büyük veri kümelerinin hesaplamaya dahil olduğunu göstermenin bir yolu olarak ve bu nedenle potansiyel çözümlerin iyi performans göstermesi gerekiyor. Elbette, büyük veriler ölçeklenebilirlik ve verimlilik gibi her zaman ilişkili terimler taşırlar, ancak sorunu büyük bir veri sorunu olarak tanımlayan şey nedir ?

Hesaplama, veri madenciliği / bilgi alımı gibi bazı özel amaçlar ile mi ilgili olmalı yoksa veri kümesi yeterince büyükse, genel grafik problemleri için bir algoritma büyük veri olarak etiketlenebilir mi? Ayrıca, nasıl büyük olduğunu yeterince büyük (bu tanımlamak mümkündür ise)?


7
Verilerinizin normal kullanım için çok büyük olmaya başladığına dair güzel bir makale chrisstucchio.com/blog/2013/hadoop_hatred.html
Johnny000

18
"Excel'e yüklenemeyecek kadar büyük olan her şey" çalışan şaka.
Spacedman

1
Bu sadece bir terim olarak atılmakta olup olmamasına bağlıdır.
John Robertson

Tam olarak 1 GB. Bu kural kitabındaki kesinti. Belirsizlik için yer yoktur.
Hack-R,

Bu mükemmel bir soru. Cevap çeşitliliği ile belirtildiği gibi, tanım ... undefined
Manu H

Yanıtlar:


86

Bana göre (ilişkisel bir veritabanı arka planından geliyor), "Büyük Veri" esasen veri büyüklüğü ile ilgili değil (bu, şu ana kadarki cevapların toplamıdır).

"Büyük Veri" ve "Kötü Veri" yakından ilişkilidir. İlişkisel Veritabanları 'bozulmamış veri' gerektirir. Veriler veritabanındaysa, doğru, temiz ve% 100 güvenilirdir. İlişkisel Veritabanları "Mükemmel Veri" gerektirir ve verilerin veritabanına yüklenmeden önce iyi hazırlandığından emin olmak için büyük miktarda zaman, para ve hesap verebilirlik sağlanır. Veriler veritabanındaysa, 'müjde' olur ve sistemin gerçeklik anlayışını tanımlar.

"Büyük Veri", bu sorunu diğer yönden ele alır. Veriler iyi tanımlanmadı, çoğu yanlış olabilir ve çoğu eksik olabilir. Verinin yapısı ve düzeni ilişkisel olarak doğrusaldır.

Büyük Veri'nin yeterli hacme sahip olması gerekir; böylece hatalı veya eksik verilerin miktarı istatistiksel olarak önemsiz hale gelir. Verilerinizdeki hatalar birbirlerini iptal etmek için yeterince yaygınsa, eksik veriler ihmal edilebilecek kadar küçükse ve veri erişim gereksinimleriniz ve algoritmalarınız eksik ve yanlış verilerle bile işlevsel olduğunda, "Büyük Veri" ye sahip olursunuz. .

"Büyük Veri" gerçekten hacim ile ilgili değil, verilerin özellikleri ile ilgili.


6
1 Hemen hemen değil yaklaşık olmanın büyük veriler üzerinde stres dışarı takdir boyutu ne ziyade hakkında ve (özellikleri) içeriği ne .
Rubens

4
Bu çok canlandırıcı bir bakış açısı. Bunu daha önce hiç duymamıştım, ancak bu çok doğru. Bu, SQL ve NoSQL teknolojilerinin rekabetçi değil, tamamlayıcı olduğunu göstermektedir.
Jay Godse,

7
Yapılandırılmamış verilerden bahsediyorsun, büyük verilerden değil. Yapılandırılmamış veriler genellikle NoSQL çözümlerine ve uygulamada büyük verilere yol açar, ancak yine de farklıdır.
TheGrimmScientist,

Bunun, büyük verilerin ne olduğuna dair iyi bir iş perspektifi olduğunu düşünüyorum, ancak “büyük veriler ne kadar büyük?” Şeklinde belirtilen soruyu cevaplamıyor.
saat

33

Haklı olarak not ettiğiniz gibi, bu günlerde "büyük veriler" herkesin sahip olduklarını söylemek istediği bir şeydir; bu, insanların terimi nasıl tanımladıklarına dair belirli bir gevşeklik gerektirir. Yine de, genel olarak, eğer en azından Hadoop gibi büyük veri teknolojileriyle tamamlamadan, RDBMS gibi daha geleneksel teknolojilerle yönetmenin artık mümkün olmadığı durumlarda, kesinlikle büyük verilerle uğraştığınızı söyleyebilirim.

Durum böyle olması için verilerinizin gerçekte ne kadar büyük olması gerektiği tartışmalıdır. İşte , 5 TB'tan daha az veri için uygun olmadığını iddia eden (biraz kışkırtıcı) bir blog yazısı . (Daha açık olmak gerekirse, "5 TB'den daha az büyük veri değildir" anlamına gelmez, sadece "5 TB'dan daha az Hadoop'a ihtiyacınız olacak kadar büyük değildir" demiştir.)

Ancak, daha küçük veri kümelerinde bile, Hadoop gibi büyük veri teknolojileri, toplu işlemlere uygun olma, yapılandırılmamış verilerle (aynı zamanda yapısı önceden bilinmeyen veya değişmeyen veriler) iyi bir şekilde çalma, yatay ölçeklenebilirlik gibi diğer avantajlara sahip olabilir. mevcut sunucularınızı güçlendirmek yerine daha fazla düğüm ekleyerek ölçeklendirme) ve (yukarıdaki bağlantılardaki notlardaki yorumculardan biri olarak) veri işlemenizi harici veri kümeleriyle bütünleştirme yeteneği (bir haritayı düşünün - eşleştiricinin bulunduğu yeri azaltın) başka bir sunucuya çağrı yapar). NoSql veritabanları gibi büyük verilerle ilişkili diğer teknolojiler, hızlı bir performans ve tutarlı kullanılabilirliği vurgularken, büyük veri kümelerinin yanı sıra yarı yapılandırılmamış verileri idare edebilme ve yatay ölçeklendirebilir.

Elbette, geleneksel RDBMS, ACID garantileri (Atomiklik, Tutarlılık, İzolasyon, Dayanıklılık) ve belirli işlemler için daha iyi performansın yanı sıra daha standart hale getirilmiş, daha olgun ve (birçok kullanıcı için) daha aşina olmak üzere kendi avantajlarına sahiptir. Dolayısıyla, tartışmasız "büyük" veriler için bile, verilerinizin en az bir bölümünü geleneksel bir SQL veritabanına yüklemek ve bunu büyük veri teknolojileriyle birlikte kullanmak mantıklı olabilir.

Bu nedenle, daha cömert bir tanım, büyük veri teknolojilerinin sizin için bir katma değer sağlaması için yeterince büyük olduğu sürece büyük verilere sahip olmanızdır. Ancak görebildiğiniz gibi, bu yalnızca verilerinizin boyutuna değil, onunla nasıl çalışmak istediğinize ve esneklik, tutarlılık ve performans açısından ne tür gereksinimleriniz olduğuna bağlı olabilir. Nasıl verilerinizi kullandığınız kullandıysanız bunu olandan soruya daha alakalı için (örneğin veri madenciliği). Bununla birlikte, veri madenciliği ve makine öğrenmesi gibi kullanımların, çalışmak için yeterince büyük bir veri kümeniz varsa, faydalı sonuçlar vermesi daha olasıdır.


Bu yorum neredeyse 5 yaşında ve bir kısmı hala doğru olsa da, alıntı yaptığım blogdaki 5 TB eşiği artık kesinlikle doğru değil. Örneğin, Microsoft, 100 TB'a kadar "hiper ölçekli" SQL DB'ler sunar: docs.microsoft.com/en-us/azure/sql-database/… Elbette, büyük SQL DB'leri olan birçok kuruluşun da olduğu varsayılabilir: Farklı iş yüklerini desteklemek için bir Spark kümesi. Birini ya da diğerini seçmen gereken bir kural yok.
Tim Goodman

21

Dünyadaki toplam veri miktarı: 2012'de 2,8 zetabayt, 2015 yılına kadar ( kaynak ) 8 katına ulaşması ve 40 ayın iki katına çıkması bekleniyor . Bundan daha büyüğü olamaz :)

Tek bir büyük organizasyonun örneği olarak, Facebook günde 100 terabaytlık bir 100 petabaytlık bir depoya çekiyor ve 2012'den itibaren günde 70k sorguyu kullanıyor ( kaynak ) Mevcut depoları> 300 petabayt.

Büyük veri muhtemelen Facebook sayısının iyi bir bölümüdür (1/100 büyük olasılıkla evet, 1/10000 büyük olasılıkla hayır: tek bir sayı değil, bir spektrumdur).

Boyutuna ek olarak, onu "büyük" yapan özelliklerden bazıları şunlardır:

  • aktif olarak analiz edilir, sadece kaydedilmez ("Büyük verilerden faydalanmıyorsanız, o zaman büyük verilere sahip değilsiniz, sadece bir veri kümeniz var" Jay Parikh @ Facebook)

  • veri ambarı inşa etmek ve işletmek büyük bir altyapı projesidir

  • önemli oranda büyüyor

  • yapılandırılmamış veya düzensiz yapıya sahip

Gartner tanımı: "Büyük veri, yüksek işlem hacmi, yüksek hız ve / veya yeni işlem biçimleri gerektiren yüksek çeşitlilikte bilgi varlıklarıdır" (3V'ler) Bu nedenle, "bigness" in tamamen veri kümesinin büyüklüğü ile ilgili olmadığını da düşünürler. ayrıca sürat, yapı ve ihtiyaç duyulan alet çeşitleri hakkında.


2
Dünyadaki toplam veri miktarı her 40 ayda bir ikiye katlanırsa, o zaman kesinlikle bundan daha büyük olabilir . ; p
Air

2
Diğerleri 4 V’lik büyük veri IBM’i, hatta 5 V’li DAVE BEULKE 2011
nmtoken


13

Bana göre Büyük Veri araçlarla ilgili (sonuçta, başladığı yer); "büyük" bir veri kümesi, geleneksel araçlarla kullanılamayacak kadar büyüktür - özellikle, tek bir makine yerine bir kümede depolama ve işleme gerektirecek kadar büyüktür. Bu, geleneksel bir RDBMS'yi dışlar ve işleme için yeni teknikler ister; özellikle, çeşitli Hadoop benzeri çerçeveler, bir hesaplamanın küme üzerine dağıtılmasını kolaylaştırarak bu hesaplamanın şeklini kısıtlama pahasına olmasını sağlar. Referansı http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html adresine göndereceğim.; Büyük Veri teknikleri, başka türlü işlenemeyecek kadar büyük olan veri kümeleri için son çaredir. Herhangi bir amaç için herhangi bir veri setinin yeteri kadar büyük olsaydı kalifiye olabileceğini söyleyebilirim - eğer problemin şekli mevcut "büyük veri" araçlarının uygun olmadığı şekilde ise, o zaman muhtemelen yeni bir ürün ortaya koymak daha iyi olurdu ad.

Elbette bazı örtüşme var; last.fm'de (kısaca) çalıştığımda, Hadoop'u kullanarak aynı 50TB veri setinde ve oldukça saçma bir sunucuda bir SQL veritabanında çalıştık (1TB RAM olduğunu hatırlıyorum ve bu birkaç yıl önce). Hangi anlamda üzerinde çalıştığınıza bağlı olarak, bu bir anlamda hem büyük veri hem de büyük veri anlamına geliyordu. Ancak bunun doğru bir karakterizasyon olduğunu düşünüyorum; Hadoop işlerinde çalışan insanlar, Büyük Veri konferanslarına ve web sitelerine gitmeyi faydalı bulurken, SQL işlerinde çalışanlar yoktu.



7

Büyük Veri, veri hacmi tarafından tanımlanır, bu doğru, ancak yalnızca değil. Büyük verinin özellik bir depolamak için ihtiyaç vardır çok ait çeşitli ve bazen de yapılandırılmamış maddeleri her zaman ve gelen sensörlerin ton , genellikle yıl veya on yıl .

Ayrıca, ölçeklenebilir bir şeye ihtiyacınız vardır, böylece verileri geri bulmanız yarım yıl almaz.

İşte geleneksel yöntemlerin artık işe yaramayacağı büyük veri geliyor. SQL ölçeklenebilir değildir. Ve SQL çok yapılandırılmış ve bağlantılı verilerle çalışır (tüm bu Birincil ve yabancı anahtar karmaşası, innerjoin, gömülü istek ...).

Temel olarak, depolama daha ucuz ve daha ucuz hale geldiğinden ve veriler gittikçe daha değerli hale geldiğinden, büyük yönetici mühendisden her şeyi kaydetmesini ister. Tüm bu mobil, sosyal ağ, katıştırılmış öğeler vb. İçeren yeni sensörlere bu tonları ekleyin. Klasik yöntemler işe yaramayacağından yeni teknolojiler bulmalılar (her şeyi dosyalarda, json formatında, büyük indeksli, noSQL dediğimiz dosyada saklamak).

Bu yüzden Büyük Veri çok büyük olabilir, ancak çok büyük olmayabilir, ancak ham bir formatta hızlı ve çalışır halde saklanması gereken yapılandırılmamış veya çeşitli verileri karmaşık hale getirebilir. Önce odaklanıyor ve saklıyoruz, sonra da herşeyi birbirine nasıl bağlayacağımıza bakıyoruz.


6

Big Data'nın genomikte, özellikle de novo meclisinde nasıl olduğunu paylaşacağım.

Genomunuzu dizilediğimizde (örneğin: yeni genleri tespit eder), milyarlarca yeni nesil kısa okuma yaparız. Bazı okumaları bir araya getirmeye çalıştığımız aşağıdaki resme bakın.

görüntü tanımını buraya girin

Bu basit görünüyor? Peki ya o okurlardan milyar tane varsa? Ya bu okumalar sıralama hataları içeriyorsa? Peki ya RAM'iniz okumaya devam edecek kadar hafızaya sahip değilse? Çok yaygın Alu Elemanı gibi tekrarlayan DNA bölgeleri ne durumda ?

De-novo montajı bir De-Bruijn grafiği çizilerek yapılır :

görüntü tanımını buraya girin

Grafik, örtüşen okumaları temsil eden akıllı bir mayınlı veri yapısıdır. Mükemmel değil ama tüm olası çakışmaları oluşturmak ve bunları bir dizide saklamaktan daha iyidir.

Montaj işleminin tamamlanması günler alabilir çünkü bir montajcının geçmesi ve çökmesi gereken çok sayıda yol vardır.

Genomikte, şu durumlarda büyük bir veriye sahipsiniz:

  • Tüm kombinasyonları zorlayamazsın
  • Bilgisayarınız verileri depolamak için yeterli fiziksel belleğe sahip değil
  • Boyutları azaltmanız gerekir (örneğin, gereksiz grafik yollarını daraltma)
  • Sinirleniyorsun çünkü bir şey yapmak için günlerce beklemek zorundasın
  • Verileri temsil etmek için özel bir veri yapısına ihtiyacınız var.
  • Veri kümenizi hatalar için filtrelemeniz gerekir (örn: sıralama hataları)

https://en.wikipedia.org/wiki/De_Bruijn_graph


5

Algoritmaları grafik haline getirmek için özel bir şey var, o zaman özel kılan orijinal sorular, o da verileri esasen bölümlendirme yeteneği hakkında.

Bazı şeyler için, bir dizideki sayıları sıralamak gibi, veri yapısındaki sorunu daha küçük ayrık parçalara bölmek çok da zor değildir, örneğin : Burada: Paralel yerinde birleştirme sıralaması

NPhard

Bu yüzden sıralamak için 10 GB'lık numaralar normal bir PC'de çok iyi bir şekilde yaklaşılabilir bir sorun olabilirken (sadece dinamik programlama yoluyla girebilir ve program akışı hakkında çok iyi bir öngörülebilirlik elde edebilirsiniz), 10GB'lık bir grafik veri yapısıyla çalışmak zaten zorlu olabilir.

GraphX gibi metodların kullanımı ve grafiklerin içsel zorluklarını bir miktar aşmak için özel hesaplama paradigmaları gibi çok sayıda özel çerçeve vardır .

Sorunuzu kısaca cevaplamak için: Başkaları tarafından daha önce de belirtildiği gibi, verileriniz normal bir PC'de ana belleğe sığmadığında ancak sorununuzu cevaplamak için hepsine ihtiyaç duyduğunuzda, verilerinizin zaten biraz büyük olduğu konusunda iyi bir ipucu. Kesin etiketleme olsa da, biraz veri yapısı ve sorulan soru üzerinde düşünüyorum.


4

Bence büyük veri, boyutun istediğiniz şeyi yapmanızı engellediği noktada başlar. Çoğu senaryoda, uygulanabilir olduğu düşünülen çalışma süresinde bir sınır vardır. Bazı durumlarda bir saat, bazı durumlarda ise birkaç hafta olabilir. Veriler, yalnızca O (n) algoritmalarının uygulanabilir zaman aralığında çalışabileceği kadar büyük olmadığı sürece, büyük verilere ulaşmadınız.

Hacim, teknoloji seviyesi ve özel algoritmalar agnostik olduğu için bu tanımı seviyorum. Kaynaklara agnostik olmadığı için, lisansüstü bir öğrenci Google'dan önce büyük veri noktasına ulaşacaktır.

Verinin ne kadar büyük olduğunu ölçebilmek için, onu yedeklemek için gereken zamanı düşünmeyi seviyorum. Teknoloji ilerlediğinden, birkaç yıl önce büyük sayılan hacimler artık ılımlı. Yedekleme süresi, teknoloji geliştikçe tıpkı öğrenme algoritmalarının çalışma süresi gibi artar. Y bayt veri kümesinin değil, yedeklemenin X saat sürdüğü veri kümesi hakkında konuşmanın daha mantıklı olduğunu düşünüyorum.

PS.

Büyük veri noktasına ulaşmış olsanız ve karmaşıklık algoritmalarını O (n) 'den daha fazla çalıştıramasanız bile, bu tür algoritmalardan faydalanmak için yapabileceğiniz birçok şeyin olduğunu not etmek önemlidir.

Örneğin, Özellik seçimi, çalışan birçok algoritmanın bağlı olduğu özellik sayısını azaltabilir. Birçok uzun kuyruk dağılımında, baştaki birkaç maddeye odaklanmanın yararı olabilir. Bir örnek kullanabilir ve üzerinde yavaş algoritmalar çalıştırabilirsiniz.


O(n)

4

Veriler "Büyük Veri" dir, öyle bir hacme sahipse, iki veya daha fazla emtia bilgisayar üzerinde analiz etmek, bir üst uç bilgisayardan daha ucuzdur.

Bu aslında Google’ın “BigFiles” dosya sisteminin nasıl oluştuğunu açıklar. Page ve Brin, web dizinlerini depolamak ve aramak için süslü bir Sun sunucusuna sahip olamadılar, bu yüzden birkaç emtia bilgisayarı bağladım.


1

@Dan Levin'in söyledikleriyle aynı fikirdeyim. Nihayetinde veriden yalnızca saklamak yerine faydalı bilgiler almak istediğimizden, "Büyük veri" olarak adlandırılan şeyi belirlemesi gereken algoritmaları / sistemleri öğrenme yeteneğidir . ML sistemleri geliştikçe, bugün Büyük Veri'nin ne olduğu, yarın Büyük Veri olmayacak.

Büyük verileri tanımlamanın bir yolu olabilir:

  • Büyük veri : Tipik bir iş istasyonunda ML modellerini makul sürede (1-2 saat) oluşturamayacağınız veriler (4GB RAM ile)
  • Büyük olmayan veriler : yukarıdakilerin tamamlayıcısı

Bu tanımı farz edersek, tek bir satır tarafından kullanılan bellek (tek bir veri noktası için tüm değişkenler) makine RAM'ini geçmediği sürece, Büyük olmayan veri rejiminde olmalıyız .

Not: Vowpal Wabbit (bugüne kadarki en hızlı ML sistemi), tek bir satır (veri noktası) <RAM (4GB) olduğu sürece ayarlanmış herhangi bir veriyi öğrenebilir. Satır sayısı bir sınırlama değildir, çünkü çoklu çekirdeklerde SGD kullanır. Deneyimden bahsederken, bir dizüstü bilgisayarda günde 10 k özellik ve 10MN sıra içeren bir model çalıştırabilirsiniz.


1

"Büyük veri" tam anlamıyla sadece çok fazla veridir. Her şeyden çok bir pazarlama terimi olsa da, bunun anlamı genellikle verileri bir kerede analiz edemeyeceğiniz kadar çok veriye sahip olmanızdır, çünkü veriyi bellekte tutması için gereken hafıza miktarı (RAM) işlemek ve analiz etmek, mevcut hafıza miktarından daha büyüktür.

Bu, analizlerin genellikle verinin diğer bölümleriyle karşılaştırmak için modellerin oluşturulmasına izin veren rastgele veri bölümleri üzerinde yapılması gerektiği anlamına gelir.

Licensed under cc by-sa 3.0 with attribution required.