Привет, Хабр. Меня зовут Владимир Утратенко, я — Head of Infrastructure and Security в Uzum Market. У меня богатый опыт найма DevOps-инженеров, ведь последние 6 лет я — нанимающий менеджер. А ещё много лет подряд занимаюсь DevOps как моделью разработки. Сегодня мы поговорим про боли в CI/CD, которые часто упускают из вида DevOps-специалисты, лиды и CTO.
Всем привет. Меня зовут Кирилл, я маркетинговый аналитик в Uzum. В этой статье я хочу поделиться с вами практическими примерами, которые демонстрируют реальную ценность методов причинно-следственного анализа. Отдельно расскажу, как библиотека CausalImpact помогает в решении бизнес-задач.
Привет, с вами снова Даша и Uzum Market. В прошлый раз мы глубоко погрузились в пайплайн работы поиска нашего маркетплейса, и я обещала вам вернуться с новостями о его улучшении. Так вот, время пришло, и сегодня мы поговорим про наш опыт внедрения векторного поиска!
Всем привет! Меня зовут Иван Кузнецов, я Head of Frontend в Uzum Market. Расскажу о сложностях, с которыми мы столкнулись на пути к реализации микрофронтендовой архитектуры, и поделюсь результатами, которые мы получили в процессе пакетирования наших решений с помощью Lerna. Надеюсь, тебе, дорогой читатель, будет очень интересно :)
Отфильтровав для Вас большое количество источников и подписок, сегодня собрал все наиболее значимые новости из мира будущего, машинного обучения, роботов и искусственного интеллекта за последнее время.
Меня зовут Рушан, и я автор Telegram-канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие новости.
Итак, а теперь сам дайджест:
Привет! Меня зовут Саша, я продакт-лид в Uzum Market, в этом посте я расскажу вам, как вывести ecom-приложение на новый для вас рынок. Может быть, этот опыт пригодится вам, если вы тоже работаете в ecommerce (да и не только) и планируете выходить на новые рынки или просто любите читать подобные истории.
Итак, под катом:
• наш процесс запуска маркетплейса и ПВЗ в Узбекистане;
• особенности национального менталитета и потребительских привычек;
• BNPL-рассрочка как ощутимый драйвер продаж и потребительской лояльности;
• чек-лист — что нужно обязательно учесть при выходе на непривычный вам рынок.
Последние годы преподнесли нам целую серию испытаний. Из четырёх всадников один только Голод потерялся где-то по дороге, остальные успешно доскакали и поприветствовали нас. А кроме глобальных потрясений и фонового ужаса и стресса, есть ещё и простые личные проблемы — семья, горящие проекты и вся остальная жизнь со своими тревогами и заботами.
Когда накатывает сразу много трудностей со всех сторон, легко стать нервным и раздражительным, злым и неэмпатичным. Если же вы менеджер, то в таком состоянии можно утянуть за собой на дно ещё и команду. Шторм отступит, а вы останетесь без неё.
Я сам проходил через такой период в своей жизни и хочу рассказать, как я чуть не развалил свою команду, что мне помогло этого не сделать и как я выбрался из пропасти.
Привет, Хабр! Давно не виделись (2 года, ровно).
Отфильтровав для Вас большое количество источников и подписок, сегодня собрал все наиболее значимые новости из мира будущего, машинного обучения, роботов и искусственного интеллекта за июль. Не забудьте поделиться с коллегами, друзьями или просто с теми, кому интересны такие новости.
Итак, а теперь дайджест за июль:
1. Представьте на мгновение, что вы ИИ. Часы длинные, но годы короткие.
Привет, меня зовут Даша, я отвечаю за ранжирование в команде поиска Uzum Market. За время существования нашей команды мы успели накопить достаточный багаж факапов знаний, чтобы начать делиться им с вами.
Поиск — один из основных источников дохода маркетплейсов. Сценарий, где пользователь приходит на платформу с конкретной целью приобрести товар гораздо более вероятен, чем тот, где он зашел полистать ленту.
Ежедневно сотни тысяч пользователей полагаются на поиск Uzum Market, чтобы найти нужные им товары. Наша цель как команды, ответственной за поисковый движок, — предоставить им лучший сервис и помочь найти именно то, что они ищут.
С каждым днем количество товаров в нашем маркетплейсе растёт, и если раньше мы показывали десятки релевантных товаров по одному поисковому запросу, то сейчас их уже тысячи. Как правильно отранжировать товары, чтобы пользователь дошёл до чекаута? Какие данные нужны, чтобы определить релевантность товара по запросу? На какие метрики ориентироваться, чтобы измерить качество поиска?
На эти и другие вопросы мы пытаемся ответить ежедневно. И сегодня я приоткрою завесу над некоторыми решениями, которые мы уже реализовали на нашей площадке, а также расскажу про боли и трудности, с которыми пришлось столкнуться на пути к статистически значительным изменениям в метриках.
Велком всех под кат в увлекательное путешествие по внутренностям поиска Uzum Market!
Нередко руководители, особенно молодые, оказываются завалены делами, большими и маленькими. Один эпик, второй, третий, договориться с другой командой, поговорить с руководителем, зафиксировать последние соглашения, написать текст вакансии, согласовать ставки, согласовать бюджет на обучение, обсудить с Васей блокеры по задаче, что-то часто начала админка 403 отдавать, где-то просадка по метрикам… На это всё накладываются проблемы вне работы.
Вроде бы понятно, что́ нужно сделать — настроить процессы, разгрести дела, чтобы не было этих завалов. Но возникает проблема курицы и яйца: чтобы разобрать завалы, нужно время, а оно всё уходит на решение бесконечных текущих задач.
Что же делать? Как снять эту боль?
Привет! Я — Дарья, руководитель проектов в Uzum Data. В этой статье поделюсь с вами опытом работы с OpenSource SMS‑шлюзом Jasmin: какие у нас были требования, с какими препятствиями столкнулись, как выбирались из трудностей.
C чего всё началось
Нам нужно было подключить новый канал смс‑рассылки, т.к. по старым каналам мы начали упираться в лимиты. Новый канал представляет собой коммуникацию с использованием A2P каналов, то есть коммуникации от бизнеса пользователям. A2P используется как в маркетинге, так и в сервисах: для подтверждения покупки, авторизации, напоминаний, рассылок и т. д.
Привет! Я – Валерия Дымбицкая, технический руководитель команды дата-инженеров в OneFactor. Это вторая часть статьи о том, как автоматически подбирать параметры для Spark-приложений на примере spark.executor.memory.
В первой части мы разбирали, как читать логи событий Spark и как достать из них три показателя того, насколько можно уменьшить память экзекьюторам (а также зачем это делать). Здесь я расскажу о том, как превратить это всё в работающую систему на продуктиве, используя довольно простые средства.
Всем привет! Меня зовут Валерия Дымбицкая, я технический руководитель команды дата-инженеров в OneFactor. В этой статье я расскажу о том, как мы научились автоматически подбирать параметры для Spark-приложений на основе логов.
Проблема, которую мы решали, может встретиться при регулярном, предсказуемом, интенсивном использовании Hadoop-кластера. Я расскажу, как мы простыми средствами сделали рабочую автономную систему тюнинга, сэкономив в итоге 15-16% ресурсов кластера. Вас ждут детали с примерами кода.
В первой половине статьи я расскажу про то, какая перед нами стояла задача, и разберу ключевые пункты для её решения. Во второй половине будет рассказ о том, как это решение подготовить к работе на продуктиве и что мы из этого всего получили.
Зачем нам вообще понадобился автоматический тюнинг?
Начнём с инфраструктуры. Сетап у нас "классический": ограниченный Hadoop-кластер из купленных серверов. В нём на тот момент, когда мы начали всё это делать, было около 30Тб RAM и 5к CPU. В этом кластере запускается множество разноплановых приложений на Apache Spark и в какой-то момент им стало тесновато. Всё больше приложений висели в PENDING значительное время, потребление памяти утроилось за последние 4 месяца. Сохранять такую тенденцию не хотелось.
Довольно много приложений были от продукта Лидогенерация. Базово он устроен так: есть список номеров телефонов (база) и есть Spark ML Pipeline, который каким-то образом отбирает из этой базы лидов абонентов для некоего целевого действия – например, для предложения продукта клиенту. База может меняться от раза к разу. Вот такую пару из
Привет, Хабр! Меня зовут Александр, в компании oneFactor я являюсь руководителем платформенных продуктов, и одна из моих целей — это развитие платформы конфиденциальных вычислений. Именно о них мы и будем говорить в данной статье, пройдя путь по преобразованию Платформы работы с данными в Платформу конфиденциальных вычислений над данными, где основной целью является – обеспечить нераскрытие информации, загружаемой в Платформу, даже для администратора Платформы.
Привет, Хабр! Меня зовут Денис, в компании oneFactor я занимаю позицию архитектора, и одна из моих обязанностей — это развитие технического стека компании. В этой статье я расскажу про нашу data platform’у (далее просто DP или платформа) и про мотивацию внедрения в неё Kubernetes. Также подсвечу трудности, с которыми мы столкнулись в рамках пилота. И расскажу про набор активностей, которые не вошли в пилот, но будут выполнены во время миграции. Дополнительно представлю короткий обзор текущей интеграции между Spark и Kubernetes. Стоит отметить, что вопросы, связанные с хранилищем, здесь обсуждаться не будут.