User
Весной 2021 года во французском Страсбурге случилось яркое событие: полностью сгорел дата-центр одного из крупнейших европейских хостинг-провайдеров (OVH). Всего за несколько часов пожар отрубил доступ к миллиону популярных сайтов и онлайн-сервисов во всём мире. Одна из вероятных причин — человеческий фактор. В результате под угрозой существования оказался не только сам ЦОД, но и весь бизнес провайдера. К слову, и в России ЦОДы тоже горят. К сожалению, пожар — не единственная проблема больших данных. Не менее опасно — highload системы. Это когда, например, приложение перестаёт справляться с моментальной нагрузкой, а вся инфраструктура работает на пределе возможностей, и запаса для роста у неё нет. Забегая вперед, скажу, что решение есть у каждой из перечисленных проблем. Но, обо всём по порядку.
Из этой статьи узнаете, как использовать Listener API и библиотеки качества данных, чтобы улучшить наблюдаемость данных для Apache Spark на разных уровнях.
Tarantool, как известно, поддерживает любой язык, который совместим с C и компилируется в машинный код. В том числе есть возможность реализации хранимых функций и модулей на Lua и C. Тем не менее, уже в двух своих проектах мы использовали Rust (в одном полностью перенесли Lua-код на Rust) и получили 5-кратное увеличение производительности по сравнению с Lua и сопоставимый результат, который дает по производительности C.
Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в Quadcode. Сегодня хочу рассказать о Data-специалистах и познакомить вас с нашей командой Data Platform.
Привет, Хаброжители! Мы весьма рады, что вы решили изучить особенности интервью по проектированию ИТ-систем вместе с нами. Из всех технических интервью именно на этом задают самые сложные вопросы. Претенденту предлагается спроектировать архитектуру программной системы: новостной ленты, поиска Google, системы мгновенных сообщений и т. д. Задачи такого рода наводят ужас, ведь у них нет единственно верных решений. Они обычно отличаются масштабностью и расплывчатостью. Допускаются свободные и неясные формулировки без стандартного или правильного ответа.
Сейчас Data Warehouse в Авито — это инсталляция на 32 серверах. Мы используем девятую версию Vertica и ClickHouse. В команде, которая отвечает за хранилище, работает 21 человек. Поток событий, который мы загружаем, достигает 20 миллионов событий в минуту. Я расскажу, как менялось наше хранилище аналитических данных с 2013 года.
Часто перед дата-инженерами ставится задача по миграции данных из какого-либо источника или системы в целевое хранилище. Для этого существует множество различных инструментов. Если говорить про платформу Big Data, то чаще всего у разработчиков на слуху Apache NiFi или ETL-задачи, написанные на Spark, ввиду универсальности этих инструментов. Но давайте предположим, что нам необходимо провести миграцию данных из РСУБД в Hadoop. Для подобного рода задач существует очень недооцененный пакетный ETL-инструмент – Apache Sqoop. Его особенность в следующем:
Всем привет, я — Сергей Бобрецов, CTO в Wildberries.
Сегодня Wildberries — самый большой маркетплейс в России и мы так часто заняты повседневным хайлоадом, что не всегда успеваем рассказать что за всем этим стоит: какие технологии и решения под капотом, как мы справляемся с адом черной пятницы и ужасами киберпонедельника.
Стоит начать с того, что основным генератором прогресса в WB с самого начала и по сей день является фактор роста. По бизнес-метрикам мы растем примерно х2 каждый год уже много лет, а по техническим (количестуву запросов / транзакций / трафику / объему данных и т. д.) — рост может быть даже быстрее, и это создает множество вызовов: технических, архитектурных и организационных.
В итоге, чтобы запустить любую программу или систему в прод на мало-мальски долгий срок нужно обязательно учитывать кратный рост нагрузки, иначе совсем скоро придется вносить серьезные изменения в архитектуру или вообще все переделывать. Речь, конечно, не только про код – надо иметь стратегию масштабирования на уровне железа, сети, данных, самого приложения, команды и т. д.
Сегодня я хочу рассказать немного про нашу инфраструктуру.
Данная статья является гайдом по использованию кастомных агрегаторов в Spark SQL API. Она “выросла” из моих заметок, которые я делал себе с начала работы со Spark. Сейчас, по мере накопления опыта, мне все это кажется уж слишком наивным и простым, но в свое время мне это показалось чертовски удобным/изящным/заслуживающим внимания, поэтому и решил опубликовать, тем более на Хабре про это еще вроде не писали. Статья ориентирована в первую очередь на тех, кто только начинает работать со Spark, поэтому и помечена как “tutorial”. Если у вас есть какие-либо интересные кейсы по использованию кастомных агрегаторов - делитесь в комментариях!
Ниже мы будем говорить о user-defined aggregations functions (UDAF) org.apache.spark.sql.expressions.Aggregator, которые могут быть использованы для DataSet’ов с целью агрегации группы элементов в одно значение каким-угодно-пользователю образом.
OneSoil — это agtech-компания с беларусскими корнями. У нас 400 000 пользователей со всего мира, для которых мы регулярно обновляем продукт.
Как и у всех продуктовых компаний, у нас есть проблема: непрерывный поток обновлений — это дорого. Поэтому мы ищем способы оптимизировать разработку, и вот недавно мы сделали контрастный NDVI — новую фичу, которая стала у пользователей одной из любимых, а нам почти ничего не стоила.
Для начала: в чём суть нашего продукта?
OneSoil делает приложение для точного земледелия. В 2021 году сельское хозяйство — это такая же высокотехнологичная сфера, как авиапромышленность. Роль OneSoil — предоставлять фермерам данные о состоянии их полей, чтобы их работа стала эффективнее. Когда у тебя несколько сотен гектаров с разными культурами, за ними очень сложно следить не используя технологии: рискуешь пропустить сорняки, болезни растений, проблемы почвы, а обойти все поля пешком невозможно. OneSoil берёт спутниковые снимки и обрабатывает их с помощью собственных алгоритмов, а потом даёт фермерам результаты в удобном виде в приложении.
Один из главных функционалов продукта — индекс NDVI. По нему фермеры понимают, сколько на поле растительности и здорова ли она. Индекс рассчитывается по тому, как растения отражают солнечный свет (здоровое растение активно поглощает красный свет и отражает ближний инфракрасный).
Существует миллион разных причин, по которым могут возникать сбои в работе конвейеров данных, и нет ни одного универсального подхода, помогающего сразу понять, как и почему они случаются. В этой статье я расскажу вам о пяти шагах, которые нужно совершить дата-инженеру, чтобы провести анализ первопричин (Root Cause Analysis - RCA) проблем с качеством и пригодностью данных (Data Quality).
Обзор
Apache Hive – система управления (СУБД) реляционными базами данных (РБД) с открытым исходным кодом для запросов, агрегирования и анализа параметров и режимов рабочих нагрузок с большими данными. В этой статье описываются ключевые инновационные инструменты для полноценной пакетной обработки в корпоративной системе хранения данных. Мы представляем гибридную архитектуру, которая сочетает в себе традиционные методы массивно-параллельных архитектур (MPP) с физически разделенной памятью с более современными концепциями больших данных, облаков для достижения масштабируемости и производительности, требуемых современными аналитическими приложениями. Мы исследуем систему, подробно описывая улучшения по четырем основным направлениям: транзакция, оптимизатор, среда выполнения и федерация (интеграционный процесс). Затем мы приводим экспериментальные результаты, чтобы продемонстрировать производительность системы для типовых рабочих нагрузок, и в заключение рассмотрим дорожную карту сообщества.
Netflix создаёт интересный и качественный контент, который часто собирает награды на фестивалях, так что потребности студии подталкивают технологический прогресс. Так появились облачные конвейеры постпроизводственного редактирования и совместной работы, которые требуют сложного набора функций, включая создание и размещение высококачественного прокси-контента. После получения, проверки и кодирования контента этап упаковки инкапсулирует закодированные видео и аудио в независимые от кодека медиаконтейнеры. Благодаря этому становятся доступными синхронизация аудио-видео, произвольный доступ к элементам и защита от копирования.
Необходимость поддерживать рабочие процессы ставит перед упаковочной службой новые задачи. Но это коротко. А теперь давайте поговорим об этом подробнее.
В этой статье вы узнаете о том, какими способами мы пытались обновлять таблицы в Hadoop, содержащие сотни терабайт данных.
И если в начале нашего пути процесс обновления длился несколько часов (до десяти-двенадцати часов), то теперь ему требуется всего тридцать-сорок минут, а использование вычислительных ресурсов уменьшено вдвое!
При этом была создана библиотека расширения Spark, которая предоставляет DataSource для преобразования данных в файлах в формат этого DataSource, изменения данных командой MERGE через DataFrame API или SQL, а в будущем ещё и UPDATE, DELETE и некоторые операции DDL.
Файлы при этом можно будет читать любым привычным способом, ведь они не модифицированы, а метаданные не обязательны для их чтения.
Вы увидите код этой библиотеки на языке Scala, который сможете использовать, а может быть даже доработать и поделиться своими успехами.
Я постараюсь пояснить, почему был сделан тот или иной выбор, но могу умолчать о чём-то, что кажется очевидным, или, наоборот, о чём я не имею представления. Вы сможете задать вопросы, а я постараюсь ответить на них.
Это первая статья из нескольких, и в ней будет рассказано только о немногих реализованных классах (они нужны для распределения данных определённым способом), поэтому наберитесь терпения, я расскажу всё по частям. Впрочем, пора перейти к повествованию.
Один из современных способов хранения большущего объема данных для платформ обработки и анализа данных - это распределение каждого датасета между несколькими узлами в кластере. Если мы используем облако, то весь датасет разделяется на множество объектов. Это может привести к появлению “слишком большого количества небольших файлов” что является хорошо известной проблемой в области Big Data. Формирование небольших файлов происходит по нескольким причинам, например, при сохранении входящих потоковых данных, сообщение за сообщением, при партиционировании по ключу с перекосом данных и т.д. Драйвер должен следить за изменениями метаданных всех файлов, чтобы планировать распределенную обработку данных при сохранении или чтении данных датасета используя Namenode, MapReduce или задачи Spark. Когда файлов слишком много, для хранения их метаданных требуется дополнительная память, а при их перечислении этих данных требуется гораздо больше времени на сетевое взаимодействие.
Во время работы в Datalake вы могли заметить, что при выполнении задачи Spark затрачивается слишком много времени на чтение датасета из s3/HDFS, где нужно подождать, даже чтобы увидеть запущенные экзекьюторы. Или вы могли заметить, что вашему Hive запросу может понадобиться несколько минут, чтобы инициировать задачи. Скорее всего, причина в том, что изначально драйвер большую часть времени тратит на просмотр всех метаданных файлов/объектов датасета в s3, особенно когда небольших файлов слишком много. Это связано с тем, что именно драйвер выполняет перечисление файлов в датасете, оценивает размер/партиции, а затем распределяет работу между экзекьюторами. Таким образом, слишком большое количество небольших файлов может привести к снижению производительности, а в худшем случае драйвер может поймать исключение из-за нехватки памяти.
Мой уход из Яндекса, как не потерять мотивацию за полгода подготовки в FAANG и реджект в Google.