Data Engineering *

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

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

Некоторое время назад многие российские компании, чей бизнес очень сильно завязан на обработке и анализе больших объемов данных (банки, ритейл, телеком) задумались о том, как можно уменьшить стоимость владения хранилищами данных, построенных на западных технологиях. События последнего времени только ускорили этот процесс. И сейчас количество компаний, для которых актуальна миграция существующих хранилищ данных, построенных на 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

В данной статье делюсь замеченной на практике проблемой. Смысл проблемы заключается в использовании противоречащих подходов на уровне Persistance и DevOps.

В условиях отсутствия возможности лицензирования и поддержки иностранных вендорских решений по хранилищам данных, встал вопрос о замене этих решений на отечественное программное обеспечение, с вендорской поддержкой, находящееся в реестре российского ПО и которое не уступает по производительности и объемам хранения зарубежным аналогам, таким как 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) с именем кластера для всех рабочих областей. Этот тип сценария инициализации ранее считался устаревшим и не будет больше использоваться.

Привет, Хабр! На связи Т1 Цифровая Академия из Холдинга Т1. Сегодня расскажем о
том, как мы помогали клиенту справиться с нехваткой data-инженеров и увеличить темпы найма, дообучая кандидатов навыкам работы с Apache Spark на реальных задачах компании.

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

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

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

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

В мире баз данных идентификаторы имеют решающее значение для уникальной идентификации записей. Традиционно многие разработчики предпочитали автоматически увеличивающиеся целочисленные идентификаторы. Однако есть еще один вариант, который набирает популярность: универсально уникальные идентификаторы (UUID). В этой статье мы рассмотрим, почему UUID часто являются лучшим выбором по сравнению с автоматически увеличивающимися идентификаторами.

Большие данные мертвы. В той их части, которая характеризуется как “большие”. Так считает Джордан Тигани, инженер-основатель Google BigQuery, человек, который больше 10 лет рассказывал всем о пользе big data. Что он имеет в виду и что это значит для бизнеса? Давайте разбираться.

Таблица справочник, которая является медленно изменяющейся и также генерирует DAG.

В статье рассказывается как можно хранить бизнес-метрики и собирать их через DAG.

Всем привет!

В этой статье мы расскажем, как нам удалось настроить взаимодействие Apache Spark и S3 для обработки больших файлов: с какими проблемами пришлось столкнуться и как нам удалось их решить.

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

Изучая задачу, я понял, что мне нужно обнаруживать чаек по фотографиям. Для решения задачи я решил использовать yolov8s, потому что он мне показался оптимальнейшим из линейки yolov8 для моего случая. Также, мне как-то рассказывали про sahi (Slicing Aided Hyper Inference), и я решил, что это мой шанс попробовать этот инструмент в качестве улучшения конечного результата.

Итак, у меня был датасет, включающий фотографии, уже разбитые на train, validation, test, запакованные в zip архив. Первым делом, я клонирую репозиторий для yolov8, устанавливаю и импортирую необходимые на первых парах библиотеки и распаковываю то, что нужно распаковать.

Привет, Хабр! Меня зовут Иван Сивков, я наставник на курсе «Специалист по Data Science» в Яндекс Практикуме. В этой статье покажу, как построить пайплайн в библиотеке scikit-learn на базе встроенных инструментов и сократить количество кода при преобразовании данных. Эта статья рассчитана на новичков, которые только начинают изучать Data Science, но уже знают основные понятия.