Improving software flow

Открываю сегодня в Казани наш ИТ-фестиваль с вышеуказанным докладом, а материалы к нему публикую здесь

4 основные книги, из которых родилась идея доклада
- The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта.
- The DevOps Handbook (2016 год) - книга с популяризацией devops подхода
- Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент.
- The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс

Связанные книги
- Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации.
- Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта.
- A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке.
- Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов
- SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них
- "Lean Software Development" - книга про lean практики в разработке

Исследования
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)

Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
- Эволюция подходов к развитию мобильного банка Тинькофф
- Эволюция web Tinkoff на ArchDays

#Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

Скидка до 22% на ресурсы управляемых баз данных Greenplum и OpenSearch в Yandex Cloud

Теперь у вас есть возможность резервировать определенный объем ресурсов — Committed volume of services, CVoS — с фиксированной ценой в течение полугода или года. Это предложение доступно для всех пользователей и позволяет существенно сократить расходы при стабильном потреблении сервисов.

Условия CVoS распространяются на Yandex Managed Service for Greenplum и Yandex Managed Service for OpenSearch, работающие на платформах с процессорами Intel Ice Lake. Размер скидки: 15% при резервировании на пол года и 22% при резервировании на 1 год.

➡️ Подробнее по ссылке.

#реклама

Почти закончили написание обновленной версии книги про Azure Data Factory с читателями канала. Добавили про Azure Bicep (Infrastructure as a Code), Azure Data Explorer, Azure Synapse, Azure DevOps and Microsoft Fabric.

Появилась ссылка на мое выступление на MDF Fest - Gentle vs Hardcore Data Engineer, Tue, Aug 22, 3:00 PM PDT

А как жить? Хороший вопрос. Но это замечательное видео на 1,5 часа, Алексей простым и понятным языком рассказал про базовые и очевидные вещи, про которые многие знают, но все равно не делают. Если вы встряли, стоите на месте, то я вам рекомендую смотреть это видео каждую неделю, пока не измените свою жизнь.

Тут и про спорт, и про иностранные языки, вообще много все, и много лично перекликается с моим опытом и мировоззрением. Я давно понял, что винить никого не нужно в своих неудачах, просто надо делать. Важна дисциплина, важен спорт, важен английский язык, важны книги, важно отвечать за слова и помогать другие безвозмездно и далее по списку. А ведь у меня и синий пояс по джиуджитсу и по плавания разряд, а я все время не нахожу на качественный спорт из-за работы. Буду меняться. Обязательно еще раз послушаю видео. Ведь для успешного человека и для качественной жизни важны и голова и тело💪

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

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

В Канаде за такие слова можно, я имею ввиду про контекст видео, про успешных мужиков, чтобы лучше привлекать женщин😁 скажут вам что вы харасите их🫣

Мастерская, конечно, работа с цифрами и визуализацией.
А по зарплатам аналогичный график будет?

Очередной раунд собеседования успешно пройден. Спасибо современным технологиям, все как вы любите;)

Давайте рассмотрим пример Databricks failure (Spark Job Crash) с ошибкой "Out of Memory" или если быть точней - "Executor heartbeat timed out." . Согласно графику из Spark Metrics, видно, что кластер находится под высокой нагрузкой и не вывозит (картинка в следующем примере).

Сам по себе job простой - SparkSQL join 2х таблиц, который никогда не выполняется.

Если посмотреть логи, то можно увидеть информацию про garbage collection (я недавно шарил презентацию про оптимизацию Spark и проблемы GC):

