Привет! Меня зовут Маша Сафронова, и я уже почти 3 месяца работаю младшим продуктовым дизайнером в Lamoda Tech. За последний год я успела пройти стажировку и поработать в двух других крупных IT-компаниях, а еще раньше я переучилась и пришла в дизайн из другой профессии. 

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

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

Прошлая статья «Работаем с Git: первые шаги в GitHub» была посвящена установке, настройке Git и классическим операциям из набора для новичков GitHub. А теперь перейдём к практике и рассмотрим «горячие» сценарии, которые делают трудовые будни куда веселее. Или не очень.

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

Мы в beeline cloud не только создаем современные цифровые продукты, но и обучаем разработке в облаке студентов нашего курса Base Cloud DevOps. Однако выстроить эффективный процесс невозможно без знания основных инструментов. Один из них — система контроля версий Git. Перевели для вас статью, которая поможет извлечь из работы с этой утилитой еще больше пользы.

Когда-то я и не задумывался о существовании каких-то правил для составления комментариев к коммитам, но потом любознательность взяла верх. Мне казалось, что простых сообщений наподобие «добавлена функция 2», «исправлена ошибка на панели навигации» или просто «foo» вполне достаточно. Однако моя уверенность в том, что комментарии к коммитам, как правило, никто не читает, оказалась ошибкой. Хорошо составленные commit messages очень важны, они помогают нам самим в будущем извлечь максимальную пользу из своих стараний и продуманности.

Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., но надеюсь, она даст базовое представление о видах СУБД и принципах их работы.

В статье мы рассмотрим следующие типы баз данных:

Аналитические системы должны эффективно обрабатывать сложные пользовательские запросы к десяткам и сотням терабайт данных (пета-?). Продвинутый оптимизатор запросов является важнейшим компонентом любого big data движка. В данной статье мы рассмотрим, как устроен оптимизатор запросов в массивно-параллельном аналитическом SQL-движке Trino.

Привет, Хабр! Меня зовут Максим Кита, я разработчик баз данных, специализируюсь на анализе, планировании и выполнении запросов, а также на оптимизации производительности.

Я расскажу о высокоуровневой архитектуре ClickHouse, CI/CD, тестировании производительности, интроспекции, абстракциях и алгоритмах и выборе библиотек для высокопроизводительных приложений. Поделюсь ниндзя-техниками, которые помогут ускорить ваши системы. Вы сможете попробовать эти советы и практики на своем проекте и оценить насколько они полезны.

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

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

В интернете существуют много однотипных статей иллюстрирующих базовое использование материализованных представлений (далее - матвью) на движке AggregatingMergeTree, но если ваша задача выходит за рамки “1 нода, 1 метрика, 1 параметр агрегации” эти статьи вам мало чем помогут. Я посчитал, что моим коллегам может пригодиться своего рода гайд о том, как пользоваться данными представлениями для более сложных задач.

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

В рамках моей задачи хранилище данных (далее - DWH) реализовано в виде реплицированного кластера состоящего из 3 нод, данные на ноды распределяются равномерно в соответствии с ключом сортировки таблиц. Существует исходная таблица source, которая содержит столбцы id, timecode_1, metric_data - данные представляют собой временной ряд утилизации ресурсов с гранулярностью 1 минута. Данные поступают блоками каждые 2 минуты.

С увеличением спроса на операции, которые требуют больших объемов записи, традиционные базы данных, использующие B-дерево, становятся узким местом, поскольку обновление записей в b-дереве приводит к многочисленным беспорядочным операциям ввода-вывода (IO) и обновлению нескольких страниц на диске. B-дерево очень хорошо подходит для "тяжелых" операций чтения. Для операций с большими объемами записи у нас есть LSM-дерево.

Давайте попробуем понять, что такое LSM-дерево, как оно работает на самом деле.

В прошлой статье мы рассмотрели количество партиций, которое по умолчанию создается Apache Spark при инициализации DataFrame, DataSet. В текущей статье продолжим рассматривать количество партиций у Spark DataFrame и DataSet, созданных на основе таблицы в Relational Database.

Привет! В рамках своей работы в beeline tech мы часто взаимодействуем с геоданными. Для решения проблем, связанных с хранением, обработкой и анализом большого объема распределенных пространственных данных, мы используем Apache Sedona (бывший Geospark). Мы — Денис Афанасьев, аналитик больших данных, и Женя Рыбалкин, инженер больших данных, под катом расскажем, почему выбрали именно этот инструмент и что он умеет. А чтобы показать, зачем вообще работать с геоданными, давайте возьмем пример расчета посещаемости хоккейных матчей в Москве, как-никак плей-офф в разгаре.

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

Следствием такого развития, как в количественном, так и в качественном плане, стал ощутимый рост того объёма данных, который все эти устройства генерируют. Ну и что нам с ними делать? Давайте разберемся на примере геоданных!

Зачем вообще кому-то нужны геоданные?

Всем привет!

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

Меня зовут Вадим Опольский и я работаю data-инженером и участвую в проведении онлайн-тренингов. В статье есть ссылки на воркшопы, чтобы повторить практические вещи из Apache Flink, о которых я расскажу. А обсудим мы следующие проблемы:

➜ Неравномерный поток данных;

➜ Потери данных при передаче их из Kafka в storage;

➜ Масштабирование и скейлинг;

➜ Backpressure;

➜ Мелкие файлы на HDFS;

➜ Стриминговый процессинг.

Александр Ледовский, тимлид команды аналитики и DS в Авито, рассказал про опыт работы с Apache Spark и о том, как правильно задавать параметры Spark-сессии, чтобы получить ресурсы.

В предыдущей статье я рассказал, как организовать систему распределенного машинного обучения на GPU NVidia, используя язык Java с фреймворками Spring, Spark ML, XGBoost, DJL в standalone кластере Spark. Особенностью поставленной задачи являлось организация системы под управлением ОС Windows 10 Pro, в Docker‑контейнерах. Эксперимент оказался не вполне успешным. В данной статье я покажу, как воспользоваться имеющимися наработками и запустить Spark Jobs в Kubernetes в режимах client и cluster, опишу особенности работы с Cassandra в Spark, покажу пример обучения модели и ее дальнейшего использования. В этот раз буду использовать язык Kotlin. Репозиторий с кодом доступен на GitLab.

Данная статья представляет интерес для тех, кто интересуется системами Big Data и стремится создать систему, позволяющую, в том числе, выполнять задачи распределенного машинного обучения на Spark в Kubernetes, используя GPU NVidia и Cassandra для хранения данных.

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

Для такой операции, в MongoDB штатно предусмотрена функция $sample, которую можно использовать в составе pipeline при проведении агрегации данных. Однако, как показала практика, выполнение выборки полей таким образом на большой коллекции может занимать весьма ощутимое время. Чтобы сократить время выполнения таких выборок, потребовалось разработать собственный алгоритм, который на порядки увеличил скорость работы. Ниже приведен подход и вариант реализации данного алгоритма.

Инженеры данных (англ. data engineer) готовят данные для анализа, машинного обучения и других целей. В деталях это означает множество операций с данными: сбор, хранение, обработка, интеграция, трансформация и представление в нужной для работы приложений и систем форме.

Из краткого определения сложно понять нюансы профессии и тем более захотеть стать инженером данных. Поэтому мы с коллегами собрали мифы о data engineering и выделили наиболее популярные.

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