На схеме для написания запросов к данным, которые лежат в delta-таблицах, могут использоваться 2 пути: 1) скопировать нужные данные в Amazon Redshift и писать запросы там; 2) Использовать Amazon Athena и читать delta-таблицы напрямую из S3 бакета.
Для второго варианта мы используем AWS Glue Catalog и Glue Crawler. Glue Catalog - это fully-managed Hive metastore, который позволяет собрать метаданные о файлах, хранящихся в data lake. В данном случае Glue Catalog используется как хранилище метаданных для delta-таблиц, к которым пишутся запросы через Athena.
В качестве BI-инструмента на схеме используется Amazon QuickSight. Он таким же образом может подключаться как к скопированным данным в Redshift, так и напрямую к delta-таблицам.


P.S. На этом закрываем нашу рубрику построения аналитических архитектур. Дальше я собираюсь переходить к более частным вещам. Например, следующую рубрику я хочу посвятить SQL и теории баз данных, где постараюсь осветить все ключевые моменты.

Всем привет!

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

Так как я учил SQL на платном курсе и потом закреплял знания на рабочих задачах и на таких платформах, как Leetcode и Hacker Rank, предлагаю поступить следующим образом:

Не хочу просто гуглить любые курсы и вставлять ссылки на них в пост. Убеждён, что многие из вас проходили какие-то конкретные бесплатные базовые курсы по SQL и нашли их для себя очень полезными. Поэтому:

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

Спасибо!

Всем привет.

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

ТОП 10 бесплатных и бюджетных курсов и материалов по SQL по версии подписчиков:

1. sql-ex.ru - классика для многих специалистов.

2. Udemy SQL для Анализа Данных Глеба Михайлова (платный, но бюджетный). Многие советуют.

3. Курс по SQL от Анатолия Балакирева на Data Learn (бесплатный). - Подробный и очень структурированный курс.

3. Анализ данных на языке SQL в "Специалист". Платный и самый дорогой из списка. Но есть возможность учиться очно. Цитирую рекомендацию: "Препод очень толковый. На ходу разбираются практические задачки. Даёт базу с 0 вплоть до уровня курсоров, транзакций и т.д."

4. Основы SQL на Stepik (платный, но бюджетный). Рекомендация: "Просто добавлю про один неочевидный, но очень большой плюс - выработка автоматизма. После окончания курса стоит только подумать о каком-то запросе, руки его уже сами печатают."

5. Интерактивный тренажер по SQL (бесплатный). Рекомендация: "Пушечный стартовый курс
Если прям никогда не открывали SQL, то это то, что нужно: задачки, задачки, задачки."

6. Learn DB (подписочная модель). Рекомендация: "Очень годный курс. Сейчас у них подписочная модель, но не очень дорогая. Всем советую🙂"

7. Stepik SQLite для аналитики Антона Жиянова (платный, но бюджетный).

8. SQL Developer Анализ данных на языке SQL (бесплатный).

9. Udemy: SQL для начинающих: с нуля до сертификата Oracle (платный, но бюджетный).

10. Хабр: Вопросы по SQL на собеседовании


P.S. Спасибо Sergey Novik, @Graffeev, @ruslanadv, @Artem_ne_Artem, @MrSparkline, @Krakatau27, @Garry_S, @dmi_inod, @BaburovNik, @Alexander_Zlenko, @user2764, @AnalystAM, @ashakhverdyan за рекомендации и вовлечённость!

Шпаргалка по SQL

