Big Data *

Привет, Habr !

Я работаю инженером по машинному обучению в Мегафоне. Занимаюсь аналитикой данных и являюсь частью команды разработки MLOps платформы. Задача нашей команды состоит в том, чтобы выстраивать и оптимизировать процессы разработки и продуктивизации моделей машинного обучения, предоставлять функционал для основных этапов (сбор данных, MQ/DQ, продуктивизация).

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

Видеозапись по мотивам статьи можно посмотреть здесь.

Эта статья будет интересна аналитикам и инженерам, которые работают с BigData и регулярно сталкиваются с необходимостью продуктивизировать модели на Hadoop.

Затронем следующие темы:

Привет! Продолжу рассказ о том, как мы превращаем банк в «биг дата» — организацию. Очевидно, что чем больше данных использует компания, тем больше зависит от их качества. Но, зачастую, вопросам качества данных при разработке витрин уделяется недостаточно внимания. Это связано с тем, что требования к качеству данных не фиксируются в бизнес‑требованиях, а разработчик витрины/инженер данных не всегда досконально знает предметную область. Будущее — за организацией контрольных мероприятий в контуре бизнес‑заказчиков. Этот тренд получил название Self‑Service функции. У нас в Газпромбанке по такому принципу строится проверка качества данных для ML‑моделей. Каждому аналитику/разработчику моделей доступен функционал оценки качества данных любой витрины. Рассказываю, как выстроили такую схему работы.

Это перевод поста из блога The Analytics Engineering Roundup (горячо рекомендую!) под названием Becoming Pangea про тенденции в индустрии данных и аналитики, стратегические преимущества и проблемы, с которыми сталкиваются компании в ней, влияние основных облачных провайдеров на её будущее и роль стандартов в формировании в ней технологических экосистем.

Привет! Меня зовут Алексей, я дата-аналитик. Четыре года назад я пришёл в дата-анализ из сферы, далековатой от IT, — пивоварения (хотя о том, что на самом деле они не так далеки, я рассказывал здесь). До того как я нашёл свою нишу, тщетно пробовал вкатиться в IT через разные курсы по Python, TensorFlow и веб-разработке. Потратил на это три года и 100 тысяч рублей, в какой-то момент выгорел ещё в процессе обучения, чуть не бросил попытки, но собрался и в итоге самостоятельно и бесплатно изучил анализ данных, который мне сразу зашёл. 

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

Крайне важный кейс для бизнеса — автоматизация бизнес процессов, где раньше можно было только использовать, например, оператора или клиентского менеджера, а сейчас им на помощь и замену чат-боты, голосовые ассистенты и вот и настало время, когда без машинного обучения и NLP уже никуда. Предлагаю рассмотреть NER сервисы и если обратиться к wikipedia:

Named-entity recognition (NER) (also known as (named) entity identification, entity chunking, and entity extraction) is a subtask of information extraction that seeks to locate and classify named entities mentioned in unstructured text into pre-defined categories such as person names, organizations, locations, medical codes, time expressions, quantities, monetary values, percentages, etc.

Привет, меня зовут Мария Стефова, и я продакт-менеджер образовательной среды в Нетологии. Сегодня расскажу вам, как мы разрушили барьер между студентом и экспертом и создали сервис для получения живой обратной связи во время выполнения домашнего задания. Сейчас мы получаем в месяц от 2 500 до 4 500 вопросов от студентов, а средний показатель отвеченных вопросов — 95–98%. 

Хотя в начале запуска сервиса вопросов и ответов всё было не так радужно: мы словили много хейта от экспертов, и чтобы добиться феноменальных результатов, нам пришлось сильно постараться и отстроить все бизнес-процессы. Немалую роль сыграло и внедрение ML (англ. Machine Learning). Именно оно помогло автоматизировать ответы на львиную долю рутинных вопросов и повысить скорость их обработки. В статье я поделюсь с вами историей о том, как мы размечали данные, искали баланс между порогом вероятности и охватом вопросов, обучали и дообучали модель, а также расскажу об итогах нашей работы.

Некоторое время назад многие российские компании, чей бизнес очень сильно завязан на обработке и анализе больших объемов данных (банки, ритейл, телеком) задумались о том, как можно уменьшить стоимость владения хранилищами данных, построенных на западных технологиях. События последнего времени только ускорили этот процесс. И сейчас количество компаний, для которых актуальна миграция существующих хранилищ данных, построенных на Oracle, MS SQL и других проприетарных СУБД, на решения открытого ПО и отечественных поставщиков, резко выросло, а СУБД GreenPlum фактически становится отраслевым стандартом в хранилищах данных.

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

Именно такую задачу поставил нам клиент – крупная торговая компания. После небольшого ознакомления с возможными методиками, выбор пал на метод COSMIC (Common Software Measurement International Consortium [1]), являющийся одной из разновидностей оценки функционального объема по функциональным точкам и выросший до стандарта ISO 19761. Плюсом в пользу СOSMIC стало разработанное консорциумом адаптированное руководство для оценки функционального объема хранилищ данных [2].

