Наскільки великі великі дані?

Багато людей використовують термін великі дані досить комерційним шляхом, як засіб вказування на те, що великі набори даних беруть участь у обчисленнях, і тому потенційні рішення повинні мати хороші показники. Звичайно, великі дані завжди містять пов'язані терміни, такі як масштабованість та ефективність, але що саме визначає проблему як велику проблему даних ?

Чи має бути обчислення пов'язане з якимось набором конкретних цілей, як, наприклад, обробка даних / пошук інформації, чи може алгоритм загальних проблем із графіком позначатись великими даними, якщо набір даних буде достатньо великим ? Крім того , як великий є досить великим (якщо це можливо визначити)?

Для мене (виходячи з фона реляційних баз даних), "Big Data" - це не в першу чергу про розмір даних (що становить основну частину того, що інші відповіді поки що).

"Великі дані" та "Погані дані" тісно пов'язані. Реляційні бази даних вимагають "незайманих даних". Якщо дані є в базі даних, вони є точними, чистими і на 100% надійними. Для реляційних баз даних потрібні "великі дані", і перед завантаженням у базу даних вкладається величезна кількість часу, грошей та підзвітності. Якщо дані є в базі даних, це "євангеліє", і це визначає системне розуміння реальності.

"Big Data" вирішує цю проблему з іншого напрямку. Дані погано визначені, значна частина їх може бути неточною, і значна частина їх може бути відсутнім. Структура та компонування даних лінійні на відміну від реляційних.

Big Data повинен мати достатній обсяг, щоб кількість поганих даних або відсутніх даних ставала статистично незначною. Коли помилки у ваших даних досить поширені, щоб скасувати одне одного, коли відсутні дані пропорційно досить малі, щоб бути незначними і коли ваші вимоги та алгоритми доступу до даних функціонують навіть із неповними та неточними даними, тоді у вас є "великі дані" .

"Великі дані" - це насправді не об'єм, це характеристика даних.

Як ви правильно зазначаєте, в наші дні "великі дані" - це те, що кожен хоче сказати, що має, що тягне за собою певну нещільність у тому, як люди визначають цей термін. Однак, як правило, я б сказав, що ви, звичайно, маєте справу з великими даними, якщо масштаб такий, що керувати більш традиційними технологіями, такими як RDBMS, принаймні неможливо, принаймні, не доповнюючи їх такими технологіями великих даних, як Hadoop.

Наскільки насправді мають бути ваші дані для того, щоб це було так, є дискусійним. Ось (дещо провокаційний) пост у блозі, який стверджує, що насправді це не так для менш ніж 5 ТБ даних. (Щоб було зрозуміло, він не стверджує, що "менше 5 ТБ - це не великі дані", а просто "Менше 5 ТБ недостатньо велике, що вам потрібно Hadoop".)

Але навіть у менших наборах даних великі технології даних, такі як Hadoop, можуть мати інші переваги, включаючи те, що вони добре підходять для пакетних операцій, добре грають з неструктурованими даними (а також з даними, структура яких не відома заздалегідь або можуть змінитися), горизонтальна масштабованість ( масштабування, додаючи більше вузлів замість покращення існуючих серверів) та (як один із коментаторів вищезазначених поштових приміток) можливість інтегрувати обробку даних із зовнішніми наборами даних (подумайте про зменшення карти, де відображається здійснює дзвінок на інший сервер). Інші технології, пов’язані з великими даними, такі як бази даних NoSql, підкреслюють швидку продуктивність та постійну доступність під час роботи з великими наборами даних, а також здатні обробляти напівструктурні дані та масштабувати горизонтально.

Звичайно, традиційні RDBMS мають свої переваги, включаючи гарантії кислотних кислот (Atomicity, Consistency, Isolation, Durability) та кращі показники для певних операцій, а також більш стандартизовані, зріліші та (для багатьох користувачів) більш звичні. Тож навіть для безперечно "великих" даних може бути доцільним завантаження хоча б частини ваших даних у традиційну базу даних SQL та використання її у поєднанні з великими технологіями передачі даних.