It's designed to give you a meaningful structure but also to let you add your own
notes (that's why the empty boxes are there). It starts from the absolute basics
(SELECT * FROM table_name;) and guides you to the intermediate level (JOIN,
HAVING, subqueries). I added everything that you will need as a data analyst/
scientist.

The ideal use case of this cheat sheet is that you print it in color and keep it next to
you while you are learning and practicing SQL on your computer.

Что бы я рассказал себе про SQL 10 лет назад? 😳

На какие вещи стоит обратить внимание, чтобы после обучения на шаблонных таблицах "Сотрудник-Зарплата" или "Студент-Оценка" не впасть в ступор на первой же боевой задаче?

https://bit.ly/2FRvYNQ

#itresume #sql

Язык R, не смотря на своё узкое назначение, входит в топ 10 наиболее популярных языков программирования согласно различным рейтингам, включая TIOBE. А для анализа данных R является чуть ли не стандартом отрасли.

Хочу порекомендовать канал @R4marketing. Автором которого является Алексей Селезнёв, руководитель отдела аналитики в Netpeak.

Канал посвящён языку R. На данный момент там собрано огромное количество русскоязычных материалов по изучения R:

- Статьи
- Видео уроки
- Вебинары и доклады с конференций
- Заметки по R
- Книги
- Бесплатные онлайн курсы
- Новости и релизы из мира R

В канале опубликовано более 500 ссылок на русскоязычные материалы по R.

Кому интересно - подписывайтесь!

https://news.1rj.ru/str/R4marketing

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

Все SQL-команды можно разделить на такие группы:

DQL (Data Query Language). Язык запросов к данным. К этой группе относится одна, всем известная команда - SELECT. Благодаря ей, мы запрашиваем нужные нам данные из базы.

DDL (Data Definition Language). Язык определения данных. Благодаря командам из этой группы, мы создаём, изменяем и удаляем различные объекты в нашей базе данных - базы данных, схемы, таблицы.
Примеры команд: CREATE, DROP, ALTER, TRUNCATE.

DML (Data Manipulation Language). Язык манипуляции данных. Как понятно из названия, мы используем эту группу команд для внесения изменений в наших данных. Мы можем записывать данные в таблицы, изменять значения в нужных колонках, удалять строки в таблицах.
Примеры команд: INSERT, UPDATE, DELETE.

DCL (Data Control Language). Язык контроля данных. Команды из этой группы используются для управления доступом к объектам в базе данных и к самим данным. Благодаря этим командам мы можем предоставлять и отзывать разрешения для пользователей базы данных.
Примеры команд: GRANT, REVOKE, DENY.

TCL (Transaction Control Language). Язык управления транзакциями (более подробно о транзакциях напишу отдельный пост в рубрике о теории баз данных).
Примеры команд: COMMIT, ROLLBACK, SAVE POINT.

Завтра выступлю на митапе и расскажу про построение сквозной аналитики на базе Google Cloud. Я уже выступал с этой темой, но в этот раз немного расширил контент. Так что приглашаю всех:)

Всем привет!

В этот вторник ждем всех на митап

🔥 Доклад про построение маркетинговой аналитики на GCP

@MLinMarketing

🔸19:00 - 20:00

🎤 Денис Соловьев, Data Engineer at Ciklum

📋 Построение маркетинговой аналитики на базе Google Cloud

📋 Рассмотрим преимущества создания маркетинговой аналитики с использованием облачных технологий. Поговорим о том, на что стоит обратить внимание перед построением решения. Посмотрим на примеры аналитических архитектур для решения маркетинговых задач. Разберём организацию DWH на базе Google BigQuery. Затронем BigQuery ML и какие задачи можно решать с его помощью.

— — —

🗓 05 октября, начало в 19:00 мск, Вторник

🌐 ОНЛАЙН

Регистрация на мероприятие тут

Добавляйте в календарь, ссылка придет на почту перед началом митапа

Ещё одна универсальная шпаргалка про порядок выполнения SQL-операций.

Логический порядок выполнения операторов "под капотом":

1. FROM (выбор таблицы)
2. JOIN (комбинация с подходящими по условию данными из других таблиц)
3. WHERE (фильтрация строк)
4. GROUP BY (агрегирование данных)
5. HAVING (фильтрация агрегированных данных)
6. SELECT (возврат результирующего датасета)
7. DISTINCT (выбор только уникальных значений)
8. ORDER BY (сортировка)


И статья с объяснением на примерах.

» Сегодня смотрим доклад про построение маркетинговой аналитика

Спикеры: Денис Соловьев, Data Engineer at Ciklum

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

Подключайтесь!

🧞‍♂️ ВИДЕО с ML in Marketing Meetup
@MLinMarketing

📋 Тема: Построение маркетинговой аналитики на базе Google Cloud

📋 Описание: Рассмотрим преимущества создания маркетинговой аналитики с использованием облачных технологий. Поговорим о том, на что стоит обратить внимание перед построением решения. Посмотрим на примеры аналитических архитектур для решения маркетинговых задач. Разберём организацию DWH на базе Google BigQuery. Затронем BigQuery ML и какие задачи можно решать с его помощью.

🎤 Спикер: Денис Соловьев, Data Engineer at Ciklum
- автор телеграм канала про аналитику @smart_data_channel

🎬 Видео

📥 Презентация

— — —
Кстати, вопросы по докладу можно задавать тут же в комментариях ;)

⚡️Масштабное независимое исследование онлайн-курсов по аналитике ⚡️

