Вряд ли можно поспорить сегодня с аргументом, что скорость и эффективность обработки информации стали ключевыми факторами успеха любого цифрового проекта. При этом традиционные подходы к хранению и обработке данных уже не могут удовлетворить растущие потребности бизнеса и пользователей. Именно в этот момент на сцену выходит Apache Ignite — высокопроизводительная, распределенная платформа для вычислений в памяти. Рассказывает Александр Столяров, ведущий программист компании Comindware.
Apache *
Свободный веб-сервер
Как полностью устранить дублирующие записи в ClickHouse
Всем привет!
Меня зовут Валерий Локтаев, я backend-разработчик сервиса биллинга в CloudMTS.
В этой статье я расскажу, как насовсем убрать дублирующие записи в ClickHouse (CH). Логичный вопрос — откуда вообще взялась проблема? Можно взять движок таблицы ReplacingMergeTree, указать ORDER BY в качестве ключа дедупликации, и CH чудесным образом удалит все дубли в базе.
ReplacingMergeTree, безусловно, отличное решение. Но представьте, что ваша задача — сделать так, чтобы в таблице дубли никогда не появлялись, даже на несколько секунд.
Далее я расскажу, в каких случаях это необходимо и какое решение удалось подобрать.
1.0.BackupStorage на NixOS
Всем привет, меня зовут Алексей, являюсь IT‑инженером в одной из крупных компаний. Иногда включаю внутреннего авантюриста и ищу что‑то редкое и очень интересное.И в данной статье хочу поделиться стеком, который имеет право на жизнь.
Да и надеюсь, что информация для кого‑то будет интересна, как и для меня.
Если бы я раньше нашел такой туториал — быстрее бы разобрался со всеми нюансами.
Мы заглянули под капот Kafka и решили проблему потерянных сообщений
Kafka — это масштабируемая, отказоустойчивая платформа для обмена сообщениями в реальном времени. Она позволяет обрабатывать миллионы сообщений в секунду. Однако некоторые ситуации приводят к потере событий. Например, Kafka требует хорошего стабильного сетевого соединения между клиентами и брокерами; если сеть нестабильна, это может легко привести к потере сообщений.
Команда разработчиков Trendyol Tech видоизменила архитектуру и решила эту проблему с помощью outbox-шаблона, но столкнулась с другой проблемой — дублированием событий. Приводим перевод статьи о том, как разработчики залезли под капот Kafka и нашли решение этих двух проблем.
Истории
Apache Flink ML – прогнозирование в реальном времени
Всем привет!
В этой статье рассмотрим применение библиотеки Apache Flink ML для построения конвейеров машинного обучения. Затем реализуем простой проект по прогнозированию поведения системы, а также ответим на вопросы: какие задачи Machine Learning подходят для Flink и какие особенности Flink делают его подходящим для использования в задачах Machine Learning.
Обработка больших и очень больших графов: Pregel
Статья является продолжением предыдущей статьи в рамках цикла статей, посвященных обработке больших и очень больших графов. В статье реализованы распределенные версии четырех классических алгоритмов: "Связные компоненты", "Кратчайшее расстояние", "Топологическая сортировка" и PageRank на Apache Spark DataFrame API. Алгоритмы составлены в соответствии с идеями популярного фреймворка распределенной обработки графов Pregel.
Доступ к потоковой передаче данных в режиме реального времени
Как Redpanda и Materialize — продукты, не основанные на JVM — делают потоковую обработку доступной для широких масс за счет снижения операционных издержек? Обсудим в статье.
Apache Spark 3.4 для Databricks Runtime 13.0
Databricks — это аналитическая платформа для облачных вычислений, работы с большими данными и машинного обучения. Компания разрабатывает data lake и работает с фреймворком Apache Spark. Приводим перевод статьи Databricks о нововведениях Apache Spark 3.4, который вошел в релиз Databricks Runtime 13.0.
Что такое «хорошо» и что такое «плохо» в NiFi. Часть 3
Переносимость процессоров и паттерны
Вот и обещанная третья часть саги о том, что в NiFi можно делать и как это делать правильно, без претензий на истину в последней инстанции, конечно. Сегодня расскажу о переносимости процессоров и дам несколько паттернов для самых популярных задач на платформе ZIIoT. Если вдруг вам интересно почитать про оптимизацию схем и производительности в NiFi — велком в первую часть. Если мечтаете узнать больше о мониторинге, то вторая часть — must read. Только потом сюда не забудьте вернуться.
Ивентная модель данных с использованием Kafka и Kafka Connect: Построение гибкой и распределенной архитектуры
Привет, Хабр! В наше время при постоянном росте объемов данных и необходимостью более быстрой и надежной обработки информации, мы сталкиваемся с требованием к эффективному обмену и синхронизации данных между различными системами. Отслеживание и обработка данных в реальном времени стало жизненно необходимым для современных приложений.
В этой статье мы рассмотрим, как Kafka Connect – мощный инструмент из экосистемы Apache Kafka – приходит на помощь при решении сложной задачи синхронизации данных между базами данных. Мы рассмотрим, как используя Kafka Connect, мы можем эффективно следить за изменениями в одной базе данных, обрабатывать их в нашем Java приложении и мгновенно записывать их в другую базу данных, обеспечивая надежность и безопасность данных.
Построим гибкую и масштабируемую архитектуру, которая позволит нам забыть о проблемах связанных с несогласованными данными и наслаждаться мгновенным доступом к актуальной информации для наших бизнес-процессов.
Аутентификация клиента Kafka SSL в мультитенантной архитектуре
Apache Kafka является ключевым продуктом не только для преобразования сообщений, но и при обработке данных в реальном времени, а также для многих других случаев использования. Архитектуры, размещенные в облаке, утверждают, что они безопасны с точки зрения коммуникации и обеспечения общей безопасности. Но когда дело доходит до частого взаимодействия клиента/потребителя с сервером/производителем, Kafka обеспечивает встроенную поддержку SSL, а также пользовательскую аутентификацию. В этой статье мы шаг за шагом настроим такой механизм аутентификации.
Градиентный бустинг: как подобрать гиперпараметры модели в 5 раз быстрее, чем обычно?
В этой статье я расскажу, как, используя недокументированные возможности фреймворка Apache Spark, качественно подобрать гиперпараметры для модели градиентного бустинга всего за один человеко-день вместо обычных пяти.
Потоковая обработка данных с помощью Kafka Streams: архитектура и ключевые концепции
При реализации потоковой обработки и анализа данных может возникнуть необходимость агрегирования записей для объединения нескольких независимых поток данных или обогащения какой-либо модели данных. Для этой цели может использоваться Kafka Streams, которая позволяет выполнять обработку данных в режиме реального времени.
В этой статье мы рассмотрим основные компоненты Kafka Streams и теоретические аспекты их использования. Мы будем использовать последние версии технологий, доступных на сегодня: Kafka 3.4.0 и Java 17 в качестве языка программированию. Для снижения входного порога мы будем использовать только нативные возможности Kafka и Kafka Streams, и не будем рассматривать решения с использованием различных фреймворков вроде Spring.
Ближайшие события
Как Flink Table API упрощает разработку
Apache Flink является популярным фреймворком для обработки больших данных и аналитики в режиме реального времени. Одним из ключевых компонентов этого фреймворка является Table API, который предоставляет удобный и выразительный способ работы с данными в формате таблиц, аналогичный SQL.
Если вы разработчик, который хочет узнать больше о том, как использовать Apache Flink Table API для обработки потоковых данных, или если вы интересуетесь современными инструментами аналитики данных, эта статья для вас.
Что такое «хорошо» и что такое «плохо» в NiFi. Часть 2
Мониторинг
Продолжаем разговор о том, что в NiFi делать можно и нужно, а что можно, но лучше не стоит. Если вы пропустили первую часть разговора, то вам сюда. Там про улучшение читаемости схем и повышение производительности (ну почти). Здесь же пойдет речь о том, как проводить мониторинг бизнес-части схемы, чтобы всем было хорошо (ну или чтобы не было плохо), ну и немного о переносимости процессоров. Поехали!
Есть мнение, что хуже всего — не вести мониторинг бизнес-части схемы совсем, используя популярный подход «и так сойдет!». Но если подумать, есть одна вещь хуже отсутствия мониторинга — неправильный мониторинг.
Apache Airflow в связке с Kubernetes
Привет! Меня зовут Алексей Карпов, я DevOps-инженер (MLOps) отдела ML разработки в OKKO. Хочу поделиться опытом в работе с Apache Airflow в связке с Kubernetes. Расскажу, как установить Airflow в Kubernetes, настроить автоматическую синхронизацию DAG'ов с удалённым репозиторием, а также как отладить его работу. Всё это — на примере запуска простейшего DAGа.
Консолидация отображения данных с использованием протокола OData
Появилась у нас тут задачка, вывести на портале Incomand данные из разных подсистем (1С, Тезис…) . Конечно можно было бы написать плагины, каждый из которых слазил бы в подсистему, получил данные и показал их на портале - НО - мы бы получили p2p и спагетти, порталу пришлось бы разбираться с форматами и протоколами работы каждой системы….
Работа Apache Kafka на примерах. Поднимаем Kafka Cluster используя docker-compose
В этой статье продемонстрирую и объясню работу Kafka, используя как можно меньше определений и больше практики. Мы рассмотрим 3 сценария работы с Kafka. Для последнего сценария мы поднимем Kafka Cluster в Docker и с помощью UI увидим, как происходит общение между сервисами.
Kafka за 20 минут. Ментальная модель и как с ней работать
Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.
Как мы распиливаем монолит без даунтайма
Всем привет!
На связи Михаил, и я продолжаю делиться историями про рефакторинг одного из сервисов облачной платформы #CloudMTS. В прошлый раз я рассказывал о том, как мы аккуратно раскладывали по папочкам код в соответствии с принципами чистой архитектуры. Сегодня поговорим о решении, которое позволяет нам распиливать монолит по кусочкам без простоев.
Наши причины перехода были следующими:
- В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
- Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
- Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.
Вклад авторов
eapotapov 163.6Polina_Averina 153.6ph_piter 97.0alextokarev 92.0Morozka 77.0mechanicusilius 66.0Anna_sokol22 56.0ITSumma 51.0ValeryKomarov 47.0neoflex 46.0