Отже, більш щедрим визначенням буде те, що у вас є великі дані, якщо вони досить великі, що технології великих даних надають вам додаткову вартість. Але, як ви бачите, це може залежати не тільки від розміру ваших даних, але і від того, як ви хочете працювати з ними, і яких вимог ви маєте щодо гнучкості, послідовності та продуктивності. Як ви використовуєте ваші дані більш безпосереднє відношення до питання , ніж те , що ви використовуєте його для (наприклад , інтелектуального аналізу даних). Однак, такі випадки, як обробка даних та машинне навчання, швидше дають корисні результати, якщо у вас є достатньо великий набір даних для роботи.

Загальний обсяг даних у світі: 2,8 zetabytes в 2012 році, за оцінками, до 8 zetabytes до 2015 року ( джерело ) та з подвоєнням 40 місяців. Неможливо отримати більше за це :)

Як приклад однієї великої організації, Facebook набирає по 500 терабайт на день, на 100 петабайтних складів і виконує 70 к запитів на день на ньому станом на 2012 рік ( джерело ) Їх поточний склад становить> 300 петабайт.

Великі дані - це, мабуть, хороша частка номерів у Facebook (1/100, мабуть, так, 1/10000, мабуть, ні: це спектр, не одне число).

Окрім розміру, деякі функції, які роблять його "великим":

• він активно аналізується, а не просто зберігається (цитата "Якщо ви не користуєтеся великими даними, то у вас немає великих даних, у вас є просто купа даних" Джей Парих @ Facebook)

• створення та експлуатація сховища даних є важливим інфраструктурним проектом

• вона зростає зі значними темпами

• він неструктурований або має неправильну структуру

Визначення Gartner: "Великі дані - це великий об'єм, висока швидкість та / або інформаційні ресурси високої різноманітності, які потребують нових форм обробки" (3В). Тому вони також вважають, що "масштабність" полягає не лише в розмірі набору даних, але також про швидкість і структуру та вид необхідних інструментів.

Для мене Big Data - це насамперед про інструменти (зрештою, саме з цього і почалося); "великий" набір даних - це занадто великий, щоб обробляти звичайними інструментами - зокрема, досить великими, щоб вимагати зберігання та обробки на кластері, а не на одній машині. Це виключає звичайні RDBMS та вимагає нових методів обробки; зокрема, різні структури, схожі на Hadoop, полегшують розподіл обчислень по кластеру за рахунок обмеження форми цього обчислення. Я друге посилання на http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html; Технології Big Data - це крайній прийом для наборів даних, які просто занадто великі для обробки будь-яким іншим способом. Я б сказав, що будь-який набір даних для будь-яких цілей може бути кваліфікованим, якщо він буде досить великим - хоча якщо форма проблеми така, що існуючі інструменти "великих даних" не підходять, то, мабуть, було б краще придумати новий назва.

Звичайно, є певне перекриття; коли я (коротко) працював на last.fm, ми працювали над тим самим набором даних 50TB за допомогою Hadoop, а також у базі даних SQL на досить смішному сервері (я пам’ятаю, він мав 1 Тб оперативної пам’яті, і це було кілька років тому). Що в певному сенсі означало, що це є і не великими даними, залежно від того, над якою роботою ви працювали. Але я думаю, що це точна характеристика; людям, які працювали на роботах Hadoop, було корисно відвідувати конференції та веб-сайти Big Data, тоді як люди, які працювали на SQL-роботах.

Дані стають "великими", коли один товарний комп'ютер вже не може обробляти кількість наявних у вас даних. Він позначає момент, коли потрібно почати думати про створення суперкомп'ютерів або використання кластерів для обробки даних.