2023-08-03T18:41:59.782+0000: [Full GC (Ergonomics) [PSYoungGen: 2012308K->0K(4189184K)] [ParOldGen: 10396300K->8628584K(10632192K)] 12408608K->8628584K(14821376K), [Metaspace: 137299K->137299K(1181696K)], 2.9204327 secs] [Times: user=9.30 sys=0.16, real=2.92 secs] 
2023-08-03T18:42:13.326+0000: [Full GC (Ergonomics) [PSYoungGen: 874490K->0K(4189184K)] [ParOldGen: 9882410K->8734574K(10954240K)] 10756900K->8734574K(15143424K), [Metaspace: 137405K->137405K(1181696K)], 3.6903566 secs] [Times: user=11.13 sys=0.09, real=3.69 secs] 
2023-08-03T18:42:24.128+0000: [Full GC (Ergonomics) [PSYoungGen: 614069K->0K(4189184K)] [ParOldGen: 10084503K->10137697K(12568064K)] 10698573K->10137697K(16757248K), [Metaspace: 137417K->137417K(1181696K)], 7.4416142 secs] [Times: user=24.72 sys=0.09, real=7.45 secs] 
.
.
2023-08-03T18:45:48.356+0000: [Full GC (Ergonomics) [PSYoungGen: 2430464K->2430025K(4304384K)] [ParOldGen: 12567859K->12567859K(12568064K)] 14998323K->14997884K(16872448K), [Metaspace: 137502K->137502K(1181696K)], 11.6564436 secs] [Times: user=44.72 sys=0.18, real=11.66 secs] 
2023-08-03T18:46:00.013+0000: [Full GC (Ergonomics) [PSYoungGen: 2430464K->2430025K(4304384K)] [ParOldGen: 12567859K->12567858K(12568064K)] 14998323K->14997883K(16872448K), [Metaspace: 137502K->137502K(1181696K)], 11.5040092 secs] [Times: user=44.30 sys=0.10, real=11.50 secs] 
2023-08-03T18:46:11.518+0000: [Full GC (Ergonomics) 2023-08-03T18:46:23.979+0000: [Full GC (Ergonomics) [PSYoungGen: 2430464K->2430439K(4304384K)] [ParOldGen: 12567858K->12567858K(12568064K)] 14998322K->14998297K(16872448K), [Metaspace: 137503K->137503K(1181696K)], 11.9345509 secs] [Times: user=45.50 sys=0.16, real=11.94 secs] 
2023-08-03T18:46:35.914+0000: [Full GC (Ergonomics) [PSYoungGen: 2430464K->2430451K(4304384K)] [ParOldGen: 12567858K->12567858K(12568064K)] 14998322K->14998310K(16872448K), [Metaspace: 137503K->137503K(1181696K)], 11.6086862 secs] [Times: user=44.60 sys=0.18, real=11.61 secs] 

Время GC больше 10 секунд (real=11.50 secs) и так же видно что у Spark Executor не хватает памяти:

23/08/03 18:41:09 INFO UnsafeExternalSorter: Thread 50 spilling sort data of 2.2 GiB to disk (0 time so far)
23/08/03 18:41:21 INFO UnsafeExternalSorter: Thread 50 spilling sort data of 2.2 GiB to disk (1 time so far)
23/08/03 18:41:29 INFO UnsafeExternalSorter: Thread 50 spilling sort data of 2.1 GiB to disk (2 times so far)
23/08/03 18:41:36 INFO UnsafeExternalSorter: Thread 50 spilling sort data of 2.1 GiB to disk (3 times so far)
23/08/03 18:41:57 INFO UnsafeExternalSorter: Thread 50 spilling sort data of 2.0 GiB to disk (0 time so far)

Перед тем как наш джоб kaput, мы видим ошибку "GC overhead limit exceeded":

23/08/03 18:36:15 WARN TaskSetManager: Lost task 5.0 in stage 29.0 (TID 1738) (xx.xxx.xxx.xxx executor 0): java.lang.OutOfMemoryError: GC overhead limit exceeded

Так же несколько executers выдали ошибку exit status 52, что тоже значит "out of memory".

23/08/03 18:36:19 WARN TaskSetManager: Lost task 212.0 in stage 29.0 (TID 1945) (10.224.176.134 executor 0): ExecutorLostFailure (executor 0 exited caused by one of the running tasks) Reason: Command exited with code 52

Для начало можно было добавить в конфигурацию Spark Executer Java Option "G1GC as the garbage collection algorithm" и для sc.setSystemProperty указать KryoSerialize для "spark.serializer". Что это такое, лучше спросить у chatGPT;)

Но это не сильно помогло и поэтому постаринке нужно просто увеличить размер Spark Executor, то есть у каждой ноды должно быть в 2 раза больше оперативки и ядер. Вообще это классика, на любую проблему я всем рекомендую удвоить compute.

PS Практически каждый день мне приходится иметь дело с ошибками Spark, и 60% из них это "Out of Memory". 20% это связано с настройкой сети, особенно если используется Databricks внутри виртуальной сети (VNET/VPC) и опцию Secure Cluster Connectivity (No Public Ip). То есть без доступа к интернету. Другие 10% это интеграция Databricks c BI, другими базами, Git. Ну остальное это уже по мелочи.

PPS Этот пример очень хорошо демонстрирует разницу между Snowflake и Databricks. Оба продукта для аналитики и консолидации данных. Но вот в Snowflake тюнить не надо, просто размер кластера удваивать иногда, а вот у Databricks можно и потюнить, но все равно потом удвоить кластер😜