Data Engineering *

Управление и устойчивая обработка данных являются важнейшим фактором успеха практически во всех организациях. В то время как платформа Cloudera Data Platform (CDP) уже поддерживает весь жизненный цикл данных от 'Edge до AI', мы в Cloudera полностью осознаем, что предприятия имеют больше систем за пределами CDP. Очень важно избегать того, чтобы CDP становилась ещё одной обособленной платформой в вашем ИТ-ландшафте. Чтобы исправить это, она может быть полностью интегрирована в существующую корпоративную ИТ-среду, какой бы разнообразной она ни была, и даже помогать отслеживать и классифицировать широкий спектр существующих активов данных, чтобы обеспечить полную картину от начала и до конца. В этом блоге мы выделим ключевые аспекты CDP, которые обеспечивают управление данными и покажем, как их можно расширить, чтобы включить в них метаданные для не связанных с CDP систем со всего предприятия.

Сегодня, 4 мая, в день Звездных войн мы подготовили для Вас подробный гайд по основным функциям библиотеки dplyr. Почему именно в день Звездных войн? А потому что разбирать мы все будем на примере датасета starwars.

Ну что, начнем!

Добрый день, уважаемые читатели! Материал носит теоретический характер и адресован исключительно начинающим аналитикам, которые впервые столкнулись с BI-аналитикой.

Что традиционно понимается под этим понятием? Если говорить простым языком, то это комплексная система (как и, например, бюджетирование) по сбору, обработке и анализу данных, представляющая конечные результаты в виде графиков, диаграмм, таблиц.

Это требует слаженной работы сразу нескольких специалистов. Дата-инженер отвечает за хранилища и ETL/ELT-процессы, аналитик данных помогает в заполнении базы данных, аналитик BI разрабатывает управленческие панели, бизнес-аналитик упрощает коммуникации с заказчиками отчетов. Но такой вариант возможен, только если фирма готова оплачивать работу команды. В большинстве случаев небольшие компании для минимизации затрат делают ставку на одного человека, который зачастую вообще не обладает широким кругозором в области BI, а имеет лишь шапочное знакомство с платформой для отчетов.

В таком случае происходит следующее: сбор, обработка и анализ данных происходит силами единственного инструмента – самой BI-платформой. При этом данные предварительно никак не очищаются, не проходят компоновки.  Забор информации идет из первичных источников без участия промежуточного хранилища. Результаты такого подхода можно легко лицезреть на тематических форумах. Если постараться обобщить все вопросы касательно BI-инструментов, то в топ-3 попадут, наверное, следующие: как загрузить в систему плохо структурированные данные, как по ним рассчитать требуемые метрики, что делать, если отчет работает очень медленно. Что удивительно, на этих форумах вы практически не найдете обсуждений ETL-инструментов, описания опыта применения хранилищ данных, лучших практик программирования и запросов SQL. Более того, я неоднократно сталкивался с тем, что опытные BI-аналитики не очень лестно отзывались о применении R/Python/Scala, мотивируя это тем, что все проблемы можно решить только силами BI-платформы. Вместе с тем всем понятно, что грамотный дата инжиниринг позволяет закрывать массу проблем при построении BI-отчетности.

В предыдущей статье мы с вами разобрались с тем, как использовать функцию UNNEST для работы с повторяющимися записями в Google BigQuery.

В этой статье мы идём дальше, и поговорим про конструкцию SELECT FROM UNNEST.

Используя конструкцию SELECT FROM UNNEST, вы говорите: «Я хочу применить функцию UNNESTк повторяющейся записи в ее собственной маленькой временной таблице. Далее выбрать одну строку из неё и поместить ее в наши результаты, так же как если бы это было любое другое значение ».

Задача классификации - одна из самых известных в машинном обучении. Очень многие проблемы, решаемые с помощью ML, так или иначе сводятся к классификации — распознавание изображений, например. И все выглядит просто и понятно, когда нам нужно определить объект в один из нескольких классов. А что если у нас не плоская структура из нескольких классов, а сложная разветвленная иерархия на 683 категории? Именно о таком случае мы сегодня и поговорим. Под катом - рассказ о том, зачем в задачах классификации нужны сложные иерархии и как с ними жить.

С выходом Apache Spark 3.1 в марте 2021-го проект Spark on Kubernetes официально перешел в статус общедоступного и готового к эксплуатации. Это стало результатом трехлетней работы быстрорастущего сообщества, участники которого помогали в разработке и внедрении (изначально поддержка Spark on Kubernetes появилась в Spark 2.3 в феврале 2018 года). Команда Kubernetes aaS от Mail.ru Cloud Solutions перевела самое важное из статьи об основных возможностях Spark 3.1, в которой автор подробно остановился на улучшениях в Spark on Kubernetes.

Какой язык использовать для анализа данных - это максимально избитая и больная тема. Поэтому мы объединились с Алексеем Селезневым, руководителем отдела аналитики в Netpeak и автором телеграм-канала R4Marketing, и подготовили сравнение операторов SQL и глаголов языка R. Для удобства и переносимости сделали это в карточках.

