SQL *

ИЩЕМ ЗАМЕНУ КОФЕИНУ с помощью ChatGPT

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

Я попросил помощи у ChatGPT и он успешно создал очень сложную таблицу с легальными аналогами кофеина и даже с вычисляемым столбцом на основе НЕЧЁТКИХ критериев (если вы это сможете на SQL - Вы гений!), но плохо справился с сортировкой в этой таблице.

Внимание: ниже изображение, ссылки некликабельные. Я ничего не продаю.

В первом цифровом столбце не удалось отсортировать числа по убыванию. Пытался примерно 15-20 минут. Пробовал разные промпты и пояснения. Это странно.

Этот инструмент (ChatGPT) отлично понимает команды манипуляции таблицей, в данном пример я попросил создать таблицу на основе данных с крупных магазинов, указал какие столбцы нужны и какая в них должна быть информация, указал порядок столбцов, в том числе относительный, типа столбец с такими данным добавь перед таким-то столбцом.

ChatGPT смог создать СВОДНЫЙ столбец на основе ранее созданных столбцов.Это столбец со взвешенными суммами весов веществ в других столбцах и коэффициенты взвешивания ОН сам нашел и нашел весьма точно.

Причем для каждого продукта ОН смог найти состав веществ по определенным критериям и перечислил их, создав отдельный столбец. Не все вещества, а только по определенным фильтрам (только такие, которые не являются кофеином, но оказывают воздействие, сходное с действием кофеина. Попробуйте самостоятельно без ИИ запрограммировать такой запрос на SQL с учетом нечеткого критерия схожести воздействия и еще определите коэффициент похожести для создания взвешенной суммы масс веществ в порции БАД.

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

Топ вопросов на собеседованиях по SQL. Что вам точно нужно знать для получения оффера?

Знание SQL — мастхэв при работе с базами данных в большинстве современных компаний. У нас в Сравни дата-специалисты используют SQL, взаимодействуя с множеством технологий и инструментов, от Snowflake, Greenplum и ClickHouse до Superset. При найме стажёров в наши технические команды, тестовое задание в большинстве случаев включает в себя проверку знаний по SQL.

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

Чтобы помочь вам с этим, наш дата-инженер Владимир Шустиков подготовил цикл из 5 видео, в которых рассмотрел ключевые вопросы об SQL на собеседованиях. Материал составлен по мотивам прохождения десятков собеседований в ИТ-команды компаний. С его помощью можно не только подготовиться к интервью (как морально, так и практически), но и проверить себя: сопоставить свои знания про SQL с тем, что на самом деле ожидают от специалиста. 

Полезно будет дата-инженерам, аналитикам, а также бэкенд-разработчикам. 

Каждое видео посвящено отдельному блоку вопросов по SQL:

1. Топ вопросов на собеседовании по SQL — порядок выполнения запроса, виды команд, типы данных

• YouTube

• RUTUBE

2. Топ вопросов на собеседовании по SQL — логические и физические виды JOIN, оконные функции, EXPLAIN

• YouTube

• RUTUBE

3. Топ вопросов на собеседовании по SQL — NULL, Агрегация

• YouTube

• RUTUBE

4. Топ вопросов на собеседовании по SQL — задачи на JOIN, различие между TRUNCATE, DROP, DELETE

• YouTube

• RUTUBE

5. Топ вопросов на собеседовании по SQL — WHERE, HAVING, QUALIFY; подзапросы и CTE; сочетания запросов

• YouTube

• RUTUBE

Смотрите, углубляйте свои знания в SQL, получайте офферы!

ТГ-канал нашего инженерного сообщества Sravni Tech

Всем привет! Совсем недавно в ИТ-инфополе снова активно заговорили о супераппах и их развитии.

Что такое суперапп?

Суперапп — это мобильное приложение, объединяющее множество сервисов и функций в одном месте. 

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

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

1️⃣ Неоспоримым преимуществом является синергия и обширная база пользователей. Даже новым фичам и продуктам внутри супераппа практически не стоит беспокоиться о том, откуда взять трафик. Например, “Самокаты” были запущены сразу в рамках Яндекс Go, поскольку там уже находилась целевая аудитория этого сервиса.

2️⃣ Супераппы генерируют море данных о самых разных аспектах жизни пользователей, и для аналитика это – рай! У вас будет возможность анализировать поведение пользователей в комплексе, выявлять скрытые взаимосвязи и находить инсайты, которые невозможно получить, работая в компании, специализирующейся на одном узком направлении. Это просто кладезь для персонализации, настройки рекомендаций и CRM-коммуникаций. 

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

Но есть и другая сторона.

1️⃣ Бешеная конкуренция за ресурсы. Пиксели на экране супераппа не бесплатны. Вашей команде придется часто толкаться локтями с коллегами и доказывать, что ваш продукт достоин быть первым в выпадающем списке, не скрываться за скроллом и т.д. Аналитикам регулярно нужно доказывать эффективность каждого сервиса в рамках приложения. И порой это скатывается в бюрократию, приводящую к топтанию на месте. 

2️⃣ Сложность атрибуции эффектов. В рамках супераппа каждая команда хочет оценивать своё влияние, и здесь перед аналитиком встает логичная задача: как и к кому атрибуцировать активность пользователей. На рынке существует много практик (last/first click, position-based и т. д.), но внедрить и обосновать конкретную методологию — крайне непростая задача, а спрогнозировать и доказать долгосрочное влияние, чтобы положить его в цели/бюджеты... ну, вы поняли)

