Насколько велики большие данные?

Многие люди используют термин « большие данные» довольно коммерческим способом, чтобы показать, что в вычислениях участвуют большие наборы данных, и поэтому потенциальные решения должны иметь хорошую производительность. Конечно, большие данные всегда имеют связанные термины, такие как масштабируемость и эффективность, но что именно определяет проблему как проблему больших данных ?

Должно ли вычисление быть связано с каким-то определенным набором целей, таких как интеллектуальный анализ данных / поиск информации, или же алгоритм для общих проблем с графами может быть помечен как большие данные, если набор данных был достаточно большим ? Кроме того , как большой является достаточно большим (если это возможно определить)?

Для меня (исходя из опыта работы с реляционными базами данных), «Большие данные» - это в первую очередь не размер данных (что составляет большую часть того, что есть в других ответах).

«Большие данные» и «Плохие данные» тесно связаны. Реляционные базы данных требуют «нетронутых данных». Если данные находятся в базе данных, они точны, чисты и надежны на 100%. Реляционные базы данных требуют «больших данных», и огромное количество времени, денег и ответственности тратится на то, чтобы убедиться, что данные хорошо подготовлены, прежде чем загружать их в базу данных. Если данные находятся в базе данных, это «Евангелие», и оно определяет системное понимание реальности.

«Большие данные» решают эту проблему с другой стороны. Данные плохо определены, многие из них могут быть неточными, а большая часть фактически может отсутствовать. Структура и расположение данных являются линейными, а не реляционными.

Большие данные должны иметь достаточный объем, чтобы количество неверных данных или отсутствующих данных стало статистически незначимым. Когда ошибки в ваших данных достаточно распространены, чтобы компенсировать друг друга, когда недостающие данные пропорционально малы, чтобы их можно было пренебречь, и когда ваши требования и алгоритмы доступа к данным функционируют даже с неполными и неточными данными, тогда у вас есть «Большие данные» ,

«Большие данные» на самом деле не о объеме, а о характеристиках данных.

Как вы правильно заметили, в наши дни «большие данные» - это то, что каждый хочет сказать, что у них есть, что влечет за собой некоторую разболтанность в том, как люди определяют термин. В целом, однако, я бы сказал, что вы, безусловно, имеете дело с большими данными, если масштаб таков, что уже невозможно управлять более традиционными технологиями, такими как RDBMS, по крайней мере, не дополняя их технологиями больших данных, такими как Hadoop.

То, насколько большими должны быть ваши данные для этого, является спорным. Вот (несколько провокационное) сообщение в блоге, в котором утверждается, что на самом деле это не так для данных объемом менее 5 ТБ. (Для ясности, он не утверждает, что «меньше 5 ТБ - это не большие данные», а просто «Меньше 5 ТБ - это недостаточно, чтобы вам нужен Hadoop».)

Но даже для небольших наборов данных технологии больших данных, такие как Hadoop, могут иметь и другие преимущества, в том числе то, что они хорошо подходят для пакетных операций, хорошо играют с неструктурированными данными (а также с данными, структура которых заранее неизвестна или может измениться), горизонтальной масштабируемостью ( масштабирование путем добавления большего количества узлов вместо усиления существующих серверов) и (как один из комментаторов вышеупомянутых связанных заметок к заметкам) возможность интегрировать обработку данных с внешними наборами данных (подумайте о сокращении карты там, где сопоставитель) звонит на другой сервер). Другие технологии, связанные с большими данными, такие как базы данных NoSql, подчеркивают высокую производительность и постоянную доступность при работе с большими наборами данных, а также способностью обрабатывать полуструктурированные данные и масштабироваться по горизонтали.

Конечно, традиционные СУБД имеют свои преимущества, в том числе гарантии ACID (атомарность, согласованность, изоляция, долговечность) и лучшую производительность для определенных операций, а также более стандартизированные, более зрелые и (для многих пользователей) более знакомые. Таким образом, даже для неоспоримо «больших» данных, это может иметь смысл для загрузки, по меньшей мере, части данных в традиционную базу данных SQL и использовать его в сочетании с большими технологиями передачи данных.

