Ну и я тут говорю не о бесконечном потоке сознания, а о вполне конечном огромном файле размером в 99 ТиБ, который содержит какой-то текст — возможно, про Гитлера, возможно, Lorem ipsum, или вообще краткое содержание Википедии.
Просто верно ли я понимаю, что mapreduce не приспособлен к работе с неструктурированными данными? И в данном конкретном случае, нельзя получить корректный результат без предварительной обработки и разбиения мегафайла на записи приемлемого размера, которые могут поместиться в память? И при этом мы можем выбрать только такой размер чанка, который кратен размеру записи?
Ну, у нас же big data, правильно? Пусть исходный текст является повторением вот той строки 1 триллион раз, т.е. итоговый размер структуры будет составлять 1.09e+14 байт, или порядка 99 ТиБ. Т.е. в память мы эту строку запихнуть точно не сможем. При этом ожидаемый выхлоп алгоритма должен быть
А по факту будет отчет с разными комбинациями слов, разрезанных пополам в произвольных позициях. И даже если увеличить размер чанка до, например, 4 ГиБ, которые поместятся в памяти произвольной ноды, у нас все равно есть слова на границах, которые были разрезаны. Или я все же упускаю что-то в понимании?
Я прочитал вашу статью, представил ваши примеры, и у меня возник вопрос начинающего.
Предположим, что мы в полном соответствии с примером в статье хотим посчитать повторения слов в следующем известном шуточном стихотворении:
Ехал Гитлер через Гитлер
Видит Гитлер Гитлер Гитлер
Сунул Гитлер в Гитлер Гитлер
Гитлер Гитлер Гитлер Гитлер
Размер чанка примем равным 8 байтам, и для простоты будем считать, что текст у нас в какой-то однобайтовой кодировке, поэтому 1 байт = 1 знак, и вместо переносов строки — обычные пробелы.
Если я все правильно понимаю, то это значит, что мапперы на входе получат следующее разбиение:
Наверное, вы уже поняли, что меня смущает, но я доведу мысль до конца. Теперь, перед тем, как передать данные в reducer-ы, платформа выполняет группировку по ключу.
Если варьировать размер блока, результаты тоже будут дико гулять, и все еще не иметь ничего общего с правильным ответом, полученным традиционным способом. Что я понял неправильно? Почему так получается? Как с таким бороться?
Автор, к сожалению, обороты вида "Так я и сделал в далеком 2009 году, когда ты, читатель, не знал даже про Руби" вместо расположения вызывают отталкивающее ощущение :(
Послушайте видео с роботами Boston Dynamics в живых испытаниях, с оригинальным звуком — вы услышите дикий вой, хорошо знакомый любому, кто когда-либо заходил в серверную под нагрузкой. Этот вой — это десятки кулеров, которые охлаждают всю внутреннюю машинерию, и именно он является причиной того, что многие видео boston dynamics имеют отфильтрованный звуковой ряд.
«Накапливаться» не получится, т.к. информация и не создается. Я внимательнее перечитал ваш комментарий и понял, в чем суть вашего вопроса.
С точки зрения обратимости времени, сгорание вашего харда не уничтожает информацию — да, частицы жесткого диска перемагничиваются, вступают в реакции с окислителем, излучают всяческие фотоны в процессе, но если запустить процесс вспять, то из кучи пепла можно получить в точности ваш жесткий диск, как он был.
С черными дырами проблема в том, что процесс падения вещества в черную дыру не получается обратить. У них, насколько известно, нет «внутреннего состояния», только заряд, масса и скорость вращения. Поэтому при обращении времени возникает вопрос, когда из черной дыры должна вылететь частица, и что это за частица должна быть. В поведении самой ЧД нет ничего, что указывало бы на то, что из нее что-то вообще должно бы вылетать при обращении времени, в этом сложность, и именно это понимается под уничтожением информации.
Фотон, по мере того как преодолевает гравитационное притяжение, совершает работу, соответственно, теряет энергию, поэтому его частота понижается.
Простите, а в этой фразе точно все правильно? Мне казалось, что гравитационное красное смещение возникает из-за замедления времени рядом с массивными объектами, поэтому когда фотон переходит через границу медленного времени и быстрого времени, его частота понижается, сродни тому, как понижается частота при переходе через границу сред с разной оптической плотностью — только в данном случае четкой границы нет, это градиент.
Я нашел его комментарий по этой теме на slashdot, но без подробностей. Люди в публикации ссылаются на вот этот препринт, но я еще не смотрел его на предмет, можно ли из него извлечь достаточно данных для формального описания алгоритма.
Нет, он доказал, что нижняя граница не 106846168, а 1029, а потом уже до 1029 добил программой. До 106846168 добивать бы пришлось до конца жизни Вселенной, это ж, фактически, 222742478, а доитерироваться в обозримое время даже до 2128 уже проблематично.
28 сентября 2016 в 08:32 пользователь ripatti написал:
Виноградов доказал не от 1 до N, а от N до бесконечности. Т.е. чтобы доказать тернарную гипотезу полностью, можно было бы просто проверить руками или на компьютере от 1 до N, если бы не астрономическое число N.
upd. Собственно, Хельфготт доказал тернарную гипотезу снизив границу N до не настолько большого числа, а все числа до N добил с помощью компьютера.
Отличный шуточный пост посреди недели, спасибо! Можно с серьезным лицом показывать коллегам и встревоженно спрашивать "о б-ги, как же нам жить дальше?".
По сути поста — плохая аналогия подобна котенку с дверцей. Если всю мякотку свести к одному практическому примеру, то вы утверждаете, что компьютер с 64 ГБ памяти тратит на получение 1 байта в восемь раз больше времени, чем компьютер с 1 ГБ памяти. Ну конечно же так и есть! Даже поспорить не с чем. Пока библиотекарь дойдет до границы чипа, пока найдет нужный байт в каталоге байтов… А там и обед уже, а потом и короткий день.
Ну и да, глупый вопрос не по теме — с чего вы вообще взяли, что доступ к произвольному элементу связного списка — это O(1)?
На мой взгляд — вполне нормальная практика. Плюс, большинство библиотек так или иначе предоставляют утилитарный метод для этого, куда можно просто скормить массив промисов.
Просто верно ли я понимаю, что mapreduce не приспособлен к работе с неструктурированными данными? И в данном конкретном случае, нельзя получить корректный результат без предварительной обработки и разбиения мегафайла на записи приемлемого размера, которые могут поместиться в память? И при этом мы можем выбрать только такой размер чанка, который кратен размеру записи?
А по факту будет отчет с разными комбинациями слов, разрезанных пополам в произвольных позициях. И даже если увеличить размер чанка до, например, 4 ГиБ, которые поместятся в памяти произвольной ноды, у нас все равно есть слова на границах, которые были разрезаны. Или я все же упускаю что-то в понимании?
Предположим, что мы в полном соответствии с примером в статье хотим посчитать повторения слов в следующем известном шуточном стихотворении:
Размер чанка примем равным 8 байтам, и для простоты будем считать, что текст у нас в какой-то однобайтовой кодировке, поэтому 1 байт = 1 знак, и вместо переносов строки — обычные пробелы.
Если я все правильно понимаю, то это значит, что мапперы на входе получат следующее разбиение:
Теперь мапперы прогоняют свой алгоритм для каждого чанка и выдают следующие ключи:
Наверное, вы уже поняли, что меня смущает, но я доведу мысль до конца. Теперь, перед тем, как передать данные в reducer-ы, платформа выполняет группировку по ключу.
Ну и наши reducer-ы просто суммируют единички для каждого слова.
Мне кажется проблемой то, что мы, по моему пониманию, решили не ту задачу, которую хотели. Мы получили вот это:
А хотели (я хотел) вот это:
Если варьировать размер блока, результаты тоже будут дико гулять, и все еще не иметь ничего общего с правильным ответом, полученным традиционным способом. Что я понял неправильно? Почему так получается? Как с таким бороться?
Автор, к сожалению, обороты вида "Так я и сделал в далеком 2009 году, когда ты, читатель, не знал даже про Руби" вместо расположения вызывают отталкивающее ощущение :(
А почему в исходниках этого нет?
С точки зрения обратимости времени, сгорание вашего харда не уничтожает информацию — да, частицы жесткого диска перемагничиваются, вступают в реакции с окислителем, излучают всяческие фотоны в процессе, но если запустить процесс вспять, то из кучи пепла можно получить в точности ваш жесткий диск, как он был.
С черными дырами проблема в том, что процесс падения вещества в черную дыру не получается обратить. У них, насколько известно, нет «внутреннего состояния», только заряд, масса и скорость вращения. Поэтому при обращении времени возникает вопрос, когда из черной дыры должна вылететь частица, и что это за частица должна быть. В поведении самой ЧД нет ничего, что указывало бы на то, что из нее что-то вообще должно бы вылетать при обращении времени, в этом сложность, и именно это понимается под уничтожением информации.
Если перейти на appleupdate.org, там уведомление, что это исследовательский проект лаборатории Касперского. Что это значит?
Придумали, господа Брайт и Александреску (да, тот самый).
Отличный шуточный пост посреди недели, спасибо! Можно с серьезным лицом показывать коллегам и встревоженно спрашивать "о б-ги, как же нам жить дальше?".
По сути поста — плохая аналогия подобна котенку с дверцей. Если всю мякотку свести к одному практическому примеру, то вы утверждаете, что компьютер с 64 ГБ памяти тратит на получение 1 байта в восемь раз больше времени, чем компьютер с 1 ГБ памяти. Ну конечно же так и есть! Даже поспорить не с чем. Пока библиотекарь дойдет до границы чипа, пока найдет нужный байт в каталоге байтов… А там и обед уже, а потом и короткий день.
Ну и да, глупый вопрос не по теме — с чего вы вообще взяли, что доступ к произвольному элементу связного списка — это O(1)?
P.S. У вас все [ссылки] отвалились.
На мой взгляд — вполне нормальная практика. Плюс, большинство библиотек так или иначе предоставляют утилитарный метод для этого, куда можно просто скормить массив промисов.