Big Data *

Как специалисты data science (DS) оперативно рассчитывают рентабельность инвестиций в проект (ROI) на реальной практике, то есть в ситуации, когда нет актуальной информации о необходимых данных? К примеру, чтобы рассчитать компонент оттока в Lifetime Value (LTV), требуются месяцы аналитики. К каким инструментам прибегают, чтобы ускорить эти процессы?

Для быстрой оценки ROI есть классический метод оценки смежных компонентов: охвата, влияния и усилия. Эти параметры помогают относительно точно спрогнозировать итоговые показатели ROI, а рассчитываются значительно быстрее. 

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

Влияние — это ожидаемые улучшения для целевых клиентов, обеспечиваемые продуктом. Такие улучшения достаточно точно оцениваются по аналогичным кейсам, а если таковых на рынке нет, то стоит учесть величину улучшения, на которую рассчитывают инвесторы. Также можно учитывать общую усредненную формулу, по которой на ранних этапах разработки продукта ожидается улучшение на 10–20%, так как базовая реализация предоставляет внушительный потенциал. Для относительно зрелого продукта, прошедшего годы итеративных доработок, улучшение на 1–2% уже будет существенным. 

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

Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.

Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.

Сгенерированные UUIDv7 имеют все преимущества UUID и при этом упорядочены по дате и времени создания. Это ускоряет поиск индексов и записей в БД по ключу в формате UUID, значительно упрощает и ускоряет базы данных и распределенные системы. Неупорядоченность значений UUID прежде сдерживала использование UUID в качестве ключей и вынуждала разработчиков выдумывать собственные форматы идентификаторов или довольствоваться последовательными целыми числами в качестве ключей.

Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".

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

Предложенная мной ниже спецификация UUIDv7 с дополнительной функциональностью описывает максимально надежный и удобный вариант структуры UUIDv7 для самых сложных и высоконагруженных информационных систем. Функциональность упорядочена по приоритету реализации

Так или иначе сталкиваться с регулярными выражениями приходилось большинству разработчиков. Мое первое знакомство произошло с реализацией regex в STL std::regexp. Чаще всего регулярки используются в проверке входных данных, что-то вроде проверки корректности введенного пользователем URL, адреса IPv4, адреса IPv6, телефонного номера и при этом скорость выполнения операции regex не сильно влияет на время отклика от приложения. Но, что если вам приходится проверять сотни, тысячи или даже десятки тысяч правил и все это на постоянно меняющихся наборах входных данных в реальном времени? В этой ситуации вам не просто нужен быстрый алгоритм, вам понадобится лучший из них, вам понадобиться чемпион!

Привет, Хабр! С вами вновь Александр Бобряков, техлид в команде МТС Аналитики. И я с очередной статьёй из цикла про фреймворк Apache Flink.

В предыдущей части я рассказал, как тестировать stateless- и stateful-операторы Flink с использованием вспомогательных TestHarness-абстракций, предоставляемых Flink.

В этой статье напишем тесты на всю джобу с использованием мини-кластера Flink и при помощи JUnit Extension. Ещё мы начнём выделять удобные вспомогательные абстракции для тестов, которые понадобятся позже.

Привет, Хабр! Меня зовут Данил Картушов. 👋

В этом посте я расскажу, как музыкальная платформа Deezer, используя метаданные, с первых секунд научилась рекомендовать персонализированные треки новым пользователям!

Airflow в Lamoda Tech играет роль оркестратора процессов обработки данных. Ежедневно с его помощью мы запускаем 1 800+ тасок на проде, примерно половина из которых являются Spark-приложениями.

Все Spark-приложения сабмитятся из Docker-контейнеров. И здесь сталкиваемся с проблемой: в нашем случае не существует готовых решений для запуска Spark-приложений, позволяющих легко править конфигурацию и следить за количеством потребляемых ресурсов.

Меня зовут Андрей Булгаков, я лид команды разработчиков Big Data в Lamoda Tech. Вместе с разработчиком Иваном Васенковым в этой статье мы поделимся историей создания Airflow-оператора для запуска Spark-приложений.