Итак, более щедрым определением будет то, что у вас есть большие данные, если они достаточно велики, чтобы технологии больших данных предоставляли вам дополнительную ценность. Но, как вы можете видеть, это может зависеть не только от размера ваших данных, но и от того, как вы хотите с ними работать, и от того, какие у вас требования в отношении гибкости, согласованности и производительности. Как вы используете ваши данные более непосредственное отношение к вопросу , чем то , что вы используете его для (например , интеллектуального анализа данных). Тем не менее, такие виды использования, как интеллектуальный анализ данных и машинное обучение, с большей вероятностью принесут полезные результаты, если у вас достаточно большой набор данных для работы.

Общий объем данных в мире: 2,8 зетабайта в 2012 году, по оценкам, к 2015 году достигнет 8 зетабайтов ( источник ), а время удвоения составит 40 месяцев. Не может быть больше, чем это :)

В качестве примера одной крупной организации Facebook загружает 500 терабайт в день в хранилище объемом 100 петабайт и выполняет по нему 70 тыс. Запросов в день по состоянию на 2012 год ( источник ). Их текущий склад составляет> 300 петабайт.

Большие данные - это, вероятно, хорошая доля чисел Facebook (1/100, вероятно, да, 1/10000, вероятно, нет: это спектр, а не одно число).

В дополнение к размеру, некоторые из функций, которые делают его «большим»:

• он активно анализируется, а не просто сохраняется (цитата «Если вы не пользуетесь большими данными, значит, у вас нет больших данных, у вас есть просто куча данных» Jay Parikh @ Facebook)

• создание и эксплуатация хранилища данных является крупным инфраструктурным проектом

• оно растет значительными темпами

• он неструктурирован или имеет неправильную структуру

Определение Gartner: «Большие данные - это информационные ресурсы большого объема, высокой скорости и / или большого разнообразия, которые требуют новых форм обработки» (3 В). Таким образом, они также думают, что «размер» не полностью соответствует размеру набора данных, но также о скорости и структуре, а также о видах необходимых инструментов.

Для меня Big Data - это, прежде всего, инструменты (в конце концов, именно там они и начались); «Большой» набор данных - это слишком большой набор данных, чтобы его можно было обрабатывать обычными инструментами, в частности, достаточно большой, чтобы требовать хранения и обработки в кластере, а не на одной машине. Это исключает обычные СУБД и требует новых методов обработки; в частности, различные Hadoop-подобные структуры позволяют легко распределять вычисления по кластеру за счет ограничения формы этих вычислений. Я добавлю ссылку на http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html; Методы больших данных являются последним средством для наборов данных, которые просто слишком велики, чтобы их можно было обрабатывать любым другим способом. Я бы сказал, что любой набор данных для любых целей может быть квалифицирован, если он достаточно велик - хотя, если форма проблемы такова, что существующие инструменты «больших данных» не подходят, то, вероятно, было бы лучше придумать новый имя.

Конечно, есть некоторые совпадения; когда я (кратко) работал над last.fm, мы работали над тем же набором данных объемом 50 ТБ, используя Hadoop, а также над базой данных SQL на довольно нелепом сервере (я помню, что он имел 1 ТБ ОЗУ, а это несколько лет назад). Что в некотором смысле означало, что оба были, а не большие данные, в зависимости от того, над какой работой вы работали. Но я думаю, что это точная характеристика; люди, которые работали над заданиями Hadoop, находили полезным посещать конференции и веб-сайты Big Data, а люди, которые работали над заданиями SQL, этого не делали.

Данные становятся «большими», когда отдельный компьютер больше не может обрабатывать объем данных, которые у вас есть. Он обозначает момент, когда вам нужно задуматься о создании суперкомпьютеров или использовании кластеров для обработки ваших данных.

Большие данные определяются объемом данных, это верно, но не только. Особенность больших данных является то , что вам нужно хранить много из различных , а иногда неструктурированных питаний всех времен и от тонны датчиков , как правило , в течение многих лет или десяти лет .

Кроме того, вам нужно что-то масштабируемое, чтобы вам не понадобилось полгода, чтобы найти данные.

Итак, вот большие данные, где традиционный метод больше не работает. SQL не масштабируется. И SQL работает с очень структурированными и связанными данными (со всеми этими первичными и внешними ключами, внутренним соединением, скрытым запросом ...).

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

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

Я поделюсь, как большие данные похожи на геномику, в частности сборку de-novo.

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

Это выглядит просто? Но что, если у вас есть миллиард таких чтений? Что если эти чтения содержат ошибки последовательности? Что делать, если в вашей оперативной памяти недостаточно памяти для чтения? Как насчет повторяющихся областей ДНК, таких как очень распространенный элемент Alu ?

