10 важнейших навыков будущего
Информация не новая, но тема, на мой взгляд, остается важной. На Всемирном экономическом форме, в докладе "Будущее рабочих мест", значительное внимание уделяется перспективным навыкам, необходимым успешным сотрудникам будущего.
Итак, какие же навыки нам с вами предстоит развивать:
1. Творческое мышление
2. Аналитическое мышление
3. Технологическая грамотность
4. Любознательность и непрерывное обучение
5. Устойчивость, гибкость и адаптивность
6. Системное мышление
7. ИИ и BigData
8. Мотивация и самосознание
9. Управление талантами
10. Сервисная ориентация и обслуживание клиентов
Какие из них актуальны для системного аналитика? На мой взгляд, все.
— Без любознательности, адаптивности и стремления к постоянному обучению невозможно быстро приспосабливаться к новым технологиям и успешно внедрять их.
— Быть творческим и гибким — это возможность смотреть на задачи и данные с разных точек зрения, проводя исследования как в глубину, так и в ширину.
— Эмпатия и активное слушание полезны не только в работе с бизнес-заказчиками, но и с "товарищами по цеху". Построение хранилища — это, прежде всего, командная работа.
— Важность аналитического и системного мышления, а также внимания к деталям для системного аналитика, думаю, не требует дополнительных объяснений :)
— И, наконец, развитие в профессии невозможно без внутренней мотивации и самосознания.
Есть ли у вас свой "топ-3" софт-скиллов, которые вы считаете ключевыми для успешной карьеры?
#soft_skills
Информация не новая, но тема, на мой взгляд, остается важной. На Всемирном экономическом форме, в докладе "Будущее рабочих мест", значительное внимание уделяется перспективным навыкам, необходимым успешным сотрудникам будущего.
Итак, какие же навыки нам с вами предстоит развивать:
1. Творческое мышление
2. Аналитическое мышление
3. Технологическая грамотность
4. Любознательность и непрерывное обучение
5. Устойчивость, гибкость и адаптивность
6. Системное мышление
7. ИИ и BigData
8. Мотивация и самосознание
9. Управление талантами
10. Сервисная ориентация и обслуживание клиентов
Какие из них актуальны для системного аналитика? На мой взгляд, все.
— Без любознательности, адаптивности и стремления к постоянному обучению невозможно быстро приспосабливаться к новым технологиям и успешно внедрять их.
— Быть творческим и гибким — это возможность смотреть на задачи и данные с разных точек зрения, проводя исследования как в глубину, так и в ширину.
— Эмпатия и активное слушание полезны не только в работе с бизнес-заказчиками, но и с "товарищами по цеху". Построение хранилища — это, прежде всего, командная работа.
— Важность аналитического и системного мышления, а также внимания к деталям для системного аналитика, думаю, не требует дополнительных объяснений :)
— И, наконец, развитие в профессии невозможно без внутренней мотивации и самосознания.
Есть ли у вас свой "топ-3" софт-скиллов, которые вы считаете ключевыми для успешной карьеры?
#soft_skills
❤1
Вакуум в Greenplum: путь к производительности
Эффективное хранилище данных — это не только оптимально подобранное оборудование (или облачные сервисы) и ПО. Для поддержания целостности данных, оптимизации производительности и обеспечения эффективного использования ресурсов также важно регулярно проводить различные мероприятия по поддержанию "здоровья" DWH.
При удалении или обновлении данных Greenplum помечает эти строки для удаления, но не освобождает место сразу, хотя новые транзакции их не видят. Периодическое выполнение команды VACUUM удаляет эти помеченные строки и оптимизирует структуру хранения. После этого происходит оптимизация индексов, устраняются мертвые ссылки и восстанавливается их эффективность. Затем VACUUM обновляет статистику, необходимую оптимизатору запросов для принятия более интеллектуальных решений при планировании запросов.
Простыми словами, vacuum — это цифровой уборщик, который приводит базу данных в порядок, освобождая место для новых данных и обеспечивая бесперебойную работу всего механизма.
Рекомендации по использованию VACUUM от VMvare:
— запускать VACUUM после крупных операций UPDATE и DELETE.
— избегать использования VACUUM FULL: вместо этого предпочтительнее использовать операцию CREATE TABLE...AS, а затем переименовать и удалить оригинальную таблицу.
— чаще выполнять VACUUM для системных каталогов, чтобы избежать их разрастания и необходимости запуска VACUUM FULL.
— никогда не прерывать выполнение VACUUM FULL для системного каталога и не используйте команду kill для этого процесса.
Для поддержания производительности чтения метаданных необходимо периодически запускать VACUUM FULL для таблиц системного каталога. Однако, стоит учитывать несколько важных моментов:
— Чистка системного каталога эквивалентна остановке сегмента кластера.
— Нельзя прерывать уже запущенный VACUUM FULL системного каталога, чтобы избежать поломки сервиса Greenplum на сегменте.
— Существует жёсткий лимит на объём "мёртвых" строк для VACUUM – не более 1 ГБ указателей строк на процесс.
Регулярное выполнение вакуума обеспечивает оптимальное использование физического пространства и способствует поддержанию высокой производительности базы данных, особенно при интенсивной вставке и удалении данных.
Хотите почитать про вакуум ещё? На хабре есть неплохая статья на этот счёт: Особенности VACUUM в MPP-форках PostgreSQL.
#greenplum
Эффективное хранилище данных — это не только оптимально подобранное оборудование (или облачные сервисы) и ПО. Для поддержания целостности данных, оптимизации производительности и обеспечения эффективного использования ресурсов также важно регулярно проводить различные мероприятия по поддержанию "здоровья" DWH.
При удалении или обновлении данных Greenplum помечает эти строки для удаления, но не освобождает место сразу, хотя новые транзакции их не видят. Периодическое выполнение команды VACUUM удаляет эти помеченные строки и оптимизирует структуру хранения. После этого происходит оптимизация индексов, устраняются мертвые ссылки и восстанавливается их эффективность. Затем VACUUM обновляет статистику, необходимую оптимизатору запросов для принятия более интеллектуальных решений при планировании запросов.
vacuum sandbox.table_name;
Простыми словами, vacuum — это цифровой уборщик, который приводит базу данных в порядок, освобождая место для новых данных и обеспечивая бесперебойную работу всего механизма.
Рекомендации по использованию VACUUM от VMvare:
— запускать VACUUM после крупных операций UPDATE и DELETE.
— избегать использования VACUUM FULL: вместо этого предпочтительнее использовать операцию CREATE TABLE...AS, а затем переименовать и удалить оригинальную таблицу.
— чаще выполнять VACUUM для системных каталогов, чтобы избежать их разрастания и необходимости запуска VACUUM FULL.
— никогда не прерывать выполнение VACUUM FULL для системного каталога и не используйте команду kill для этого процесса.
Для поддержания производительности чтения метаданных необходимо периодически запускать VACUUM FULL для таблиц системного каталога. Однако, стоит учитывать несколько важных моментов:
— Чистка системного каталога эквивалентна остановке сегмента кластера.
— Нельзя прерывать уже запущенный VACUUM FULL системного каталога, чтобы избежать поломки сервиса Greenplum на сегменте.
— Существует жёсткий лимит на объём "мёртвых" строк для VACUUM – не более 1 ГБ указателей строк на процесс.
Регулярное выполнение вакуума обеспечивает оптимальное использование физического пространства и способствует поддержанию высокой производительности базы данных, особенно при интенсивной вставке и удалении данных.
Хотите почитать про вакуум ещё? На хабре есть неплохая статья на этот счёт: Особенности VACUUM в MPP-форках PostgreSQL.
#greenplum
❤1
Дайджест статей за ноябрь
DWH и BigData:
Что такое метаданные и зачем они нужны?
Snowflake:
Коротко о Snowflake
Краткий обзор архитектуры Snowflake для начинающих
Greenplum:
Вставка данных в таблицу Greenplum через INSERT INTO
Вакуум в Greenplum: путь к производительности
SQL и БД:
Множественные комбинации: перекрёстное соединение в SQL
DROP, DELETE, TRUNCATE — погружение в мир удаления данных
Сказка о потерянном времени или проблемы с датами при репликации
EXCEPT в SQL: ищем уникальные значения
Документация:
Качества документации: непротиворечивость
Soft skills:
10 важнейших навыков будущего
#дайджест
DWH и BigData:
Что такое метаданные и зачем они нужны?
Snowflake:
Коротко о Snowflake
Краткий обзор архитектуры Snowflake для начинающих
Greenplum:
Вставка данных в таблицу Greenplum через INSERT INTO
Вакуум в Greenplum: путь к производительности
SQL и БД:
Множественные комбинации: перекрёстное соединение в SQL
DROP, DELETE, TRUNCATE — погружение в мир удаления данных
Сказка о потерянном времени или проблемы с датами при репликации
EXCEPT в SQL: ищем уникальные значения
Документация:
Качества документации: непротиворечивость
Soft skills:
10 важнейших навыков будущего
#дайджест
❤1
Магия SQL Joins: как собрать нужные данные при соединений таблиц
JOIN — фундаментальная функция в SQL, которая позволяет объединять информацию из разных таблиц. С её помощью можно объединять строки из двух или более таблиц на основе связанного между ними столбца. Основными ключевыми словами для JOIN являются INNER JOIN, LEFT JOIN (или LEFT OUTER JOIN), RIGHT JOIN (или RIGHT OUTER JOIN) и FULL JOIN (или FULL OUTER JOIN).
Понимание принципов работы с JOIN поможет эффективно объединять данные и избежать множества ошибок.
Ниже приведу несколько примеров использования JOIN, а в следующий раз поговорим о типичных ошибках при использовании, об улучшении производительности запросов и других особенностях при объединении таблиц.
INNER JOIN
Представим, что у нас есть база данных университета. С помощью INNER JOIN можно легко объединить студентов и занятия, на которые они записаны.
LEFT JOIN
Теперь перейдём к электронной коммерции. Воспользуемся LEFT JOIN (INCLUSIVE), чтобы получить список всех клиентов, включая тех, кто еще не совершил покупку.
Если же нам нужно найти только тех покупателей, которые не совершали заказ, то вносим небольшие правки в EXCLUSIVE-запрос:
RIGHT JOIN
Теперь представим, что перед нами база библиотеки. Воспользуемся RIGHT JOIN (INCLUSIVE), чтобы получить список всех книг, даже тех, которые не выданы ни одному читателю.
Если же нужно найти только книги, которые выданы читателям, добавляем EXCLUSIVE условие:
FULL JOIN
Перейдём к управлению проектами. С помощью FULL JOIN (INCLUSIVE) выведем всех сотрудников и все проекты, независимо есть ли между ними связь.
Если же нам нужно вывести всех сотрудников без проектов и все проекты, без связанных сотрудников, модифицируем запрос до EXCLUSIVE:
Хочу отметить, что прежде чем приступать к использованию JOIN, необходимо хорошо понимать модель базы данных и саму цель запроса. Примеры выше подчеркивают универсальность SQL JOIN.От правильного выбора зависит вся работа нашего запроса и запутаться очень легко. В первое время в качестве помощи можно использовать шпаргалку, до тех пор пока знания не дойдут до автоматизма.
#sql #join
JOIN — фундаментальная функция в SQL, которая позволяет объединять информацию из разных таблиц. С её помощью можно объединять строки из двух или более таблиц на основе связанного между ними столбца. Основными ключевыми словами для JOIN являются INNER JOIN, LEFT JOIN (или LEFT OUTER JOIN), RIGHT JOIN (или RIGHT OUTER JOIN) и FULL JOIN (или FULL OUTER JOIN).
Понимание принципов работы с JOIN поможет эффективно объединять данные и избежать множества ошибок.
Ниже приведу несколько примеров использования JOIN, а в следующий раз поговорим о типичных ошибках при использовании, об улучшении производительности запросов и других особенностях при объединении таблиц.
INNER JOIN
Представим, что у нас есть база данных университета. С помощью INNER JOIN можно легко объединить студентов и занятия, на которые они записаны.
SELECT
students.student_id,
students.student_name,
students.grade,
courses.course_name
FROM students
INNER JOIN
courses ON students.student_id = courses.student_id;
LEFT JOIN
Теперь перейдём к электронной коммерции. Воспользуемся LEFT JOIN (INCLUSIVE), чтобы получить список всех клиентов, включая тех, кто еще не совершил покупку.
SELECT
customers.customer_id,
orders.order_id
FROM customers
LEFT JOIN
orders ON customers.customer_id = orders.customer_id;
Если же нам нужно найти только тех покупателей, которые не совершали заказ, то вносим небольшие правки в EXCLUSIVE-запрос:
SELECT
customers.customer_id,
orders.order_id
FROM customers
LEFT JOIN orders ON customers.customer_id = orders.customer_id
WHERE orders.customer_id IS NULL;
RIGHT JOIN
Теперь представим, что перед нами база библиотеки. Воспользуемся RIGHT JOIN (INCLUSIVE), чтобы получить список всех книг, даже тех, которые не выданы ни одному читателю.
SELECT
books.book_id,
borrowers.borrower_name,
books.title,
books.author,
books.genre
FROM
books
RIGHT JOIN
borrowers ON books.borrower_id = borrowers.borrower_id;
Если же нужно найти только книги, которые выданы читателям, добавляем EXCLUSIVE условие:
SELECT
books.book_id,
borrowers.borrower_name,
books.title,
books.author,
books.genre
FROM
books
RIGHT JOIN
borrowers ON books.borrower_id = borrowers.borrower_id
WHERE books.borrower_id IS NULL;
FULL JOIN
Перейдём к управлению проектами. С помощью FULL JOIN (INCLUSIVE) выведем всех сотрудников и все проекты, независимо есть ли между ними связь.
SELECT
e.employee_id,
e.employee_name,
pr.project_id,
pr.project_name
FROM
employees e
FULL JOIN
projects pr ON e.employee_id = pr.employee_id;
Если же нам нужно вывести всех сотрудников без проектов и все проекты, без связанных сотрудников, модифицируем запрос до EXCLUSIVE:
SELECT
e.employee_id,
e.employee_name,
pr.project_id,
pr.project_name
FROM
employees e
FULL JOIN
projects pr ON e.employee_id = pr.employee_id
WHERE
pr.employee_id IS NULL OR pr.project_id IS NULL;
Хочу отметить, что прежде чем приступать к использованию JOIN, необходимо хорошо понимать модель базы данных и саму цель запроса. Примеры выше подчеркивают универсальность SQL JOIN.От правильного выбора зависит вся работа нашего запроса и запутаться очень легко. В первое время в качестве помощи можно использовать шпаргалку, до тех пор пока знания не дойдут до автоматизма.
#sql #join
❤1
Разгадка тайн соединения NULL-значений в SQL
Продолжим серию статей про особенности работы с #null🙂 да, они ещё не закончились.
Одна из часто встречающихся проблем — непонимание как происходит JOIN таблиц с NULL-значениями. Давайте посмотрим на примерах.
Допустим у нас есть две таблицы:
user_names
user_roles
INNER JOIN
Строки, для которых нет совпадения в обеих таблицах, исключаются из результирующего набора. В том числе, если в столбце, по которому происходит соединение, встречаются значения с NULL, эти строки будут исключены из результата, так как два NULL нельзя сравнить между собой.
Результат:
LEFT JOIN
Возвращает все записи из левой таблицы (users_name) и соответствующие записи из правой таблицы (users_role).
Результат:
Здесь стоит отметить, что появившиеся Null в полях r.ud_id — не являются Null-значениями из таблицы users_role.
FULL JOIN
Возвращает все записи, включая совпадения в левой или правой таблице. Строки в любой из таблиц будут содержать NULL значения в столбцах из другой таблицы, в случае отсутствия совпадения по ключу.
Результат:
Обратим внимание, что строки с NULL NULL повторяются дважды, так как они не равны друг другу и их нельзя объединить.
#sql #null
Продолжим серию статей про особенности работы с #null
Одна из часто встречающихся проблем — непонимание как происходит JOIN таблиц с NULL-значениями. Давайте посмотрим на примерах.
Допустим у нас есть две таблицы:
user_names
us_id name
1 Илья
2 Ольга
3 Null
Null Null
user_roles
us_id role
1 admin
2 user
3 user
Null guest
Null Null
INNER JOIN
Строки, для которых нет совпадения в обеих таблицах, исключаются из результирующего набора. В том числе, если в столбце, по которому происходит соединение, встречаются значения с NULL, эти строки будут исключены из результата, так как два NULL нельзя сравнить между собой.
SELECT u.us_id, r.us_id, name, role
FROM user_names u
INNER JOIN user_roles r ON u.us_id = r.us_id;
Результат:
u.us_id r.ud_id name role
1 1 Илья admin
2 2 Ольга user
3 3 Null user
LEFT JOIN
Возвращает все записи из левой таблицы (users_name) и соответствующие записи из правой таблицы (users_role).
SELECT u.us_id, r.us_id, name, role
FROM user_names u
LEFT JOIN user_roles r ON u.us_id = r.us_id;
Результат:
u.us_id r.ud_id name role
1 1 Илья admin
2 2 Ольга user
3 3 Null user
Null Null Null Null
Здесь стоит отметить, что появившиеся Null в полях r.ud_id — не являются Null-значениями из таблицы users_role.
FULL JOIN
Возвращает все записи, включая совпадения в левой или правой таблице. Строки в любой из таблиц будут содержать NULL значения в столбцах из другой таблицы, в случае отсутствия совпадения по ключу.
SELECT u.us_id, r.us_id, name, role
FROM user_names u
FULL JOIN user_roles r ON u.us_id = r.us_id;
Результат:
u.us_id r.ud_id name role
1 1 Илья admin
2 2 Ольга user
3 3 Null user
Null Null Null Null
Null Null Null guest
Null Null Null Null
Обратим внимание, что строки с NULL NULL повторяются дважды, так как они не равны друг другу и их нельзя объединить.
#sql #null
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Не потеряйте себя, попав в вихрь IT-технологий
Практически всем нам в детстве внушали деструктивные и тревожные идеи "Без труда не вытащишь и рыбку из пруда", "Терпение и труд все перетрут", "Кто не работает, тот не ест" и другие. А современные реалии приправили это всё повальным трендом на "успешный успех". И вот мы попадаем в бесконечную гонку к новым вершинам, где страшно остановиться, ибо "сразу выпадешь на обочину". Особенно это актуально для молодых и амбициозных специалистов (под молодыми я имею ввиду отнюдь не возраст, а давность входа в специальность). Кажется что, если ты остановишься на минуту — мир рухнет.
Однако, реальность немного другая. Да, в мире IT важно держать руку на пульсе и быть в курсе последних технологий, и это отлично. Но не стоит забывать и о ментальном здоровье, о режиме работы и отдыха, то есть о набившем оскомину work-life balance. Баланс — ключ к сохранению физического и эмоционального здоровья без которых просто не имеет смысла всё остальное.
Опасность в том, что в стремлении удержаться на волне новых технологий мы упускаем из виду заботу о себе. И рано или поздно это может привести к хронической усталости, стрессу, а может и к серьезным заболеваниям.
Как себе помочь?
— Всегда выделяйте время "на себя" и то, что вас наполняет. Хобби, спорт, время с друзьями — не забывайте об этом, даже когда кажется, что вы ничего не успеваете на работе и дома. На вас не держится мир. Отдыхая, вы инвестируете в свою будущую продуктивность.
— Используйте различные техники тайм-менеджмента (pomodoro, таймблокинг и другие), и обязательно отдыхайте в перерывах, а не просто переключайтесь с задачи на задачу.
— Не превращайте свое свободное время в непрерывное обучение на проф.темы. Мир прекрасен и огромен, и ваш широкий кругозор тоже принесёт пользу.
— Изучайте новое из интереса, а не из обязанности. Даже в тех случаях, когда нужно изучить что-то скучное, выбирайте наиболее удобный способ обучения и не забывайте о перерывах.
— Не ругайте себя за периоды низкой проф. активности и время, проведенное "без явной пользы".
— Движение — жизнь. Как бы это ни звучало банально, много движения — прогулки, спорт, танцы или просто разминка — помогут вашему телу и мозгу.
— Уделяйте внимание здоровью и не игнорируйте "звоночки". Всегда проще и дешевле вылечить болезнь на ранней стадии. И нет, тело не подождёт.
— Сон — верный союзник. Ещё одна банальность, но как часто в погоне за продуктивностью, мы в первую очередь урезаем именно его. При этом сон — фундамент здоровья и хорошего самочувствия.
— Учитесь говорит "нет". Не бойтесь отказываться от лишних обязательств, чтобы избежать перегрузки.
Конечно же, не стоит впадать в крайности и полностью забивать на свои обязанности. Но если становится совсем невмоготу — будьте честны с собой и работодателем. Берите отпуск. Меняйте работу. Слушайте себя. Для "крайних" случаев можно послушать лекцию Ильи Якямсева "Эффективность не работает".
Берегите себя. С наступающим 2024 годом!🎄
А блог тем временем уходит на зимние каникулы☃️
#soft_skills
Практически всем нам в детстве внушали деструктивные и тревожные идеи "Без труда не вытащишь и рыбку из пруда", "Терпение и труд все перетрут", "Кто не работает, тот не ест" и другие. А современные реалии приправили это всё повальным трендом на "успешный успех". И вот мы попадаем в бесконечную гонку к новым вершинам, где страшно остановиться, ибо "сразу выпадешь на обочину". Особенно это актуально для молодых и амбициозных специалистов (под молодыми я имею ввиду отнюдь не возраст, а давность входа в специальность). Кажется что, если ты остановишься на минуту — мир рухнет.
Однако, реальность немного другая. Да, в мире IT важно держать руку на пульсе и быть в курсе последних технологий, и это отлично. Но не стоит забывать и о ментальном здоровье, о режиме работы и отдыха, то есть о набившем оскомину work-life balance. Баланс — ключ к сохранению физического и эмоционального здоровья без которых просто не имеет смысла всё остальное.
Опасность в том, что в стремлении удержаться на волне новых технологий мы упускаем из виду заботу о себе. И рано или поздно это может привести к хронической усталости, стрессу, а может и к серьезным заболеваниям.
Как себе помочь?
— Всегда выделяйте время "на себя" и то, что вас наполняет. Хобби, спорт, время с друзьями — не забывайте об этом, даже когда кажется, что вы ничего не успеваете на работе и дома. На вас не держится мир. Отдыхая, вы инвестируете в свою будущую продуктивность.
— Используйте различные техники тайм-менеджмента (pomodoro, таймблокинг и другие), и обязательно отдыхайте в перерывах, а не просто переключайтесь с задачи на задачу.
— Не превращайте свое свободное время в непрерывное обучение на проф.темы. Мир прекрасен и огромен, и ваш широкий кругозор тоже принесёт пользу.
— Изучайте новое из интереса, а не из обязанности. Даже в тех случаях, когда нужно изучить что-то скучное, выбирайте наиболее удобный способ обучения и не забывайте о перерывах.
— Не ругайте себя за периоды низкой проф. активности и время, проведенное "без явной пользы".
— Движение — жизнь. Как бы это ни звучало банально, много движения — прогулки, спорт, танцы или просто разминка — помогут вашему телу и мозгу.
— Уделяйте внимание здоровью и не игнорируйте "звоночки". Всегда проще и дешевле вылечить болезнь на ранней стадии. И нет, тело не подождёт.
— Сон — верный союзник. Ещё одна банальность, но как часто в погоне за продуктивностью, мы в первую очередь урезаем именно его. При этом сон — фундамент здоровья и хорошего самочувствия.
— Учитесь говорит "нет". Не бойтесь отказываться от лишних обязательств, чтобы избежать перегрузки.
Конечно же, не стоит впадать в крайности и полностью забивать на свои обязанности. Но если становится совсем невмоготу — будьте честны с собой и работодателем. Берите отпуск. Меняйте работу. Слушайте себя. Для "крайних" случаев можно послушать лекцию Ильи Якямсева "Эффективность не работает".
Берегите себя. С наступающим 2024 годом!
А блог тем временем уходит на зимние каникулы
#soft_skills
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2☃1❤1🔥1
Дайджест статей за декабрь
SQL
Магия SQL Joins: как собрать нужные данные при соединений таблиц
Разгадка тайн соединения NULL-значений в SQL
Life
Не потеряйте себя, попав в вихрь IT-технологий
#дайджест
SQL
Магия SQL Joins: как собрать нужные данные при соединений таблиц
Разгадка тайн соединения NULL-значений в SQL
Life
Не потеряйте себя, попав в вихрь IT-технологий
#дайджест
Telegram
В мире больших данных
Магия SQL Joins: как собрать нужные данные при соединений таблиц
JOIN — фундаментальная функция в SQL, которая позволяет объединять информацию из разных таблиц. С её помощью можно объединять строки из двух или более таблиц на основе связанного между ними…
JOIN — фундаментальная функция в SQL, которая позволяет объединять информацию из разных таблиц. С её помощью можно объединять строки из двух или более таблиц на основе связанного между ними…
❤1
MPP — ключ к эффективной обработке больших данных
Я неоднократно упоминала в своих статьях аббревиатуру MPP, но не рассказывала, что же это такое. Даже если вы уже знакомы с этим термином, давайте всё равно освежим ваши знания.
MPP (Massive Parallel Processing) — это архитектурный подход к обработке данных, широко применяемый в хранилищах данных. Его суть заключается в распределении и параллельной обработке данных на нескольких серверах (узлах) одновременно, что обеспечивает высокую производительность и масштабируемость. В результате общее время выполнения операций сокращается в 10-100 раз по сравнению с традиционными СУБД.
Пример объяснения принципа MPP:
Представим ресторан с одним поваром, который готовит все поступающие заказы последовательно от начала до конца. При необходимости масштабирования и для улучшения производительности мы можем нанять дополнительных поваров с разными зонами ответственности, каждый из которых отвечает за свой этап приготовления блюд (нарезка, выпечка, варка, гриль и т.д). Точно также и в MPP каждый узел параллельно обрабатывает свою часть данных, ускоряя процесс и улучшая общую производительность системы.
Ключевые преимущества MPP:
— Высокая производительность: распределенная обработка данных на узлах кластера обеспечивает быстрое выполнение запросов.
— Масштабируемость: простота добавления новых узлов для обработки дополнительных объемов данных.
— Эффективное использование ресурсов: параллельная обработка данных на нескольких серверах повышает общую эффективность.
Важный момент. MPP-системы предназначены для обработки и анализа больших объемов данных, но не эффективны для обработки единичных OLTP -транзакций, таких как частые операции вставки, обновления и удаления отдельных строк данных.
#dwh
Я неоднократно упоминала в своих статьях аббревиатуру MPP, но не рассказывала, что же это такое. Даже если вы уже знакомы с этим термином, давайте всё равно освежим ваши знания.
MPP (Massive Parallel Processing) — это архитектурный подход к обработке данных, широко применяемый в хранилищах данных. Его суть заключается в распределении и параллельной обработке данных на нескольких серверах (узлах) одновременно, что обеспечивает высокую производительность и масштабируемость. В результате общее время выполнения операций сокращается в 10-100 раз по сравнению с традиционными СУБД.
Пример объяснения принципа MPP:
Представим ресторан с одним поваром, который готовит все поступающие заказы последовательно от начала до конца. При необходимости масштабирования и для улучшения производительности мы можем нанять дополнительных поваров с разными зонами ответственности, каждый из которых отвечает за свой этап приготовления блюд (нарезка, выпечка, варка, гриль и т.д). Точно также и в MPP каждый узел параллельно обрабатывает свою часть данных, ускоряя процесс и улучшая общую производительность системы.
Ключевые преимущества MPP:
— Высокая производительность: распределенная обработка данных на узлах кластера обеспечивает быстрое выполнение запросов.
— Масштабируемость: простота добавления новых узлов для обработки дополнительных объемов данных.
— Эффективное использование ресурсов: параллельная обработка данных на нескольких серверах повышает общую эффективность.
Важный момент. MPP-системы предназначены для обработки и анализа больших объемов данных, но не эффективны для обработки единичных OLTP -транзакций, таких как частые операции вставки, обновления и удаления отдельных строк данных.
#dwh
❤1👍1
Путешествия во времени вместе со Snowflake
Одна из крутых функций Snowflake — это Time Travel, позволяющая "путешествовать во времени" для восстановления данных, которые были изменены или удалены в прошлом. Теперь уничтожить данные безвозвратно будет не так просто😅
Основные возможности Time Travel
— Запрос данных из прошлого.
Можно выполнять запросы к данным, которые были обновлены или удалены. Это уникальная возможность анализа и восстановления информации на разных исторических этапах БД.
Пример запроса, вытягивающего исторические данные по состоянию на 10 минут назад:
— Создание клонов таблиц, схем и БД. Time Travel позволяет создавать клонированные копии на определенный момент в прошлом. Это полезно для анализа и восстановления состояния данных за конкретный временной отрезок.
Пример создания клона таблицы с указанной меткой времени:
— Восстановление удаленных объектов. Теперь можно восстанавливать случайно удаленные таблицы, схемы и базы данных.
Пример просмотра удалённых таблиц:
Восстановление удалённой таблицы:
! Если объект с таким же именем уже есть в базе, то восстановление невозможно, необходимо переименовать новый объект до восстановления.
Как это работает?
Snowflake сохраняет состояние данных перед выполнением операций над ними.
Сколько хранятся данные?
Всё зависит от версии подписки на Snowflake. Для Standard срок хранения составляет всего 1 день. А для Enterprise-версии — от 1 до 90 дней для стандартных таблиц. Snowflake позволяет настроить срок хранения на уровне объекта.
Time Travel — это инструмент для обеспечения целостности и восстановления данных, который предоставляет уникальные возможности работы с исторической информацией.
Дополнительную информацию о функции Time Travel можно прочитать в доке.
#snowflake
Одна из крутых функций Snowflake — это Time Travel, позволяющая "путешествовать во времени" для восстановления данных, которые были изменены или удалены в прошлом. Теперь уничтожить данные безвозвратно будет не так просто
Основные возможности Time Travel
— Запрос данных из прошлого.
Можно выполнять запросы к данным, которые были обновлены или удалены. Это уникальная возможность анализа и восстановления информации на разных исторических этапах БД.
Пример запроса, вытягивающего исторические данные по состоянию на 10 минут назад:
SELECT *
FROM table_name AT(OFFSET => -60*10);
— Создание клонов таблиц, схем и БД. Time Travel позволяет создавать клонированные копии на определенный момент в прошлом. Это полезно для анализа и восстановления состояния данных за конкретный временной отрезок.
Пример создания клона таблицы с указанной меткой времени:
CREATE TABLE restored_table CLONE table_name
AT(TIMESTAMP => 'Fri, 29 Dec 2023 00:00:00 +0500'::timestamp_tz);
— Восстановление удаленных объектов. Теперь можно восстанавливать случайно удаленные таблицы, схемы и базы данных.
Пример просмотра удалённых таблиц:
SHOW TABLES HISTORY LIKE 'old%' IN db_name.schema_name;
Восстановление удалённой таблицы:
UNDROP TABLE table_name;
! Если объект с таким же именем уже есть в базе, то восстановление невозможно, необходимо переименовать новый объект до восстановления.
Как это работает?
Snowflake сохраняет состояние данных перед выполнением операций над ними.
Сколько хранятся данные?
Всё зависит от версии подписки на Snowflake. Для Standard срок хранения составляет всего 1 день. А для Enterprise-версии — от 1 до 90 дней для стандартных таблиц. Snowflake позволяет настроить срок хранения на уровне объекта.
Time Travel — это инструмент для обеспечения целостности и восстановления данных, который предоставляет уникальные возможности работы с исторической информацией.
Дополнительную информацию о функции Time Travel можно прочитать в доке.
#snowflake
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Ключи в базах данных: коротко о важном
При работе с БД важно понимать разницу между ключами.
Primary Key (PK) – уникальный идентификатор для каждой записи в таблице, гарантирует целостность данных. Эффективное использование этого ключа требует тщательного выбора типа данных. Использование слишком длинных строк (VARCHAR(MAX) и подобных) или сложных типов может существенно повлиять на производительность запросов при соединении по ключу.
Если нужен уникальный идентификатор, который может быть сгенерирован в любом месте без возможности конфликта, можно рассмотреть использование UUID или hash от строки (выбор конкретного метода зависит от целей и типа БД). Также PK поддерживает auto increment.
Foreign Key (FK) создает связь между двумя таблицами, ссылаясь на PK в другой таблице. FK обеспечивает целостность связей между таблицами и логически структурирует данные. Именование полей — это важный аспект проектирования БД, который способствует легкости в понимании структуры данных. Хороший тон в наименовании FK — использование стандартных сокращений и отражение связи с PK.
Unique Key (UK) – ограничение базы данных, которое гарантирует уникальность значений в столбце или группе столбцов. Это позволяет исключить дубликаты и обеспечить целостность данных. UK может содержать одно NULL значение.
При создании индексов, PK — это кластерный индекс, а UK — некластеризованный.
Резюме:
— PK: уникальный идентификатор для записей, обеспечивает единственность.
— UK: обеспечивает уникальность значений без строгой идентификации.
— FK: создает отношения между таблицами.
— В таблице может быть только 1 PK и несколько UK.
— Именование любых ключей должно быть осмысленным.
#databasedesign
При работе с БД важно понимать разницу между ключами.
Primary Key (PK) – уникальный идентификатор для каждой записи в таблице, гарантирует целостность данных. Эффективное использование этого ключа требует тщательного выбора типа данных. Использование слишком длинных строк (VARCHAR(MAX) и подобных) или сложных типов может существенно повлиять на производительность запросов при соединении по ключу.
Если нужен уникальный идентификатор, который может быть сгенерирован в любом месте без возможности конфликта, можно рассмотреть использование UUID или hash от строки (выбор конкретного метода зависит от целей и типа БД). Также PK поддерживает auto increment.
Foreign Key (FK) создает связь между двумя таблицами, ссылаясь на PK в другой таблице. FK обеспечивает целостность связей между таблицами и логически структурирует данные. Именование полей — это важный аспект проектирования БД, который способствует легкости в понимании структуры данных. Хороший тон в наименовании FK — использование стандартных сокращений и отражение связи с PK.
Unique Key (UK) – ограничение базы данных, которое гарантирует уникальность значений в столбце или группе столбцов. Это позволяет исключить дубликаты и обеспечить целостность данных. UK может содержать одно NULL значение.
При создании индексов, PK — это кластерный индекс, а UK — некластеризованный.
Резюме:
— PK: уникальный идентификатор для записей, обеспечивает единственность.
— UK: обеспечивает уникальность значений без строгой идентификации.
— FK: создает отношения между таблицами.
— В таблице может быть только 1 PK и несколько UK.
— Именование любых ключей должно быть осмысленным.
#databasedesign
❤1
NULL и агрегатные функции
И вновь разговоры про NULL. Особое внимание заслуживает работа с агрегатными функциями в выражениях, включающих NULL-значения.
NULL представляет собой отсутствие значения или неизвестное состояние, и поэтому добавляет сложности при взаимодействии с агрегатными функциями. Распространенной ошибкой является предположение, что NULL ведет себя как обычное значение. Но это не так!
Вернёмся к основам. Одним из фундаментальных аспектов SQL является трехзначная логика (3VL), различающая TRUE, FALSE и UNKNOWN. И при применении агрегатных функций к выражениям с NULL-значениями важно учитывать состояние UNKNOWN, которое вносит NULL. Ничего не понятно?😁 Рассмотрим на конкретных примерах.
Предположим у нас есть таблица table_for_count:
Результат: 8
Результат: 6☹️
В то время как COUNT(*) посчитает все строки, независимо от наличия значений NULL, COUNT(column_1) исключит в подсчёте строки, где указанный столбец равен NULL.
Аналогично, работают функции SUM, AVG, MAX и MIN. Я отдельно выделила AVG, чтобы вы обратили на него внимание.
table_for_avg:
Результат: 1.5 (в некоторых расчётах — это будет верным, но может быть и нет — учитывайте контекст запроса!)
Что делать?
Хорошая практика — использование функций COALESCE или NVL для замены NULL-значений на значения по умолчанию или определенные пользователем до применения агрегатной функции. Важно устанавливать значения осмысленно, иначе это внесёт ещё больше хаоса в результаты запроса.
Ещё один вариант — использование оператора CASE для создания условной логики и обработки NULL значений.
Выбор метода зависит от конкретной бизнес-задачи и, конечно же, СУБД (и не забывайте проверять план выполнения запроса для лучшего решения).
Результат: 8😍
Отсутствие понимания взаимодействия агрегатных функций с выражениями, включающими NULL значения, может привести к появлению некачественной отчетности и интерпретации данных, что впоследствии подорвёт доверие ко всей аналитике. Поэтому будьте на чеку и учитывайте NULL-значения там, где это необходимо.
Другие заметки про работу с NULL-значениями можно найти по хэштегу👇
#null
И вновь разговоры про NULL. Особое внимание заслуживает работа с агрегатными функциями в выражениях, включающих NULL-значения.
NULL представляет собой отсутствие значения или неизвестное состояние, и поэтому добавляет сложности при взаимодействии с агрегатными функциями. Распространенной ошибкой является предположение, что NULL ведет себя как обычное значение. Но это не так!
Вернёмся к основам. Одним из фундаментальных аспектов SQL является трехзначная логика (3VL), различающая TRUE, FALSE и UNKNOWN. И при применении агрегатных функций к выражениям с NULL-значениями важно учитывать состояние UNKNOWN, которое вносит NULL. Ничего не понятно?
Предположим у нас есть таблица table_for_count:
column_1
49
60
NULL
12
50
11
NULL
5
select * from table_for_count
Результат: 8
select count(column_1) from table_for_count
Результат: 6
В то время как COUNT(*) посчитает все строки, независимо от наличия значений NULL, COUNT(column_1) исключит в подсчёте строки, где указанный столбец равен NULL.
Аналогично, работают функции SUM, AVG, MAX и MIN. Я отдельно выделила AVG, чтобы вы обратили на него внимание.
table_for_avg:
column_2
1
NULL
2
select avg(column_2) from table_for_avg
Результат: 1.5 (в некоторых расчётах — это будет верным, но может быть и нет — учитывайте контекст запроса!)
Что делать?
Хорошая практика — использование функций COALESCE или NVL для замены NULL-значений на значения по умолчанию или определенные пользователем до применения агрегатной функции. Важно устанавливать значения осмысленно, иначе это внесёт ещё больше хаоса в результаты запроса.
Ещё один вариант — использование оператора CASE для создания условной логики и обработки NULL значений.
Выбор метода зависит от конкретной бизнес-задачи и, конечно же, СУБД (и не забывайте проверять план выполнения запроса для лучшего решения).
select count(coalesce(column_1, 0)) from table_for_count;
Результат: 8
Отсутствие понимания взаимодействия агрегатных функций с выражениями, включающими NULL значения, может привести к появлению некачественной отчетности и интерпретации данных, что впоследствии подорвёт доверие ко всей аналитике. Поэтому будьте на чеку и учитывайте NULL-значения там, где это необходимо.
Другие заметки про работу с NULL-значениями можно найти по хэштегу
#null
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Дайджест статей за январь
DWH:
MPP — ключ к эффективной обработке больших данных
SQL и БД:
Ключи в базах данных: коротко о важном
NULL и агрегатные функции
Snowflake:
Путешествия во времени вместе со Snowflake
#дайджест
DWH:
MPP — ключ к эффективной обработке больших данных
SQL и БД:
Ключи в базах данных: коротко о важном
NULL и агрегатные функции
Snowflake:
Путешествия во времени вместе со Snowflake
#дайджест
❤1
Forwarded from Осторожно, карьерные работы! (Simon Osipov)
Try to reserve judgement and observe. Ask a lot of questions. Be the dumbest person in the room. Instead of "Wow that's a dumb way of doing it" say "Huh that's not how I've done it in the past, what constraints led you to this design?"
Цитата, которая мне очень помогает не гореть на работе. Какие я только дизайны таблиц и сервисов и хранилищ не видел за последние годы, и каждый раз мне хотелось кричать "Ну что за идиотизм!". Но с опытом понимаешь, что, хоть иногда и бывает просто глупость или неопытность человека, делавшего что-то, чаще всего у них были входящие ограничения, которые привели к данному решению.
И ты сразу успокаиваешься ❤️
@career_works
Цитата, которая мне очень помогает не гореть на работе. Какие я только дизайны таблиц и сервисов и хранилищ не видел за последние годы, и каждый раз мне хотелось кричать "Ну что за идиотизм!". Но с опытом понимаешь, что, хоть иногда и бывает просто глупость или неопытность человека, делавшего что-то, чаще всего у них были входящие ограничения, которые привели к данному решению.
И ты сразу успокаиваешься ❤️
@career_works
❤1
Explicit is better than implicit: не используйте SELECT *
Один из моих любимых принципов в The Zen of Python (PEP-20) — это "Explicit is better than implicit" (явное — лучше неявного). Он актуален не только для питона, но и для любого кода, документации и в целом жизни. Сегодня я хочу поговорить о примере использования этого принципа.
Часто для сокращения sql-кода используется конструкция
Почему так делать не нужно?
1. Структура данных: ничто не вечно
Даже если кажется, что исходная таблица никогда не изменится, через Х времени это произойдёт. Столбцы могут быть добавлены или удалены, и отлаженный процесс будет сломан. Но из-за отсутствия явного указания, найти и исправить ошибку будет не так просто.
2. Снижение производительности
3. Сложность в понимании логики запроса
Используя неявное указание, мы усложняем дальнейшую поддержку запроса другими людьми. Явное перечисление — это самодокументирующийся код с четким пониманием смыслов.
4. Непреднамеренное раскрытие данных
Для четкой понимании логики запроса, оптимизации запросов и упрощения рефакторинга всегда указывайте столбцы явно (разве что речь не идёт об ad-hoc запросах).
#sql
Один из моих любимых принципов в The Zen of Python (PEP-20) — это "Explicit is better than implicit" (явное — лучше неявного). Он актуален не только для питона, но и для любого кода, документации и в целом жизни. Сегодня я хочу поговорить о примере использования этого принципа.
Часто для сокращения sql-кода используется конструкция
SELECT *
, которая выгружает информацию сразу из всех колонок. Согласитесь, если у вас таблица с 200 столбцами, то вместо того, чтобы писать колбасу из перечислений, куда проще просто поставить *. Ведь мы на 100% уверены, что все столбцы нужны.Почему так делать не нужно?
1. Структура данных: ничто не вечно
Даже если кажется, что исходная таблица никогда не изменится, через Х времени это произойдёт. Столбцы могут быть добавлены или удалены, и отлаженный процесс будет сломан. Но из-за отсутствия явного указания, найти и исправить ошибку будет не так просто.
2. Снижение производительности
SELECT *
в запросах извлекает все столбцы из указанных объектов, включая те, которые не требуются. Это может значительно увеличить объем получаемых данных и снизить скорость выполнения запроса и его производительность (это особенно актуально для колоночного хранения).3. Сложность в понимании логики запроса
Используя неявное указание, мы усложняем дальнейшую поддержку запроса другими людьми. Явное перечисление — это самодокументирующийся код с четким пониманием смыслов.
4. Непреднамеренное раскрытие данных
SELECT *
может случайно раскрыть конфиденциальную информацию, которая не предназначалась для текущего контекста или анализа. К примеру, это может случиться после того как в исходную таблицу будут добавлены новые столбцы о которых заранее никто не предполагал. Для четкой понимании логики запроса, оптимизации запросов и упрощения рефакторинга всегда указывайте столбцы явно (разве что речь не идёт об ad-hoc запросах).
#sql
🔥2❤1
Принцип DRY при написании документации
В разработке принцип "Не повторяйся" (Don't Repeat Yourself, DRY) является одним из ключевых для эффективности и качества итогового продукта. Его же можно использовать и в подготовке документации.
Основной смысл: каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.
Согласитесь, очень часто мы забываем и о системе (концентрируясь лишь на единственной его части), и о непротиворечивости (правим доки в одном месте и забываем о других).
Мои советы по использованию этого принципа:
1. Внедрение шаблонов
Большинство документов подлежит стандартизации. Используйте шаблоны не только для сокращения бесполезного труда, но и для систематизации. Хорошо структурированный документ всегда понятнее и чаще всего оставляет меньше простора для явных ошибок.
2. Использование ссылок
Вместо дублирования информации, старайтесь использовать ссылки на уже существующие материалы. Тогда и исправлять придётся не по всему пространству, и концы найти будет проще.
3. Контроль версий
Системы контроля версий актуальны не только для кода и разработки, но и для поддержания информации в актуальном виде — мы всегда можем "откатиться" к старой версии или понять кто, что и когда изменял (и пойти к этому человеку с вопросами). Сейчас контроль версий есть в большинстве систем для работы с информацией (Notion, Confluence, Google Docs, etc).
Ключ к хорошей документации — в постоянном стремлении к упрощению и оптимизации процесса её написания. В конце концов, некачественная документация столь же бесполезна, как и её полное отсутствие.
#документация
В разработке принцип "Не повторяйся" (Don't Repeat Yourself, DRY) является одним из ключевых для эффективности и качества итогового продукта. Его же можно использовать и в подготовке документации.
Основной смысл: каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.
Согласитесь, очень часто мы забываем и о системе (концентрируясь лишь на единственной его части), и о непротиворечивости (правим доки в одном месте и забываем о других).
Мои советы по использованию этого принципа:
1. Внедрение шаблонов
Большинство документов подлежит стандартизации. Используйте шаблоны не только для сокращения бесполезного труда, но и для систематизации. Хорошо структурированный документ всегда понятнее и чаще всего оставляет меньше простора для явных ошибок.
2. Использование ссылок
Вместо дублирования информации, старайтесь использовать ссылки на уже существующие материалы. Тогда и исправлять придётся не по всему пространству, и концы найти будет проще.
3. Контроль версий
Системы контроля версий актуальны не только для кода и разработки, но и для поддержания информации в актуальном виде — мы всегда можем "откатиться" к старой версии или понять кто, что и когда изменял (и пойти к этому человеку с вопросами). Сейчас контроль версий есть в большинстве систем для работы с информацией (Notion, Confluence, Google Docs, etc).
Ключ к хорошей документации — в постоянном стремлении к упрощению и оптимизации процесса её написания. В конце концов, некачественная документация столь же бесполезна, как и её полное отсутствие.
#документация
🔥2❤1
Группировка NULL-значений
Мы уже рассмотрели множество особенностей NULL, но это ещё не всё.
На очереди группировка данных, включающих NULL-значения.
Как думаете, будут ли NULL сгруппированы или каждый будет считаться самостоятельной единицей?
В этот раз, если вы читали мои предыдущие статьи, ответ может вас удивить. При использовании GROUP BY, строки с NULL в группирующем столбце объединяются в одну группу. Казалось бы NULL обозначает "неизвестное" значение и как мы можем его группировать? Но факт остаётся фактом, при агрегации все NULL считаются равными между собой и формируют единую группу.
Чтобы сделать это поведение более очевидным при аналитике, мы можем использовать функции COALESCE или CASE, чтобы заменить NULL на значение, которое ясно указывает на отсутствие данных, например, на 'Неизвестно'.
#sql #null
Мы уже рассмотрели множество особенностей NULL, но это ещё не всё.
На очереди группировка данных, включающих NULL-значения.
Как думаете, будут ли NULL сгруппированы или каждый будет считаться самостоятельной единицей?
В этот раз, если вы читали мои предыдущие статьи, ответ может вас удивить. При использовании GROUP BY, строки с NULL в группирующем столбце объединяются в одну группу. Казалось бы NULL обозначает "неизвестное" значение и как мы можем его группировать? Но факт остаётся фактом, при агрегации все NULL считаются равными между собой и формируют единую группу.
Чтобы сделать это поведение более очевидным при аналитике, мы можем использовать функции COALESCE или CASE, чтобы заменить NULL на значение, которое ясно указывает на отсутствие данных, например, на 'Неизвестно'.
#sql #null
❤1
Ребята из Data Secrets выложили отличные карточки, рассказывающие про манипуляцию данными. Очень рекомендую ознакомиться, запомнить и не использовать визуальный обман при построении своих отчетов.
Ну и, конечно же, развивайте критическое мышление, чтобы и самим не попадаться на чужие уловки.
Ну и, конечно же, развивайте критическое мышление, чтобы и самим не попадаться на чужие уловки.
Telegram
Data Secrets
Не абьюзеры, но графиками манипулировать умеем. И вас научим.
Только помните: это ВРЕДНЫЕ советы. Не применяйте их сами, но всегда обращайте внимание на такие подвохи в графиках, построенных другими.
Только помните: это ВРЕДНЫЕ советы. Не применяйте их сами, но всегда обращайте внимание на такие подвохи в графиках, построенных другими.
❤1
Pomodoro: когда время — наш союзник
Кто из нас не искал волшебный ключик к продуктивности? Часто кажется, что время начинает бежать быстрее, когда до дедлайна остается чуть меньше, чем ничего. И при этом отвлекающих факторов вокруг разом становится всё больше и мессенджеры разрываются от новых сообщений. Внимание расфокусируется, мы начинаем торопиться и совершать ошибки.
Что может повысить эффективность? Один из моих помощников — метод Pomodoro.
Идея проста — сосредоточенно работать по 25 минут, закрыв все отвлекающие чаты и поставив телефон в режим "Не беспокоить", затем делать короткий перерыв на 5-10 минут, а через несколько рабочих 25-минуток сделать большой перерыв в 15-20 минут. Эти интервалы названы «помидорами», по кухонному таймеру в форме помидора, который использовал создатель метода, Франческо Чирилло, когда был студентом.
Как это работает? Во-первых, 25 минут — идеальное время для сосредоточенной работы без отвлекающих факторов. Больше нашему мозгу уже сложновато. Во-вторых, короткие перерывы помогают отдохнуть и перезагрузиться, чтобы затем с новыми силами взяться за следующий «помидор». Не обязательно подчинять этому методу все 8 часов каждого своего рабочего дня — будьте гибкими.
Интересно, что метод Помодоро не просто учит нас работать с таймером. Он учит ценить каждую минуту, планировать и отдыхать с умом. Мы начинаем осознаннее подходить к своему времени и задачам, учимся разделять большие проекты на маленькие, более управляемые части. И это уже настоящее искусство.
А ещё, как и в случае с методом Утёнка о котором я писала ранее, Помодоро добавляет элемент игры в наш рабочий процесс. Как будто мы не просто выполняем задачу, а участвуем в каком-то захватывающем челлендже.
Если вы, как и я, иногда ощущаете спады эффективности, попробуйте метод Помодоро. Может оказаться, что именно эти 25-минутные интервалы — то, что нужно для буста вашей продуктивности🚀
#soft_skills
Кто из нас не искал волшебный ключик к продуктивности? Часто кажется, что время начинает бежать быстрее, когда до дедлайна остается чуть меньше, чем ничего. И при этом отвлекающих факторов вокруг разом становится всё больше и мессенджеры разрываются от новых сообщений. Внимание расфокусируется, мы начинаем торопиться и совершать ошибки.
Что может повысить эффективность? Один из моих помощников — метод Pomodoro.
Идея проста — сосредоточенно работать по 25 минут, закрыв все отвлекающие чаты и поставив телефон в режим "Не беспокоить", затем делать короткий перерыв на 5-10 минут, а через несколько рабочих 25-минуток сделать большой перерыв в 15-20 минут. Эти интервалы названы «помидорами», по кухонному таймеру в форме помидора, который использовал создатель метода, Франческо Чирилло, когда был студентом.
Как это работает? Во-первых, 25 минут — идеальное время для сосредоточенной работы без отвлекающих факторов. Больше нашему мозгу уже сложновато. Во-вторых, короткие перерывы помогают отдохнуть и перезагрузиться, чтобы затем с новыми силами взяться за следующий «помидор». Не обязательно подчинять этому методу все 8 часов каждого своего рабочего дня — будьте гибкими.
Интересно, что метод Помодоро не просто учит нас работать с таймером. Он учит ценить каждую минуту, планировать и отдыхать с умом. Мы начинаем осознаннее подходить к своему времени и задачам, учимся разделять большие проекты на маленькие, более управляемые части. И это уже настоящее искусство.
А ещё, как и в случае с методом Утёнка о котором я писала ранее, Помодоро добавляет элемент игры в наш рабочий процесс. Как будто мы не просто выполняем задачу, а участвуем в каком-то захватывающем челлендже.
Если вы, как и я, иногда ощущаете спады эффективности, попробуйте метод Помодоро. Может оказаться, что именно эти 25-минутные интервалы — то, что нужно для буста вашей продуктивности
#soft_skills
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1🍾1
Традиционные методы загрузки данных всё ещё актуальны: полная, инкрементальная и дельта-загрузка в DWH
При организации работы хранилища данных важно выбрать оптимальный метод загрузки. Существует множество современных способов переноса данных из источников, например, Change Data Capture (CDC) или прямая передача данных без необходимости их временного хранения. Они предлагают продвинутые возможности для репликации данных в реальном времени с отслеживанием историчности. Но иногда данные нужно перенести быстро или в силу бизнес-требований нет необходимости использовать трудозатратные способы. Тогда мы выбираем традиционные методы репликации.
Полная загрузка — это перенос всех данных из источника (объекта) в хранилище за один раз. Каждый раз, когда нам нужно обновить данные, мы снова перезагружаем объект целиком. Этот метод прост и надежен, если объем данных невелик (н-р, это актуально для редко обновляемых справочников) или есть строгое требование к целостности данных (а других способов гарантировать её нет). Однако, с увеличением количества данных, полная загрузка становится всё более времязатратной и ресурсоемкой.
Инкрементальная загрузка предполагает добавление только новых записей (операция Insert) в хранилище без обновления или удаления уже существующих (если что-то из уже загруженных данных в источнике изменилось, данные в хранилище перестанут быть достоверными). Этот метод эффективнее, так как за один раз загружается меньший объем данных. Однако он несёт в себе риски утраты доверия к данным.
Дельта-загрузка, или загрузка с частичной перезагрузкой, — более продвинутый метод. Он включает в себя загрузку не только новых записей (Insert), но и обновление существующих данных (Update), а иногда и удаление устаревших записей (Delete). Дельта-загрузка требует сложной логики отслеживания изменений в источнике, что позволяет синхронизировать хранилище с актуальным состоянием данных с высокой точностью. Если, конечно, система-источник может предоставить необходимую информацию об изменениях.
Выбор между методами загрузки зависит от множества факторов: бизнес-задач, объема данных, частоты обновлений, требований к актуальности и доступных вычислительных ресурсов. И несмотря на то, что дельта-загрузка может показаться предпочтительнее, так как она обеспечивает баланс между эффективностью обработки и актуальностью данных, система-источник может ограничить нас в выборе и тогда придётся, например, использовать полную перезагрузку, но не целиком объекта, а за промежуток времени Х.
Примеры объектов и вариантов их репликации:
1. Справочник стран (обновляется редко, небольшой объем) — полная загрузка
2. Логи (старые данные не изменяются, только приходят новые) — инкрементальная загрузка
3. Текущее состояние заказа (данные в полях обновляются, есть отслеживание изменений) — дельта-загрузка
Мой совет: всегда ориентируйтесь именно на ваши бизнес-требования, внимательно изучайте источник, а не просто слепо следуйте "лучшим практикам". Гибкость в выборе метода загрузки — ваш ключ к эффективному управлению данными.
#dwh
При организации работы хранилища данных важно выбрать оптимальный метод загрузки. Существует множество современных способов переноса данных из источников, например, Change Data Capture (CDC) или прямая передача данных без необходимости их временного хранения. Они предлагают продвинутые возможности для репликации данных в реальном времени с отслеживанием историчности. Но иногда данные нужно перенести быстро или в силу бизнес-требований нет необходимости использовать трудозатратные способы. Тогда мы выбираем традиционные методы репликации.
Полная загрузка — это перенос всех данных из источника (объекта) в хранилище за один раз. Каждый раз, когда нам нужно обновить данные, мы снова перезагружаем объект целиком. Этот метод прост и надежен, если объем данных невелик (н-р, это актуально для редко обновляемых справочников) или есть строгое требование к целостности данных (а других способов гарантировать её нет). Однако, с увеличением количества данных, полная загрузка становится всё более времязатратной и ресурсоемкой.
Инкрементальная загрузка предполагает добавление только новых записей (операция Insert) в хранилище без обновления или удаления уже существующих (если что-то из уже загруженных данных в источнике изменилось, данные в хранилище перестанут быть достоверными). Этот метод эффективнее, так как за один раз загружается меньший объем данных. Однако он несёт в себе риски утраты доверия к данным.
Дельта-загрузка, или загрузка с частичной перезагрузкой, — более продвинутый метод. Он включает в себя загрузку не только новых записей (Insert), но и обновление существующих данных (Update), а иногда и удаление устаревших записей (Delete). Дельта-загрузка требует сложной логики отслеживания изменений в источнике, что позволяет синхронизировать хранилище с актуальным состоянием данных с высокой точностью. Если, конечно, система-источник может предоставить необходимую информацию об изменениях.
Выбор между методами загрузки зависит от множества факторов: бизнес-задач, объема данных, частоты обновлений, требований к актуальности и доступных вычислительных ресурсов. И несмотря на то, что дельта-загрузка может показаться предпочтительнее, так как она обеспечивает баланс между эффективностью обработки и актуальностью данных, система-источник может ограничить нас в выборе и тогда придётся, например, использовать полную перезагрузку, но не целиком объекта, а за промежуток времени Х.
Примеры объектов и вариантов их репликации:
1. Справочник стран (обновляется редко, небольшой объем) — полная загрузка
2. Логи (старые данные не изменяются, только приходят новые) — инкрементальная загрузка
3. Текущее состояние заказа (данные в полях обновляются, есть отслеживание изменений) — дельта-загрузка
Мой совет: всегда ориентируйтесь именно на ваши бизнес-требования, внимательно изучайте источник, а не просто слепо следуйте "лучшим практикам". Гибкость в выборе метода загрузки — ваш ключ к эффективному управлению данными.
#dwh
🔥2❤1
Дайджест статей за февраль
DWH
Традиционные методы загрузки данных всё ещё актуальны: полная, инкрементальная и дельта-загрузка в DWH
SQL
Explicit is better than implicit: не используйте SELECT *
NULL
Группировка NULL-значений
Документация
Принцип DRY при написании документации
Soft skills
Pomodoro: когда время — наш союзник
#дайджест
DWH
Традиционные методы загрузки данных всё ещё актуальны: полная, инкрементальная и дельта-загрузка в DWH
SQL
Explicit is better than implicit: не используйте SELECT *
NULL
Группировка NULL-значений
Документация
Принцип DRY при написании документации
Soft skills
Pomodoro: когда время — наш союзник
#дайджест
❤1