3️⃣ Всегда необходимо учитывать влияние новых решений на другие продукты и сервисы, входящие в экосистему супераппа. Например, оценивать, как размещение точки входа в ваш продукт на главной странице повлияет на остальные продукты, и в случае негативного влияния предоставить аргументы и цифры, нивелирующие его. Это требует включения “helicopter view” — понимания взаимосвязией сервисов, ключевых метрик, процессов и инструментов на уровне всей платформы.

А что вы думаете, какой опыт интереснее и ценнее: в больших мультикатегорийных сервисах или в командах, сфокусированных на одном сервисе/продукте?

Еще больше про аналитику в td data dreamen

В конце прошлого года Группа Arenadata выпустила обновления ряда своих продуктов.

Новые релизы:

• Arenadata DB (ADB) — v6.27.1.59;

• Arenadata DB Backup Manager (ADBM) — v2.3.2;

• Arenadata DB Control (ADBC) — v4.11.0;

• Arenadata Streaming (ADS) — v3.6.2.2.b1;

• Arenadata Catalog (ADC) — v0.8.0;

• Arenadata Cluster Manager (ADCM) — v2.5.0.

Обновления компонентов Arenadata Cluster Manager (ADCM):

• Arenadata Monitoring (ADM) — v4.1.0;

• Arenadata Enterprise Tools (ADET) — v2024121800.

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

⛓ Текст обзора и ссылки на полное описание релизов здесь.

Учим SQL с помощью «Игры в кальмара». Вышел занимательный учебник, где нужно стать частью Организации Squid Game и помогать в подготовке Игр с помощью SQL.

Вы только что были приняты на работу в качестве Data Scientist в таинственную организацию Squid Game. Фронтмен, управляющий Squid Games, пообещал вам полностью удаленную работу. Но, как это обычно бывает в индустрии, вас подставили и обманули. Оказалось, что роль больше связана с аналитикой продуктов на SQL, а работа не полностью удаленная, а гибридная: 5 дней в офисе, 2 дня удаленно. Вы даже не успели пожаловаться на эту работу, как фронтмен приставил к вашей голове пистолет и начал требовать ответы на различные бизнес‑вопросы. Вы должны написать SQL‑запросы, чтобы ответить ему — иначе пуля.

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

Представляем YDB DWH — компонент для аналитической обработки данных в СУБД Яндекса

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

Система горизонтально масштабируется за счёт шардирования — автоматического партиционирования по объёму и нагрузке, — а также обеспечивает быстрое выполнение запросов благодаря массивно‑параллельной архитектуре (МРР).

