Комментарии 76
На вопрос "с какого объёма начинаются большие данные?" я бы ответил так: с объёма, с которого можно строить обучающие модели. Возможно, это даже 1 (один) мегабайт.
то есть на небольших данных модели строить нельзя?
А можно и вообще без данных, просто случайно константу выбрать.
Линейные модели обычно можно. Если сэмплов от нескольких сотен и соотношнние количества точек/размерность пространства (количества факторов) > 5-10
Большие данные еще и характеризуются большой вариабельностью, и скоростью прироста - те самые 3V или даже 5V.
То есть это не просто "небольшой стационарный набор однородных данных". Но даже небольшой набор может характеризоваться вариабельностью параметров и каким-то приростом, например, 1 Мб.
Можно, но они будут оверфититься.
И в чем же они большие? Автор ведь даёт четкую идею - много - это когда вы обычной базой обработать не можете, вам нужно что-то особое (например, BigQuery). 1 мегабайт обработать базой, разумеется, можно. Или программой прямо в памяти.
Автор сам же и опровергает - то, что вчера было нельзя обработать "обычной БД на обычном компьютере", сейчас - запросто... Что странно - "большизна" больших данных зависит от того, в каком году вы смотрите на эти данные.
Для микроконтроллера умной лампочки, с 8кб собственной памяти на борту, 1 мегабайт - это будет бигдата. Вопрос зачем лампочке обрабатывать мегабайт данных, оставим за бортом.... Идея состоит в том что бигдата - это что-то неподъемное для какой-либо отдельно взятой системы.
Что-то подумалось.... каталог всех звёзд во вселенной.
Можно пойти ещё дальше. Большие данные это 0 и 1. Из них можно построить всё! (улыбается).
Большие данные - необязательно "пища" для ИИ. Их можно анализировать классическими методами, фиксированными функциями и алгоритмами.
мне кажется скоро можно ожидать статью в которой также внятно будет расписано что ИИ это не какая то супер технология, а одна из групп алгоритмов анализа у которой есть как свои плюсы так и свои минусы и свои ограничения на область применения.
Обязательно. Плюс тут есть фактор, которого у бигдаты не было: на базе ИИ успели понаделать совсем уже обывательских инструментов. С одной стороны, хайп громче, с другой - рук, которые прощупывают границы применимости, тоже больше, причём в разы.
Так что статья эта появится, как мне кажется, гораздо быстрее. И не в техническом СМИ.
Это очень опасный подход, потому что хранить данные можно по разному.
Например, в одном проекте ~900М csv ужался до ~20M parquet.
А количество данных для нашей задачи было очень большим.
с объёма, с которого можно строить обучающие модели.
Машинное обучение в предельных случаях может использовать модели с 1-2 параметрами, т.е. можно уложиться примерно в 1 байт. Возможность машинного обучения - точно не критерий "больших данных".
Для человека, который поднял на бесплатном хостинге какой-нибудь условный водпресс и пробует импортировать в него свои 1кк записей и не может дождаться окончания — это bigdata, и решения в нем не в переносе данных в облако гугла (они то будут рады big money, которые им клиент заплатит) а в поиске узких мест и исключения их, смене алгоритмов с неэффективных на эффективные и т.п.
Облачные решения, не важно что они решают, — это игры с тарифами. Где то можно сэкономить на бесплатных лимитах, а где то потеряешь, заплатив за других халявщиков, сверх доходов площадки.
Как не крути, но часто лучшее решение это не залить все данные куда то с ограниченным интерфейсом, а арендова/купить полноценные машины с процессорами и дисковыми хранилищами, и пилить узкоспециализированное решение, по деньгам как минимум это будет гораздо эффективнее.
Про инструменты.
[шутка, которая вроде и не шутка]
Bigdata - это когда Excel не справляется.
Ну Excel тоже растет, и еcли данные не растут в геомтерической прогрессии очем говорит автор, от и его хватит на многое, кроме того Excel не только средство хранения данных, но и их визуализации, причем может использовать как свои данные так и внешние, а не один движок БД встроенными средствами визуализации обычно не обладает (Access ;) ).
Слышал ещё два определения:
...это когда приходится на ночь оставлять считать.
...это когда скорость поступления данных превышает скорость их обработки
Второе мне больше всего нравится, и по большому счёту мнение в статье поддерживает.
Большие данные - это же не про объем, а про способы обработки. Когда у нас есть инструменты и фреймворки, которые позволяют относительно легко проводить трансформации и аггрегации на нескольких машинах параллельно, то это и есть "большие" данные. Обрабатвыаешь всего 300гб в день, но с использованием кластера спарка и гринплама? Это "большие" данные. Обрабатываешь 1тб в день в несколько потоков, но это числодробилка на одной машине? Не "большие" данные
Если вы храните старые данные, хорошо бы понять, зачем они вам. Вы проводите один и тот же тип анализа снова и снова? Тогда не будет ли намного дешевле просто хранить отчеты? Вы держите данные на черный день? Вы думаете, что найдутся новые вопросы, которые вы, возможно, захотите задать? Если да, то насколько это важно? Насколько велика вероятность того, что это что‑то изменит? Или вы просто собираете данные, как человек с синдромом Плюшкина хранит в доме старые ненужные вещи?
Как всегда. Самые важные и интересные вопросы — в самом конце статьи.
Вот с этого и следовало бы начинать. Было бы крайне интересно узнать о реальных достижениях промышленных систем. Кому и в чём они помогли. Если.
И нужно сосредоточиться не на их объеме, а на том, как выделять из них действительно полезную и важную информацию.
В научных экспериментах сначала ставят задачу и вырабатывают план эксперимента, где явно прописывают те данные, которые хотят получить. Нельзя просто так собрать некие данные и дать аналитику. Что-то он там найдёт.
И ещё один момент. Одно дело — внутренние цели фирмы, другое — цели общества. Общество тоже может захотеть получить доступ к аналитическим данным фирмы.
Да и, конечно, крайне интересно узнать про какие-нибудь архитектурные достижения в области баз данных. В статье как-то мимоходом это всё упоминается. В самом общем виде.
В научных экспериментах сначала ставят задачу и вырабатывают план эксперимента, где явно прописывают те данные, которые хотят получить. Нельзя просто так собрать некие данные и дать аналитику. Что-то он там найдёт.
Насколько я понимаю "бигдату", эксперименты будет происходить уже после.
Условно всю концепцию бигдаты можно представить так:
Мы делаем продукт и не знаем как нам еще повысить метрики (есть какие-то гипотезы и мы их проверяем, но это как иголку в стоге сена искать)
Давайте собирать вообще все действия и реакции пользователя, клики, время находжения на странице, вообще все возможно (и это действительно дофига инфы при большой пользовательской базе)
Потом мы весь этот огромный массив данных отдадим куда-нибудь в ML или аналитикам, чтобы они искали корелляции
А вот когда корелляции найдены, мы уже используем их как идеи для постановки эксперимента (например мы вдруг обнаружили, что пользователи, которые больше времени проводят на странице выбора аватарки, покупают больше товаров. И дальше мы уже делаем гипотезы и ставим эксперименты на основе этих данных)
Оригинал статьи вышел в блоге https://motherduck.com/, который "powered by DuckDB" (физически и морально). Поэтому подробности архитектурных достижений нужно искать в районе документации DuckDB.
TLDR; Чувак 10 лет пытался продавать на конференциях продукт, решающий несуществующую практически ни у кого проблему, а щас он наконец осознал ненужность и немедленно поспешил запилить об этом запись в бложек (странно что не на конференции).
Зашел оставить этот комментарий, а тут вы. Только добавить хотел, что от этого продажника следует ожидать "лучшее решение", логика намекает.
лет 10 назад понравилась мысль, в интернете вычитал "Компьютер позволяет решать те проблемы, которые до его изобретения не существовали"
Скорее за 10 лет его слайды, нарисованные на салфетке в старбаксе за 10 минут до первой презентации, несколько надоели, и на конференции уже не приглашают, самому приходится заявки подавать. И он делает отличный ход - полный дисрапшн, или переобувание в воздухе, как посмотреть. Как продавец автор мне даже где-то симпатичен, стиль и напор вызывают уважение
Стоит отметить что продукт шикарный. Реально моментально считает любую аналитику
Статья о том, что люди очень часто копят ненужные данные и вместо того чтобы просто их стереть, страдают, платят, работают, опять платят. А надо просто научится не ценить своих данных слишком сильно и чистить их безжалостно. А то получаются Плюшкины 21-го века.
Вы невнимательно читали статью. Люди НЕ копят. BigQuery никому не нужен.
Люди копят, данных много, но для обработки этого не нужны BigData решения, т.к. реально используется малая часть - свежие.
Даже хуже: данных много с точки зрения сущностей, но не так уж много, если в гигабайтах вешать.
Есть ещё одна проблема, о которой в статье почти ничего нет. Данные разнородные и между собой мало провязанные. Отсюда вытекает, что основная сложность не в том, чтобы перелопатить терабайты, а в том, чтобы из сотни мегабайт данных, скажем, касс и другой сотни МБ данных сайта смочь сделать бизнесово значимые выводы.
в точку. И главное с этой задачей никакие инструменты справится не помогут. Тут нужен особый подход, без которого все это сваливается в dataswamp из которого прорастают как троcтники отдельные репорты и датапродукты никак не связанные в общую модель.
Вот наверное суть бигдаты в том и заключается, чтобы придумать метод анализа данных, не имеющих очевидной связи.
Скажем так, была мечта, что бигдата поможет эти неочевидные связи отлавливать. Или даже так: на больших числах можно будет заменить настоящие связи корреляцией.
По мере накопления практики стало ясно - только до определённого потолка, причём довольно низкого. Какая-то объективная real life связка нужна, как ни крути.
размер тут как раз роли особой не играет.
MongoDB — масштабируемая база данных
Спасибо, что нам напомнили.
Лучше было такого кликбейтного заголовка не делать.
Выскажу личное мироощущение - "биг дата" никогда и не воспринималась как профессия. При всем разнообразии it-спецов эта стезя выбивается из общего ряда как слесарь с разрядом 9 и три четверти.
Вопрос в другом - уже раскрутили колесо сансары, что "биг дата это круто, это нужно". Не дело переключать внимание публики, что "теперь биг дата совсем не круто, а круто-круто (что-то другое), все бегом туда". Манагеру, который умеет выбивать трендовые проекты, переключиться нетрудно. А программистам стресс, зачем, все уже привыкли что "давайте еще и биг дату наведем" - так пусть люди работают спокойно.
Что ж, теперь осталось как-то отучиться "... жрать кактус"
Google BigQuery? Не встречал. Ещё MnogoDB как конкурента вспомнил:)
Во многом с автором согласен.
Разделения хранения и вычислений - не про горячие данные, которые позволяют чувствовать бизнес на кончиках пальцев. Чем ближе данные с вычислительным ресурсам, тем лучше. Предельный случай - InMemory. И современные системы неплохо с этим справляются.
Наверное, это плохой продажник. Cloudera, GreenPlum, Teradata, Oracle Exadata, Vertica, ClickHouse, elasticsearch. Это то, что встречалось мне на проектах в крупных компаниях и гос. структурах за последние лет 6. 70% решений совсем не с клаудной архитектурой, но обрабатывают огромные данные в больших компаниях. При этом нагрузка большей частью аналитическая. Старый транзакционный хлам на самом деле никому не интересен и его регулярно обрезают, если это позволяет сделать сама транзакционная система (чаще не позволяет).
Бигдата - это то, что не уместилось в Excel 🙃
Ну и куда теперь девать всех выпускников скилл-факторов, -боксов и прочих практикумов, которые отштудировали курс "Инженер БигДаты"? :)
Hidden text
Смешно. В такой компании работал, а не знает аксиом. Большие данные - это, в первую очередь, неоднородность. Если данные однородны, то обработка небольшой выборки даст те же результаты, что и обработкс всех данных. Это решает проблемы volume и velocity. У вас нет больших данных, если их не надо разбивать на более однородные кластеры, на которых и строятся модели, на каждом - своя.
да у меня порноархив больше чем половина примеров его больших данных . Слабаки какие-то. Добавили бы архив свопов. Или полные ежедневные бэкапы всех жестких дисков компании, включая бэкапы дисков бэкап серверов.. Наконец, у них что нет видеонаблюдения? Детский сад просто, данных не могут найти. На худой конец все транзакции можно распечатать в pdf документы, и то хлеб
Очень интересно, что и сам разработчик системы, похоже, не видит основной силы BigQuery. И в комментариях не написали. Может я чего не понимаю? Но я на BigQuery переводил четыре компании; пользуюсь с 2012 года. И подтверждаю, что в каждой следующей компании данных было меньше и меньше (с тезисом переоценённости тупо объема данных не спорю).
Нннно! Фишка BigQuery в необыкновенно большой вычислительной мощности в моменте. Если у меня есть идея что-то посчитать, я могу получить ответ и на одной машине за час, например. А BigQuery выплёвывает результат за 2 секунды. И я, увидев какая лажа получилась, переписываю запрос и опять за 2 секунды вижу результат. А потом я могу месяц эти данные не трогать и система оплаты будет только за хранение. В этом и суть.
Странно, что инженер этого не понимает.
инженер как раз понимает. Просто фишка в том что с bigquery можно работать точно также как работали с Oracle 20 лет назад. Такая же модель данных, такие же подходы к ETL такой же репортинг. А до этого всем продавали магию "big data" которая якобы совсем не похожа на старые подходы к аналитике данных.
Простой пример, где полезен Google BigQuery - хранение данных всей планеты OpenStreetMap (полный дамп терабайта полтора размером) в подготовленном для использования виде тематических слоев и с регулярным автообновлением, см. https://github.com/mobigroup/bigquery-openstreetmap Поскольку этот открытый проект я писал по заказу Google Inc., он именно на BigQuery ориентирован, хотя я тот же самый код использую для хранения данных в PostgreSQL и SQLite… но с ними требуется уметь извлекать и агрегировать пространственные данные, в то время как BigQuery делает это автоматически (при условии правильно подготовленных данных, разумеется). Более того, бесплатного месячного лимита хватит на пачку запросов, которых может быть уже достаточно - и это не потребует от пользователя неделю обрабатывать дамп OpenStreetMap локально и еще разбираться с производительностью запросов. Если же эти данные нужны постоянно и запросов много, конечно, стоимость сервиса BigQuery будет намного выше использования локальной базы данных. Каждому свое. НАСА вот вообще простейший вроде бы сервис хранения космоснимков предоставляет - но когда каждый космоснимок размером порядка гигабайта и их миллионы, этот сервис оказывается очень востребованным.
...да здравствуют большие данные?
Но почти никому на самом деле такой инструмент был не нужен
Возможно это объясняется тем, что компании с реально большими данными не захотят мигрировать в чужое платное облако, подверженное влиянию государства, а просто поднимут у себя Apache стек и будут работать на нем.
А где шутка про подростковый секс?
У большинства людей нет так уж много данных
Неужто стало доходить??? (и не только у людей, но и у организаций)...
С самого начала статьи я не мог отделаться от старого-доброго привкуса от американских специалистов "по корпоративному впариванию" которые по два раза делают карьеру:
Создать и продать проблему
Продать решение проблемы которая была вызвана действиями которые были направлены на решение выдуманной проблемы
??? Profit? РАНО! Доим дальше: GOTO 1
Сделай больно, а потом ослабь чтобы стало хорошо.
Который год такое наблюдаю и кажется в США это особо популярный жанр.
если только вы не решите резко сократить данные (подробнее об этом позже)
"Смотрите чего я умею. Готов поработать на ваш бизнес, пишите в Линкедин."
Остап Бендер знал несколько сравнительно честных способов от'ема денег, среди них были и бигдата и озера данных вместо хранилищ данных и искусственный интелект.
Большие данные мертвы. Это нужно принять