В FunBox мы делаем продукты для мобильных операторов: различные порталы, геосервисы, платежи, мобильную рекламу и многое другое.  Один из наших проектов построен на микросервисной архитектуре. Основная функциональность связана с обработкой потоков событий, поэтому мы выбрали событийно-ориентированную архитектуру. Для организации централизованного, масштабируемого и быстрого механизма обмена сообщениями используем Apache Kafka. Это популярная платформа для решения подобных задач, плюс у неё есть интерфейс для организации потоковой обработки событий.

Привет, меня зовут Алексей Белявцев и я ETL-архитектор в X5 Group. Наши объёмы данных соизмеримы с крупнейшими международными компаниями и требуют специального ухода и содержания, что накладывает определённый отпечаток на специфику используемых решений. Я не планирую грузить вас описанием детальной архитектуры (всё равно её нельзя публиковать), скриптами загрузки (их тем более) и другими скучными подробностями технической реализации, которые в достатке присутствуют во всех data-driven компаниях, а хочу заглянуть в будущее и попытаться представить архитектуру, удовлетворяющую всем потенциально возможным требованиям, масштабируемую, отказоустойчивую и просто приятную во всех отношениях.

Речь пойдёт о практиках сборки данных (подготовка снастей и поиск водохранилища), а также о нахождении оптимальной точки раздачи данных (лунке в зимний сезон или просто удачного места в рогозе) в реалиях очень big data, сотен систем-источников (СИ) и петабайтах данных (примерно как порыбачить в океане). Цель изложения заключается в консолидации и структурировании информации по теме и размышлениях об идеализированной архитектуре в зависимости от потребностей подразделений компании в данных. Будут высказаны предположения по опережающему развитию архитектуры под новые требования бизнеса третьего десятилетия 21 века, при этом многие из затронутых тем на текущем этапе развития направления являются более чем holywar-ными, причём подходы, успешно использующиеся в одних компаниях, могут быть провальны в других и наоборот (зависит от многих факторов).

Kafka нельзя назвать новым продуктом на рынке ПО. Прошло примерно 10 лет с того времени, как компания разработчик LinkedIn выпустила его в свет. И хотя к тому времени на рынке уже были продукты со схожей функциональностью, но открытый код и широкая поддержка экспертного сообщества прежде всего в лице Apache Incubator позволила ему быстро встать на ноги, а впоследствии составить серьезную конкуренцию альтернативным решениям.

Традиционно Kafka рассматривался как набор сервисов для приема и передачи данных, позволяющий накапливать, хранить и отдавать данные с крайне низкой задержкой и высокой пропускной способностью. Этакий надежный и быстрый (да и в общем-то наиболее популярный на данный момент) брокер сообщений по этой причине весьма востребован во множестве ETL процессов. Преимущества и возможности Kafka многократно обсуждались, в том числе и на Хабре. К тому же, статей на данную тематику весьма много на просторах интернета. Не будем повторять здесь достоинства Kafk-и, достаточно посмотреть на список организаций, выбравших этот продукт  базовым инструментом для технических решений. Обратимся к официальному сайту, согласно которому на данный момент Kafka используется тысячами компаний, в том числе более 60% компаний из списка Fortune 100. Среди них Box, Goldman Sachs, Target, Cisco, Intuit и другие [1].

На сегодняшний день Apache Kafkaне без оснований часто признается лучшим продуктом на рынке систем по передаче данных. Но Kafka не только интересен в качестве брокера сообщений. Огромный интерес он представляет и в силу того, что на его основе возникли и развиваются многие специфические программные продукты, которые позволяют Kafka существенным образом расширить возможности. А это свою очередь позволяет ему уверено продвигаться в новые области ИT рынка.

Всем привет! Это мой дебют на Хабре с переводом классной статьи по теме инжиниринга данных.

Оригинал статьи:

From Data Driven to Driving Data— The dysfunctions of Data Engineering

