Data Engineering *

Apache Spark на Kubernetes: чем полезен Apache YuniKorn 

Хотя Apache Spark предоставляет множество возможностей для разнообразных сценариев применения, его использование сопряжено с дополнительной сложностью и высокими затратами на обслуживание и администрирование кластера. В планировщике Kubernetes по умолчанию есть пробелы с точки зрения эффективного развертывания пакетных рабочих нагрузок на том же кластере, где также планируется длительная работа других сервисов. Для пакетных рабочих нагрузок из-за требуемого параллелизма вычислений в основном должно планироваться совместное и гораздо более частое выполнение. В этой статье мы подробно рассмотрим некоторые из этих пробелов и исследуем преимущества использования Apache YniKorn вместо стандартного планировщика.

Привет! Это мой первый пост здесь! Решил его написать, чтобы облегчить путь всем начинающим знакомство с ESP 8266. Много времени потратил чтобы разобраться с этой темой и что-то началось получаться. Изначально я отправлял данные в таблицу Googlesheets (об этом надо написать отдельный пост). Но потом захотелось сделать опорный проект - заготовку для дальнейшего развития. Итогом стала данная статья.

Итак, у нас есть ESP-01.

Компания EPAM давно работает с данными, первые крупные заказчики с проектами по Big Data появились в далёком 2001 году. В то время известные аналитические компании Gartner и Forrester, а также крупные поставщики Oracle, Microsoft и IBM отмечали, что компании должны двигаться в сторону Big Data, поскольку эти технологии незаменимы во всех областях, связанных с обработкой больших объёмов данных. С того времени команда экспертов EPAM постепенно росла, работая над всё более сложными проектами и предлагая проверенные решения и качественные продукты для работы с большими данными. Сегодня только в российском EPAM более 500 человек работают в Data-практике. О том, как всё начиналось, какие проекты встречались, какие провалы случались, к чему должны готовиться Data-специалисты и о том, какие вообще бывают Data-специалисты, я поговорила с руководителем Data-практики EPAM в России — Ильей Герасимовым. 

Добрый день уважаемые читатели! Данная статья является продолжением публикации "Повторяем когортный анализ, выполненный в Power BI, силами Python" (ссылка). Настоятельно рекомендую познакомиться с ней хотя бы бегло, иначе последующее повествование будет вам малопонятным. С момента ее выхода на Хабр прошло достаточно времени. Я основательно пересмотрел методологию решения подобных задач. Первым желанием было просто переписать старый материал, но после недолгих размышлений я пришел к выводу, что более разумным шагом будет оформить наработки в новую рукопись.

Какова основная причина моего "недовольства" Python и Power BI? Язык Python/R c тематическими библиотеками и Power BI (Tableau, Qlik) могут на 70-80% закрыть потребности бизнеса в расчете сложных метрик и построении визуализаций. Но только если речь идет об обработке относительно небольших датасетов с уже агрегированными данными. Если мы говорим о предварительном манипулировании данными в промышленном масштабе, то здесь игра переходит на сторону сервера с БД и используется SQL. Данный момент я не осветил в предыдущей публикации, поэтому решил ликвидировать это упущение здесь.

Привет, Хабр! У кого из вас black belt на sql-ex.ru, признавайтесь? На заре своей карьеры я немало времени провел на этом сайте, практикуясь и оттачивая навыки. Должен отметить, что это было увлекательное и вознаграждающее путешествие. Пришло время воздать должное.

В этой публикации я собрал топ прикладных задач и мои подходы к их решению в терминах SQL. Каждая задача снабжена кусочком данных и кодом, с которым можно интерактивно поиграться на SQL Fiddle.

Вторая часть нашей серии «Почему ваши приложения Spark медленно работают или выходят из строя» следует за первой частью об управлении памятью и посвящена вопросам, возникающим при искажении данных и очистки памяти в Spark. Как и многие другие проблемы, связанные с производительностью Spark, симптомы нарастают по мере увеличения объема данных, обрабатываемых приложением.

Всем привет! В этой статье я постараюсь описать, что такое фильтр Блума, рассказать о его назначении и показать сценарии, в которых его можно использовать. Я также реализую фильтр Блума на Python с нуля в целях облегчения понимания его внутреннего устройства.

Несколько недель назад я опубликовал твит на тему «частые ошибки с нейросетями», перечислив несколько общих ошибок принадлежащих к обучению нейронных сетей. Твит получил несколько больше взаимодействий чем я ожидал (включая целый вебинар :)). Действительно, многие заметили большой разрыв между тем «вот как работает слой свертки» и «наша сверточная сеть достигает результатов произведения искусства».

