дневник Бриджит Джунс (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. Эти дополнения из комментариев и наших обсуждений, спасибо всем, кто делится полезностями🧡