Леруа мерлен рекомендации

Если вы используете в своей работе NiFi, то наверняка не раз задумывались об оптимизации, а может быть и делали ее. В этом посте я поделюсь своими наработками в области настроек NiFi, благодаря которым мы получили позитивные результаты и улучшили работу наших собственных сервисов. А если конкретно, речь пойдет про выбор стратегии балансировки нагрузки между нодами кластера (load balancing), настройке работы процессоров NiFi в рамках одной ноды (Concurrent tasks, Run Duration), а также о том, что делать с косяками Merge Record. Если интересно, ныряйте под кат и давайте обсудим, что еще хорошего можно сделать с NiFi. 

Привет, Хабр! Сегодня мы поговорим о том, как сделать систему управления отоплением в загородном доме своими руками, используя легкодоступные микроконтроллеры и свободное ПО…причем сделать её так, чтобы можно было запрограммировать работу нужных устройств при помощи моего любимого JavaScript. Под катом — разбор трех вариантов решения этой задачи (включая тот самый, который я выбрал), а также масса рассуждений о преимуществах и недостатках данного подхода. Всех любителей сделайсамов и очумелых ручек приглашаю под кат.

Привет!

Меня зовут Александр Поплёвко, я руководитель продукта онлайн-платежей в Леруа Мерлен.

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

Под катом небольшая история о том, как мы организовали «факап-митапы» (тоже не без факапов) внутри нашей компании, зачем это вообще нужно и при чём тут some title some text.

Всем привет! Меня зовут Александр Токарев, я технический архитектор домена «Управление данными» в «Леруа Мерлен». Год назад мы уже делали обзор нашей Платформы данных, сейчас же я расскажу про её развитие за последний год и про задачи, которые нам удалось решить.

Мы столкнулись с необходимостью масштабировать наш подход, когда количество источников, интегрированных в платформу, стало больше 150. Всего же мы планируем интегрировать данные из более чем 800 систем. Однако ETL-инструменты, которые мы использовали на первых этапах развития дата платформы, не позволяли добиться эффективного масштабирования. Кроме того, сам процесс интеграции источников был достаточно трудоемким. Поэтому возник запрос на рефакторинг архитектуры процесса поставки данных, который, с одной стороны, позволил бы эффективно горизонтально масштабироваться, а с другой стороны, упростил бы сам процесс интеграции. В результате мы пришли к следующей схеме процесса.

Начнем эту увлекательную историю издалека. Во время первого локдауна, в начале 2020 года, сайт Леруа Мерлен испытал бóльшую нагрузку, чем когда-либо. Проводившие много времени дома и на даче наши пользователи взялись чинить полочки, проектировать новые кухни и всеми силами делать свой дом уютнее, воплощая в жизнь новые ремонтные проекты, а инженеры были вынуждены экстренно адаптировать системы под небывалый наплыв трафика. Тогда же стало ясно, что начатое незадолго до локдауна внедрение элементов SRE нужно ускорить.

Внедрение автоматизированных практик тестирования — очень полезная штука. Однако при подходе к этой задаче возникает масса вопросов. Какую платформу выбрать? Сложной ли будет миграция? Какие подводные камни ждут впереди? В своем посте я расскажу, как мы переносили практику тестирования и внедряли «тесты как код» на базе Allure TestOps.

Достаточно давно (по меркам ИТ-мира) я посмотрел доклад Артема Ерошенко с Heisenbug 2020 «Тест-кейсы как код». С переходом в Леруа Мерлен со старой TMS на Allure TestOps появилось желание полноценно попробовать данный подход у себя.

В статье расскажу о том, что из этого получилось.

Привет, Хабр! Меня зовут Ткачев Константин, и я работаю архитектором в Леруа Мерлен.

В этой статье я хочу рассказать, как мы смогли, используя только open-source, построить систему работы с метаданными, которая позволила:
— централизовать и унифицировать описания данных, используемых в компании;
— автоматизировать процессы загрузки данных в корпоративное хранилище — платформу данных;
— и сделать еще многое-многое другое…

А если добавить к этому, что мы сделали это быстро — и в итоге за пару месяцев получили работающую систему, то станет ясно, почему мы решили поделиться этим опытом с пользователями Хабра.

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

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

