Привет! Меня зовут Антон Васильев, я работаю инженером технической поддержки компании Arenadata и нередко сталкиваюсь с довольно каверзными задачами и багами. Одной из них была проблема оптимизации механизма UPSERT в Greenplum 6. В этой статье я хочу рассказать, как эта задача может быть решена.

Меня зовут Антон Сорока, я математик и аналитик данных.

Я хотел бы рассказать об алгоритме, который выделяет кусочно-линейный тренд из временного ряда и сам определяет точки изменения тренда. Другими словами, это алгоритм для автоматического кусочно-линейного приближения любой функции. Это может понадобиться, если вам важно анализировать линейные тренды ряда, но единственная линия явно недостаточно точно описывает ряд, и самостоятельно искать точки, где тренд менялся, неудобно. Реализация этого алгоритма есть в open-source библиотеке для анализа изменений временных рядов, написанной на Python.

• возникла задача “сделать быстро хоть что-то, а потом посмотрим”;
• появился бурно развивающийся проект, с подключением новых источников и переделкой бизнес-модели минимум раз в неделю;
• появился заказчик, который не представляет как система должна выглядеть и какие функции выполнять в конечном итоге, но готов к экспериментам и последовательному уточнению желаемого результата с последовательным же приближением к нему;
• заглянул менеджер проектов с радостной вестью: “А теперь у нас аджайл!”.

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

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

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В этой лекции мы узнаем, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. Разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош, чем отличается Materialize от Memoize, а Gather Merge от "просто" Gather.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2).

Всем привет! Случались ли у вас ситуации, когда количество DAG’ов в вашем Airflow переваливает за 800 и увеличивается на 10-20 DAG’ов в неделю? Согласен, звучит страшно, чувствуешь себя тем героем из Subway Surfers… А теперь представьте, что эта платформа является единой точкой входа для всех аналитиков из различных команд и DAG’и пишут более 50 различных специалистов. Подкосились ноги, холодный пот и желание уйти из IT?

Не спешите паниковать, под катом я расскажу о том, как контролировать потребление ресурсов DAG’ов Airflow для предупреждения неоптимально написанных DAG’ов и борьбы с ними.

Меня зовут Давид Хоперия, я Data Engineer в департаменте данных Ozon.Fintech и моим основным инструментом является Apache Airflow, поэтому настало время углубиться в детали его работы.

Да, в этих ваших интернетах есть много материалов о том кто такой Data Engineer (DE), в том числе и на самом хабре. Но мне самому захотелось об этом рассказать. Опыт, хоть и небольшой, в этой сфере у меня есть (Сейчас Data Engineer в Сбер Образовании). 

ЭТА СТАТЬЯ НЕ ЯВЛЯЕТСЯ СУПЕР ТЕХНИЧЕСКОЙ, В КОТОРОЙ СТРОГО ВСЕ ПО НАУЧНОМУ. ТУТ Я ОБЪЯСНЯЮ ТЕМУ ПРОСТЫМ ЯЗЫКОМ (по другому не сумею)

Приветствую, current_user()!

Хочется тебе показать, как можно хранить sql-скрипты объектов БД так, чтобы было удобно и разработчику, и ревьюеру, а так-же рассказать о плюсах и минусах такого подхода.

Так-же хотелось-бы узнать твоё мнение о таком подходе и обсудить, возможно стоит что-нибудь добавить в нём.

В прошлой статье я показал, как условие с парой однотипных неравенств, плохо поддающееся индексации с помощью btree, можно переделать на эффективно gist-индексируемое в PostgreSQL условие относительно диапазонных типов, а наш сервис анализа планов запросов explain.tensor.ru подскажет, как именно это сделать.

Но что делать, если неравенств у нас не два, а целых четыре, да еще и с разными типами участвующих полей? Например, для целей бизнеса это может быть задачей вроде "найди мне все продажи за декабрь на сумму 10-20K", что на SQL будет выглядеть примерно так:

dt >= '2023-12-01'::date AND dt <= '2023-12-31'::date AND

sum >= 10000::numeric AND sum <= 20000::numeric

