SQL *

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

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

Уверен, что мой рассказ будет полезен не только пользователям Superset, но и всем аналитикам, которые используют SQL в своей работе и учёбе.

Не буду рассказывать про базовое построение таблиц на BI системе Superset, с этим прекрасно справятся тонны видео на ютубе и бесполезные курсы (про которые я писал ранее). Но сразу скажу, что суперсет в отличие от некоторых других BI систем начинает раскрываться только если ты знаешь SQL, так что хотим мы этого или нет – погружаться в тонкости языка придётся.

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

Итак, Что такое «Вес в приросте» и чем он отличается от обычного «Прироста», и в чем собственно говоря — сложность?

Разберёмся на примере:

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

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

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

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

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

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

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

-- library.tdl

CREATE PROCEDURE dwellTimeByMode(@signals, @target, @outPrefix,
  @modes = ['pedestrian', 'non_pedestrian', 'car', 'bike'],
  @groupid='cell10') AS BEGIN
    LOOP $mode IN $modes BEGIN
        SELECT * FROM $signals INTO "{$signals}/{$mode}" WHERE mode=$mode;

        CALL dwellTime(@signals_userid_attr=userid,
            @target_userid_attr=userid,
            @target_grouping_attr=$groupid
        ) INPUT signals FROM "{$signals}/{$mode}", target FROM $target
        OUTPUT INTO "{$outPrefix}/{$mode}";

        ANALYZE "{$signals}/{$mode}";
        ANALYZE "{$outPrefix}/{$mode}";
    END;
END;

--- ... --- ... --- ... ---

-- script.tdl

CALL dwellTimeByMode(@signals=$this_month, @target=$population, @outPrefix=$this_month);

Нафига это надо?

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

Unit of Work отслеживает все объекты, которые были загружены в память и изменены в ходе выполнения программы. Он управляет их состояниями и сохраняет изменения в базе данных в конце транзакции. Это делается с использованием сессий, которые действуют как контейнеры для всех изменений.

Когда работа завершена, Unit of Work выполняет commit для всех изменений, сохраняя их в базе данных. Если что-то пошло не так, выполняется rollback, и база данных возвращается в состояние до начала транзакции.

В данной статье рассмотрим, как реализовать паттерн Unit of Work с использованием SQLAlchemy.

В SQL server есть замечательная технология - AlwaysOn. Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload.

Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов).

Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.

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

Эта статья — небольшой гид по функциям работы с массивами в ClickHouse. Мы рассмотрим самые полезные и мощные инструменты, такие как arrayJoin, arrayMap, arrayFilter, и другие. Разберём, как их использовать для решения повседневных задач аналитики данных, на конкретных примерах.

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

Вам могут пригодиться array функции, когда стандартные SQL-запросы становятся сложными и трудными для понимания. Например, вместо использования множества подзапросов и объединений для отслеживания последовательности действий пользователя, вы можете использовать функции работы с массивами. Кроме того, использование функций позволяет фильтровать элементы внутри массива, избавляя от необходимости написания сложных условий в подзапросах. Функции работы с массивами в ClickHouse помогут сократить количество кода и упростить запросы, заменяя многократные подзапросы на более элегантные и читабельные решения.

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

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

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

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

На Хабре я часто вижу статьи о реализации тех или иных фич на Python-фреймворках. Я объединил все эти фичи в реальный проект с открытым исходным кодом, чтобы у вас сложилась целостная картина. Мы с вами создадим UX/UI на Figma, напишем фронтенд на HTML, CSS, SASS, Bootstrap и JavaScript, создадим ER-диаграмму в MySQL Workbench, напишем бекэнд на Flask, создадим регистрацию через социальные сети OAuth 2.0 в один клик, используем брокер сообщений и асинхронную очередь Celery для отправки писем на электронную почту, сделаем WYSIWYG-редактор, реализуем полнотекстовый поиск Elasticsearch, закешируем Redis, покроем тестами pytest и запустим в Docker-контейнерах, поговорим о многопроцессности для WSGI-шлюза Gunicorn.

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

Обязательно сохраняйте в закладки!

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

Реализовывать все это будем на Python и нам потребуются библиотеки.

Всем привет!

В прошлой статье мы с вами разобрались, как устроена MPP-архитектура Greenplum. Сегодня мы в сотрудничестве с @imzorin углубимся и разберемся, что представляет из себя DDL в этом хранилище. Также постараемся выделить основные моменты, на которые стоит обращать внимание при выборе типа таблиц, дистрибуции и прочего.

Написание запросов для решения аналитических задач — это основное занятие тех, кто работает с данными Pinterest. Но подбор подходящих данных и преобразование описания проблемы в корректный и эффективный SQL‑код могут оказаться непростыми делами. Ведь речь идёт о среде, которая быстро меняется, и о значительных объёмах данных, разбросанных по разным местам.

Недавно возникла потребность переместить данные из Bubble в Heroku, так как Bubble начал требовать много денег за хранение и доступ к большому кол-ву данных, поэтому было решено переместить данные проекта в Heroku.

В статье рассказано, как вам может помочь утка при работе с данными, с OLAP-нагрузкой и как она может плавать в вашем Data Lake. Вы узнаете всё самое важное про DuckDB и сможете попрактиковаться в работе с DuckDB.

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

Как вы поняли из названия, сегодня мы поговорим про авторизацию и аутентификацию. Прежде чем вы приступите к прочтению статьи, настоятельно рекомендую вам ознакомиться с прошлым материалом по теме разработки собственного API через FastApi.

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

Моя предыдущая статья неожиданно вызвала бурное обсуждение. Я решил вспомнить молодость (30 лет назад я подрабатывал переводчиком технической литературы) и перевести блог от компании JitBit с рекомендуемыми вопросами по SQL на собеседовании, с которого и началась предыдущая статья. На литературность перевод не претендует, все же я не писатель, я программист. Смайлики и маскирование слов сохранены как в оригинале.

Кто ходил на собеседования по устройству на работу, тот знает, спрашивают там всякое и странное. Нередко можно встретить задачу SQL по нахождению сотрудников с максимальной зарплатой в отделе. Причем ваш потенциальный начальник считает, что у этой задачи есть только одно «правильное решение», то, про которое он прочитал в Интернете. Так ли это?