Меня зовут Владимир Цыбров, я релиз-инженер Леруа Мерлен и сегодня расскажу, какие в компании были подходы к построению пайплайнов и улучшению качества их кода. Спойлер: мы использовали подход InnerSource и предоставили командам self-service-инструменты.

Привет, Хабр! Сегодня мы хотим рассказать о том, как машинное обучение помогает нам освободить время сотрудников в магазинах от длительного пересчета товаров в прямых поставках и сосредоточиться на работе с клиентами. В этом посте мы расскажем, как работает наш продукт «Светофор 3.0», сколько рабочего времени он позволяет экономить и как мы используем ML для оценки вероятностей наличия расхождений в заказах. Кроме этого, расскажем о тонкостях выстраивания доверия сотрудников рекомендациям умной системы. Всех заинтересованных приглашаем под кат и к обсуждению в комментариях.

«Всякое решение плодит новые проблемы» (закон Мерфи)

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

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

Всем привет! Основным инструментом оркестрации задач для обработки данных в Леруа Мерлен является Apache Airflow, подробнее о нашем опыте работы с ним можно прочитать тут. А также мы находимся в постоянном поиске инструментов и фреймворков для упрощения работы наших дата сайентистов и дата инженеров. Один из таких инструментов – фреймворк Ray, который позволяет создавать ML пайплайны из DAGов Airflow. В статье от Astronomer подробно рассматривается, как начать его использовать и с его помощью быстро развернуть и обучить модель.

Привет, Хабр! Сегодня мы хотим поделиться нашим опытом создания собственной платформы микрофронтэндов и постепенной миграции веб-сайта компании на микросервисы. В этом посте вы узнаете, как мы пришли к этому решению, каким образом организовано тестирование фрагментов сайта, а также немного о повседневных задачах разработчиков, которые создают компоненты для такого модульного сайта. Если вы тоже занимаетесь микрофронтами или планируете это делать, обязательно делитесь опытом и присоединяйтесь к нашей дискуссии.

О том как мы внедряли Apache Airflow для использования различными командами в нашей компании, какие задачи мы хотели решить этим сервисом. Внутри описание архитектуры деплоя и наш Infrastructure as Code (IaC).

Всем привет! Недавно мы в первый раз организовали внутренний Хакатон и в этой статье я расскажу про то, как мы это сделали и про шишки, которые мы набили по пути его организации. Статья будет полезна всем, кто впервые организовывает Хакатон: и инженерам, и DevRel, и HR.

Несколько лет назад Леруа Мерлен начала масштабную программу ИТ-трансформации с использованием таких прогрессивных течений, как микросервисная архитектура, предметно-ориентированное проектирование (оно же DDD) и формирование собственных in-house-команд разработки. Пилотным проектом этой программы стало построение омниканальной платформы продаж, то есть возможность для клиента сделать взаимодействие с компанией удобным и доступным через любой существующий канал продаж, будь то сайт, магазин, колл-центр и т. д., в том числе наша платформа дает возможность взаимодействовать с различными партнерами для получения бизнес-синергии. Этой статьей мы начинаем рассказ об опыте использования open-source-платформы Camunda.

Всем привет!

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

Apache Airflow – простой и удобный batch-ориентированный инструмент для построения, планирования и мониторинга дата-пайплайнов. Ключевой его особенностью является то, что, используя Python-код и встроенные функциональные блоки, можно соединить множество различных технологий, использующихся в современном мире. Основная рабочая сущность Airflow – DAG – направленный ацикличный граф, в котором узлами являются задачи, а зависимости между задачами представлены направленными ребрами. 

Те, кто использует Apache Airflow для оркестрации задач загрузки данных в хранилище, наверняка оценили гибкость, которую он предоставляет для решения шаблонных задач. Когда весь процесс разработки сводится к заполнению конфигурационного файла с описанием параметров DAGа и списком задач, которые должны выполняться. У нас в Леруа Мерлен такой подход успешно используется для создания задач по перекладыванию данных из raw-слоя в ods-слой хранилища. Поэтому было решено распространить его на задачи по заполнению витрин данных.  

Всем привет! В недавней статье мы рассказали, как мы шли к построению нашей Data Platform.

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

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