На днях ученые из MIT показали альтернативу многослойному перцептрону (MLP). MLP с самого момента изобретения глубокого обучения лежит в основе всех нейросетей, какими мы их знаем сегодня. На его идее в том числе построены большие языковые модели и системы компьютерного зрения.

Однако теперь все может измениться. В KAN (Kolmogorov-Arnold Networks) исследователи реализовали перемещение функций активации с нейронов на ребра нейросети, и такой подход показал блестящие результаты.

Всем привет! На связи команда ad-hoc аналитики X5 Tech. В этой статье мы – Лев Баскин, Андрей Полушкин и Александр Сахнов – расскажем, как без регистрации и смс спланировать смены для сотрудников офлайн-магазинов. Казалось бы, задача достаточно тривиальная: берём симплекс метод или другой метод условной оптимизации и на основе ожидаемой загрузки получаем расписание сотрудников. Однако, не всё так просто. 

Первое препятствие на пути – масштабы. У Х5 порядка 25 000 магазинов от Калининграда до Владивостока и более 378 000 работников, обеспечивающих непрерывное функционирование бизнеса. У каждого магазина своя специфика и различающиеся бизнес-процессы. Во-вторых, даже зная, сколько часов занимает тот или иной процесс и как он локализован во времени, из-за внешних факторов нельзя так просто взять и поместить его в расписание. Например, обстановка на дорогах может повлиять на время поставки и, как следствие, сдвинуть ряд процессов в магазине. Достаточно предисловия, перейдём к сути!

Привет, друзья! Сегодня обсудим образование. Конечно, не всю систему в целом, а только те аспекты, которые затрагивают действующих и будущих BI-специалистов. Как получить фундаментальные знания в отрасли, где быстро и бесплатно найти ответ на волнующий вопрос, у кого научиться работать на конкретной BI-платформе, чтобы претендовать на ключевые позиции в крупных компаниях? Если вы задаете себе такие вопросы относительно Visiology, то все ответы на них найдете под катом.

Привет, Хабр! Представляю вам перевод статьи "How Uber Serves Over 40 Million Reads Per Second from Online Storage Using an Integrated Cache" автора Preetham Narayanareddy. Из неё вы узнаете, как в Uber проектировалась система кэширования на основе Redis, с какими сложностями и тонкостями пришлось столкнуться разработчикам, и как в итоге им удалось создать действительно высокопроизводительное решение.

Постановка задачи:

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

Сделаем небольшое отступление. Многие уже на этом моменте могут сказать, что подобные задачи решаются методом коллаборативной фильтрацией. И в целом они будут правы. Но есть случаи, когда фильтрация не подходит или ее недостаточно. Для примера давайте представим себя в роли продавца автомобилей, который думает, какой новой маркой / моделью авто ему начать торговать. Допустим у него есть выбор из 1000 вариантов. И тут уже становится понятно, что идея коллаборативный фильтрации не очень хорошо вписывается в этот случай. Продавцу хочется сделать выбор, не основываясь на предпочтениях других продавцов, а исходя из неких характеристик, определяющих выгоду объекта.

В сухом остатке имеем n признаков. Что с ними нужно сделать, чтобы достичь желаемого? Можно суммировать значение всех признаков для объекта и получить итоговую оценку, которая отражает совокупный итог всех знаний об объекте. Но что не так в таком простом подходе?

В данной статье рассматривается влияние бакетизации на мощность статистических критериев в условиях различных распределений данных и при разном объеме выборки. Особое внимание уделено зависимости мощности критерия от количества бакетов и размера выборки. Исследование предоставляет важные выводы для проектирования и анализа A/B тестирования и других форм экспериментальных исследований.

Многие компании в последнее время ввели должность «ИИ-тренера» (AI-тренера), при этом просто разметчики/ассесоры никуда не делись. Что это — просто красивая обертка нейминга над тем же самыми или что-то концептуально новое?

Давайте попробуем в этом разобраться и однозначно ответить на вопрос о различиях.

