дневник Бриджит Джунс (de)👩‍💻💅

✍️ Дорогой дневник, что я успела натворить с DataHub

1️⃣ oops!... i did incident
Первой моей задачей с DataHub (местами сокращу как dh) стала благородная миссия: если падает таска в airflow - доставлять весточку в dh об этом и создавать инцидент. Зачем? Чтобы у объектов, связанных с DAG-ом, отображалось наличие проблемы. Ну и, конечно, нужно было сделать так, чтобы такой открытый инцидент в dh после успешного перезапуска таски закрывался.

Основной сложностью в этом всем стало "взаимодействие" с GraphQL dh. Нужно было разобраться как с запросами на получение данных, так и с мутациями для создания и разрешения инцидентов. Я до этого момента не имела особо понятия, что за GraphQL такой. В общем, пришлось с этим пострадать, не всегда было явно понятно, как получить то, что мне нужно вообще👁👄👁. Но штука интересная!

2️⃣ разногласия dh и airflow
Сначала всё было красева:
упал DAG → инцидент открылся → перезапустили→ инцидент закрылся → 🎉

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

В итоге пришлось устроить dh и airflow дополнительные переговоры🤝:
берём открытые инциденты → идём в Airflow API → проверяем реальное состояние DAG run → и если всё ок — закрываем инцидент.

3️⃣ "мы только посмотреть"
Следующая моя задача была связана с тестированием column-level lineage в dh. До этого у нас использовался только стандартный lineage между объектами, но аналитики захотели оценить возможность отображения зависимостей на уровне отдельных колонок. После первого опыта работы с dh разобраться было уже проще. Плюс, от меня не требовалось какого-то системного решения, для начала нужен был пример реализации на выборочных объектах для дальнейшего принятия решения (надо оно нам или не очень-то было и надо).

4️⃣ Ну и сейчас еще ковыряюсь с "интеграцией" Kafka и dh
Хотим автоматически строить lineage в dh между Kafka-топиками и Kafka Engine таблицами в ClickHouse.
На самом деле, основная часть уже готова (урееей💅), остались всякие мелочи.

привет🙋‍♀️

Меня долго не было, и сложно написать что-то мега-полезное, потому что довольно много занималась задачами, не связанными напрямую с SQL (моим любименьким💔). Вместо этого приходилось больше работать с GraphQL, Grafana, алертами и DataHub(по ощущениям больше всего), ну и, в общем, писать какой-то код на питоне.

Не знаю, как писать об этом так же увлеченно, но всё-таки, это тоже может быть полезно, так что пора собираться с силами. Начну пока просто с набора заметок и впечатлений об этом промежутке времени.

⭐️ Первое, о чем хочется написать: для меня было чистым мучением заниматься разными задачами, где нужно было писать код, отличный от привычных DAG-ов. Но именно поэтому мне и давали довольно много таких задач. И сейчас этим заниматься стало явно проще, хотя я всё еще low-skill по личным ощущениям, особенно в сравнении со своей командой.

И (не без влияния этого ощущения) каждый раз немного выбивает из колеи осознание того, насколько быстро сделали бы ту или иную задачу твои коллеги, в то время как ты ковыряешься с ней уже вторую неделю🥲

⭐️ Что еще: Работа над кодом, тестирование, ошибка, поиск проблемы, снова работа над кодом, тестирование, снова ошибка (повторите х раз и получите) → дергающийся глаз и желание взорваться. Вполне себе полагаю, что так может быть не у всех, но для меня это стало одной из больших сложностей - постоянное ощущение, что ничего не получается. Да, с запросами, например, такое тоже бывает, но почему-то там логи ошибок читать и понимать мне изначально было намного проще. Они какие-то более "дружелюбные" что ли, вот как объяснить?

⭐️ Разбираться в написанном кем-то коде, проваливаться в несколько файлов, чтобы понять, что происходит... и всё равно не понимать, что происходит. С DAG-ами обычно всё проще: открыл файл - увидел логику. А вот когда нужно разобраться в какой-нибудь системе алертов или другом внутреннем инструменте, очень быстро оказывается, что ответ на любой вопрос находится где-то в другом файле... а нет, надо провалиться еще немного в другой файл... и еще. И вот так уже не понимаешь, где ты и кто ты👀

⭐️ Делать по принципу "беру рабочий пример и адаптирую его под свою задачу" (не знаю, насколько это нормальный подход, но пока работает - пользуюсь). Например, когда начались проблемы с tg и мне нужно было перенести всякие алерты в Mattermost, очень помог существующий код для telegram, хотя его, конечно, пришлось во многом менять и я это сделала 100% не лучшим образом, если посмотреть пристально и с нескольких сторон, но все работает отлично, поэтому на текущий момент - окей.