О том, как дата инженерам перестать быть сервисной командой в компаниях, "управляемых данными", и перебраться за руль в этом сложном процессе.

В этой статье я поделюсь с вами ресурсами и методологией, которые я активно использовал для прохождения сертификации “Databricks Certified Associate Developer for Apache Spark 3.0”.

Ас-саляму алейкум, братья!

Думаю многие в своей жизни хотели разобраться с тем как при помощи программного кода обрабатывать изображения и видео. Применений у этого навыка бессчётное количество, у кого на что фантазии хватит. Можно начать с автоматической коррекции огромного числа фотографий, а закончить deep fake видео с участием " Олега Тинькова ".

Какой же инструмент для этого применить, да если ещё учесть что вы закоренелый джавист? Думаю лучшим инструментом в этом случае будет библиотека OpenCV. Исходя из всего вышеперечисленного представляю вам серию видеороликов в которых Я подробно расскажу вам о том как установить библиотеку OpenCV, её функционале и работе с изображением и видео на языке Java.

Apache Spark – фреймворк для обработки больших данных, который давно уже стал одним из самых популярных и часто встречаемых во всевозможных проектах, связанных с Big Data. Он удачно сочетает в себе скорость работы и простоту выражения своих мыслей разработчиком.

Разработчик работает с данными на достаточно высоком уровне и, кажется, что нет ничего сложного в том, чтобы, например, соединить два набора данных, написав всего одну строку кода. Но только задумайтесь: что происходит в кластере при соединении двух наборов данных, которые могут и не находится целиком на каком-либо из узлов кластера? Обычно Spark со всем справляется быстро, но иногда, а особенно, если данных действительно много, необходимо все-таки понимать – что происходит уровнем ниже и использовать это знание, чтобы помочь Spark работать в полную силу.

Сложные типы данных, такие как массивы (arrays), структуры (structs) и карты (maps), очень часто встречаются при обработке больших данных, особенно в Spark. Ситуация возникает каждый раз, когда мы хотим представить в одном столбце более одного значения в каждой строке, это может быть список значений в случае с типом данных массива или список пар ключ-значение в случае с картой.

Поддержка обработки этих сложных типов данных была расширена, начиная с версии Spark 2.4, за счет выпуска функций высшего порядка (HOFs). В этой статье мы рассмотрим, что такое функции высшего порядка, как их можно эффективно использовать и какие связанные с ними функции были выпущены в последних выпусках Spark 3.0 и 3.1.1. Для кода будем использовать Python API.

После агрегаций и оконных функций, которые мы рассмотрели в прошлой статье, HOF представляют собой еще одну группу более продвинутых преобразований в Spark SQL.

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

Четкая работа микросервисных приложений в значительной степени зависит от передачи сообщений и асинхронных операций.

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

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

История о том, как суточный ETL-контур карабкался в реалтайм.

В рамках AdTech-подразделения холдинга Rambler&Co выделено отдельное направление Usermodel, которое занимается анализом и сегментацией аудитории, а также повышением конверсий на площадках. Один из проектов этого направления –  Recommender (система рекомендаций), в котором искусственный интеллект подстраивается под интересы пользователей и из массы контента на площадке выбирает самые интересные новости и статьи персонально для каждого посетителя сайта.

Что вы узнаете из этой статьи?

• Зачем нам нужен Realtime-контур на Spark?

• Как правильно написать его так, чтобы он джойнил логи на лету?

• С какими подводными камнями можно столкнуться?

Наша миссия в Kesque — дать разработчикам возможность создавать распределенные облачные приложения, сделав высокопроизводительную технологию обмена сообщениями независимую от типа облака доступной для всех. Разработчики хотят писать распределенные приложения или микросервисы, но не хотят возиться с управлением сложной инфраструктурой сообщений или быть привязанными к конкретному поставщику облачных услуг. Им нужно решение, которое просто работает. Везде.

