Хотя концепция "умного дома" в полном объёме мало кем используется в жизни (и ещё меньше кем самостоятельно реализована), отдельные его компоненты - разного рода датчики, умные розетки, камеры и прочее, с доступом через "облако" - давно не редкость. До покупки дачи меня всё это слабо волновало - в квартире я вполне обходился механическими выключателями и градусником на окне. Тем не менее, необходимость следить за состоянием загородного дома вынудила заняться этим вопросом и я пошёл по самому простому пути с MiHome и кучей датчиков. Конечно, в нём хватает проблем - баги, которые не устраняют годами, датчики для разных регионов, периодически [кратковременно] отваливающееся облако. В целом, однако, всё это удовлетворительно работает уже не первый год, технического интереса не представляет и рассказать я хотел не об этом.

Вопрос, который меня всерьёз стал беспокоить уже на вторую зиму ((а именно зима - самый проблемный сезон) - необходимость в резервном решении на случай, если информация от MiHome перестанет поступать и надо будет решать - нужно ли срочно ехать и топить/чинить дом или можно ещё подождать, пока проблема сама рассосётся. Основных причин прекращения поступления информации три:

Для запуска и эксплуатации высоконагруженных ИТ-решений с петабайтами данных в активе, нужно проработанное решение, позволяющее гибко управлять ресурсами. Одним из критичных аспектов этого решения, является разделение Compute & Storage — разделение ресурсов инфраструктуры под вычисление и хранение соответственно. Если не реализовать такое разделение в крупном проекте, инфраструктура рискует превратиться в «чемодан без ручки» — эффективность использования ресурсов будет низкой, а сложность управления ресурсами и средами будет высока. На примере команды SberData и их корпоративной аналитической платформы я расскажу, когда требуется разделение Compute & Storage и как это реализовать максимально нативно.

Статья подготовлена по мотивам доклада на VK Data Meetup «Как разделить Compute & Storage в Hadoop и не утонуть в лавине миграций».

Гуд ньюз эвриван! Вышло большое обновление учебника «100-Year QA‑Textbook — русскоязычная версия» — одного из самых полных источников по тестированию.

С момента первого релиза (100'000 хабр‑просмотров!) прошло полгода.
За это время столетний учебник стал бесплатным пособием для 10'000+ самообучающихся студентов.

11 апреля 2024, после всех переносов, ракета Ангара А5 с разгонным блоком Орион, она же «Ангара тяжелая», стартовала с космодрома Восточный. Пресс центр Роскосмоса не смог нормально описать ни орбиту, ни как дела, ни что за блок Орион — анонам пришлось самим искать информацию:

— Запуск ракеты Ангара — неделю спустя,
— Разгонный блок Орион от Ангары на нужной орбите.

После выхода на какую‑то, условно «опорную» орбиту, хотя это и не она, от РН отделилась попутная нагрузка в виде 3 микро — нано — спутников, и разгонный блок с макетом чего надо. Макет и блок должны были оказаться на орбите захоронения — 200 километров выше геостационара или чуть больше.

Для аналитиков, владение SQL — это база. И от познаний в SQL зачастую зависит, отправит ли вам компания, где вы собеседуетесь — оффер.

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

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

В предыдущих сериях (FAQ • 1 • 2 • 3 • 4 • 5 ) мы весьма подробно рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL поверх Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

В данной части поговорим о том, как добавить в выражения SQL поддержку функций. Например,

SELECT
    MAX(score1, score2, score3, score4, score5) AS max_score,
    MIN(score1, score2, score3, score4, score5) AS min_score,
    MEDIAN(score1, score2, score3, score4, score5) AS median_score,
    score1 + score2 + score3 + score4 + score5 AS score_sum
FROM raw_scores INTO final_scores
WHERE ABS(score1 + score2 + score3 + score4 + score5) > $score_margin;

— тут у нас функции MAX, MIN и MEDIAN принимают любое количество аргументов типа Double и возвращают Double, а ABS только один такой аргумент.

Вообще, кроме общей математики, в любом уважающем себя диалекте SQL как минимум должны быть функции для манипуляций с датой/временем, работы со строками и массивами. Их мы тоже обязательно добавим. В classpath, чтобы движок мог их оттуда подгружать. До кучи, ещё и операторы типа >= или LIKE, которые у нас уже были реализованы, но хардкодом, сделаем такими же подключаемыми.

Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут. 

Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти.

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

Airflow в Lamoda Tech играет роль оркестратора процессов обработки данных. Ежедневно с его помощью мы запускаем 1 800+ тасок на проде, примерно половина из которых являются Spark-приложениями.

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

Меня зовут Андрей Булгаков, я лид команды разработчиков Big Data в Lamoda Tech. Вместе с разработчиком Иваном Васенковым в этой статье мы поделимся историей создания Airflow-оператора для запуска Spark-приложений.

Это мой вольный перевод статьи "Why You Should Start Writing Spark Custom Native Functions", которая вдохновила меня на некоторые собстенные изыскания по данной теме. Их результат я планирую опубликовать позже, а пока выношу на ваш суд этот перевод.

Статья на примере реализации функции по генератации UUID рассматривает, как писать Spark native функции, которые были бы "прозрачны" для Catalyst (в отличии от UDF, которые являются "черными ящиками" для него). Сравнение производительности ожидаемо показывает, что Catalyst Expressions значительно превосходят UDF при увеличении размера данных.

Кому интересно узнать, как писать Spark native функции - прошу под кат.

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

Давайте ненадолго перенесёмся в школьные годы и вспомним уроки математики и физики. Помните, чему равно число π? Естественно, помните, мы же на Хабре! А чему равно π в квадрате? Это тоже странный вопрос. Конечно, 9,87. А чему равно ускорение свободного падения g помните? Ещё бы, это число так тщательно вдолбили в нашу память, что захочешь — не забудешь: 9,81 м/c². Конечно, оно может варьироваться, но для решения базовых школьных задачек мы обычно использовали именно это значение.

А теперь, внимание, следующий вопрос: а с какого это перепугу π² примерно равно g?

Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.

Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.

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

Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".

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

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

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

Различные СУБД предлагают широкий набор разновидностей операторов JOIN для таблиц. Если Вам встретилась проблема с производительностью CROSS JOIN, - например, декартово произведение таблицы с миллионом записей самой на себя, - добро пожаловать, в этой статье перечислены простейшие способы избавиться от CROSS JOIN.

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

Примеры в статье рассматриваются на основе CROSS JOIN из ClickHouse. Текущая версия ClickHouse не оптимизирует CROSS JOIN автоматически. Также стоит отметить, что поскольку часто SQL запросы не пишутся вручную, а, например, собираются по частям программно, то перечисленные далее случаи вполне реальны.

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

Изучаем оптический SFP трансивер. Рассматриваем его внутреннее устройство, элементный состав, электрические подключения. Для закрепления материала попробуем отправить и принять сообщение по оптоволокну, используя платформу Arduino.

Сначала запрос адаптирован для работы в PostgreSQL 15.6.

Затем работа запроса проверена на достаточно объемной иерархии - в качестве источника данных использована структура архива jdk-master.zip из OpenJDK 22