Спойлер к проблеме из сегодняшнего заголовка: «Никак». Об этом мы и поговорим.

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

Привет, Хабр! Меня зовут Сергей Евсеев, сегодня я расскажу, как в Apache NiFi настраивается ETL-пайплайн на задаче с JSON’ами. В этом мне помогут инструменты Jolt и Avro. Пост пригодится новичкам и тем, кто выбирает инструмент для решения схожей задачи.

Что делает наша команда

Команда работает с данными по рекрутингу — с любой аналитикой, которая необходима персоналу подбора сотрудников. У нас есть различные внешние или внутренние источники, из которых с помощью NiFi или Apache Spark мы забираем данные и складируем к себе в хранилище (по умолчанию Hive, но есть еще PostgreSQL и ClickHouse). Этими же инструментами мы можем брать данные из хранилищ, создавать витрины и складывать обратно, предоставлять данные внутренним клиентам или делать дашборды и давать визуализацию.

Описание задачи

У нас есть внешний сервис, на котором рекрутеры работают с подбором. Сервис может отдавать данные через свою API, а мы эти данные можем загружать и складировать в хранилище. После загрузки у нас появляется возможность отдавать данные другим командам или работать с ними самим. Итак, пришла задача — нужно загрузить через API наши данные. Дали документацию для загрузки, поехали. Идем в NiFi, создаем пайплайн для запросов к API, их трансформации и складывания в Hive. Пайплайн начинает падать, приходится посидеть, почитать документацию. Чего-то не хватает, JSON-ы идут не те, возникают сложности, которые нужно разобрать и решить.

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

Мы решили просто загружать все подряд — на месте разберемся, что нам нужно и как мы это будем грузить, потом пойдем к источникам с конкретными вопросами. Так как каждый метод API отдает свой класс данных в виде JSON, в котором содержится массив объектов этого класса, нужно построить много таких пайплайнов с обработкой разного типа JSON’ов. Еще одна сложность — объекты внутри одного и того же класса могут отличаться по набору полей и их содержимому. Это зависит от того, как, например, сотрудники подбора заполнят информацию о вакансии на этом сервисе. Этот API работает без версий, поэтому в случае добавления новых полей информацию о них мы получим только либо из данных, либо в процессе коммуникации.

В статье описывается практическое применение популярных Open-Source технологий в области интеграции, хранения и обработки больших данных: Apache NiFi, Apache Airflow и Greenplum для проекта по аналитике учета вывоза отходов строительства.

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

Меня зовут Дмитрий Курганский, я Tech Lead команды MLOps в Банки.ру.
Мы работаем над тем, чтобы грамотно организовать и ускорить этапы жизненного цикла ML. В этой статье поделюсь нашим опытом применения Embedding: от запуска Яндекс Data Proc кластера через Airflow до оптимизации этапа применения Embedding с помощью Spark.
Материал в целом будет актуален для этапа применения (inference) любых моделей для больших наборов данных, работающих в batch режиме по расписанию.

Это мой вольный перевод статьи "Why You Should Start Writing Spark Custom Native Functions", которая вдохновила меня на некоторые собстенные изыскания по данной теме. Их результат я планирую опубликовать позже, а пока выношу на ваш суд этот перевод.

Статья на примере реализации функции по генератации UUID рассматривает, как писать Spark native функции, которые были бы "прозрачны" для Catalyst (в отличии от UDF, которые являются "черными ящиками" для него). Сравнение производительности ожидаемо показывает, что Catalyst Expressions значительно превосходят UDF при увеличении размера данных.

Кому интересно узнать, как писать Spark native функции - прошу под кат.

Только изучили один инструмент, как сразу же появились новые? Придется разбираться! В статье мы рассмотрим новый тип баз данных, который отлично подходит для ML задач. Пройдем путь от простого вектора до целой рекомендательной системы, пробежимся по основным фишкам и внутреннему устройству. Поймем, а где вообще использовать этот инструмент и посмотрим на векторные базы данных в деле.