Великі дані визначаються обсягом даних, це правильно, але не тільки. Особливість великих даних є те , що вам потрібно зберігати багато з різних , а іноді неструктурованих годувань всіх часів і від тонни датчиків , як правило , в протягом багатьох років або десяти років .

Крім того, вам потрібно щось масштабоване, щоб не знадобитися півроку, щоб знайти дані.

Отже, ось великі дані, де традиційний метод більше не працюватиме. SQL не масштабується. І SQL працює з дуже структурованими і пов'язаними даними (з усіма цими першокласними і зовнішніми безладдями, внутрішнім з'єднанням, імбризованим запитом ...).

В основному, оскільки зберігання стає дешевшим і дешевшим, а дані стають все більш цінними, великий менеджер просить інженера записати все. Додайте до цього тонни нових датчиків із усіма цими мобільними, соціальними мережами, вбудованими елементами ... тощо. Оскільки класичні методи не спрацюють, їм доведеться знаходити нові технології (зберігання всього у файлах, у форматі json, з великим індексом, що ми називаємо noSQL).

Тож Big Data можуть бути дуже великими, але вони можуть бути не такими великими, але складними неструктурованими або різними даними, які потрібно швидко та швидко зберігати у необробленому форматі. Спочатку ми фокусуємось і зберігаємо, а потім дивимось, як все пов’язати разом.

Я поділюся, що таке великі дані в геноміці, зокрема збірка de-novo.

Коли ми послідовно проводимо послідовність вашого геному (наприклад: виявляємо нові гени), ми приймаємо мільярди коротких читань наступного покоління. Подивіться на зображення нижче, де ми намагаємось зібрати кілька прочитаних.

Це виглядає просто? Але що робити, якщо у вас є мільярд цих прочитаних? Що робити, якщо ці читання містять помилки послідовності? Що робити, якщо у вашої оперативної пам’яті не вистачає пам’яті, щоб зберігати показання? Що з повторюваними ділянками ДНК, наприклад, дуже поширеним елементом Alu ?

Збірка De-novo проводиться шляхом побудови графіка De-Bruijn :

Графік є розумною мінімізованою структурою даних для представлення збігів, що перекриваються. Це не ідеально, але це краще, ніж генерувати всі можливі перекриття та зберігати їх у масиві.

Процес складання може зайняти кілька днів, оскільки існує досить багато шляхів, які асемблеру потрібно буде пройти та згортати.

У геноміці у вас є великі дані, коли:

• Ви не можете жорстоко форсувати всі комбінації
• На вашому комп'ютері недостатньо фізичної пам'яті для зберігання даних
• Потрібно зменшити розміри (наприклад: згортання зайвих контурів графіків)
• Вас розгнівають, бо вам доведеться чекати днів, щоб зробити що-небудь
• Для представлення даних вам потрібна спеціальна структура даних
• Вам потрібно відфільтрувати набір даних щодо помилок (наприклад: помилки в послідовності)

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

Існує особлива річ для графіки алгоритмів, ви створюєте оригінальні запитання, що робить потім особливим, а саме про те, що він здатний істотно розділяти дані.

Для деяких речей, як сортування чисел у масиві, не надто складно розділити проблему на структурі даних на менші диз'юнктивні фрагменти, наприклад, тут: Паралельне місце злиття сортування

$NP-hard$

Отже, хоча сортування чисел 10 ГБ може бути дуже доступною проблемою на звичайному ПК (Ви можете просто ввійти за допомогою динамічного програмування та мати дуже хорошу передбачуваність щодо потоку програми), робота з структурою даних графіків 10 ГБ вже може бути важкою.

Існує ряд спеціалізованих фреймворків, таких як GraphX ​​з використанням методів та спеціальних обчислювальних парадигм, щоб дещо обійти властиві завдання графіків.

Отже, щоб коротко відповісти на ваше запитання: Як вже згадували інші, коли ваші дані не входять у основну пам'ять на звичайному ПК, але вам потрібно все це, щоб відповісти на вашу проблему, - це хороший натяк на те, що ваші дані вже дещо великі. Точне маркування, хоча залежить, я трохи думаю про структуру даних і запитання.