⭐️ Быть в ощущении: «Я не могу это сделать без чьей-то помощи» стало сложнее. Я совершенно не против спрашивать, наоборот, это тоже часть работы. Но всё-таки хочется расти и учиться справляться самой, поэтому необходимость обращаться за помощью ощущается как-то тяжелее что ли, даже если сейчас я делаю это уже реже🥲

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

А сейчас (на самом деле уже давно) мне просто очень хотелось сюда вернуться. И еще хочется немного задневниковать, чем я занималась, может быть, рассказать что-то полезное или узнать что-то новое от тех, кто всё еще меня читает🧡

🇷🇺ТОВАРИЩИ🇷🇺

Хотите узнать, до чего доводит людей рабочая суббота?

🇷🇺 Ответ в видео.


А если тоже хочешь преисполниться в своём познании, то подписывайся на 🇷🇺 родмаперов.

А для остальных есть чатик.

грубо говоря, примерно так😁😁
для всех, кому картинки помогают запоминать[me]

Помните разбирали шарды и реплики в ClickHouse? Так вот, сегодня у нас на обэд🍽 три базовых сущности, которые важно не путать: partitions, parts и гранулы. Делаю себе заметки и делюсь с вами✨

Partition:

Partition - это логическое (и физическое) разбиение таблицы по какому-то ключу. Чтобы его задать, мы используем при создании таблицы правило, с помощью:
PARTITION BY🪚

Например, PARTITION BY toYYYYMM(month), что означает, что данные будут храниться по месяцам - каждая партиция соответствует одному месяцу. Это про логику.

И физически каждая партиция хранится отдельно на диске.

Зачем это нужно:

• когда данные разбиты на файлики по ключевому полю, можно быстро удалять/заливать данные за конкретный период (например, DROP PARTITION🗑 не будет перебирать и фильтровать строки, он просто удалит выбранные партиции - то бишь соответствующие файлы)

• ну и запросы работают быстрее, если фильтр попадает в партицию (тогда ClickHouse не будет трогать остальные).

Чаще всего партиции делят по периодам времени📆, как было у нас в примере выше, но ключ может быть любым.

Part:

Part - это физический кусок данных, по сути - отдельный файлик.

Откуда берется?
Когда мы вставляем данные в таблицу, ClickHouse создаёт отдельный part(файлик). Потом движок MergeTree постепенно объединяет мелкие parts в более крупные (этот процесс называется merge).

👾Вот тут важный момент, в котором я раньше путалась: не понимала, почему внутри партиции может быть несколько parts, если партиция - это вроде как физическая единица. Но вот так вот - пока parts не сольются в один файл, внутри партиции может быть несколько parts.

С этим моментом, кстати, связано то, что в ClickHouse не стоит делать очень много мелких вставок (по строке, например). Потому что в таком случае придется выполнять merge слишком часто...🥲 Рекомендуется вставлять данные в ClickHouse пакетами, от 10 000 строк за раз🤝

Гранула (granule):

Гранула - это самая маленькая единица хранения в MergeTree. Это блок строк, которые ClickHouse может прочитать за раз.
Размер гранулы по умолчанию - 8192 строк (2 в 13 степени🐈). Но может быть изменен при создании таблицы (задаётся параметром).

Гранула - это логическая единица. Набор строк внутри гранулы не хранится в отдельном файле. Чтобы запомнить, где какая гранула, ClickHouse делает метки📌 и создает файл индекса, который хранит метки.

Зачем нужны гранулы:

Они позволяют эффективно работать с индексами: если фильтр не попадает в гранулу, то её можно целиком пропустить;

именно за счёт гранул достигается ускорение при чтении данных✈️

Что пригодится на практике:

• partition удобно использовать для крупных операций (удалить или перенести данные за месяц или год)🐈

• parts нужно контролировать, чтобы их не стало слишком много (иначе запросы и мёрджи замедлятся)🐈

• гранулы напрямую влияют на скорость выборки - чем лучше подобран первичный ключ, тем меньше лишних гранул будет прочитано🐈

Всем хиллоу и лёгкой рабочей субботы! У меня после отпуска улиточный темп🐌 но не сдаемся, ползем дальше)

напоминашка: через полчасика начнем чтения заключительной (11) главы книги "Основы инженерии данных👾"💫

Ответ к вчерашнему посту⬆️

В формате команды:

EXCHANGE TABLES 
    dicts_db.very_important_dict