Поэтому я подумал, что будет весело смести пыль со своего блога, чтобы раскрыть свой твит в более объемном формате, которого и заслуживает эта тема. Однако, вместо того чтобы углубиться в перечень еще большего количества частых ошибок или их конкретизацию, я хотел бы копнуть глубже и поговорить о том, как обойти эти ошибки целиком (или исправить их очень быстро).

В коммерческой разработке многие сценарии использования машинного обучения подразумевают мультитенантную архитектуру и требуют обучения отдельной модели для каждого клиента и/или пользователя.

В качестве примера можно рассмотреть прогнозирование закупок и спроса на какие-либо продукты с помощью машинного обучения. Если вы управляете сетью розничных магазинов, вы можете использовать данные истории покупок клиентов и итогового спроса на эти продукты для прогнозирования расходов и объёмов закупок для каждого магазина по отдельности.

Чаще всего в таких случаях для развёртывания моделей пишут службу Flask и помещают её в контейнер Docker. Примеров одномодельных серверов машинного обучения очень много, но когда дело доходит до развёртывания нескольких моделей, у разработчика остаётся не так много доступных вариантов для решения проблемы.

В мультитенантных приложениях количество арендаторов заранее не известно и может быть практически не ограничено — в какой-то момент у вас может быть только один клиент, а в другой момент вы можете обслуживать отдельные модели для каждого пользователя тысячам пользователей. Вот здесь и начинают проявляться ограничения стандартного подхода к развертыванию:

Spark приложения легко писать и легко понять, когда все идет по плану. Однако, это становится очень сложно, когда приложения Spark начинают медленно запускаться или выходить из строя. Порой хорошо настроенное приложение может выйти из строя из-за изменения данных или изменения компоновки данных. Иногда приложение, которое до сих пор работало хорошо, начинает вести себя плохо из-за нехватки ресурсов. Список можно продолжать и продолжать.

Важно понимать не только приложение Spark, но также и его базовые компоненты среды выполнения, такие как использование диска, сети, конфликт доступа и т.д., чтобы мы могли принимать обоснованные решения, когда дела идут плохо.

В этой серии статей я хочу рассказать о некоторых наиболее распространенных причинах, по которым приложение Spark выходит из строя или замедляется. Первая и наиболее распространенная — это управление памятью.

Если бы мы заставили всех разработчиков Spark проголосовать, то условия отсутствия памяти (OOM) наверняка стали бы проблемой номер один, с которой все столкнулись. Это неудивительно, так как архитектура Spark ориентирована на память.

Привет, Хабр! 

Меня зовут Иван Хозяинов, а работаю в ITSumma, где изучаю и применяю технологии, связанные с большими данными, машинным обучением и аналитикой. В этой статье хочу рассказать о системе хранения и обработки данных и инструментах, которые встречаются на пути от сырых исходников до представления, удобного для последующего анализа. 

Поговорим, как связаны серверы в дата-центре и распределенные приложения для обработки данных и почему пришлось написать свой коннектор для Spark и Greenplum.

Данные стали бесценным активом, позволяющим компаниям лучше понимать своих пользователей, прогнозировать их поведение и определять тренды. EventNative – проект с открытым исходным кодом, разработанный командой из Jitsu, который позволяет упростить сбор данных. EventNative поддерживает работу с несколькими хранилищами данных, и ClickHouse – одно из них.

В этой статье мы расскажем как настроить EventNative с ClickHouse, а также в ней приводятся советы по эксплуатации и повышению производительности и надежности.

Что из себя представляет «столбчатый формат файла»?

Этот термин часто используется, но я не уверен, что всем до конца ясно, что он означает на практике.

Определение из учебника гласит, что столбчатые (колоночные, многоколоночные, columnar) форматы файлов хранят данные по столбцам, а не по строкам. CSV, TSV, JSON и Avro — традиционные строковые форматы файлов. Файл Parquet и ORC — это столбчатые форматы файлов.

Давайте проиллюстрируем различия между этими двумя концепциями, используя примеры некоторых данных и простой наглядный столбчатый формат файла, который я только что придумал.

Привет, Хабр!

На связи Артемий Козырь из команды Аналитики, и я продолжаю знакомить вас с Wheely. В этом выпуске:

• Основы гибких кластерных вычислений
• Колоночное хранение и компрессия данных
• Вместо индексов: ключи сегментации и сортировки
• Управление доступами, правами, ресурсами
• Интеграция с S3 или Даталейк на ровном месте

Сегодня я расскажу о том, как использовать функцию `UNNEST` в Google BigQuery для анализа параметров событий и свойств пользователей, которые вы получаете вместе с данными Google Analytics.