Аналитическая функциональность компонента YDB DWH включает колоночные таблицы с консистентным хранением данных и управление смешанной нагрузкой. В платформу СУБД Яндекса также входит движок выполнения запросов со спиллингом данных на диск, стоимостный оптимизатор, федеративные SQL‑запросы к внешним источникам данных (S3, PostgreSQL, Greenplum, Oracle, Microsoft SQL), что позволяет создавать корпоративные хранилища данных. В планах реализация поддержки SQL-диалекта PostgreSQL для интеграции как в OLAP‑, так и в OLTP‑сценарии.

Платформа распространяется по коммерческой лицензии. Её можно и установить в собственной инфраструктуре (on‑premise), и использовать как управляемый сервис в Yandex Cloud.

Подборка для аналитиков по работе с SQL

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

Типы данных SQL — что о них нужно знать начинающему аналитику. Разбираем, какими они бывают и как с ними работать.

Таблицы в SQL: типы и операции — различные типы таблиц и основные операции, которые можно выполнять над ними.

SQL-запросы — основные команды для управления базами данных.

Оконные функции в SQL — что это и как использовать.

Основные ошибки SQL — список распространённых ошибок в работе с запросами баз данных SQL и лучших практик, о которых забывают некоторые пользователи. Рассказываем, как найти ошибки и исправить их.

Потренироваться и решить 70 задач в тренажёре можно на бесплатном курсе «Основы работы с базами данных и SQL».

Зачастую бизнес‑объекты в информационных системах хранятся в классических реляционных базах данных, где каждому атрибуту объекта соответствует колонка в таблице.

Чтобы изменить такую объектную модель, например, добавить или удалить атрибут, нужно внести изменения в схему базы данных, то есть выполнить DDL‑операцию. Она сопровождается блокировками таблиц и увеличением времени простоя при работе с данными. Кроме того, при увеличении числа атрибутов можно превысить ограничение на количество колонок в таблице. Например, в Postgres их можно создать не более 1600.

Эти проблемы можно устранить, используя хранение данных в формате JSON. Основные преимущества такого подхода:

• отказ от фиксированной структуры таблиц;

• гибкость без необходимости изменения схемы.

Обращение к динамическим полям может осложниться при работе с Hibernate до версии 6.2. Более ранние версии не позволяют обращаться к полям внутри JSON на уровне HQL, что ограничивает возможности фильтрации и сортировки. Поэтому оптимальный вариант — использовать Native SQL. Hibernate позволяет регистрировать SQL‑функции, чтобы вызывать их из HQL‑запросов. Пример регистрации такой функции для Postgres приведен ниже:

registerFunction("jsonQuery",
    new SQLFunctionTemplate(StandardBasicTypes.STRING,
        "jsonb_path_query_first(?1, ?2)::varchar"));

• Первый параметр — колонка в БД, внутри которой хранится JSON, выполняющий запрос.

• Второй параметр — запрос в виде JSON Path, который позволяет добраться до определенных полей.

Пример структуры JSON и использования на ней SQL-функции в запросе:

{
  "CPU_Brand": "Intel",
  "CPU_Model": "Xeon 8380",
  "RAM_Size_GB": 64
}

SELECT obj.id
FROM userObject obj
WHERE jsonQuery(obj.json, '$.CPU_Brand') = 'Intel'

При работе с более сложными вещами, например, фильтрация объектов с вложенными данными, SQL Server требует применения конструкций CROSS APPLY и openjson.

Пишем эффективные аналитические запросы: третья лекция курса в МГТУ им. Баумана

Третья лекция нашего курса «Deep dive into SQL and DWH» прошла 21 ноября — делимся видеозаписью!

Дата-архитектор Павел Ковалёв рассказал о внутреннем устройстве систем Greenplum и Clickhouse и возможностях, которые они предоставляют с точки зрения оптимизации запросов.

Посмотреть запись можно здесь:

• YouTube

• RUTUBE

• VK

Оставшиеся два занятия курса пройдут в формате очной практики. Видеозаписи трёх прошедших лекций доступны в отдельном плейлисте.

Пишем эффективные аналитические запросы: вторая лекция курса в МГТУ им. Баумана

Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.

Вторая лекция прошла 14 ноября; предлагаем посмотреть её видеозапись.

