Привет, Хабр! Мы продолжаем цикл статей, посвященный Apache Flume. В предыдущей части мы поверхностно рассмотрели этот инструмент, разобрались с тем, как его настраивать и запускать. В этот раз статья будет посвящена ключевым компонентам Flume, с помощью которых не страшно манипулировать уже настоящими данными.
6
Рейтинг
Hadoop *
Фреймворк для распределённых приложений
Сначала показывать
Порог рейтинга
Уровень сложности
Сравнение производительности Hadoop на DAS и Isilon
6 мин
4.1KПеревод
Я уже писал о том, с помощью Isilon можно создавать озёра данных, способные одновременно обслуживать по несколько кластеров с разными версиями Hadoop. В той публикации я упомянул, что во многих случаях системы на Isilon работают быстрее, чем традиционные кластеры, использующие DAS-хранилища. Позднее это подтвердили и в IDC, прогнав на соответствующих кластерах различные Hadoop-бенчмарки. И на этот раз я хочу рассмотреть причины более высокой производительности Isilon-кластеров, а также как она меняется в зависимости от распределения данных и балансировки внутри кластеров.
+6
Data Lake – от теории к практике. Методы интеграции данных Hadoop и корпоративного DWH
6 мин
23KВ этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как Hadoop — задача интеграции данных Hadoop и данных корпоративного DWH. В Data Lake в Тинькофф Банке мы научились эффективно решать эту задачу и дальше в статье я расскажу, как мы это сделали.
Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop).
Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop).
+5
Flume — управляем потоками данных. Часть 1
11 мин
33KПривет, Хабр! В этом цикле статей я планирую рассказать о том, как можно организовать сбор и передачу данных с помощью одного из инструментов Hadoop — Apache Flume.
+17
Истории
BDRA – современная архитектура для аналитики больших данных
9 мин
11KПод большими данными обычно понимают серию подходов, инструментов и методов обработки структурированных и неструктурированных данных, которые отличают огромные объёмы и значительное многообразие. Цель такой обработки — получение воспринимаемых человеком результатов.
Поток данных может поступать из разных источников, эти данные гетерогенны и передаются в различных форматах: текст, документы, изображения, видео и многое другое. Для извлечения из таких данных полезной информации определяющее значение имеет программно-аппаратная платформа.
Поток данных может поступать из разных источников, эти данные гетерогенны и передаются в различных форматах: текст, документы, изображения, видео и многое другое. Для извлечения из таких данных полезной информации определяющее значение имеет программно-аппаратная платформа.
+10
Как устроен Relap.io — сервис, который выдает 30 миллиардов рекомендаций в месяц
4 мин
35KRecovery Mode
Мы давно ничего не писали в наш блог и возвращаемся с рассказом о нашем новом проекте: Relap.io (relevant pages).
Мы запустили рекомендательный B2B-сервис Relap.io полтора года назад. Он облегчает жизнь редакции и читателям СМИ. В будние дни Relap.io обслуживает 15 млн уников и выдаёт 30 миллиардов рекомендаций в месяц.
Сейчас Relap.io крупнейшая рекомендательная платформа в Европе и Азии.
+18
Scalding: повод перейти с Java на Scala
8 мин
22KВ этой статье я расскажу о Twitter Scalding – фреймворке для описания процесса обработки данных в Apache Hadoop. Я начну издалека, с истории фреймворков поверх Hadoop. Потом дам обзор возможностей Scalding. В завершение покажу примеры кода, доступные для понимания тем, кто знает Java, но почти не знаком со Scala.
Интересно? Поехали!
+18
MongoDB как средство мониторинга LOG-файлов
9 мин
20KВ этой статье я расскажу об использовании нереляционной базы MongoDB для мониторинга журнальных файлов. Для мониторинга log-файлов существует множество инструментов, от мониторинга shell-скриптами, завязанными на cron, до кластера apache hadoop.
Подход с мониторингом скриптами текстовых файлов удобен только в простейших случаях, когда, например, проблемы выявляются наличием в журнальном файле строк «ERROR», «FAILURE», «SEVERE» и т.п. Для мониторинга больших файлов удобно использовать систему Zabbix, где Zabbix Agent (active) будет считывать только новые данные и с определённой периодичностью отправлять их на сервер.
Подход с мониторингом скриптами текстовых файлов удобен только в простейших случаях, когда, например, проблемы выявляются наличием в журнальном файле строк «ERROR», «FAILURE», «SEVERE» и т.п. Для мониторинга больших файлов удобно использовать систему Zabbix, где Zabbix Agent (active) будет считывать только новые данные и с определённой периодичностью отправлять их на сервер.
+20
Видео докладов Badoo с конференции Highload 2015
1 мин
13KНаконец-то у нас появились видео выступления наших спикеров на Highload 2015, которые мы с удовольствием выкладываем.
Если у вас появятся вопросы к докладчикам, задавайте их в комментариях. Ребята на них обязательно ответят.
1. «Near-realtime аналитика событий в высоконагруженном проекте», доклад Александра Крашенинникова
Если у вас появятся вопросы к докладчикам, задавайте их в комментариях. Ребята на них обязательно ответят.
1. «Near-realtime аналитика событий в высоконагруженном проекте», доклад Александра Крашенинникова
+23
Kudu – новый движок хранения данных в экосистеме Hadoop
5 мин
13KKudu был одной из новинок, представленых компанией Cloudera на конференции “Strata + Hadoop World 2015”. Это новый движок хранения больших данных, созданный чтобы покрыть нишу между двумя уже существующими движками: распределенной файловой системой HDFS и колоночной базой данных Hbase.
Существующие на данный момент движки не лишены недостатков. HDFS, прекрасно справляющаяся с операциями сканирования больших объемов данных, показывает плохие результаты на операциях поиска. C Hbase все с точностью до наоборот. К тому же HDFS обладает дополнительным ограничением, а именно, не позволяет модифицировать уже записанные данные. Новый движок, согласно разработчикам, обладает преимуществами обеих существующих систем:
— операции поиска с быстрым откликом
— возможность модификации
— высокая производительность при сканировании больших объемов данных
+9
Big data от А до Я. Часть 3: Приемы и стратегии разработки MapReduce-приложений
7 мин
82KПривет, Хабр! В предыдущих статьях мы описали парадигму MapReduce, а также показали как на практике реализовать и выполнить MapReduce-приложение на стеке Hadoop. Пришла пора описать различные приёмы, которые позволяют эффективно использовать MapReduce для решения практических задач, а также показать некоторые особенности Hadoop, которые позволяют упростить разработку или существенно ускорить выполнение MapReduce-задачи на кластере.
+23
Майкл Стоунбрейкер — Hadoop на распутье
11 мин
18KПеревод
[@tsafin — Обладателя премии Тьюринга Майкла Стоунбрейкера представлять не надо, он и его студенты из Беркли и MIT создали, по ощущениям, большую часть реляционных и нереляционных баз данных за последние пару десятилетий. Ingres и Postgres, C-Store и Vertica, H-Store и VoltDB – вот лишь малая часть проектов и фирм, на который Майкл и его студенты повлияли напрямую, а ведь еще есть множество форков и деривативов…
Т.о. когда он критикует что-то, будь то NoSQL или Hadoop, то индустрии стоит, как минимум, прислушаться, а лучше попытаться измениться.
Мне показалось интересной его точка зрения на Hadoop, высказанная в статьях 2012 и 2014 года, и было интересно проследить развитие точки зрения «классика» за такой короткий промежуток времени.
Первую статью «Possible Hadoop Trajectories», опубликованную в «Comunications of ACM» http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext, Стоунбрейкер написал в мае 2012 года в соавторстве с Джереми Кепнером (Jeremy Kepner), который в тот момент работал как старший технический персонал в MIT, и как исследователь в MIT Mathematics Department и MIT Computer Science and AI Lab. Эта статья, написанная в соавторстве, кажется более дерзкой и задорной, по сравнению со второй, написанной уже им самим двумя годами позже (да и, чего уж там, первая статья написана IMHO в лучшем стиле), но я публикую их в связке, т.к. контекст за прошедшие пару лет сильно изменился, и было бы нечестно по отношению к экосистеме Hadoop/HDFS оставлять это незамеченным.
+16
Big Data от А до Я. Часть 2: Hadoop
9 мин
224KТуториал
Привет, Хабр! В предыдущей статье мы рассмотрели парадигму параллельных вычислений MapReduce. В этой статье мы перейдём от теории к практике и рассмотрим Hadoop – мощный инструментарий для работы с большими данными от Apache foundation.
В статье описано, какие инструменты и средства включает в себя Hadoop, каким образом установить Hadoop у себя, приведены инструкции и примеры разработки MapReduce-программ под Hadoop.
В статье описано, какие инструменты и средства включает в себя Hadoop, каким образом установить Hadoop у себя, приведены инструкции и примеры разработки MapReduce-программ под Hadoop.
+32
Ближайшие события
Firebird Conf: конференция для разработчиков и администраторов СУБД Firebird
6 июня
09:00 – 20:00
Москва
Файловая система и Hadoop: Опыт Twitter (Часть 2)
2 мин
9.7KНаш основной принцип работы заключается в том, что IaaS должен быть простым и понятным даже для тех, кто не сталкивался с ИТ-сферой. Поэтому мы проводим постоянную оптимизацию всех систем и рассказываем о том, что нам удалось сделать, в нашем блоге на Хабре.
Пара примеров:
Сегодня мы решили продолжить краткий разбор заметки команды инженеров Twitter о создании файловой системы для работы с кластерами Hadoop.
Пара примеров:
- «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
- Как работает API нашего IaaS-провайдера
- Как мы разработали свой DNS-менеджер
Сегодня мы решили продолжить краткий разбор заметки команды инженеров Twitter о создании файловой системы для работы с кластерами Hadoop.
+8
Файловая система и Hadoop: Опыт Twitter (Часть 1)
2 мин
12KНаш основной принцип работы заключается в том, что IaaS должен быть простым и понятным даже для тех, кто не сталкивался с ИТ-сферой. Поэтому мы проводим постоянную оптимизацию всех систем и рассказываем о том, что нам удалось сделать, в нашем блоге на Хабре.
Пара примеров:
Сегодня мы решили взглянуть на западный опыт и кратко проанализировать заметку команды инженеров Twitter, в которой они рассказали о своем подходе к работе с файловой системой для кластеров Hadoop.
Пара примеров:
- «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
- Как работает API нашего IaaS-провайдера
- Как мы разработали свой DNS-менеджер
Сегодня мы решили взглянуть на западный опыт и кратко проанализировать заметку команды инженеров Twitter, в которой они рассказали о своем подходе к работе с файловой системой для кластеров Hadoop.
+11
Утилиты командной строки могут быть в 235-раз быстрее вашего Hadoop кластера
7 мин
45KПеревод
Примечания tsafin:
Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.
Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.
Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.
Введение
Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.
+62
Анализ логов с помощью Hadoop/Python
6 мин
20KПривет, Хабр! В этом посте я хотел бы рассказать вам о том, как мы, Лаборатория новых профессий, вместе с компанией Data-centric Alliance смогли сконструировать несколько лабораторных работ, посвящённых обработке и анализу веб-логов. Эти лабораторные работы являются ключевыми в рамках первого кейса нашей образовательной программы «Специалист по большим данным» и выполняются на основе аудиторных данных DMP Facetz.DCA. Меня зовут Артем Пичугин, и я являюсь её координатором.
Представьте, что вы компания, продающая автомобили. Кому показать рекламу автомобиля? На каких сайтах? Так, чтобы недорого и эффективно? Казалось бы, ответ очевиден: пользователям, которые заходят на страницы покупки автомобилей на сайтах компаний, а также на досках объявлений типа Avito и т д.
Задача
Представьте, что вы компания, продающая автомобили. Кому показать рекламу автомобиля? На каких сайтах? Так, чтобы недорого и эффективно? Казалось бы, ответ очевиден: пользователям, которые заходят на страницы покупки автомобилей на сайтах компаний, а также на досках объявлений типа Avito и т д.
0
Краткая история масштабирования LinkedIn
9 мин
26KПеревод
Примечание переводчика: Мы в «Латере» занимаемся созданием биллинга для операторов связи. Мы будем писать об особенностях системы и деталях ее разработки в нашем блоге на Хабре (например, об обеспечении отказоустойчивости), но почерпнуть что-то интересное можно и из опыта других компаний. Сегодня мы представляем вашему вниманию адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Сервис LinkedIn был запущен в 2003 году с целью создания и поддержания сети деловых контактов и расширения возможностей поиска работы. За первую неделю в сети зарегистрировалось 2 700 человек. Спустя несколько лет число продуктов, клиентская база и нагрузка на серверы заметно выросли.
Сегодня в LinkedIn насчитывается более 350 миллионов пользователей по всему миру. Мы проверяем десятки тысяч веб-страниц каждую секунду, каждый день. На мобильные устройства сейчас приходится более 50% нашего трафика по всему миру. Пользователи запрашивают данные из наших бэкенд-систем, которые, в свою очередь, обрабатывают по несколько миллионов запросов в секунду. Как же мы этого добились?
Сервис LinkedIn был запущен в 2003 году с целью создания и поддержания сети деловых контактов и расширения возможностей поиска работы. За первую неделю в сети зарегистрировалось 2 700 человек. Спустя несколько лет число продуктов, клиентская база и нагрузка на серверы заметно выросли.
Сегодня в LinkedIn насчитывается более 350 миллионов пользователей по всему миру. Мы проверяем десятки тысяч веб-страниц каждую секунду, каждый день. На мобильные устройства сейчас приходится более 50% нашего трафика по всему миру. Пользователи запрашивают данные из наших бэкенд-систем, которые, в свою очередь, обрабатывают по несколько миллионов запросов в секунду. Как же мы этого добились?
+27
Big Data — первый опыт ED IB
4 мин
18KВсем привет! Сегодня мы хотим рассказать про наше знакомство с Big Data, которое началось в 2012 году, когда рынок ещё не накрыла волна популярности темы больших данных.
К тому времени у нас уже накопилась экспертиза в области построения хранилищ данных. Мы рассматривали различные пути улучшения стандартных архитектур ХД, поскольку заказчик хотел обрабатывать большие объёмы данных за короткое время и при ограниченном бюджете. Мы понимали, что большие объёмы данных для стандартного хранилища прекрасно обрабатываются на MPP-платформах, но де-факто это дорого. Значит, нам нужна недорогая распределенная система. Ей оказался Hadoop. Он нуждается в минимальных начальных вложениях, а первые результаты можно получить очень быстро. В дальнейшей перспективе – горизонтальное, практически линейное масштабирование, открытая платформа и много интересных дополнительных функций: например, NoSQL, быстрый поиск по данным, подобие SQL-языка доступа к данным.
К тому времени у нас уже накопилась экспертиза в области построения хранилищ данных. Мы рассматривали различные пути улучшения стандартных архитектур ХД, поскольку заказчик хотел обрабатывать большие объёмы данных за короткое время и при ограниченном бюджете. Мы понимали, что большие объёмы данных для стандартного хранилища прекрасно обрабатываются на MPP-платформах, но де-факто это дорого. Значит, нам нужна недорогая распределенная система. Ей оказался Hadoop. Он нуждается в минимальных начальных вложениях, а первые результаты можно получить очень быстро. В дальнейшей перспективе – горизонтальное, практически линейное масштабирование, открытая платформа и много интересных дополнительных функций: например, NoSQL, быстрый поиск по данным, подобие SQL-языка доступа к данным.
+9
Data Science: путь к профессионализму
8 мин
21KПеревод
Здравствуйте все!
На волне непрекращающихся дискуссий о Hadoop и прочих больших данных мы не могли пройти мимо замечательной публикации Джерри Овертона, рассказывающей о профессиональном подходе к анализу больших данных в компаниях любого размера. Понятные картинки, предоставленные автором, а также краткий парад технологий, без которых современному Data scientist'у не обойтись. Поэтому пусть статья и начинается с (ошибочной!) посылки: «Не читайте книги по Data Science», она заслуживает публикации в блоге нашего издательства.
Если среди уважаемых читателей найдутся те, кто захочет обсудить Hadoop и прочие технологии из его экосистемы, а также литературу по специфическим алгоритмам, затронутым автором — давайте побеседуем об этом в комментариях.
На волне непрекращающихся дискуссий о Hadoop и прочих больших данных мы не могли пройти мимо замечательной публикации Джерри Овертона, рассказывающей о профессиональном подходе к анализу больших данных в компаниях любого размера. Понятные картинки, предоставленные автором, а также краткий парад технологий, без которых современному Data scientist'у не обойтись. Поэтому пусть статья и начинается с (ошибочной!) посылки: «Не читайте книги по Data Science», она заслуживает публикации в блоге нашего издательства.
Если среди уважаемых читателей найдутся те, кто захочет обсудить Hadoop и прочие технологии из его экосистемы, а также литературу по специфическим алгоритмам, затронутым автором — давайте побеседуем об этом в комментариях.
+9
Вклад авторов
alizar 319.0ffriend 128.0asash 109.0ph_piter 83.8fortyseven 83.0sgzmd 83.0Deneb 66.0olegchir 63.0PastorGL 62.0pustota_2009 61.0