На западе в производственных компаниях царит тишина и порядок. Данное, казалось бы, расслабленное состояние – сильно обманчиво. Под тишиной и порядком кроется постоянная концентрация на результат, можно сказать, «благоприятный стресс». В зависимости от региона и страны данный «благоприятный стресс» может отличаться, но всегда имеет общую цель – постоянно меняться к лучшему, неукоснительно соблюдая требования. В США, например, «благоприятный стресс» сильно связан с незащищенностью трудовых отношений (уволить могут за одну минуту). Долгие годы под страхом увольнения формировалась целая культура, которая вылилась в активность и концентрированность персонала на результате. Многие работники приходят на работу раньше и задерживаются на ней не для того, чтобы показать начальству видимость работы, а для того, чтобы успеть сделать намеченное, успеть сделать больше. В Европе работа строится иначе – работники пытаются максимально использовать рабочее время. На крупном авиационном заводе во Франции приходилось нередко видеть картину, когда люди в буквальном смысле бегают. К сожалению, в промышленных компаниях такая модель управления встречается крайне редко, особенно в государственном секторе.

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

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

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

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

Как отдельная профессия Big Data Engineering появилась довольно недавно. И даже крупные компании очень часто путают, чем занимается этот специалист, каковы его компетенции и зачем он вообще в организации.

Поэтому в сегодняшней статье, специально к старту нового потока курса по Data Engineering, мы разберёмся, кто такой Big Data Engineer, чем он занимается и чем отличается от Data Analyst и Data Scientist.  Этот гайд подойдёт людям, которые хотят работать с большими данными и присматриваются к профессии в целом. А также тем, кто просто хочет понять, чем занимаются инженеры данных.

Считается, что Data Science — это очень сложное направление, в котором обязательно нужны математические знания и техническое образование. Это верно только отчасти: внутри Data Science есть сайентисты, аналитики и инженеры. У них разные задачи и им нужен разный бэкграунд. О том, на кого легче выучиться гуманитарию, что нужно знать, чтобы войти в новую специальность и можно ли стать хорошим аналитиком данных без профильного опыта, рассказывает преподаватель GeekBrains, Data Analyst с уклоном в Data Engineering Никита Васильев.

RPA (Robotic Process Automation) сейчас в некотором смысле напоминает старую добрую миниатюру Реввы: “Киииборги. Они заполонили всю планету!”. Про RPA говорят все чаще и чаще, появляются статьи и видео, рассказывающие о небывалом росте этого сегмента и многомиллионных экономиях тех, кто уже внедрил у себя RPA. Не то, чтобы и раньше этого не было, но сейчас стало уж совсем много.

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

Некоторое время назад, столкнувшись с определенными задачами, я выбирал средство для их решения и обратил внимание именно на RPA. Прорвавшись через миллион рекламных статей и восторженных видео от реселлеров, протестировав практически все, что доступно в trial / free версиях, я остановился на Automation Anywhere, который неплохо подходил под требования. Позже, к слову, я обнаружил что в нашей компании существует целый отдел, который занимается автоматизацией с помощью Blue Prism. Обратная, так сказать, сторона крупных корпораций - не всегда знаешь, что у нас уже есть…

Ну да речь не об этом. Не сразу, но через какое-то время я обнаружил, что самая сложная задача в RPA, это вовсе не написание роботов и не процесс их имплементации и сопровождения. Самое сложное - это управление ожиданиями на стороне менеджмента. Понимаете - они не инженеры, они управленцы. Они не понимают и не знают как, а главное почему, многие вещи работают так или иначе. Они читают такие же рекламные статьи и смотрят такие же рекламные видео как я в самом начале - и делают вывод: “Это же то, что нам нужно! Это решит все проблемы!”. И начинают интенсивно форсировать процесс внедрения. И хорошо, если есть  внутренний инженерный ресурс, который этим вопросом будет заниматься и подскажет, что где и как. А вот если задача попадет к интеграторам - это может быть большой проблемой. Может быть не сразу, может быть в перспективе, но я думаю что обязательно будет, и вот почему:

Меня зовут Никита Василюк, я инженер по работе с данными в департаменте данных и аналитики Lamoda. Я и моя команда занимаемся всем, что связано с распределенной системой хранения и обработки данных.

Периодически нам приходится отвечать на вопросы, где у нас лежат те или иные данные. Поэтому однажды мы решили провести эксперимент и внедрить Data Catalog, чтобы запросы приходили уже не к нам, а в систему. Например, если человеку понадобилась информация, связанная с заказами, он может перейти в систему, ввести слово order и найти все, что ему нужно по этой теме. Мы рассмотрели три инструмента и в итоге… не стали ничего менять. Рассказываю почему.

Что делать если перед вами стоит задача нагрузочного тестирования, в проекте используется postgres и хранятся персональные данные раскрытие которых недопустимо?

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

Привет, Хабр! Меня зовут Ксюша Блажевич, я руководитель направления data science и product-owner в Леруа Мерлен. 13 апреля в 19:00 МСК мы совместно с Yandex.Cloud организуем митап о платформах данных, на котором обсудим c Авито и Райффайзенбанком методы и инструменты скоринга входных данных, их агрегации и создании единой системы. 

Под катом расписание митапа и анонсы докладов: о релизе нового функционала Yandex Object Storage, методах ускорения time to market до 1 дня, применении lightGBM при приемке товара на складах и оптимизации размещения банкоматов с помощью JupyterHub. 

Стать разработчиком, если ты не технарь и у тебя нет профильного диплома, вполне реально — много подобных примеров можно найти в сети. Считается, что Python — один из самых простых способов войти в эту профессию, но есть масса нюансов, которые могут повлиять на обучение. О том, как его построить, чтобы не обжечься на первом языке программирования, рассказывает преподаватель Python в GeekBrains и главный инженер Сбера по разработке в Data Analytics Вероника Голубева.

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

Но порог входа в Kubernetes для Data Scientists все еще остается высоким. Мы хотим помочь в работе с непростой технологией, поэтому покажем, как можно быстро развернуть Spark внутри Kubernetes и запустить в нем свое приложение.

Запуск клиента информатики