SQL *

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

Если не видели дайджест за прошлый год — время наверстать упущенное!

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

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

В этой части немного поработаем с массивами.

Spring Data JPA считается швейцарским ножом для работы с БД в Java. Однако Spring Data JPA не заслуживает своего триумфа и вот почему...

Посчитаем по пунктам потенциальные грабли и проблемы, с которым встречается DBA на своем рабочем месте. Сколько получилось у вас? Отпишитесь в комментариях.

Привет всем!

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

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

P.S. Если автор что-то не разобрал и не написал, значит он посчитал это не обязательным в рамках этой статьи :-)

Будем разбирать примеры на такой небольшой таблице, где указана прибыль (net_profit) компании на каждый месяц в рамках одного года.

Привет, Хабр! В рамках Business Intelligence для расчета KPI и других статистических характеристик могут использоваться различные средства. Универсальным и мощным инструментом является язык DAX, в этой статье я хочу показать его преимущества на примере популярной задачи расчета коэффициента проникновения в Power BI.

Если интересна аналитика с DAX - то добро пожаловать! :)

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

В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).

После месяцев рутинного сканирования строк в структуры я решил: «Хватит это терпеть!» и психанув, создал обертку, которая:

✔ Автоматизирует скан — никаких rows.Scan(), просто передаете структуру
✔ Работает с любыми вложенностями — даже сложные JSON-поля парсятся без боли
✔ Не тормозит — минимальные накладные расходы, вся мощь pgx сохраняется
✔ Подходит для любого проекта — можно внедрять постепенно

👉 Это не просто библиотека — это мой ответ на боль всех gopher'ов!

Это вторая часть материала о финансовом стеке — теперь на уровне hard. В этой статье — не про SUM и диаграммы. Здесь речь пойдёт об ИТ-инструментах, которые помогают финансистам выйти за пределы ручной рутины, автоматизировать ключевые процессы и действительно влиять на бизнес.

Если вы уже уверенно работаете в Excel, пишете SQL-запросы и собираете отчёты — пора двигаться дальше. Power Query, витрины в SQL, архитектура BI, Python, API — всё, что позволит вам:

- ускориться в 3 раза,
- сократить рутину до минимума,
- стать архитектором аналитики, а не просто исполнителем.

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

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

В статье подробно разбирается план выполнения запроса с оконной функцией в MS SQL Server, проводится сравнительный тест производительности с альтернативным запросом.

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

Всем привет! Меня зовут Александр Андреев, я старший SRE дата-инженер и бывший BI/DWH-разработчик с многолетним опытом работы с BI‑платформой QlikView/Qlik Sense. В своей статье‑шпаргалке я хочу поделиться с вами практически всеми возможными вопросами и ответами с собеседований на должность Qlik‑разработчика. Данная шпаргалка гарантированно закроет 99% возможных вопросов на собеседованиях на позиции, где упоминается Qlik в качестве BI‑системы. Таких позиций с каждым годом все больше, причем знание Qlik в качестве BI‑системы требуют как с чистых «биайщиков», так и с дата‑инженеров на некоторых сеньорских и lead позициях.

Подготовка к собеседованию на позицию с QlikView/Qlik Sense в качестве BI‑системы требует глубокого понимания как базовых концепций, так и продвинутых техник работы с платформой. В этой статье я собрал 85 наиболее важных вопросов, которые помогут вам систематизировать знания и успешно пройти техническое интервью.

Привет! Меня зовут Кирилл Львов, я fullstack-разработчик в компании СберАналитика. В этой статье хочу рассказать про мощный инструмент трансформации данных — DBT (Data Build Tool).

Сегодня любой средний и крупный бизнес хранит множество данных в разрозненных источниках (CRM, ERP, HRM, базы данных, файловые хранилища и т.д.). Каждая из этих систем самодостаточна и закрывает определённую боль бизнеса, но собрав данные из таких источников и стандартизировав их, нам открывается возможность анализировать данные, строить модели машинного обучения и принимать на основе этих данных управленческие решения. Для того чтобы реализовать такой подход строятся ELT (или ETL) процессы. ELT (Extract, Load, Transform) — это процесс, состоящий из трех этапов:

Привет, Хабр! Это Ахмед Шериев, сооснователь стартапа VoxOps, а сегодня — еще и гостевой автор блога Friflex. Моя статья — про опыт разработки офлайн-приложений. 

Я делал офлайн-поддержку в приложениях на самых разных языках. Как вовремя и успешно, так и с факапами. Например, обещал за две недели внедрить офлайн, а потом появлялись скрытые кейсы, и разработка затягивалась до месяца, двух, трех… 

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

Я внедрял поддержку offline как в роли разработчика, так и в роли руководителя и директора по разработке. Поэтому тема мне хорошо знакома с обеих сторон. Кто помнит, с ней я выступал на CrossConf.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

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

Мы воспользуемся FastAPI для бэкенда, React для фронтенда, заставим их между собой общаться через RESTful API, а бизнес-логику реализуем путём обращения к ИИ через gRPC.

В мире данных изменения — это неизбежность. Но как отслеживать и сохранять историю изменений, чтобы аналитика оставалась точной и релевантной? В нашей новой статье мы подробно разбираем концепцию медленно меняющихся измерений (Slowly Changing Dimensions, SCD) — ключевого инструмента для работы с изменяющимися данными в хранилищах и аналитических системах.

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

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

В этой статье рассмотрим тему кастомных lookup-операторов в Django ORM. Они позволяют расширить стандартный синтаксис Django, интегрируя свои SQL-функции и алгоритмы, при этом сохраняя привычный вид фильтрации.

Привет, Хабр! Популярным аналитическим языком является DAX, и он используется во множестве проектов. Соответственно, значительная часть бизнес-логики дашбордов реализована на DAX, и при переходе с Power BI на другой продукт требуется время на перевод DAX логики из Power BI. В связи с этим актуальны инструменты расширения списка платформ, на которых можно использовать DAX без Power BI.

Тем, кто интересуется «переводом» DAX на PostgreSQL — добро пожаловать под кат :)

Миф о чистых данных: почему ваш аналитик похож на сапёра.

Как бороться с самым частым убеждением при работе с данными.