SQL *

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

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

Информацию описываем вам из нашей практики работы нашего аналитика хранилищ данных.

Работу аналитика хранилищ данных можно разделить на две части:

1. Организация интеграции данных от какого‑либо источника к какому‑либо приемнику;

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

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

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

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

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.

Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.

Привет! Меня зовут Денис, я работаю аналитиком потерь на складе. В какой-то момент я устал от постоянной работы с Excel-выгрузками и решил это автоматизировать.

В итоге всё началось с простого Telegram-бота, а закончилось полноценным web-приложением с отдельным backend, интеграциями и нормальным интерфейсом.

Сегодня хочу рассказать про сам путь: как из “скрипта под задачу” постепенно вырастает система.

Есть мнение, что принципиальной точкой в развитии ИИ станет обретение им сознания. Что такое со‑знание, как оно появляется и «работает» (у Жизни, у нас, у ИИ) разговор отдельный. Но говоря о сознании нельзя пройти мимо темы так называемый «квалий», на использовании которых в качестве своеобразной базы данных как считается сознание и основывает свою работу. Конечно же есть множество литературы на эту тему, в т.ч. и Д. Чалмерс, однако к.м.к. всё же имеет смысл схематически показать что такое квалии, как они получаются и работают на краткой, простой и понятной модели с использованием ПК и языка SQL.

В этой статье продолжаем борьбу с фильтрами по дате в Apache Superset. Сегодня разберем, как реализовать подобие логики remove_filter в старых версиях (до 5), чтобы виртуальный датасет не оборачивался фильтрами.

Почему я решил сделать свой платёжный бот

Я просто хотел принимать платежи и донаты в своём Telegram-канале. Ничего сложного: кинул ссылку — получил деньги. Но когда начал смотреть существующие сервисы (Трибьюн, BotPay и подобные), столкнулся с одним и тем же: регистрация, паспорт, ИП, привязка карт. Мне это было неприятно — как будто чужой дядька лезет в интимные места.

Я не хотел светить данные, не хотел оформлять юридическое лицо, не хотел возиться с налоговой. Хотел просто продавать мануалы и принимать донаты, используя встроенную валюту Telegram — Stars.

Так родилась идея сделать своего бота: анонимного, без регистраций, без паспортов. Чтобы любой человек, у которого есть Telegram, мог создать товар, кинуть ссылку и получить деньги.

Clickhouse. CPU под нагрузкой, память на пределе, диск нагружен. Запросы тормозят. Расчёты не завершаются. Сервер на грани. Что же делать?

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

Блокировки — одна из тех тем в 1С, которые все знают на уровне «ну там что-то с параллельным доступом», но мало кто понимает до конца.

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

Когда два пользователя одновременно меняют один и тот же документ или регистр, возникает конфликт. Без блокировок один перезапишет данные другого — классическая проблема lost update. Или один прочитает данные, которые второй ещё не дозаписал.

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

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

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

Привет, Хаброжители! Реляционные базы данных используются практически в каждой компании. И разбираться в том, как они работают, приходится и разработчикам, и аналитикам, создающим дашборды и отчеты, и специалистам, которым просто нужна актуальная информация. Это увлекательное руководство по миру баз данных и SQL написано в доступной и юмористической манере. Авторы, опытные преподаватели из Университета Торонто, превращают сложные концепции в простые и понятные объяснения с помощью ярких примеров, забавных иллюстраций и практических заданий.

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

Несколько лет назад я делал внутренние доклады по PostgreSQL для команды — разбирали транзакции, блокировки и уровни изоляции на живых примерах. Потом ушёл на другой стек, а недавно вернулся к PostgreSQL и пересмотрел свои записи. Материал до сих пор актуален — базовые концепции не изменились. В статье: почему UPDATE из двух сессий «висит», чем Read Committed отличается от Repeatable Read на практике, почему Serializable падает даже без логического конфликта, и как VACUUM на самом деле работает с мёртвыми строками. Всё с SQL-примерами, которые можно повторить.

Меня зовут Виталий, я из команды ArcaneGaming.
Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт.
Встречайте - Snuffer!

😫 С чего всё началось?
Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):

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

Естественно, можно спроектировать базу данных, вообще не заботясь ни о каких правилах. И она даже будет работать! Все будет прекрасно ровно до первого ее реального использования в продакшене. При проектировании «абы-как» возникают три типовые проблемы: избыточность, аномалии обновления, аномалии удаления.

И вот это уже плохо.

В этой статье хотелось бы начать раскрытие больной для многих пользователей Apache Superset темы — фильтры по дате. Начнем с малого: как суперсет выбирает колонку даты; как выбрать желаемую колонку вместо той, которую он выбирает; каким образом это реализовано; какие баги породили этим решением; почему КОП не доведет до добра.

Простой вопрос, который разделяет инженеров и «операторов фреймворков»

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

Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:

• API отвечало слишком долго

• CPU базы был загружен почти на 100%

Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.

Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".

С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL.

Продолжу цикл по системе.

Чего хочется от ETL процесса?

Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду.

Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.

Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.

Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.

В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе.

Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок.

Как бы нам это все замиксовать?

На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано.

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