Внутри — обзор инструментов построения DWH/Data Lake, в том числе: Hadoop, Spark, Trino, Databricks, Amazon Athena, Amazon Redshift и Google BigQuery.

Посмотреть можно здесь:

✅YouTube

✅RUTUBE

✅VK

Следующая лекция курса будет посвящена техникам оптимизации аналитических SQL-запросов и состоится уже в ближайший четверг, 21 ноября, с 17:25 до 19:00.

Присоединяйтесь в зуме!

Пишем эффективные аналитические запросы: первая лекция курса в МГТУ им. Баумана

Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.

Первая лекция прошла 7 ноября — предлагаем посмотреть её видеозапись.

Внутри лекции:

• Обзор основных понятий курса (OLTP и OLAP, хранилище данных, его базовые слои, архитектуры обработки данных и т.д.)

• Устройство DWH — на примере компании Сравни

• Основы оптимизации аналитических SQL-запросов

• Как решать проблемы с неэффективными запросами: практические кейсы

Посмотреть запись можно здесь:

✅YouTube

✅RUTUBE

✅VK

Следующая лекция курса, посвященная архитектурному обзору инструментов для построения DWH, пройдёт уже в ближайший четверг, 14 ноября, с 17:25 до 19:00. Присоединяйтесь в онлайне!

***

Больше информации о наших лекциях, митапах, статьях и других полезных материалах про ИТ, в тг-канале Sravni Tech.

Привет! Я — Ося, разработчик в Инновационном Центре «Безопасный транспорт», ваш виртуальный проводник в мир технологий и разработки. В блоге рассказываю, как решаю сложные задачи и делюсь знаниями. Здесь мы будем разбираться в коде, обсуждать подходы к проектам и актуальные тренды в IT. Пишу о разработке, больших данных и инновационных технологиях.

Я — робот-осьминог и талисман ИЦ, который иллюстрирует разносторонность и многозадачность нашей команды. Мои 8 щупалец представляют различные направления работы, а 3 сердца обеспечивают высокую эффективность. Отсутствие скелета позволяет гибко адаптироваться к изменениям, а более 1000 рецепторов на щупальцах помогают мне воспринимать малейшие колебания в окружении.

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

Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99% — Кирилл Грищук

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

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

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/qHW9

Сделал Неовим-плагин, для работы дбт-моделями. Пока реализованы несколько сценариев:

• запуск модели;

• полный перезапуск модели;

• компилирование модели с выводом в новый буфер;

• генерация yaml-описания модели с выводом в новый буфер;

• отображение зависимостей модели в Телескопе.

Установка и доступные команды доступны в репозитории. Если есть пожелания и рекомендации — пишите в гит или телеграм.

Чем дольше копаю тему статистического анализа производительности СУБД, тем больше удивляюсь - почему никто не занимался/не занимается использованием математических методов в DBA ? Статей и материалов практически - нет. По performance engineering - можно найти, по DBA в общем то тишина.

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

Это же так просто и в общем то лежит на поверхности - сделал изменение , собери статистику влияния и оцени характер полученных результатов по совокупности опытов. Нужно подчеркнуть - не картинки, не "кажется" , "наверное" , "скорее всего", "может быть" , а цифры. И цифры взятые не с потолка , а рассчитанные математически. И даже не надо ничего нового придумывать и изобретать - медиана, мода , стандартное отклонение , дисперсия , корреляция - 3й курс КАИ, если не ошибаюсь. Вполне достаточно , для получения объективных результатов анализа, а не гаданий и шаманских танцев с бубнами.

Почему DBA не используют математику ? Риторический вопрос ....

О способе оценки производительности отдельного SQL запроса .

В дополнении к теме:

Размышления о мониторинге производительности отдельного SQL запроса

Для возможного варианта решения задачи:

https://habr.com/ru/posts/833162/

если производительность отдельного SQL запроса в настоящее время не мониторится.

Предположение.

Для того, чтобы оценить производительность отдельного SQL запроса необходимо и достаточно получить отношение стоимости запроса (EXPLAIN ANALYSE) к актуальному времени выполнения запроса .

Важное следствие и ограничение:

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

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

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