Мы с моими коллегами из компании твердо решили узнать все-все самое важное об онлайн образовании по теме аналитики и data science. Об онлайн образовании говорят повсеместно, курсы чрезвычайно распространены, ведь профессии в IT-сфере сейчас очень популярны. Думаю, что огромная часть аудитории данного канала либо прошла, либо собирается пройти курсы, связанные с анализом данных.

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

Буду признателен коллегам владельцам каналов по аналитике за репост. Разумеется, результатами опроса мы вскоре с вами поделимся в виде симпатичного дашборда 🤓

➡️ Ссылка на опрос

p.s. Любые комменты по опросу тоже приветствуются

🧑‍🎓 Матрица компетенций BI-аналитика
Сделал матрицу компетенций, она родилась за год большой работы по менторству BI-аналитиков и «сериала» с Русланом. С радостью и гордостью хочу поделиться ей с комьюнити. Получилось круто.

Матрица будет полезна и новичкам — есть подсветка проседающих навыков и ссылки на учебные материалы. И компаниям — для составления планов развития сотрудников.

Необходимо оценить себя по 68 навыкам из 6 направлений, которые важны BI-аналитику на мой взгляд. Каждый навык имеет уровень «прокачки» от 1 до 4 и описание, с примером ожиданий знаний от уровня. Но это только пример, при сомнениях, оцените навык по ощущениям от «джун» до «лид».

Матрица – не истина в последней инстанции, а ориентир и быстрый способ оценить себя. В идеале должна заполняться вместе с ментором, кто мог бы валидировать результат и дать практику.

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

🔗 Ссылка
#избранное

Всем привет. Давно не писал на канале, так что буду исправляться.

Мы продолжаем тему SQL и баз данных, и сегодня я хочу рассказать о 4-х типах объектов, которые встречаются в большинстве СУБД: base table (таблица), temporary table (временная таблица), view (представление), materialized view (материализованное представление).

Решил написать небольшую шпаргалку с описанием этих объектов и в каких случаях какой объект использовать или не использовать.


Base table - классическая таблица. На логическом уровне это выделенное пространство на диске или в памяти, где хранятся данные, которые мы загрузили в эту таблицу.
Базовая таблица является основой для создания других объектов в базе данных.


Temporary table - временная таблица, которая, как правило, существует в рамках одной сессии подключения к базе данных. Простыми словами, если вы подключились к базе данных, создали временную таблицу, использовали её для своих нужд и разорвали соединение, то в рамках следующей сессии этой таблицы уже не будет.

Когда использовать: временные таблицы могут быть полезными, если вы часто обращаетесь к данным большой базовой таблицы (base table) в рамках одной сессии. Это, в свою очередь, может замедлять скорость работы и потреблять большое количество вычислительных ресурсов, что сильно снижает эффективность. Поэтому, вы можете создать временную таблицу на базе основной для хранения промежуточных результатов и писать запросы уже к ней, что может сильно повысить производительность.

Когда не использовать: временные таблицы лучше не использовать для сложной логики запросов и вычисляемых полей. Для этих задач больше подходят views (представления).


View - по сути, это хранимый SQL-запрос, который содержит в себе направления к данным, которые хранятся в основных таблицах. Т.е. представление хранит не данные сами по себе, а направление к ним.

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

Когда не использовать: со временем базовые таблицы могут становиться всё больше, и сложный запрос во view становится всё медленее, что делает анализ данных очень долгим и неудобным. Чтобы устранить просадку в производительности, мы можем материализовать результаты запроса, который хранится в представлении. Для этой задачи и существуют materialized views.

Materialized views - специальный тип представлений, который так же, как и стандартное представление является хранимым запросом. Но в отличие от стандартного представления материализованное хранит уже данные, а не просто направление к ним. Т.е. результат запроса материализуется и становится похожим на обычную таблицу, к которой мы можем писать запросы. Процесс материализации и обновления представления происходит в заданный интервал времени на основе изменений в базовых таблицах, к которым это представление обращается.

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

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


В следующий раз сделаю похожий пост про партиции и индексы.

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

Партиционирование - это метод разделения одной большой таблицы (родительской) на много маленьких таблиц (партиций).
Разделение родительской таблицы происходит по заданному условию: например, у нас есть таблица с заказами, каждый заказ произошёл в определённую дату. Мы можем партиционировать эту таблицу по дате заказа.

