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

https://datascience.stackexchange.com/questions/19

16-10-2019
|

Вопрос

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

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

Решение

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

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

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

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

"Большие данные" на самом деле связаны не с объемом, а с характеристиками данных.

Другие советы

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

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

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

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

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

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

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

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

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

Он активно анализируется, а не только хранится (цитата «Если вы не пользуетесь большими данными, то у вас нет больших данных, у вас есть просто куча данных» Jay Parikh @ facebook)
Создание и управление хранилищем данных является крупным инфраструктурным проектом
Он растет значительным темпом
это неструктурировано или имеет нерегулярную структуру

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

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

Конечно, есть некоторое совпадение; Когда я (кратко) работал на последнем. Что в некотором смысле означало, что это были и не были большими данными, в зависимости от того, над какой работой вы работали. Но я думаю, что это точная характеристика; Люди, которые работали на рабочих местах Hadoop, сочли полезными на конференции и веб -сайты с большими данными, в то время как люди, которые работали на рабочих местах SQL.

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

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

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

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

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

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

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

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

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

Сборка де-ново выполняется путем построения De-Bruijn График:

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

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

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

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

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

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

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

Для алгоритмов графика, однако, существует задача, что поиск дополнительного разделения на данном графическом метрике, как известно, является $ np-hard $.

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

Есть ряд специализированных структур, таких как График Использование методов и специальных вычислительных парадигм, чтобы несколько обходить неотъемлемые проблемы графиков.

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

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

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

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

Пса

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с datascience.stackexchange