Big Data *

Привет! Меня зовут Алексей, я дата-аналитик. Четыре года назад я пришёл в дата-анализ из сферы, далековатой от 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, заточенный на задачи подготовки и трансформации наборов данных.

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

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

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

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

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

Краткое содержание предыдущей серии:
Вступление
Постановка задачи
Проектирование языка. Операторы жизненного цикла наборов данных
Проектирование системы типов

Готовим гибридную систему мониторинга + щепотка observability дабы нанести непоправимую пользу всему прогрессивному человечеству. С ароматом кофе, перед использованием можно добавить свои данные по вкусу.

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

— Евдокимов, ты что, совсем уже там кукухой поехал?! При живом-то Spark SQL! Опять ты ненормальным программированием маешься, нет бы что-то полезное делал…
— Ну-ну-ну, спокойно, спокойно. Я ещё настолько не уехал, чтобы потратить целый год на страдание полной ерундой. Речь на сей раз пойдёт не о развлекухе, а о диалекте языка, специализированном для решения целого класса задач, для которых любой существующий SQL был бы, в теории, хорошим решением, если бы не несколько серьёзных «но».

Короче, у нас будет немного не такой SQL, который вы все так хорошо знаете, но и этот вариант вы полюбите, я обещаю. Тут лучше другой вопрос задать:
— Разве кому-то нужен голый SQL-ный движок?

Нет, голый — не нужен. Так рассказывать я буду о разработке настоящего production ready инструмента, с интерактивным шеллом с подсветкой синтаксиса и автодополнением, который сможет работать в клиент-серверном режиме, и не только на кластере, но и локально. Да не монолитный, а расширяемый при помощи подключаемых функций. И с автогенератором документации впридачу. Короче, всё будет совсем по-взрослому, с рейтингом M for Mature.