Я думаю, що великі дані починаються з того місця, коли розмір заважає тобі робити те, що ти хочеш. У більшості сценаріїв існує обмеження часу виконання, яке вважається можливим. В деяких випадках це година, в деяких випадках це може бути кілька тижнів. Поки дані не є достатньо великими, щоб тільки O (n) алгоритми могли працювати у здійснені часові рамки, ви не досягли великих даних.

Мені подобається це визначення, оскільки воно є агностичним щодо обсягу, рівня технології та конкретних алгоритмів. До ресурсів це не агресивно, тому студент досягне великого рівня даних перед Google.

Для того, щоб можна було кількісно оцінити, наскільки великі дані, я хотів би розглянути час, необхідний для резервного копіювання. З часом розвитку технології обсяги, які кілька років тому вважалися великими, зараз помірні. Час резервного копіювання поліпшується, як покращується технологія, так само як і час роботи алгоритмів навчання. Я вважаю, що розумніше говорити про набір даних, на який потрібно тривати резервне копіювання X годин, а не набір даних у байтах Y.

PS.

Важливо зауважити, що навіть якщо ви досягли великої точки даних і не можете запускати алгоритми складності більше, ніж O (n), прямо, вперед, ви можете зробити багато, щоб все-таки скористатися такими алгоритмами.

Наприклад, вибір функції може зменшити кількість функцій, від яких залежить багато алгоритмів роботи. Для багатьох довгих розподілів хвостів фокусування на кількох предметах в голові може бути корисним. Можна використовувати зразок і запускати на ньому повільніші алгоритми.

Дані - це "великі дані", якщо вони настільки об'ємні, що аналізувати їх на двох або більше товарних комп'ютерах дешевше, ніж на одному комп'ютері високого класу.

Це, по суті, як виникла файлова система Google "BigFiles". Пейдж і Брін не могли дозволити собі фантазійний сервер Sun для зберігання та пошуку в їх веб-індексі, тому підключили кілька товарних комп'ютерів

Я схильний погоджуватися з тим, що @Dan Levin вже сказав. Зрештою, оскільки ми хочемо отримати корисні відомості з даних, а не просто їх зберігати, саме здатність вивчати алгоритми / системи повинні визначати, що називається "великими даними". З розвитком систем ML те, що було Big data сьогодні, завтра більше не буде Big Data.

Одним із способів визначення великих даних може бути:

• Основні дані : дані, за якими ви не можете побудувати моделі ML в розумний час (1-2 години) на типовій робочій станції (скажімо, 4 Гб оперативної пам’яті)
• Невеликі дані : доповнення до вищезазначеного

Якщо припустити це визначення, якщо пам'ять, зайнята окремим рядком (усі змінні для однієї точки даних), не перевищує машинну оперативну пам’ять, ми повинні знаходитись у режимі не великих даних .

Примітка: Vowpal Wabbit (на сьогоднішній день найшвидша система ML на сьогодні) може дізнатися на будь-якому наборі даних, якщо окремий рядок (точка даних) <RAM (скажімо, 4 Гб). Кількість рядків не є обмеженням, оскільки вона використовує SGD на декількох ядрах. Виходячи з досвіду, ви можете тренувати модель з 10 к функціями та 10МН рядками на ноутбуці за день.

"Великі дані" - це буквально просто велика кількість даних. Хоча це більше маркетинговий термін, ніж усе, що означає, що у вас є стільки даних, що ви не можете проаналізувати всі дані одразу, тому що об'єм пам'яті (ОЗП), який потрібно, щоб утримувати дані в пам'яті обробляти і аналізувати його більше, ніж об'єм доступної пам'яті.

Це означає, що аналіз зазвичай доводиться робити на випадкових сегментах даних, що дозволяє будувати моделі для порівняння з іншими частинами даних.