Нравятся стартапы типа youscan.ru и yieldify.com, и вообще любые сервисы которые используя приемы big data пытаюся повысить конверссии бизнессов.
Потому с чего стоит начать изучение big data, каких технологий стоит начинать, книг и т.д.?
Работаю над вопрос-ответным сайтом, мой стек из php и js. Одна из задач это рекомендации вопросов, но с ней справляется sphinx.
Окей, дискусія нижче виявила деякі розбіжності в розумінні того, скільки місця в пам’яті займає файл об’ємом 3.5GB, і чи достатньо 4GB для його обробки.
dou.ua/...orums/topic/14219/#727621
dou.ua/...orums/topic/14219/#727933
dou.ua/...orums/topic/14219/#728002
dou.ua/...orums/topic/14219/#728133
Отже подивимось на простому прикладі, як це робиться.
Це такой собі Map-Reduce, map: page -> crc16 (page це 4KB), і reduce частина будує гістограму значень crc.
У мене 8GB DRAM, а вхідним файлом нехай буде /dev/sda, це 120GB SSD, бо нічого більшого об’єму в мене немає під руками. Це приблизно 15x об’єм DRAM. Я запускаю 4 процеса в паралель на свому старенькому i5, кожен з них «завантажує» весь вхідний файл в пам’ять. Тобто у кожного процеса в його віртуальній пам’яті є повний файл, uint8_t* input в коді. Скільки фізичної пам’яті це потребує? 4*120GB або щось подібне?
Насправді ні. Ця штука відпрацювала за ~30хв, вижрав сумарно десь 5GB — на всі чотири процеси. Але це сталося лише тому, що в мене ну дуууже багато вільної пам’яті, аж цілих 7GB чи 6GB чи біля того, і мені було лінь її обмежувати. Ця програмка відпрацює без значних тормозів, без зміни кода, паралельно, маючи весь файл в віртуальній пам’яті кожного процеса, навіть якщо ядро матиме лише декілька десятків мегабайт вільних. Чому? Тому що з MAP_SHARED, ядро може вільно обмінювати сторінки між фізичною пам’ятью і mmap-нутим файлом.
Якщо не робити грубих помилок і не заважати віртуальній пам’яті працювати, необхідний об’єм фізичної пам’яті для роботи без тормозів визначається лише об’ємом сторінок пам’яті, до якох звертаються за визначенний проміжок часу (типу секунди), і він співдоноситься зі швидкістю обміну. Загальний об’єм вхідних або вихідних даних не має значення.
Для багатьох задач, зокрема в цьому прикладі, весь вихід модифікується майже безперевно, і тільки через це об’єм виходу впливає на потреби в пам’яті. Скажімо, гістограму CRC32 зробити було б значно важче на 8GB. Об’єму входа це як правило не стосується! Зокрема, парсінг відносно коротких csv рядків послідовно за незалежною обробкою потребує пам’яті порядка довжини рядка в сторінках, навіть якщо формально «весь» файл «завантажено» у пам’ять.
Коли людина починає скиглити, що 4GB фізичної пам’яті буде замало для обробки 3.5GB файла, це означає, що людина зібралась робити MAP_PRIVATE замість MAP_SHARED. Або (типово для Java) якісь повільний еквівалент MAP_PRIVATE. Звичайно це помилка, яка блокує роботу віртуальної пам’яті. Привіт DOS. Історична справка: mmap це технологія кінця 80х років, віртуальна пам’ять мабуть до 80х.
Якщо воно працює повільно, першим питанням має бути, скільки там активна зона, яка постійно читається/пишеться, чому вона така велика, і чи не можна її зменшити. Для Java з вагончиком фреймворків, після або навіть до цього варто спитати, а що там ще є в пам’яті, і якого біса воно там робить (коли йому місце на диску).
TL;DR: 4GB DRAM не є перепоною для обробки 3.5GB файла. Помилки, нерозуміння, та великий об’єм проміжних даних (коли це не є наслідком помилок і нерозуміння) може бути.
Хорошо описано!
Несколько замечаний, если позволите:
1. Данная технология будет хорошо работать только на последовательных данных. По понятным причинам.
2. Существует некий оптимальный размер блока для конкретной дисковой подсистемы — если задать его меньше, контроллер упрется в максимальное количество IOPS, если больше — будет то, что вы описали.
Выяснить его достаточно легко утилитами типа iometer (когда размер блока перестанет влиять на Mbps).
Данная технология будет хорошо работать только на последовательных данных.
Последовательных наверное не очень точное слово. Не проблема обрабатывать скажем страницы 12345, 65712, 34523, потом 23453, 235677, 9844, возвращаться назад, последовательность не обязана быть 1, 2, 3. Главное не скакать слишком быстро между страницами. Что такое «слишком быстро» уже зависит от iops, свободной памяти и прочих подробностей.
Тут тот же принцип, что с кэшем в cpu. Есть блок в кэше — берём из кэша, нету — подгружаем в кэш из памяти. Не в памяти — подгружаем с диска. Нет на локальном диске ноды — подгружаем из NAS, это для Хадупа и т.д. И проблемы те же, что с data locality в геймдеве, только масштаб другой.
Коли людина починає скиглити, що 4GB фізичної пам’яті буде замало для обробки 3.5GB файла, це означає, що людина зібралась робити MAP_PRIVATE замість MAP_SHARED.
Ми ще про файл, який тільки читається, чи взагалі про обробку даних? MAP_PRIVATE означає, що модифікації не можуть бути повернути до початкового файлу. На практиці в VM в такому випадку створюється «тіньовий» проміжний обʼєкт, який модифіковані сторінки зберігає в себе (і скидає до свопа), а немодифіковані беруться з початкового файлу. Якщо файл не модифікується, MAP_SHARED і MAP_PRIVATE повністью еквівалентні за витратами RAM і свопа на цей файл.
Коли людина починає скиглити, що 4GB фізичної пам’яті буде замало для обробки 3.5GB файла,
це означає одне з двох:
1) Що ця людина взагалі не думає про mmap, а замість того — malloc + read. На деяких мовах, де mmap не є доступним, це може бути єдиним засобом; але до чого читати його увесь разом?
2) Що обробка файлу дуже непослідовна, і дисковий кеш на такій обробці, виконуючи свою роботу, не дає ніякої користі. Так, і таке буває — тоді тільки повне розміщення в RAM дає достатню швидкість. Але я небагато бачив таких задач; наприклад, це операції з матрицями (множення, обернення), деякі випадки картографії.
Якщо файл не модифікується, MAP_SHARED і MAP_PRIVATE повністью еквівалентні за витратами RAM і свопа на цей файл.
Неточно написав, малось на увазі MAP_PRIVATE коли ці сторінки дійсно private, тобто розірваний зв’язок з файлом. В контексті, malloc (eq. MAP_PRIVATE | MAP_ANONYMOUS) + read замість mmap.
але до чого читати його увесь разом?
Питання до автора. Але це непогана ідея насправді, закинути все в пам’ять і не забивати собі голову розіром буфера, read, seek, особливо якщо читання не зовсім послідовне. Якщо робити нормально. Питання типу «не вистачить фізичної пам’яті» просто не повинні виникати.
Можливість зробити mmap в Java є.
2) Що обробка файлу дуже непослідовна
Ну і це принципово не сумісно з big data.
начните с курсов на курсере — биг дата интродакшн. В биг дата есть несколько сфер — это как хранить биг дата (распределенные системы, хадуп рд-чегото там), как ее обрабатывать — Apach Spark, R, Python, Scala, Pork, Jackl — языки для работы с данными, и последнее что я знаю это сфера Machine Learning — возможность выделить в биг дата какие то паттерны и на их основе предсказывать или автоматически что то определять. Уже есть достаточно либ с запрограммированными патернами — только подключи и вперед. Лично я столкнулся с трудностями что на файлах типа 100 мегабайт макбук еще тянул апач спарк, но когда я залил файл на 3.5 гига (100 миллионов записей) то ни ссд ни коре и7 не помогли — ждать приходилось долго а результата все не было, и все это время ноутбук изображал из себя самолет прогревающий турбины. Поэтому пришлось искать кластер и дальше практиковаться на нем.
но когда я залил файл на 3.5 гига (100 миллионов записей) то ни ссд ни коре и7 не помогли — ждать приходилось долго а результата все не было, и все это время ноутбук изображал из себя самолет прогревающий турбины.
Лол. Небось установил половину библиотек и фреймворков что тут насоветовали, да еще на джаве. Результат очевиден. Вообще тот кто предложил для бигдата писать компоненты на джаве или тролль 80 левела, или менеджер по продажам оборудования IBM )
А заставить тормозить современный камень, который выполняет под триллион микроопераций в секунду на жалких 100 млн записей (3.5 гига) это не толсто ?
А то, что обработка на каждую запись может быть безумно сложной (вплоть до аналитического решения дифура) — учитывается? Ни слова ведь не сказано, что за обработка предполагалась. Я уверен, что это не просто укладка в базу.
А я не уверен, что когда человек решил просто установить и пощупать базу — начал дифуры запускать.
«Наука начинается там, где начинают измерять» ([Менделеев]). Описание задачи и конкретные цифры (измерение темпа), хотя бы приблизительно — тогда будет о чём говорить.
Ну выяснятся какието условия задачи. Выяснится что Джава действительно притормаживает. Выяснится что на Си если переписать будет работать в раз пять быстрее ( ну типо закон такой, да ). Ну а дальше то что ? В чем смысл расследования ? С чем не согласны ?
Тему Java в данном субтреде поднимаете только вы. Остальные, насколько вижу, её просто не замечают.
Смысл «расследования» в том, что нельзя говорить о том, что что-то тормозит, не уточнив задачу и методы её решения. И во многих аспектах это от языка не зависит совсем.
Ну у меня уже по долгу службы от этих бенчмарков в глазах рябит. Поэтому уже говорю, немножко наперед.
Что касается языка, ну в приципе тоже согласен. Но нужно учитывать, если водила нацепил лысую резину и собрался в горы зимой, то ждать от него какихто особых водительских способностей тоже не стоит. Резина это есть выбор языка для быстрой обработки большх массивов информации. Особенно когда это касается железа с ограничеными возможностями.
Проблема в том, что часто дело не в языке, а, как в старом фидошном тексте, «размер не имеет прямого значения. один мой знакомый с 100MB винчом вытворял такое, что другие на 10GB не могли.»
У нас одна группа работает на kx/q, и несмотря на то, что эта штука интерпретируемая, творит такое, что на c++ писали бы годами. А всё из-за модели данных (извращённой выше крыши, но эффективной для данных задач).
У нас одна группа работает на kx/q, и несмотря на то, что эта штука интерпретируемая, творит такое, что на c++ писали бы годами
Тоесть есть реальный пример, что одна группа писала на интерпретируемом языке. Другая группа на Си. Задача была одна и таже. И у первых по скорости приложение получилось лучше чем у второй ?
Скоріш за все, поки друга группа все ще писала завдання на сі, перша вже все написала, продала, заробила бабло, та полетіла на гаваї.
С чего вы взяли? Правильный ответ — в то время, как первая на этом кошмаре написала и выполнила, что надо, вторая бы вообще потратила годы, чтобы написать то же самое.
(мимо пробегал, можна я тут вопрос, ок?)
Зачем при обработке big moderate laptop-size data может потребоваться решать дифур аналитически для каждой записи? Можно ссылки какие-нибудь на проекты или что там? Мне интересно на такое посмотреть.
А то, что обработка на каждую запись может быть безумно сложной
Ну источник задачи вроде назван, Big Data Introduction на Курсере.
Зачем при обработке laptop-size data может потребоваться решать дифур аналитически для каждой записи?
Не знаю. Я и не утверждаю, что такое там, я говорю, что есть маргинальные случаи, которые легко описать словами без влезания в детали и которые могут быть жутко прожорливыми.
Ну источник задачи вроде назван, Big Data Introduction на Курсере.
Не видел. Но если автор жалобы не способен назвать скорость решения задачи на его технике в записях в секунду, то мы продолжаем чесать языки ни о чём.
что есть маргинальные случаи, которые легко описать словами без влезания в детали и которые могут быть жутко прожорливыми.
Возражаю, обработка big data не может быть прожорливой. Иначе это либо обычные объёмы, либо затык. Big data это когда данных сильно больше чем процессорного времени, а результат (хоть какой-то) получить хочется.
Но если автор жалобы не способен назвать скорость решения задачи на его технике в записях в секунду
1e8 записей, «долго» ... ну пусть 1e3 секунд. В лучшем случае порядка 1e5 записей/сек. Это не так важно.
Человеку не хватило макбука и потребовался кластер для обработки 3.5GB данных. С тем же подходом, какие вычислительные мощности ему потребуются для обработки реально больших данных?
Возражаю, обработка big data не может быть прожорливой.
Правильнее всего сказать, что она не может быть такой, чтобы каждая отдельная обработка обрабатывала все данные. В отработке запроса BigData важнее качество фильтрации только до нужного обрабатываемого подмножества (не обязательно точно, но как можно меньше выкачивать и отрабатывать), чем скорость по отдельному элементу (различие даже на порядок не столь критично). Вот с такой постановкой вопроса я соглашусь без лишнего обсуждения.
И вот потому — опять и снова — без указания, что именно в тех гигабайтах обрабатывалось и как, обсуждать просто нечего.
я пробовал таймеры расставлять что бы глянуть что больше всего времени занимает, оказалось что редьюсы и джоины. само считывание файла проходи быстро, мапы тоже не особо нагружают.
Вы наверное не правильно поняли , локально выполняется процесс только на этапе разработки — тестовых данных , а не на реальных данных, поэтому так медленно.
Ви ще фізичні задачі не пробували? У нас в універі був 16 нодовий кластер (2000 рік) так там і то за секунди нічого не вирішувалося, і навіть не за хвилини.
Ну, правда, это странно — закипать на 3.5 гиг. Какой-нибудь видеоплеер спокойно воспроизводит файл в 10 гиг и не тормозит. Потому же в курсы и включают раздел «Mining Data Streams».
Какой-нибудь видеоплеер спокойно воспроизводит файл в 10 гиг и не тормозит.
Вылизанные алгоритмы и (обычно) аппаратная поддержка наиболее прожорливых частей (вплоть до собственно декодинга потока).
Ну, правда, это странно — закипать на 3.5 гиг.
Странно писать такую ерунду. Сначала автор жалобы не даёт ни описания выполняемой задачи, ни темпов состоявшейся обработки (100 записей в секунду? 10K? 100K?) Потом начинаются сравнения с видеопроигрыванием, хотя есть полно задач, которые могут даже 1 запись обрабатывать часами.
Вылизанные алгоритмы и (обычно) аппаратная поддержка наиболее прожорливых частей (вплоть до собственно декодинга потока).
На Джаве ?
При чём тут Java? Было сказано "
Какой-нибудь видеоплеер спокойно воспроизводит файл в 10 гиг и не тормозит".
Вылизанные алгоритмыКачество алгоритмов — и я о том же. Автор сетует не на само время обработки, а на то, что оно взлетело за облака с увеличением объема данных. Но общий подход к большим данным в том и состоит, что их первичная обработка сводится к минимуму, приводя к промежуточным результатам меньшего объема, которые подаются на вход следующего этапа обработки и т.д. При этом требуемые на каждом этапе ресурсы лежат в контролируемых пределах.
Я считаю что это очень логично написать компоненты на java, так как вы наверное знаете что big data — это большие данные -> кластер -> много разных машин с разними конфигурациями -> лучше всего подходит JVM , а не на такие языки как Cи.
ну если кластер состоит из мобильных телефонов, пентиум 2, макбуков и асусов, то может быть.
я имел ввиду разные кластера а не компьютеры внутри эти кластеров
тоесть накодил такого, что уже на один кластер не вмещается. Нужно два.
Может быть адекватно оценить свои возможности, посмотреть что в Топ 10 используется компаниях ? Нужно же всетаки понимать, что если задача расползается на 2 компьютера вместо одного, то сложность кодинга, синхронизация, инфраструктура, администрирование, нужная суммарная мощность серверов выростает в раз 5.
WTF? чувак ты о чем? я имею ввиду что обработка данных может быть произведена на разных кластерах, сегодня на 10 инстансах одного типа, завтра на 5 другого , и вот в этом моменте JVM имеет преимущество , write once run everywhere.
Ты мебель покупаешь тоже из расчета что сегодня месяц живешь в одной квартире, завтра два месяца в другой ?
Не встречал чтобы большие компании прыгали от одного кластера к другому. Все достаточно прозаично. Кросплатформерность ради самой кросплатформености, да еще в вычислительных задачах типо матрасчетов. Кому это нужно ? Красивая легенда Java ?
эм :) дело в том что когда ты запускаешь свой апликейшн , - map reduce job, то часто бывает так что у тебя не свой кластер а ты арендуешь мощности , amazon например , и там ты выбираешь именно те инстансы которые тебе нужны в данный момент, это более разумно чем все время на одном и том же кластере запускать разные по мощности апликейшены, но даже если у компании есть свой кластер, то этих компаний то много :)
сегодня на 10 инстансах одного типа, завтра на 5 другого
И что, сегодня они x86-64, а завтра они неожиданно zEC196 или Elbrus 4? Амазон такое умеет? Хочу!
write once run everywhere
Меня любой современный Unix устроит с компиляцией :)
Почему? они все похожи , но все же есть различия, зачем вдаваться в крайности и сразу приводить в пример
Elbrus 4? Достаточно понимать что бы иметь пользу от Си в данном случае, разработчикам hadoop пришлось бы писать платформу с учетом конкретного компьютера, что повысило бы время на разработку и установило бы ограничение на разработку так как на Си подобных языках существует ряд проблем как и GC так и с безопасностью , мне кажется это не стоит того что бы бегать за сомнительной производительностью , жертвуя безопасностью. Это мое мнение
пришлось бы писать платформу с учетом конкретного компьютера
В каком именно смысле? Целые стали нецелыми? ;)
так как на Си подобных языках существует ряд проблем как и GC так и с безопасностью
«Проблемы с GC на Си» это пять. А о какой именно безопасности речь?
Это мое мнение
Оно совпадает с вашей точкой зрения?
я имел ввиду безопасность вмисле указателей и прямой доступ к памяти, я всего лишь хочу показать вам,что не логично юзать Си, в данном случае так как ,если подумав, то лучше сосредоточиться на бизнес логике процесса , и не на указателях и уборкой мусора , я хочу просто написать на scale etl который отлично справляется с этим, при этом не ломая часами голову хватит ли мне памяти и о бо же мой надо же почистить мусор.
Дружище, когда у тебя алгоритм какуюто зубодробительную задачу начнет считать 7 дней вместо 1 дня, то у тебя появятся лишние 6 дней на подумать, почитать чтото по указателям Си и переписать алгоритм оптимально.
Такова правда жизни. Для остальных задач, действительно никто не будет парится по поводу указателей. Ну правда, открывается формочка 10 миллисекунд или 70 миллисекунд, абсолютно не повод использовать тут Си.
Дружок давай тогда учитывать все , писать 50 дней что бы запустить на 1 день явно будет дольше чем писать 1 день что бы запустить на 7 и потом еще 3 раза запустить на 7 дней.
Такова правда жизни.
3 раза запустить на 7 дней не получится. Потому что там могут быть баги. Ты наверно не сталкивался, когда баг воспроизводится только через 12 часов интенсивной работы алгоритма. А я сталкивался и не раз. А теперь представь что твой баг воспроизводится только через неделю интенсивной работы.
К томуже, о каких 50 днях идет речь ?
Да, Гуи рисовать на Си это то еще дельце. Но математика ... Си просто создан для математики. О чем говорит огромнейшее количество мат библиотек. Даже для всех ваших этих интерпретируемых языков, весь бекенд по сути написан на Си.
Дружище, когда у тебя алгоритм какуюто зубодробительную задачу начнет считать 7 дней вместо 1 дня, то у тебя появятся лишние 6 дней на подуматьПрелесть хадупов заключается в том что оба варианта будут делаться за пол часа, просто на разном количестве машин.
Поддержу. И в большинстве случаев стоимость этих мощностей будет ниже стоимости программистов.
Да да, теоретик. Далеко не все задачи хорошо параллелятся.
А те что параллелятся, сжирают на синхронизациях и передаче данных между узлами много ресурсов. Да даже если в одну коробку набрасывают ядер, никто толком не знает как их эффективно использовать.
Потому тупое наращивание ядер производители уже почти признали тупиком.
Лично я столкнулся с трудностями что на файлах типа 100 мегабайт макбук еще тянул апач спарк, но когда я залил файл на 3.5 гига (100 миллионов записей) то ни ссд ни коре и7 не помогли — ждать приходилось долго а результата все не было, и все это время ноутбук изображал из себя самолет прогревающий турбины
Вы явно что-то не те делаете. У меня обработка почти 3 гига джейсонов (около 4 тыс. файлов) занимает
Вообще такие объемы смешны для big data, их обрабатывают обычными средствами.
Вполне вероятно, что человек запустил виртуалку с предустановленным софтом и подзабыл накинуть в конфиге оперативки.
спарк стоит на макбукпро с ссд, 4 гига и и7. Делается парсинг строк, преобразование одного индекса — время переводится в удобочитаемое, фильтр по одному значению и потом два — три мап редьюса. даже на кластере с хадупом из 6 компов это занимает около 30 минут
Парсинг и Джава\ДотНет практически не совместимы.
Ну или нужно аккуратно тюнить с классами типа StringBuilder, Regex и др.
Для примера у меня на Си парсер который выкусывает текст из html молотит в один поток больше 400 мб\сек (без учета работы диска, диск у меня обычный, шпиндельный).
парсинг тут не особо сложный — на вход подается CSV файл, и парсинг это разделение его на части что бы решить кто будет ключом а кто валюе ну и отсечь лишние данные.
Т.е. на ноуте проводится работа с локальным файлом без Хадупа?
Оперативы точно хватает?
4 гига оперативы, файл 3.5 гига, диск ссд
файл 3,5 гига в оперативе будет занимать больше места, 4 гига это очень мало, для этого файла.
я вот думаю что 4Гб это все что есть, достаточно просто понять что сожрет ОС, что сождет JVM и другие программы , а что останется на файл, который занимает явно больше места чем в сыром виде на SSD.
С чего вы взяли, что выгруженные в память данные из файла будут занимать больше места? Формат файла текстовый? А в памяти всякие числа, время будут уже в бинарном виде.
В зависимости от того, куда складываются промежуточные результаты преобразований, фильтрации и мап-редьюсов. В общем случае в Спарке это делается в оперативу. Со всеми вытекающими последствиями в виде ухода в своп. Спарк не рассчитан на работу в экстремальных условиях 4Гб оперативы на всё. Это кластеризуемая система и юзать её нужно соответствующим образом под соответствующие задачи. Если человеку захотелось хардкора — значит нужно понимать как она работает внутри и как её запустить на ограниченных ресурсах. Но тут явно не тот случай.
Ключевой момент: промежуточные и выходные результаты. 3.5GB это входной файл. Размер промежуточных вроде как озвучен не был.
Преобразование и фильтрацию можно сделать потоково во время вычитки файла. Но результат придётся куда-то сложить, чтобы потом натравить мапредюс. А можно и тупо вычитать сразу всё файло в RDD, преобразовать, отфильтровать... И уйти в глубокий своп )) Что там у ТС происходит на самом деле — да, только гадать. :)
Преобразование и фильтрацию можно сделать потоково во время вычитки файла.
Ну и map скорее всего тоже. О чём собственно и речь, между 3.5GB входных и 4GB доступной памяти нет связи. Памяти для чтения и парсинга им фактически нужно на несколько блоков (строк, записей или чего они там обрабатывали), а не 4GB.
Другой вопрос сколько там осталось после фильтрации и map’а, и что они делают дальше. В контексте big data, они должны сильно уменьшать объём.
в спарке нету map reduce , и учтите что на иницализацию все JVM уходит тоже много времени, это тоже нужно учитывать.
в спарке нету map reduce
и учтите что на иницализацию все JVM уходит тоже много времени, это тоже нужно учитывать.а воно і не разрахована, на те що запуск екзешніка виконається за мілісікунди.
здрасті.моя вина, думал о другом когда писал.
4 гіга? і ви намагаєтесь 3.5 гб данних в пам’ять запіхнути,і дивуєтесь чого воно так повільно ?
Про реально великі дані буде таке ж питання?
(а також: mmap, ні, ніколи не чули)
До чого тут mmap? ви б ще за своп пригадали.
Про реально великі дані буде таке ж питання?Так, на реально великі данні ставлять реально великий об’єм пам’яті, а такж розбивають це все в кластер, щоб воно вмістилось.
Так, на реально великі данні ставлять реально великий об’єм пам’яті, а такж розбивають це все в кластер, щоб воно вмістилось.
...на диск. Відношення dram/диск при цьому залишається на рівні 1e2...1e3 в кращому разі. Якщо для вас big data обмежана наявною dram, у нас мабуть різні визначення big data.
До чого тут mmap?
«4 гіга? і ви намагаєтесь 3.5 гб данних в пам’ять запіхнути» — це дуже дивна фраза, якщо трошки розуміти як воно працює.
Якщо для вас big data обмежана наявною dram, у нас мабуть різні визначення big data.
це дуже дивна фраза, якщо трошки розуміти як воно працює.Ну ось є посилання-роз’яснення
Коротка неконструктивна відповідь на обидва пункти — facepalm.
(по першому пункту це сказали ще на початку)
Але то погана відповідь. Якщо все буде добре, я вам спробую це на простому прикладі показати.
Зараз виглядає так, що частина людей в треді просто не розуміє про що йдеться, а друга частина не розуміє як перша може не розуміти очевидні речі.
Чекаємо, бо весь цей срачь, на рівні, «адепти сі ненавидять джаву, але нічого путного сказати не можуть, тому пускають якийсь рендом про ммап, і подібне»
Джаву все любят. Но есть же требовательные задачи к вычислительным ресурсам ( о чем и тред ).
Некоторые думают что Джава настолько крута что потянет и бигдату.
В итоге, появляются проекты вроде Lucene которые потом долго и мучительно переписывают на Си.
(смотреть бенчмарки, к примеру, Lucene vs Sphinx)
Некоторые думают что Джава настолько крута что потянет и бигдату.Ну, поки ви тут філософствуєте, її успішно використовують в біг дейті.
Помоему гигантская куча бигдата проблем сейчас в сеть и диск упираются, и там пофиг уже си сверху или джава.
За последние 5 лет размер ОЗУ на рядовой машинке увеличился в раз 5. Скорость чтения с диска (SSD) тоже в несколько раз. А вот процы добавили в мощности максимум 30%. Посмотрим что будет делать джава, когда узким местом станет проц. А оно к тому все идет.
Ну и про LRU погугли чтоли, узнаешь много нового. Не диском единым, как говорится.
В итоге, появляются проекты вроде Lucene которые потом долго и мучительно переписывают на Си.Это как раз отличный пример, пока автор сфинкса 10 лет доводил до ума свое глючное г-но, люсин захватила мир, и стала частью кучи более высокоуровневых решений (elasticsearch, solr).
(смотреть бенчмарки, к примеру, Lucene vs Sphinx)
Отличный пример альтернативно одаренных разработчиков, которые свой альтернативно одаренный труд распространили на массы. Теперь чтобы проиндексировать массив данных, люди по всему миру ждут 10 часов, вместо
Отличный пример альтернативно одаренных разработчиков, которые свой альтернативно одаренный труд распространили на массы.Это у масс не было вубора, пока сфинкс доводили до ума.
К счастью остальные популярные базы данных, написаны на нормальных низкоуровневых языках.Кассандра и HBase например?
Кассандра и HBase например?
Это у масс не было вубора
Перепишут. Люсену на Си переписали и это перепишут.
Правда люсин на си никто не использует, как и переписывание HBase вроде Hypertable.
Ви або не прочитали, або не зрозуміли мій попередный коммент.
Я провсяк випадок нагадаю — читати послідовно з диска та робити редюс, можна і без ммапів, сі, асамблерів, паяльників, та іншої маячні.
Можна. На Java, на C, на чому завгодно. Для цього не треба 4GB пам’яті. Навіть якщо не помітити, що обробка послідовна.
Задавати ось такі питання — не можна. Особливо в контексті big data. Даних там буде більше, пам’яті (у відносних цифрах) меньше, а ліміти часу залишаться.
HBase, Cassandra, Hadoop не відкалібрують вам відчуття реальності. Якщо ви не бачите проблеми тут, ви точно так же будете дивитися на Hadoop з датасетом в 1/100 його можливостей і говорити «чого ви дивуєтесь, тут кластер в два рази більше треба».
Для цього не треба 4GB пам’яті.так, так, 256 кб буде для всього достатньо, а в гуглі сидять ідыоти, будуют футбольно поле кластерів, замість того. щоб зробити пошук на калькуляторі.
вы ж понимаете, что «надо увеличить память, чтоб быстрее» и «надо увеличить память, иначе не работает» — чуток разные вещи. к чему этот сарказм?
Вопрос из зала: А нафуя на макбуке спарк?
спарк мона запустити де завгодно, в цьому і фішка.
На одной такчке это standalone mode, и преобразования выполняется in-memory , в одном потоке, поэтому все так медленно.
таск менеджер показывает 4 нагруженных потока на процессор
Недавно был курс на Coursera Mining Massive Datasets, основанный на книге www.mmds.org.
По Big Data варто ось цю прочитати “Big Data — Nathan Marz, James Warren” (www.amazon.com/dp/1617290343 або www.manning.com/marz/ а по Machine Learning www.coursera.org/learn/machine-learning і по системі рекомендацій мабуть www.coursera.org/...learn/recommender-systems
Из языков — выучить Java, Scala, Python, R, — хотя бы 2 из них.
И если 1 из 2 выбрать Scala, то другой придётся выбрать Java и учить сначала его.
На PHP в сфере Big Data никто не пишет, на JS — тоже.
Из framework’ов — Hadoop, Spark, для начала.
Потом, возможно, Kafka и ещё несколько вещей, которых сейчас стало многовато, и не совсем ясно, что из них конкурирующее, а что дополняющее.
Из теории — теория вероятностей и статистика, machine learning.
Ну а чтобы это понять, надо иметь базовые знания по математике. Алгоритмы и структуры данных знать — наверное, тоже.
Книга № 1 по Hadoop — Tom White,
Работать с Hadoop — через Java.
Работать со Spark — через Scala (предпочтительнее) или Python.
Но это не догмы, конечно, это просто наиболее удобные и популярные варианты.
И если 1 из 2 выбрать Scala, то другой придётся выбрать Java и учить сначала его.Не обов’язково саме вчити. Поверхнево пройтись, щоб розуміти що воно таке, та на чому все побудовано, та і все.
В принципі, Java без Scala і Hadoop без Spark теж може бути досить на перший час. Така собі програма-мінімум.
Попытаться изучить строение автомобиля начиная с шуруповерта, домкрата и сварочного аппарата можно. Но зачем ?
Чтобы кое-как «начать работать с Big Data» — вообще достаточно немного знать Java и прочитать краткую обучалку по MapReduce. Но когда дело дойдёт до реальных проектов и реальных задач, то понадобится бОльшая часть того, о чём я написал выше.
Потому что вряд ли дело обойдётся написанием очередного «word count». :-)
Для чего понадобится то ? Чтобы обогревать джавой на кластере окружающую среду ?
Так и так вроде жарко на улице.
Для чего понадобится то ?
Machine learning, например.
Навскидку пример вспоминается из индустрии — «real-time bidding».
Вы на что намекаете? Вы хотите всем доказать, что никому в мире на фиг не нужны ни Java, ни Hadoop? Ну, удачи.
Нужны конечно, чтобы парсить
Вот тебе для примера Архитектура Яндекса.
highscalability.com/yandex-architecture
Нет там джава, есть чуть-чуть вместе с перлом для периферийных задач.
Была бы везде джава, не было бы Яндекса.
По Google,
www.quora.com/...t-Google-for-each-project
С++.
Поиск Яндекса создавали тогда, когда Java была ещё в зачаточном состоянии, не пригодном для серьёзных проектов. Его не могли не написать на C/C++ (ну и с возможным использованием Perl).
Потом они использовали Java, только не для поиска, а для других проектов (Яндекс.Деньги, например).
Из текста по ссылке про Google:
«Gmail is mostly Java on the server side»
блин, опять "конгресс, немцы какието"©
БигДата вырастает из понимания, что микро мир информации и макро мир информации отличается как квантовая физика и физика движения планет.
Другие методы, другие подходы. Если у вас есть что-то, что будет работать только на больших обьемах данных, а на малых обьемах это работать не будет принципиально — знайте, что вы зацепили мАкромир и биг дату. И обьемы информации тут даже не имеют принципиального значения. Просто если у вас много информации, попасть на такую задачу проще, чем на малых обьемах данных. За одно и поменяется координально структура мышления. Потому что, как не странно, все что вы знали о жизни летающих насекомых, строить ракеты вам не поможет.
а на малых обьемах это работать не будет принципиально — знайте, что вы зацепили мАкромир и биг дату.
Оно будет работать даже при одной единице данных, и неплохо будет, но так странно, что не стоило огород городить...
Вся прелесть бигдаты в том, что можно использовать топорные и простые алгоритмы и они будут работать, но только на больших обьемах данных. В мире больших чисел, случайные величины и флуктуации в модели сглаживаются, модель становится ровной и глаткой. Любую, даже очень редкую гипотезу в большой модели можно перепроверить сотни и тысячи раз, что исключает момент случайности.
Классический пример — обучения распознования изображений, чем сейчас кстати гугл занимается. Простые топорные формулы высчитывания весовых коэфициентов нейрона, умноженные на прогон сотен миллионов изображений, равно прекрасно работающий алгоритм выполняющий сложнейшую задачу по распознованию обьектов.
А что ты знаешь про бигдату? Ты ж все обрабатываешь на дедовском десктопе подключенном в розетку на балконе?
Одно из свойств бигдата это решать сложные задачи на ограниченом для такой задачи оборудовании. К томуже, кто тебе сказал что я задействован только в этом проекте ?
У тебя крайне альтернативное представление о том что такое бигдата
а я и не обещал что всем будет понятно то, о чем я пишу
А ты какой сказочник. Из последнего технической беседы с тобой. Я Си не знаю, ой я там напутал, ой я здесь не сталкивался, здесь напутал в цифрах.
По поисковым структурам данным вообще капитально плаваешь.
Но ты рассказывай сказки про то как петабайты бороздят виртуальные машины джава. Тебя очень интересно послушать.
Ну я в си действительно не профи, про «не знаю» я не говорил, про структуры данных ты сейчас заливаешь, но какое это все имеет отношение к твоему профанству в бигдате?
отношение к твоему профанству в бигдате
Свое хранилище я уже давно озвучивал. Это 1 ТБ текстовых данных , которое соответствует примерно 100 млрд фактов. На котором я постоянно кручу и катаю разные интересные алгоритмы.
Да, это хранилище достаточно скромное. Но оно ДИСКРЕТНОЕ, это не корпоративный петабайт бекапов, медиа и дублей информации в какойто реляционной лабуде (чего у меня хватает на других проектах)
А теперь озвучь с чем ты работаешь. Потому что у меня сейчас складывается впечетление что количество специалистов по «бигдате» прямо пропорционально скидочным акциям от амазона на облачные сервисы + статьи на хабре.
У меня мои MR стабильно оbранатывают 100ТБ компрессированных бинарных данных разных фин транзакций.
Вот тебе теперь вопрос на засыпку. Что полезного можно построить на этих данных, причем такого, что на 100 гб ты не смог бы получить. Если ответишь на вопрос, значит понимаешь что такое большие данные и что они дают. Если нет, значит обычный хомячок саппортер амазоновского аккаунта, которому большие данные приносят больше геморроя чем полезных возможностей.
Кстате в таких унылых финансовых базах админы больше получают чем программисты, ибо надежность прежде всего.
Мы транзакции проверяем на фрод и всякие полиси, каждая транзакция джойнится с кучей источников данных. Если мы будем проверять только 0.1% транзакций, это как то странно вобщем будет.
Что и требовалось доказать.
Большие данные расматриваются как обычная база данных с селектиками и отчетиками. Никаким мачин лернинг, серьезной аналитикой и не пахнет. Рокет Сцаинц стремится к нулю. Но пафоса ...
О, а откуда ты узнал что у нас нету machine learning, который на самом деле есть?
Тогда задам свой вопрос еще раз
Что полезного можно построить на этих данных, причем такого, что на 100 гб ты не смог бы получить. Если ответишь на вопрос, значит понимаешь что такое большие данные и что они дают.
Для
machine learningразмер имеет прямое значение.
На мой скромный взгляд ты какой то бред несешь. Научись внятно излагать мысли а не играть в загадки и полунамеки.
Многие поняли, но ты не понял. Ок, тогда на пальцах.
Сейчас много толстых лысых дядей, ходят по семинарам посвященным бигдата и спрашивают. У нас накопилось очень много данных, что полезного мы можем с ними сделать, помимо обычных коммерческих флоу. Ну там какую интересную аналитику можно построить, какие применить самообучающиеся алгоритмы, может быть можно упростить существующие алгоритмы.
Вот в этом и вопрос — что конкретно тебе дали большие данные.
Ответ «проверка по фродам» не принимается. Это обычный коммерческий флоу которому не нужны большие данные.
Если транзакций много (сотни миллионов) и данных к каждой много, то большие данные вполне себе нужны.
Мне твои бестолковые фейспалмы побоку.
Всё правильно, только мышление меняется кардинально, к понятию координат отношение ортогональное.
Сюда хорошо бы иллюстрацию — кардинал смотрит на тебя как на...
designtorg.ru/...3/02/wpid-EFavbYrAUU0.jpg
Хорошо, что не как на абсцесс.
а почему никто не советует python (numpy and etc.) как альтернатива R? Сам начал изучение с матана и python. хотя меня больше интересует ML
в pyspark
download.yandex.ru/...ompany/schad_programm.pdf Литература для для поступления в школу анализа данных Yandex
А почему не kx/q?
1) Бесплатный. 2) Популярный. 3) Как следствие п.2: вокруг R уже сложилась неплохая инфраструктура, 6000+ пакетов в офф. репозитории + биокондуктор и проч.,; отдельные создатели пакетов вообще не контрибьютят их в общий репозиторий. 4) ...
Альтернативная репа с пакетами www.bioconductor.org
Отсутствие комьюнити, отсутствие литературы (полторы книжки на Амазоне не в счёт), отсутствие адекватной бесплатной версии, очень узкая специализация и, следовательно, отсутствие каких-либо перспектив кроме работы с монстроидальной энтерпрайз-системой в одном из немногочисленных монстроидальных компаний-клиентов, откуда обычно уходят только на пенсию.
Чтото типа
www.coursera.org/learn/machine-learning
Правда инглиш нужно чуток знать
dou.ua/...orums/topic/14027/#719419 вот я как-то уже отписывался по BI не совсем Big Data но рядом. Неплохо пишет один товарищ с хабра habrahabr.ru/users/akrot/topics хорошая вводная лекция яндекса (не для изучения а просто для понимания о чём это вообще) habrahabr.ru/...mpany/yandex/blog/214217 ну и абсолютно неверное и ограниченное представление, встречающиеся внизу в каментах, о том что big data — это всегда NoSQL и исключительно NoSQL — не стоить брать во внимание. SQL — это инструмент высокого уровня и в Big Data он тоже хорошо используется. Мир давно перестал быть чёрно белым. Ну и конечно же www.coursera.org/courses?query=Big Data А вообще для того что бы подступиться к Big Data — наведите порядок в своих текущих данных. Big Data появляется от новых задач — а новые задачи появляются, и главное время и средства для их реализации, когда старые решены.
Спасибо за ссылки. Да, курс на курсере нужно пройти.
наведите порядок в своих текущих данныхнаводить порядок по какому-то алгоритму а по какому? Хочу найти эти новые задачи, но ничего не зная о биг дата, не знаю что можно применить. Вот одна из задач, которых вижу для себя интересных это кластеризировать все вопросы, но тут наверное больше алгоритмы NLP нужны.
По алгоритму наведения порядка — новые задачи искать не надо они сами перед вами проявятся — вас всё устраивает в вашей текущей структуре организации данных? Какие части системы работы с данными самые медленные? Почему? Какой рост, без изменений текущая архитектура выдержит? Какие основные векторы развития вашего проекта вы видите? Какие задачи касательно данных в связи с этими векторами появляются? Вы используете сфинкс — вы достаточно хорошо его знаете? Вы уже вышли на те запросы которые он разрешить для вас не может? Что с шардированием масштабированием? Что с ACID. Где он у вас нарушается и почему и из-за чего? Почему это не страшно и нормально? Вашу текущую СУБД вы научились настраивать и оптимизировать максимально? Вы хоть знаете ближайшие ограничения по работе с данными которые вам предстоят на текущей конфигурации? Что самое слабое звено? Как его обойти? Где и когда может появится другое слабое звено которое обойти не получится не меняя круто архитекруту и инструменты? Big Data — это инструмент, большой сложный интересный но инструмент — задачи вам ставит жизнь, пользователи, внутренний голос, рынок — а Big Data это возможный инструмен решения ваших задач, конечно научится владеть этим инструментом придётся — но учится нужно от задачи — если у вас нет задачи — то просто изучите литературу и придумайте себе задачу для обучения владения этим инструментом — прикиньте сколько вам потребуется на это времени и ресурсов, потяните ли вы такое в одиночку — или лучше пытаться найти компанию где вам разрешат кофе подносить для спецов с возможностью обучаться у них. Таких компаний на самом деле очень мало (я не работаю с BigData если что — возможно мы вырастем но пока это просто данные которых много — чем это отличается от BigData — есть в лекции).
Можно посмотреть на курсере курс по биг дата и понять что это такое. Там и литературу посоветуют и опишут базовую математику/принципы.
Вход в big data начинается с формулировки, чем именно для вашего проекта не подходит ближайшая доступная SQL СУБД (даже если она используется в тупом key-value режиме). До этого, куда-то идти бессмысленно, и получаются проблемы, как у нас было с VSC — начали с Riak, а потом судорожно переползали на Postgres, потому что у Riak не оказалось ни одного адекватного для наших задач backend’а.
Согласен, но посоветуйте лит-ру привязаную к интесующему меня направлению, а не учебник по мат. анализу
скорее по теории множеств — но конкретного учебника не подскажу
математика в принципе очень нужна, но не у нас. В украине важно программирование с немалым опытом + дюжина фреймворков + noSQL. Тогда вопрос: как без математики? Значит у нас неустаканено определение больших данных. Каждая фирма понимает по своему, и по сути математика на последнем месте, если недоросли HR вообще вспомнят такой термин.
Я уже писал что большими данными в Украине мало компаний занимается, может быть мобильный оператор какой, но не уверен — а там где ими занимаются математика там есть по определению.
Да, не устоялось содержание этого термина у нас. Путают часто рекрутеры машинное обучение с большими данными и интернетом вещей в разных пропорциях и с новообразованными названиями. И по сути больших данных почти нет.
рекрутеры часто путают и не такое)
И по сути больших данных почти нет.
Все зависит от того, под каким углом смотреть.
Обычный фильм скаченый в приличном качестве, это около 150 миллиардов пикселов и около 20 разных статистических методов сжатия в кодеке, с кучей трехэтажной матемитики. Чем не бигдата ? Ее больше чем кажется на первый взгляд, кто хочет дотянется и в глухом районном центре. Не всегда бигдата это фейсбучные лайки в хадупах, риаках и прочьих шляпах на джава.
Так и есть, любая обьемопристойная инфа, раздробленная на биты так и обозреваема. Но кто в Украине в этом востребован? Все решаемо на «макроуровне».
При Тьюринге и компьютеры не были востребованы.
И ничего, както продвигались. Все зависит от желания.
Есть лопата, можно копать.
Недавно вышла неплохая книга — Big Data: Principles and best practices of scalable realtime data systems // Nathan Marz, James Warren. Где Nathan Marz — создатель Apache Storm. Ну а вообще, Apache Storm, Apache Spark, Apache Flink — это то, на что следует обратить внимание при умной обработке BigData, там заодно и поймете проблемы и методики их решений
courses.edx.org/...leyX/CS100.1x/1T2015/info
courses.edx.org/...leyX/CS190.1x/1T2015/info
И подобные курсы
Литература — заходишь на Amazon и вбиваешь в поиск big data machine learning
Sergio Gonzales прав. Начинать надо с матана и статистики. Потом плавно переходить на machine learning с привязкой к R и Spark.
В big data главное не то, как ты разместишь сотню терабайт данных. Для этого много ума не надо. А то, как ты их обработаешь.
С матана и статистики надо начинать, но наши рекрутеры этого не понимают. Я автор не одного пособия по прикладной математике, в том числе и по матстатистике. Но это без большого технологического базиса (который аморфный и .... резиновый у нас) ничто, так еще и возраст 40+ для инженеров BigData как нереальное
По моим скромны данным, в Украине в принципе всего несколько проектов, где используется machine learning в каком-то виде. В общем случае у нас Биг Датой называют всё что ни попадя и отсюда следует абсолютное непонимание, какими скиллами должен обладать кандидат. Не только на уровне рекрутеров, но и выше.
40+ лет статистик, способный разработать качественные модели, — это очень круто. Проблема лишь в том, что здесь работы для него очень мало.
На Kaggle не пробовали в соревнованиях участвовать? Думаю, может очень помочь с поиском работы. А если потенциальный работодатель не знает что такое Kaggle — к чёрту такого работодателя, едва ли он понимает, кого он хочет взять на работу, зачем и как оценивать уровень специалиста.
Я видел публикацию о Kaggle на хабре с примерами на пайтоне, спасибо что напомнили. Займусь и этим. Проще и интереснее общаться по этим вопросам напрямую в зарубежных блогах и Linkedin, хотя их тоже превеликое множество и надо узко специализироваться.
начать с того что бы понять — есть ли увас уже биг дата и стоит ли городить огород
чувак просто хоче до бігдати, наскільки я зрозумів
Так і хочу знайти примінення їй в свому проекті, щоб чогось навчитися.
Если у тебя ее нет в проекте, то как ты ее туда применишь?
есть 700тыс пользователей и 1,5 млн вопросов. Может и не биг дата, но что-то попробовать можно
big data — оно про обработку, зачастую сложную и параллелизированную, а не про хранение террабайтов текстовых чанков. откатать-изучить при таких вводных это как пытаться применить матанализ на сложении.
upd m.habrahabr.ru/...pany/beeline/blog/218669
так эта вся хня в память на одном сервере поместиться, не надо это хадупом содомировать
я так тоже думал, пока не начал работать с файликом на 100 лимонов записей, и всего 3.5 гигабайт. Ни ссд диски ни коре и7 — ничего не спасло. Пришлось кластер искать.
«Хороший» алгоритм может поставить раком такое железо и при меньших объёмах данных. :-)
2 миллиона сущностей — это конечно не биг — но вот связей между ними может быть столько что хватит с лихвой — самое главное знать и понимать для чего вы их строите.
Jorzchyk Pushysty
Tim Tretyak
Valentin Nechayev
Mobile
DNA Exp
Grez
Mobile
Anatoli Koutsevol
reality_hacker
Sergii Vashchyshchuk
Леголас Трандуилович
Anatoli Koutsevol
Roman Khanenko
NewType
DNA Exp
Serge Ribalchenko
Denys
Igor Shevchenko
Deep Style
Oleksandr Zakrevskyi
Igor Sokolov
Valentin Nechayev
Sergio Gonzales
A G
Нестор Иванович
Отважный Заяц
Нестор Иванович
175 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів