Data Engineering *

Автор этой статьи в блоге Stack Overflow — Data QA Engineer, то есть инженер обеспечения качества данных. По его словам, у него есть друзья, занятые в сфере технологий и разработки ПО, которые не совсем понимают, что такое тестирование данных, зачем оно нужно и как оно вписывается в мир программирования.

Это вполне объяснимо: наука о данных — совершенно новая область, и даже те, кто работает с данными каждый день, должны оставаться открытыми ко всем изменениям в работе. О профессии Data QA Engineer рассказываем к старту курса по Data Engineering.

Привет! На связи Артемий – Analytics Engineer @ Wheely.

В последние годы явным стал тренд на анализ слабоструктурированных данных – всевозможных событий, логов, API-выгрузок, реплик schemaless баз данных. Но для привычной реляционной модели это требует адаптации ряда новых подходов к работе с данными, о которых я и попробую рассказать сегодня.

В публикации:

- Преимущества гибкой схемы и semi-structured data

- Источники таких данных: Events, Logs, API

- Подходы к обработке: Special Data Types, Functions, Data Lakehouse

- Принципы оптимизации производительности

Типичный диалог на планировании:
Лид:  
— Пользователи просят репликацию вот этих колонок в этих таблицах из продакшен базы в data lake.
Разработчик: 
— Когда?
Лид:  
— Вчера.

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

Всем привет! Меня зовут Семен Путников, я — инженер данных в DINS. Я работаю в команде, которая участвует в разработке инструментов управления и анализа больших данных для RingCentral. Под катом история о том, как мы решили проблему частой миграции данных для наших ETL и радуем пользователей быстрыми ответами на их запросы.

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

От автоматизированных цепочек поставок и систем по поддержанию социального дистанцирования до более ресурсоэффективных и удобных «умных» городов и транспортных средств — пространство интернета вещей (IoT) росло огромными темпами, и параллельно с этим увеличивался объем создаваемых данных. По прогнозам, к 2025 г. IoT-устройствами будет сгенерировано 73,1 зеттабайта данных.

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

Становясь все более мощными устройствами, современные подключенные автомобили (connected vehicles) со временем имеют все шансы стать настоящими центрами обработки данных на колесах. Блоки управления, примененные в новых моделях, выполняют гораздо более широкую функцию, чем простая передача информации пользователю, они обеспечивают выход в интернет, управляют бортовыми информационно-развлекательными системами и поддерживают работу голосового управления, в том числе совершение телефонных звонков в бесконтактном режиме «хендс-фри». Согласно некоторым прогнозам, уже в следующем году будет сделан еще один шаг к появлению полностью централизованных архитектур для подключенных автомобилей. Однако некоторые важнейшие задачи, стоящие на этом пути, все еще остаются нерешенными.

Расширение сетевых функций окружающей нас городской инфраструктуры будет сопровождаться значительным увеличением количества взаимодействий между транспортным средством и окружающими его объектами (V2X, Vehicle-to-Everything), а также объемов создаваемых данных. Результатом этого станет возникновение новых задач, связанных с хранением данных, поскольку критически важная информация должна регистрироваться и передаваться через блоки управления и бортовые системы автомобиля.

Привет! На связи Артемий – энтузиаст в сфере Data Warehousing, Analytics, DataOps.

Уже продолжительное время я занимаюсь моделированием DWH с использованием dbt, и сегодня пришло время познакомить вас с package для построения Data Vault – dbtVault.

В публикации:

• Готовим датасет TPC-H

• Поднимаем кластер Greenplum в Яндекс.Облаке

• Погружаемся в кодогенерацию и макросы dbtVault

• Cимулируем инкрементальное наполнение Data Vault

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

Самым известным мультиязыковым корпусом является LANG-8, в котором содержатся тексты на восьмидесяти языках. Этот массив данных был создан людьми, изучающими иностранные языки; пользователи исправляли чужие ошибки, и данные об этом автоматически попадали в систему. Однако количественное соотношение текстов на различных языках в корпусе колеблется. Так, на английском языке присутствуют свыше миллиона различных примеров, а для некоторых других языков их около десяти тысяч. Стоит также отметить тот факт, что данные собирались без какой-либо фильтрации и верификации, из-за чего в некоторых "правильных" предложениях могут присутствовать ошибки. Всё же этот корпус также крайне мал, что приводит к необходимости использования синтетических данных.

Замечание. Вся трилогия (часть 1 тут, часть 2 тут) о велосипедостроении с sqlite, xml, csv только для совсем маленьких Питоньих кодеров. Не для крутых кодеров, они умрут от скуки в нашем опусе и ничего нового не увидят. В третьей части заканчиваем все, что начали ранее.

Начинаем изыски причины и местонахождения ошибки.

Итак: правильный ответ: ошибки в коде нет. Ну точнее ошибка возникает при работе кода из-за ошибки данных в файлах. 

Чтобы убедиться, что это так, добавим в код обработку исключений.

Совсем немного поправим наш код, добавим обработку и вывод на печать исключений:

В ноябре 2018 года я запустил телеграм канал R4marketing. Канал посвящён языку R, посты канала разделены по рубрикам, одна из таких рубрик "Заметки по R". В эту рубрику входят небольшие публикации, с интересным или полезными советами по использованию R.

Этой статьёй я начинаю серию публикаций состоящих из подборок наиболее полезных заметок канала R4marketing.

Первая статья будет посвящена визуализации данных.

Привет, Хабр! Мы в Х5 очень любим данные и умеем с ними обращаться. Недавно мы провели «Цифровой четверг» — дискуссию с представителями ИТ-компаний, облачных провайдеров и телекомов.

На встрече обсудили data-driven подход: кейсы, «грабли» и базовые моменты, о которых стоит знать. Решили поделиться ключевыми мыслями по её итогам.

Существует миллион разных причин, по которым могут возникать сбои в работе конвейеров данных, и нет ни одного универсального подхода, помогающего сразу понять, как и почему они случаются. В этой статье я расскажу вам о пяти шагах, которые нужно совершить дата-инженеру, чтобы провести анализ первопричин (Root Cause Analysis - RCA) проблем с качеством и пригодностью данных (Data Quality).

Данная статья является гайдом по использованию кастомных агрегаторов в Spark SQL API. Она “выросла” из моих заметок, которые я делал себе с начала работы со Spark. Сейчас, по мере накопления опыта, мне все это кажется уж слишком наивным и простым, но в свое время мне это показалось чертовски удобным/изящным/заслуживающим внимания, поэтому и решил опубликовать, тем более на Хабре про это еще вроде не писали. Статья ориентирована в первую очередь на тех, кто только начинает работать со Spark, поэтому и помечена как “tutorial”. Если у вас есть какие-либо интересные кейсы по использованию кастомных агрегаторов - делитесь в комментариях!

Ниже мы будем говорить о user-defined aggregations functions (UDAF) org.apache.spark.sql.expressions.Aggregator, которые могут быть использованы для DataSet’ов с целью агрегации группы элементов в одно значение каким-угодно-пользователю образом.

•    Действительно ли электоральные предпочтения сельских жителей существенно отличаются от предпочтений городских жителей?

•   Зачем нужно срочно вводить электронное голосование в крупных городах России?

•   Как выглядят на графиках и на карте России аномальное голосование?

•    Подробные карты окрестностей городов России с результатами голосования на выборах в государственную Думу в 2021 году. 

Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в компании Quadcode. Сегодня хочу поговорить о реляционных СУБД, которые играют важную роль в современном IT-мире. О том, что они собой представляют и для чего нужны, понимают, вероятно, большинство читателей.

Но вот как и почему появились реляционные СУБД? Об этом многие из нас знают лишь приблизительно. А ведь история создания технологии весьма интересна, она позволяет лучше понять основу цифрового мира. Если вам интересна эта тема — прошу под кат.

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

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

окончание трилогии тут (часть 3): "Последний велосипедно-питоний бой с ошибками импорта sqlite за 2 174 433 строчки. Часть 3"

Пример использования процессора JoltTransformJson в Apache NiFi. Можно рассматривать как небольшой туториал по использованию Jolt-спецификаций.

В предыдущей статье мы поговорили про роль Data Engineer в Х5, какие задачи он решает и с каким технологическим стеком работает. Рассмотрели структуру собеседования, основные направления, по которым мы оцениваем кандидатов, и подробно разобрали базовые требования, предъявляемые нами к уровню владения Python.

В данной статье мы разберём требования к ключевым для Data Engineer в X5 навыкам: распределённые системы и вычисления на Hadoop / Spark, а также SQL и проектирование схемы данных.