Когда вы собираетесь создать лучшую инфраструктуру службы обмена сообщениями, первым делом необходимо выбрать правильную базовую технологию обмена сообщениями. Существует множество вариантов: от различных проектов с открытым исходным кодом, таких как RabbitMQ, ActiveMQ и NATS, до проприетарных решений, таких как IBM MQ или Red Hat AMQ. И, конечно же, есть Apache Kafka, являющийся чуть ли не синонимом потоковой передачи. Но мы выбрали не Apache Kafka, мы выбрали Apache Pulsar.

Итак, почему же мы создали нашу службу обмена сообщениями с использованием Apache Pulsar? Вот семь основных причин, по которым мы выбрали Apache Pulsar вместо Apache Kafka.

И почему shutdown требует отдельной статьи, а не вызова метода stop

Ну начну с того, что за метод stop такой.

Из документации, существует 2 метода которые собственно отвечают за остановку Structured stream.
query.stop() // Остановить запрос(stream)query.awaitTermination() // заблокировать пока запрос(stream) не прекратиться по причине вызова stop() или ошибки

Уже только по наличие 2ух методов мы может догадаться что метод stop() асинхронный. Что лично меня навело на мысль, что ни какой проблемы нет и graceful shutdown иметься из коробки.

Но я притворюсь что я умный и читал документацию, а не выгребал ошибки в production. Из документация

Останавливает выполнение этого запроса если он активен. Вызов блокируется до того как прекратиться выполнение query execution threads или по timeout(время не не выйдет, время задается в конфигурации).

И вот тут опытный Java/Scala разработчик по идее должен был напрячься.

Какой то Thread, уж больно напоминающий java thread по названию, прекратиться по сигналу. Да и в добавок к этому еще один, дополнительный, метод который ждет завершения. Это же thread.interupt() скажите вы, и будете правы - так что ни про какой graceful вообще речь идти не может.

Всем привет!

«Данные – это новая нефть» – вам наверняка доводилось уже не раз слышать эту фразу. Впервые в 2006 году эту идею озвучил математик Клайв Хамби в своем блоге, но с тех пор она не потеряла популярности и сейчас её можно услышать почти из каждого утюга. Особую актуальность это выражение приобрело с внедрением технологий обработки больших данных: Hadoop, MapReduce, Spark, Flink, Anaconda (Jupyter), MLFlow, Kubeflow и далее множество других названий, похожих на имена покемонов. В этой статье мы хотели бы рассказать, какие из них мы выбрали в 2021 году в Леруа Мерлен Россия для своей платформы данных. Эта статья является продолжением нашей первой статьи о платформе –  Платформа данных в Леруа Мерлен – 2 года, сотни источников и более 2.000 пользователей.

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

Привет!  Меня зовут Никита Галушко, я R&D-разработчик в Lamoda. Специально для Хабра я сделал вольный перевод интересной статьи “Postgres regex search over 10,000 GitHub repositories (using only a Macbook)”. 

Ее автор провел эксперимент: собрал датасет из 10 тысяч GitHub-репозиториев и проверил, насколько Postgres подходит для поиска по документам на одной машине — MacBook Pro, а также измерил скорость поиска и подобрал подходящую конфигурацию.

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

Практически в каждом секторе, работающем со сложными данными, Spark "де-факто" быстро стал средой распределенных вычислений для команд на всех этапах жизненного цикла данных и аналитики. Одна из наиболее ожидаемых функций Spark 3.0 - это новая платформа Adaptive Query Execution (AQE), устраняющая проблемы, которые возникают при многих рабочих нагрузках Spark SQL. Они были задокументированы в начале 2018 года командой специалистов Intel и Baidu и сегодня мы детально их обсудим.

В этом материале мы покажем, что Интернет вещей — это не так уж и сложно. Для этого за 60 минут соберем и оживим простейшую Wi-Fi розетку с управлением через Интернет.