В предыдущей части серии мы (в 100500й раз) попытались рассказать про основные приемы и стадии подхода Google MapReduce, должен признаться, что первая часть была намерено "капитанской", чтобы дать знать о MapReduce целевой аудитории последующих статей. Мы не успели показать ни строчки того, как всё это мы собираемся реализовывать в Caché ObjectScript. И про это наша рассказ сегодня (и в последующие дни).
Напомним первоначальный посыл нашего мини-проекта: вы всё еще планируем реализовать MapReduce алгоритм используя те подручные средства, что есть в Caché ObjectScript. При создании интерфейсов, мы попытаемся придерживаться того API, что мы описали в предыдущей статье про оригинальную реализацию Google MapReduce, любые девиации будут озвучены соответствующе.
Настоящий пост является является, фактически, резюме, подводящим итоги предыдущих «технологических» публикаций [1, 2, 3, 4, 5] и возникших дискуссий и обсуждений. Последние показали, что задач в которых применение R могло бы оказать хорошую помощь бизнесу очень и очень много. Однако, даже в тех случаях, когда R используется, далеко не всегда для этого применяются современные возможности R.
В первой части мы узнали о данных, и о том, как они могут быть использованы для извлечения из них метаданных или каких-то значений.
Вторая часть объяснила сам термин Big Data и показала, как он превратился в индустрию, причиной появления для которой стало влияние экономики. Эта, третья часть, в которой должно быть логическое продолжение предыдущих двух и у всего этого должен появиться смысл — грустная, местами ироничная, а местами пугающая. Вы видите сами, как технологические, бизнес, и даже социальные контракты в перспективе уже переопределялись большими данными таким путём, который мы только сейчас начинаем понимать. И, возможно, они никогда уже не станут контролируемыми.
С помощью чего бы не проводился анализ — суперкомпьютера или составленной вручную в 1665 году таблицы из списков мёртвых, некоторые аспекты больших данных существовали гораздо дольше, чем мы можем представить.
Темная сторона больших данных. Исторически роль больших данных не всегда была кристально чистотой. Идея переработки цифр, приводящей к количественной рационализации для чего-то, что мы и так хотели сделать, существует с тех пор, как у нас появились лишние деньги.
Привет, Хаброжители! Ранее мы переводили статью «Знакомство с Apache Spark». Сейчас вы знакомим Вас с одноименной книгой, написанной Сэнди Ризай, Ури Лезерсоном, Шоном Оуэн, Джошем Уиллсом.
В предыдущей статье я рассказал о том, как построить простейшую топологию для Apache Ignite. Она состояла из одного клиента и одного сервера, клиент слал на сервер сообщение и сервер его отображал. Было рассказано о том, как настроить продукт и проконтролировать его жизнедеятельность. Теперь пришло время для более сложного примера. Будет продемонстрировано построение сложной топологии и более интересные сценарии взаимодействия. Предполагается, что читатель ознакомился с базовыми операциями с Apache Ignite, изложенными в первой статье. В результате прочтения этих двух статей у читателя могут возникнуть какие-то предположения о том, как ему применить этот, без преувеличения, мощный продукт в своих проектах. Также статья будет полезна тем, кто интересуется построением высокопроизводительных систем, и хочет подсмотреть готовое решение для своего велосипеда.
Иногда приходится сталкиваться с убеждением, что R, будучи интерпретатором, слишком медленный для анализа задач «быстрого» бизнеса. В большинстве случаев такие тезисы поступают от аналитиков, не обладающих опытом разработки серьезного ПО, в т.ч. высокопроизводительных или встроенных систем, крайне требовательных к ограниченным аппаратным ресурсам. Это совершенно нормально, никто не может знать все на свете. однако, в 95% случаев оказывается, что R совершенно ни при чем, проблема заключается в неэффективном управлении памятью и процессом вычисления.
Рискну предположить, что среднестатистический читатель этой статьи с продуктом Apache Ignite не знаком. Хотя, возможно, слышал или даже читал статью на Хабре, в которой описывается один из возможных сценариев использования этого продукта. О принудительном использовании Ignite в качесте L2 кэша для Activiti я писал недавно. Возможно, узнав о том, что это написанный на Java open source продукт, позиционирующий себя как «высокопроизводительная, интегрированная и распределённая in-memory платформа для вычисления и обработки больших объёмов данных в реальном времени», обладающая, помимо прочего возможностью автоматического деплоймента вашего проекта на все ноды сложной топологии, вам захочется с ним познакомиться. Испытав такое желание, вы обнаружите, что Ignite документирован не то, чтобы совсем плохо, но и не очень хорошо. Есть туториал, кое-какой javadoc, но полного и целостного впечатления от ознакомления с этими источниками не возникает. В настоящей статье я попытаюсь восполнить этот пробел на основе собственного опыта познания Ignite, полученного преимущественно путём дебага. Возможно, в своих выводах и впечатлениях я буду не всегда прав, но таковы издержки метода. От читателя и тех, кто захочет повторить мой путь, требуется не так много, а именно знание Java 8 core, multithreading и Spring core.