Как и было обещано, в завершение серии ( 1 • 2 • 3 • 4 • 5 ) статей о разработке инструмента для ETL больших данных, я выкладываю выжимку ответов на вопросы.

А то статьи были в формате туториала для разработчиков таких инструментов (длинные и с высоким уровнем сложности), так что стоит рассказать более кратко и понятно для каждого.

Q. Что это такое?

A. Специализированный инструмент для а) быстрого создания ETL процессов и б) эффективного по стоимости их выполнения.

Промка: https://dcetl.ru
Исходники: https://github.com/PastorGL/datacooker-etl
Официальная группа в телеге: https://t.me/data_cooker_etl

В условиях отсутствия возможности лицензирования и поддержки иностранных вендорских решений по хранилищам данных, встал вопрос о замене этих решений на отечественное программное обеспечение, с вендорской поддержкой, находящееся в реестре российского ПО и которое не уступает по производительности и объемам хранения зарубежным аналогам, таким как Teradata, Oracle, SAP HANA. Как показал анализ, таким требованиям отвечает лишь решения, основанные на MPP СУБД на базе Greenplum, в частности Arenadata DB (ADB). Но как быстро и безболезненно начать миграцию с привычных хранилищ на open-source? Постараюсь в статье рассказать и показать, что удалось придумать в этом направлении

В этой статье поговорим о том, как сделать простой процесс загрузки данных с помощью Microsoft Azure Data Factory и Databricks в 2023/2024 году. Во второй части разберем миграцию init scripts из DBFS в Workspace в связи с новым обновлением от Databricks, если ее не сделать, то не удивляйтесь, что в конце 2023 года у вас начнут падать ADF pipelines и кластера в Databricks. 1 декабря 2023 г. Databricks отключит сценарии инициализации (init scripts) с именем кластера для всех рабочих областей. Этот тип сценария инициализации ранее считался устаревшим и не будет больше использоваться.

Привет, Хабр!

Меня зовут Рушан, и я автор Telegram-канала Нейрон. Сегодня в этой статье обсудим 20 проектов по аналитике данных для новичков, которые помогут приобрести базовые и полезные знания в обработке данных и которые Вы сможете использовать для создания своего портфолио. 

Эти проекты будут охватывать наиболее востребованные навыки анализа данных и наиболее часто используемые инструменты анализа данных: Excel, SQL, Python, R, Tableau, Power BI.

Итак, погнали:

Каждая компания непрерывно производит и хранит кучу данных, и это вызывает множество проблем. Объёмы хранилищ не бесконечны, как и ресурсы железа. Вот только оптимизация обработки и хранения данных не всегда приносит желаемые результаты. Как всё настроить так, чтобы значительно сократить объём занимаемый ими на диске?

У нас получилось! Мы снизили количество данных на диске в 3 раза, при этом ускорив их обработку. И сейчас расскажу как. Меня зовут Александр Маркачев, я Data Engineer команды Голосовой Антифрод в beeline. В статье затронем тему форматов ORC и Parquet, как их правильно использовать и хранить, чтобы всем было хорошо.

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

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

Идея – создать ББД с суточным начислением и собственной криптовалютой; сумму начисления ББД сделать дифференцированным по пользователям привязав к параметрам человека, которые входят в такие сферы жизнедеятельности как: экономика, образование и наука, культура и творчество, законопослушность, спорт и здоровье, социальная и общественная деятельность, экология и другие; создать именную валюту пользователей, которая напрямую связана с пользовательским ББД и является комплексной оценкой  пользы пользователя по отношению к обществу в целом; все процессы внутри сети ББД должны иметь систему вознаграждения участников от выполненной работы.

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

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, посвящённой API расширения и разного рода технической обвязке:

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

Теперь можно поговорить о последних штрихах, делающих инструмент — инструментом, а именно, об интерактивно-отладочном режиме, то есть, REPL, клиенте и сервере, а также о генераторе документации.

Ко мне обратился коллега с вопросами про бизнес-метрики – средний чек и ARPU.

В этой статье я разобрался в бизнес-метриках и ответил на вопросы:

- Что такое ARPU и средний чек? Как их рассчитывать? На какие вопросы они отвечают и для чего нужны? 

- Могут ли они ARPU и средний чек быть  равны между собой? Будут ли отличаться в динамике месяц от месяца?

- Что если в бизнесе кол-во продуктов фиксировано и все они с одинаковой ценой? Будет ли показатель от месяца к месяцу одинаков? А если рассчитывать среднюю выручку?

А для наглядности – рассчитал данные метрики на реальных данных интернет-магазина.

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, посвящённой имплементации спеки языка в коде:
Заметка об использовании prior art
Наборы данных в контексте исполнения
Переменные, настройки контекста исполнения, и метаданные параметров подключаемых функций
Интерпретатор, контекст исполнения, операторы выражений

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

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, последней, посвящённой проектированию спецификации языка:
Операторы жизненного цикла наборов данных (продолжение)
Операторы контроля потока выполнения
Операторы управления контекстом исполнения
Операторы выражений

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