Друзья! У Петра вышло продолжение серии обзорных статей про ClickHouse — open-source OLAP базу данных, ориентированную на колонки. В новой статье наш DevOps-инженер рассказывает про особенности репликации в этой СУБД.

Из этой части вы узнаете:

• как работают сервисы координации Zookeeper и ClickHouse Keeper;

• по какой причине может произойти падение репликации;

• почему не следует очищать Keeper вручную.

Чтобы вспомнить, о чём Пётр рассказывал в первой части — нажмите сюда.

А чтобы ознакомиться с новой частью — сюда.

В продолжении темы - "время отклика СУБД" https://habr.com/ru/posts/827054/

Метрику не имеет смысла использовать для алерта о деградации производительности СУБД .

Допустим имеется OLTP нагрузка на СУБД - большое количество коротких запросов. В результате, имеем некоторое значение метрики "Среднее время отклика" = sum(total_exec_time) / sum(calls).

И вот , ситуация изменилась - запросов OLTP стало меньше , но появились аналитические/долгие запросы .

В результате значение метрики увеличивается - запросов стало меньше , общее время выполнения увеличилось.

Является ли данная ситуация алертом для создания инцидента о деградации производительности СУБД ?

Конечно же - нет.

Более того - в этом случае резко увеличится количество обрабатываемых блоков разделяемой области.

Что также не является показателем деградации производительности СУБД , даже совсем наоборот .

P.S. Использование данной метрики оправдано только в одном сценарии - нагрузочное тестирование инфраструктуры при обязательном условии постоянства нагрузки на СУБД.

На днях опубликовал на GitHub свой скрипт 2013 года, который наполнял с ИБП Ippon Smart Winner 750 базу данных IBM DB2 данными по напряжению сети (за каждую секунду в течение года, по результатам наблюдений скорректировал уставки на реле напряжения, их безопасность для техники подтвердилась при отгорании нуля), обновлял статус моего DynDNS клиента по данным с роутера, запускал и останавливал виртуальную машину VMware Player (там у меня крутилась openSUSE с сайтом на Apache/Django) по расписанию и когда в планировщике BeholdTV была запланирована запись кабельного телевидения (это было необходимо, поскольку видео захватывалось в .asf/x264 - crf18/AC3 без использования графического ускорения и на всё ресурсов не хватало), следил за качеством ADSL линии. А сегодня дополнил ещё рядом скриптов: в 2014 перенёс сайт на Raspberri Pi (Arch Linux ARM) и там стал захватывать IPTV видео. Про захват у меня на Дзене можно почитать, а скрипы создания оглавления и некоторого контроля версии файлов (WSH/JS) опубликовал на GitHub здесь же. Также скрипты по установке времени и некоторой оптимизации скорости отклика сайта, мониторинга доступности посредством Online Domain Tools. Ещё дополнил своими Windows скриптами по работе с СУБД IBM DB2 Express-C и её оптимизации по книге "Best practices Tuning and monitoring database system performance" (она тоже выложена в соответствии с лицензией). Изначально не включил библиотеку RGraph для построения графиков, теперь выложил под лицензией MIT 2013 года.

На днях вышел из строя ИБП. Переключился на стабилизатор. Было уже. До техники APC стоял ИБП Ippon Smart Winner 750. Мониторил напряжение. Сохранял в базе данных SQL сервера IBM DB2 Express-C 10.5 данные за каждую секунду и хранил в течение года. Это помогло выставить уставки на реле напряжения и нормально пережить несколько отгораний нуля без потерь для техники. Скрипты соответствующие опубликовал сегодня на GitHub у себя. При работе от стабилизатора приходилось потом чинить неоднократно SQL базу данных, благо у меня было настроено журналирование в "Архивном" режиме, а сама база данных периодически тестировалась на наличие повреждений. Сложнее с остальной частью данных на компьютере: в NTFS принято частичное журналирование и внезапное отключение ведёт к необходимости решать, восстанавливать ли из бэкапа или соглашаться с тем, что возможно какие-то повреждения будут не сразу обнаружены и могут вызвать проблемы с дальнейшим ремонтом. Чуть раньше такой же пост на Дзене у себя опубликовал.