Я уже не раз писал, что условия с несколькими неравенствами (<, <=, >=, >) обычно плохо подходят для индексирования "классическим" btree, вызывают "тормоза", и необходимо придумывать различные нетривиальные подходы в PostgreSQL, чтобы добиться хорошей производительности подобного запроса.

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

WITH RECURSIVE numbers AS (SELECT 0 AS n UNION ALL SELECT n+1 FROM numbers WHERE n<89),
pixels AS (SELECT rows.n as row, cols.n as col FROM numbers as rows CROSS JOIN
numbers as cols WHERE rows.n > 4 AND rows.n < 38 AND cols.n > 9 AND cols.n < 89),
rawRays AS (SELECT row, col, -0.9049 + col * 0.0065 + row * 0.0057 as x,
-0.1487 + row * -0.0171 as y, 0.6713 + col * 0.0045 + row * -0.0081 as z FROM pixels),
norms AS (SELECT row, col, x, y, z, (1 + x * x + y * y + z * z) / 2 as n FROM rawRays),
rays AS (SELECT row, col, x / n AS x, y / n AS y, z / n AS z FROM norms),
iters AS (SELECT row, col, 0 as it, 0 as v FROM rays UNION ALL
SELECT rays.row, rays.col, it + 1 AS it, v + MAX(ABS(0.7+v*x) - 0.3,
ABS(0.7+v*y) - 0.3, ABS(-1.1+v*z) - 0.3, -((0.7+v*x) * (0.7+v*x) +
(0.7+v*y) * (0.7+v*y) + (-1.1+v*z) * (-1.1+v*z)) * 1.78 + 0.28) AS v
FROM iters JOIN rays ON rays.row = iters.row AND rays.col = iters.col WHERE it < 15),
lastIters AS (SELECT it0.row, it0.col, it0.v AS v0, it1.v AS v1, it2.v AS v2
FROM iters as it0 JOIN iters AS it1 ON it0.col = it1.col AND it0.row = it1.row
JOIN iters AS it2 ON it0.col = it2.col AND it0.row = it2.row
WHERE it0.it = 15 AND it1.it = 14 AND it2.it = 13),
res AS (SELECT col, (v0 - v1) / (v1 - v2) as v FROM lastIters)
SELECT group_concat(
substr('$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/|()1{}[]?-_+~<>i!lI;:,"^. ',
round(1 + max(0, min(66, v * 67))), 1) || CASE WHEN col=88 THEN X'0A' ELSE '' END, '')
FROM res;

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

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

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

Привет, Хабр! Когда заходет речь о поиске кратчайшего пути между двумя вершинами выбор обычно ложится на Дейкстре или Беллмана-Форда, однако есть ещё один алгоритм, который может сработать быстрее Беллмана, но не "сломается" на графах с отрицательными рёбрами.

Приятного чтения!

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

На связи участник профессионального сообщества NTA Максим Алёшин.

Сегодня создание интерактивной карты на python не составляет большого труда: стоит подключить библиотеку (например, Folium или Bokeh), указать картографический сервер, и после выполнения нескольких «магических» строк кода ваши данные как на ладони!

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

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

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

Сначала будет приведён алгоритм поиска паттернов рекуррентным перебором, потом его быстрая модификация с минимальным отсечением.

Примеры кода написаны на C++, исходники всей библиотеки лежат здесь. Также написана копия библиотеки на Java, исходники лежат здесь.

Продолжу рассказ "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap" секретами о геоданных OpenStreetMap, на которых множество компаний построили бизнес но не все делятся подробностями... Что ж, сегодня приоткроем завесу!

База данных в PosgreSQL после загрузки из дампа занимает больше 587 GB. Это уже по меркам СУБД большая база и одна огромная таблица на каждый тип объектов не сработает. Для управляемости такие данные надо секционировать, хорошо что PostgreSQL поддерживает декларативное секционирование данных. Осталось лишь придумать как разделить географические данные. После поисков и сравнений мне на помощь пришла иерархическая гексагональная геопространственная система индексирования H Все это было реализовано в моем проекте openstreetmap_h3 для быстрой обработки и загрузки мира в базу.