Data Engineering *

Волей судьбы вам досталась в наследство успешная франшиза по разведению кроликов по всему миру. Сотни тысяч ферм разного масштаба. Миллиарды животных. Огромная реферальная сеть. Ваш дед был настолько продвинутым, что смог запустить цепную реакцию и теперь система растет сама по себе, привлекая все новых и новых участников. Но увы, дед, помимо любви к животным, был заядлым фронт-end разработчиком и БД для него была лишь средством сохранения данных о своей сети. И не более.

Но вы. Вы - другое дело. Посмотрев на все это богатство вы сразу поняли, что перед вами открываются новые горизонты. Как например - открытие маркетплейса для торговли мясом или живыми животными. Вы можете интегрировать рынок сбыта в свою модель и сделать еще много и много чего. А что для этого нужно? Правильно, для этого нужна аналитика. Мощная и точная.

На прошлых выходных (23-24 сентября) Huawei проводил хакатон TechArena Ireland в Дублине. Несколько сотен зарегистрировались, больше сотни пришло. Организация потребовала немало времени и сил на подготовку места, рекламы, и прочего. (Я не буду перечислять в переводе всех пострадавших :) Они все упомянуты в англоязычном посте на LinkedIn и Medium.)

Я отвечал за подготовку задания, оценки решений и подобных мелочей. Вот как это выглядело.

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

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

В этой статье мы рассмотрим как построить пайплайн обработки данных в реальном времени с использованием Python.

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

В данной статье мы рассматриваем новый подход к классификации прикладных протоколов в сетевых пакетах.

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

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

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