Когда использовать:
- для более гибкого использования физического хранилища данных. Например, мы можем хранить отдельные партиции на разных серверах и для хранения редко запрашиваемых данных использовать более дешёвую технологию хранения на отдельном сервере;
- для гибкого управления данных в таблицах. Мы можем быстро добавлять и удалять данные на уровне партиций;
- для ускорения выполнения SQL-запросов к таблице. Партиционирование может существенно повысить скорость запросов, так как движок будет сканировать отдельные партиции, в которых лежат нужные для запроса данные, а не всю таблицу.
Вернёмся к нашему примеру с датой заказа: например, у нас есть таблица orders, и мы пишем запрос к ней, запрашивая только заказы за 2021-12-15:

SELECT * FROM orders WHERE order_date = '2021-12-15';

Так как наша таблица партиционирована по дате заказа, движок просканирует только одну партицию "2021-12-15", а не всю таблицу (в случае, если партиционирование не используется). Скорость выполнения такого запроса вырастет во много раз.

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

Индексы - на логическом* уровне это отсортированные ключи колонки таблицы (для которой и создаётся индекс), которые имеют указатели на местонахождение строк основной таблицы со значением колонки в индексе. Если сильно упростить, то индекс в базах данных очень похож на индекс в конце книг. Когда вы открываете индекс на последних страницах книги, у вас есть список ключевых слов, отсортированных от А до Я. Для каждого слова есть номера страниц, где это слово упоминается, что облегчает поиск. По такому же принципу работают индексы и в БД.
Важно сказать о том, что индексы в большей степени используются в традиционных реляционных СУБД (таких как PostgreSQL, MySQL, Microsoft SQL Server и т.д.). Современные колоночные решения, такие как Google BigQuery, Snowflake или Amazon Redshift используют специальный слой метаданных, который решает задачу повышения эффективности поиска и скорости выполнения запросов.

Когда использовать:
- на больших таблицах;
- когда увеличение скорости выполнения запросов за счёт индексов имеет больший профит, чем затраты на хранение и поддержку индексов;
- на часто используемых полях в фильтрах для часто используемых запросов.
Предположим, у нас есть большая таблица orders, и мы часто, запрашивая данные и з неё, фильтруем данные по полю segment (сегмент клиента, который совершил заказ). Например, мы пишем такой запрос:

SELECT * FROM orders WHERE segment = 'Corporate';

Мы можем создать индекс на столбец "segment", чтобы увеличить скорость выполнения запроса. Например, в PostgreSQL индекс можно создать так:

CREATE INDEX segment_idx on orders (segment);

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

Когда не использовать:
- на небольших таблицах. Индексы требуют дополнительного пространства для их хранения. Поэтому, если скорость выполнения запросов без индекса вас вполне устраивает, то и не нужно использовать дополнительные ресурсы для хранения индексов;
- на колонках с большим количеством null-значений;
- на часто обновляющихся таблицах. Частые операции вставки и обновления полей таблиц повышают нагрузку на СУБД, так как значения нужно записать/обновить в двух местах - в основной таблице и в индексе. Если вы часто производите удаления в основной таблице, то индекс становится фрагментированным (т.е. включает в себя пустые "листы"), что приводит к его неэффективности;
- на колнках с низкой кардинальностью (низким количеством уникальных значений). Например, если ваша колонка, на которую вы создаёте индекс, включает в себя только True/False значения, создание индекса не принесёт вам много профита.

* Я не просто в определении индекса написал "на логическом уровне". Логический уровень - это абстракция, которая позволяет описать объект обобщённо и как можно проще без углубления в детали. Есть ещё физический уровень, который описывает, чем на самом деле "под капотом" являются индексы. На физическом уровне для создания индексов используются специальные структуры данных: как правило, это B+tree или hash-таблицы. О структурах данных я тоже напишу, но сейчас я хочу двигаться от логического уровня к физическому для упрощения восприятия.

Хочу немного отвлечься от "техники" и затронуть достаточно философский вопрос, о котором я частенько задумываюсь:

Нужно ли сидеть за теорией из Computer Science, разбирая алгоритмы, структуры данных, внутренности баз данных и копать вплоть до того, как на физическом уровне работает процессор? Либо не стоит так заморачиваться и нужно просто брать разные инструменты, которые решают определённую задачу, и просто их "щупать"? Особенно на фоне постоянно появляющихся новых тулзов.

Некоторые будут говорить, что основы Computer Science - это база, без которой никуда, а некоторые, что они не заканчивали Computer Science, но при этом успешно работают в индустрии.

Решил сделать опрос, чтобы посмотреть, в каком отношении распределяются мнения)

После опроса напишу своё видение на этот счёт.