SQL *

Здравствуйте, дорогие друзья! Сегодня мы окунёмся в мир SQL запросов и рассмотрим различные подходы, которые разработчики используют для работы с данными в БД. В современном мире разработки, где информация становитесь все больше и больше, и скорость получения данных имеет большое значение, умение эффективно извлекать и обрабатывать данные становится неотъемлемой частью работы многих SQL специалистов (особенно тех кто работает с нагруженными системами и DWH). Мы поговорим о таких методах, как Common Table Expressions (CTE), подзапросы, представления и материализованные представления.

Enums VS Tables для создания типов моделей...

Зачем использовать вообще одно из этих решений?

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

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

Из документации ClickHouse не всегда легко сразу понять ценность функций для имплементации бизнес-логики, в частности, ценность функции runningAccumulate. Например, несмотря на богатые возможности runningAccumulate, неотформатированный код и имена вида k и sum_k из документации могут немного ввести в заблуждение.

Если Вам интересно рассмотреть state функции ClickHouse на паре примеров с более понятной логикой, то добро пожаловать :)

В статье рассмотрены примеры использования длинных (sapscript) текстов для построения шаблонов с использованием вложенности шаблонов, переменных и условных конструкций. Статья будет полезна для разработок рассылок на основе SAP NetWeaver, формирование печатных форм, рекомендательной/пояснительной документации.

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

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

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

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

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

Данная статья является четвёртой частью перевода руководства по повышению производительности Firebird за авторством А.Ковязина и Э.Грегорио от 23.05.2024 (и потому продолжается сквозная нумерация пунктов), а так же текстовой расшифровкой соответствующего видео.

Привет, Хабр! В аналитическом языке DAX одной из важных функций является SUMMARIZECOLUMNS. Эта функция готовит данные для дашбордов, также реализует декартово произведение полей группировки (если поля группировки из разных таблиц). Для понимания DAX полезно ознакомиться с особенностями SUMMARIZECOLUMNS, интересующимся деталями SUMMARIZECOLUMNS — добро пожаловать под кат :)

1. Тревожный звонок

Был хмурый лондонский вечер, когда в нашу скромную квартиру на Бейкер-стрит ворвался взволнованный инспектор Лестрейд.

— Холмс! Нам срочно нужна ваша помощь! — воскликнул он, сбрасывая с плеч дождевик. — В городе орудует хитрый вор. Он крадёт предметы, но уносит их только в одном рюкзаке ограниченной вместимости. Нам нужно вычислить, какие именно вещи он унесёт, чтобы максимизировать свою добычу!

Одним из этапов разработки витрин данных является тестирование результата и подтверждение корректности разработанного функционала. При этом организовано тестирование может быть по-разному.

Определим несколько видов тестирования:

1.     Технические тесты

Техническими тестами легко можно проверить корректность сборки витрины. Из основных видов технических тестов можно выделить:

·       Дубли - проверка на наличие дублей по ключу

·       Разрывы - проверка на разрывы в истории

·       Перекосы - проверка наложения исторических записей друг на друга

·       Даты - проверка корректности формирования дат

·       NULL в ключе - проверка NULL в ключевых и обязательных к заполнению полях

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

2.     Бизнес-тесты

Это набор тестовых запросов, направленных на выявление ошибок в бизнес-данных. Как правило набор бизнес-тестов предоставляет владелец объекта.

Бизнес-тестов может быть великое множество, здесь все зависит от вашего бизнес-домена и от конкретных требований к витрине.

Приведу примеры некоторых бизнес-тестов:

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

Штука получилась довольно продвинутая, с поддержкой императивщины типа циклов/ветвлений/переменных, и даже с поддержкой пользовательских процедур. И в плане этой самой императивщины расширяемая: может импортировать функции из Java classpath, равно как и операторы выражений. То есть, если необходимо, можно написать функцию на Java, или определить новый оператор, и использовать потом в любом выражении на SQL.

Круто? Ещё как круто. Но как-то однобоко. Если в языке у нас поддерживаются функции, то почему бы не дать нашим пользователям определять их самостоятельно? Вот прямо через CREATE FUNCTION? Тем более, что вся необходимая для этого инфраструктура уже вовсю присутствует. Да и процедуры на уровне интерпретатора у нас уже поддерживаются ведь…

Функция для затравки.

Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из ошибок, которые я совершил. Мой путь не является правильным и потому - судите "строго".

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

Сегодня поговорим про ретеншн — ту самую метрику, от которой часто пляшут все продуктовые команды. Вы знаете: «вернулся через 7 дней» (D7) — и сказано, что мы класс

Но на деле класс ломается, как только продукт усложняется. В этой статье рассмотрим, почему классический D7 retention не работает, как построить настоящие кривые удержания через когорты, в чём разница между recurring vs one-shot поведением, какие есть альтернативные метрики и сравним три метода.

На этот раз более простая и красивая визуализация. Речь пойдет о том, как нарисовать историю выполнения SQL Agent jobs — как раз тех, с которыми все время имеет дело DBA.

Выбор облачного хранилища данных — задача не из простых: десятки решений, каждая со своими плюсами и подводными камнями. В этой статье — результаты масштабного практического исследования, в ходе которого команда Agritask сравнила производительность, масштабируемость, стоимость и совместимость SQL ведущих платформ: от ClickHouse и BigQuery до Druid и Firebolt. Без маркетинговых обещаний — только реальные тесты, живые выводы и нюансы, которые неочевидны до момента внедрения.

Вам интересно, какие индексы используются больше или меньше? Какие не используются вовсе? Какие таблицы и индексы самые большие? Очень легко создать такие диаграммы. Это и красиво, и полезно.

BI-Ассистент для создания аналитических дашбордов и автоматизированного анализа данных

Привет, Habr! На связи Александр Сулейкин, Founder DUC Technologies и наша LLM-команда – Роман Бабенко и Александра Деведерова, а также Бутнев Даниил — аналитик, бывший сотрудник компании, являющейся центром компетенций по качеству и метрологии. Мы подготовили статью по возможному применению и созданию BI-ассистентов на базе LLM моделей для создания аналитических дашбордов. Данная сфера пока еще находится в зачаточном состоянии, развитие LLM для BI-решений только набирает популярность. В данной статье мы описали возможный кейс совмещения BI и LLM на примере реального Use Case в сфере метрологии.

1. Введение

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

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

Сегодня немного поговорим о здравом смысле. Правильном и неправильном API конфигурации java-библиотеки. В качестве примера будем использовать TrueSql.

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

Далее, для относительно сложных вариантов генерации SQL при изменениях бизнес-логики (или других изменениях) может измениться и сам динамически генерируемый SQL, причем результаты выполнения SQL могут остаться неизменными, однако производительность поменяется. В таких случаях изменения в производительности можно уловить при помощи бенчмарков, однако прогон бенчмарков может занимать значительное время, в связи с этим актуальна задача быстрого анализа изменений в производительности динамически генерируемого SQL. Интересны особенности анализа производительности приложения на основе SQL — добро пожаловать под кат :)

Привет, Хабр! Язык запросов DAX популярен и эффективен для построения дашбордов в Business Intelligence, и за счет свой функциональной природы DAX в чем-то ближе к реляционной алгебре, по сравнению с SQL. Особенности DAX удобно рассмотреть на основе примеров DAX-запросов, переведенных на реляционную алгебру. В частности, использование ALL в итераторе SUMX в рамках наиболее популярной DAX функции SUMMARIZECOLUMNS позволяет рассмотреть некоторые нюансы DAX. Если интересно описание ALL в DAX с точки зрения реляционной алгебры — добро пожаловать под кат! :)