Сборка de-novo выполняется путем построения графа Де-Брейна :

График представляет собой интеллектуальную структуру данных для представления перекрывающихся операций чтения. Это не идеально, но лучше, чем генерировать все возможные перекрытия и сохранять их в массиве.

Процесс сборки может занять несколько дней, потому что существует множество путей, которые ассемблер должен пройти и свернуть.

В области геномики у вас есть большие данные, когда:

• Вы не можете перебрать все комбинации
• У вашего компьютера недостаточно физической памяти для хранения данных
• Вам нужно уменьшить размеры (например: свертывание избыточных путей графа)
• Вы разозлились, потому что вам пришлось бы ждать дни, чтобы сделать что-нибудь
• Вам нужна специальная структура данных для представления данных
• Вам необходимо отфильтровать ваш набор данных на наличие ошибок (например, ошибки последовательности)

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

В графических алгоритмах есть особая вещь, ваши оригинальные вопросы, что делает их особенными, а именно, в его способности разбивать данные по существу.

Для некоторых вещей, таких как сортировка чисел в массиве, не так уж сложно разделить проблему со структурой данных на более мелкие дизъюнктивные части, например, здесь: Parallel in place, merge sort

Однако для графовых алгоритмов существует проблема, заключающаяся в том, что найти необязательное разбиение на заданную графическую метрику, как известно, для .$NP-hard$

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

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

Итак, чтобы ответить на ваш вопрос вкратце: как уже упоминалось ранее, когда ваши данные не помещаются в основную память на обычном ПК, но вам нужно все это для решения вашей проблемы, это хороший намек на то, что ваши данные уже несколько большие. Хотя точная маркировка зависит, я думаю, немного от структуры данных и задаваемых вопросов.

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

Мне нравится это определение, поскольку оно не зависит от объема, уровня технологии и конкретных алгоритмов. Это не зависит от ресурсов, поэтому аспирант достигнет точки больших данных перед Google.

Чтобы количественно определить, насколько велики данные, я хотел бы рассмотреть время, необходимое для их резервного копирования. С развитием технологий объемы, которые несколько лет назад считались большими, сейчас умеренные. Время резервного копирования улучшается по мере совершенствования технологии, так же как время работы алгоритмов обучения. Я чувствую, что более разумно говорить о наборе данных, для резервного копирования которого требуется X часов, а не о наборе данных из Y байтов.

PS.

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

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

Данные - это «большие данные», если они имеют такой объем, что анализировать их на двух или более обычных компьютерах дешевле, чем на одном компьютере высокого класса.

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

Я склонен согласиться с тем, что @Dan Levin уже сказал. В конечном счете, поскольку мы хотим извлечь полезную информацию из данных, а не просто хранить их, это способность изучать алгоритмы / системы, которые должны определять то, что называется «большими данными». Поскольку системы ML развиваются, то, что было большими данными сегодня, больше не будет большими данными завтра.

Один из способов определения больших данных может быть:

• Большие данные : данные, на которых вы не можете построить модели ML за разумное время (1-2 часа) на обычной рабочей станции (например, 4 ГБ ОЗУ)
• Небольшие данные : дополнение вышеперечисленного

Предполагая это определение, пока память, занимаемая отдельной строкой (все переменные для одной точки данных) не превышает ОЗУ машины, мы должны быть в режиме не больших данных .

Примечание: Vowpal Wabbit (безусловно, самая быстрая на сегодняшний день система ML) может учиться на любом наборе данных, если отдельная строка (точка данных) <RAM (скажем, 4 ГБ). Количество строк не является ограничением, поскольку он использует SGD на нескольких ядрах. Если верить опыту, вы можете обучить модель с 10 тыс. Функций и 10 млн рядов на ноутбуке за день.

«Большие данные» - это буквально много данных. Хотя это скорее маркетинговый термин, чем что-либо другое, обычно подразумевается, что у вас есть так много данных, что вы не можете проанализировать все данные одновременно, потому что объем памяти (ОЗУ), который потребуется для хранения данных в памяти для обрабатывать и анализировать его больше, чем объем доступной памяти.

Это означает, что анализ обычно должен проводиться на случайных сегментах данных, что позволяет строить модели для сравнения с другими частями данных.