AND 
    dicts_db.very_important_dict_new

А теперь в формате буков🤩

• EXCHANGE TABLES - это такая команда, которая просто меняет местами таблички. Если точнее, то метаданные таблиц (структуру и "указатели" на данные), не трогая сами данные.

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

То бишь - в кейсе из поста выше сначала был создан идентичный по структуре словарь (с припиской _new в конце), у которого внутри самого запроса были реализованы нужные изменения. И, несмотря на зависимости, ClickHouse "разрешил" выполнить такую операцию. Видимо, потому что объект никуда не "пропадает". Ну и потом старый словарь, то есть тот, который содержит старые данные - дропается.

Такие дела, дорогой дневник🌷 Записала, чтоб не забыть, что делать в случае, если снова встретится кейс со сложными зависимостями от какого-то словаря, который нужно изменить)

Етак! Снова кейсы из задачек👿

В рамках одной задачи, мне нужно было поменять (в том числе) запрос для словаря dicts_db.very_important_dict в ClickHouse.

Все остальные объекты по задачке поменяла (и даже не забыла про реплики), а вот именно с very_important_dict получила ошибку:

SQL Error [630] [07000]: Code: 630. DB::Exception: Cannot drop or rename dicts_db.very_important_dict (5a5a55a5-5aaa-5555-a55a-555a55a5aaaa), because some tables depend on it: some_db1.some_table1, some_db2.some_table2 (a5555a55-5a5a-55aa-55aa-aaa5a555a5a5). (HAVE_DEPENDENT_OBJECTS) (version 25.3.2.39 (official build))

Зависимые объекты, перечисленные в тексте ошибки, имеют движок ReplicatedMergeTree. Сначала попробовала только их дэтачнуть (т.к. они перечислены в тексте ошибки):

detach table  some_db1.some_table1 on cluster dwh
detach table  some_db2.some_table2 on cluster dwh

После 15 минут ожидания (подождала ZooKeeper) - та же ошибка.

Потом пошла искать все объекты, которые в DDL содержат упоминание dictionary dicts_db.very_important_dict:

select *
from system.tables
where create_table_query like '%dicts_db.very_important_dict%'

Плюсом, детачнула и все эти объекты.

detach table  first_db.some1_mv
detach table  first_db.some2_mv
detach table  first_db.some3_mv
detach table  second_db.some_history_table
detach table  third_db.table1 
detach table  third_db.table2 
detach table  third_db.table3

И все равно при попытке удалить словарь падаю на ту же ошибку.
Поэтому быстренько вернула все объекты на место. И пошла за помощью к коллегам.

Как же можно поменять запрос для такого словаря?
Пишите свои предложения и предположения🤯

А ответ - как получилось реализовать задачу в данном случае будет в следующем постике😡

Напоминашка по чтениям 📕
———————————————
Планы на встречу 5 октября:

• Домашнее задание: Добиваем 8 главу "Запросы, моделирование и преобразование" со страницы 354 до конца

• Обсуждаем главу (в том числе предыдущий раздел главы про подходы Инмона / Кимбалла и Data Vault)

Начнем в 12 по мск💛

обещала поделиться дополнением к посту по ACID/BASE👇

⭐️Я раньше думала, что в любой СУБД можно взять и "врубить" любой из уровней изоляции. But no: у каждой СУБД есть "уровень по умолчанию", а дальше можно немного двигаться "вправо-влево" в рамках ограничений конкретной реализации. В реальной жизни настройки чаще всего остаются на дефолтном уровне.

Для примера:
• СУБД sql server поддерживает все 4 уровня изоляции, но уровень по умолчанию - read commited.

• PostgreSQL - по умолчанию тоже read committed, но можно переключиться на repeatable read или serializable. А вот read uncommitted в PG как отдельного уровня нет.

⭐️ Ребята на чтениях поделились простой полезной статьей. Там, кстати, упоминается теорема CAP. Закрепляю тут.

⭐️ И просто прикольное: ACID - это же кислота, а BASE - щёлочь!👩‍🔬Воспринимала как абревиатуру и не замечала раньше. Получается совмещать их не получится, загасят друг-друга)) хых

P.S. Эти дополнения из комментариев и наших обсуждений, спасибо всем, кто делится полезностями🧡

Кстааати, всем, кто любит мемы с котиками😱 и не только(!) про IT/DS сюда 👉 @ds_memes

Мемы мемятся 4+ раза в день, можно похихикать и поделиться с коллегами (здесь их огромное количество на любой вкус)

Подписываться и следить за мемасами тут😲➡️ @ds_memes