0: Приветствую вас в подкасте гетена лист профессионального сообщества системных и бизнес аналитиков. Здесь мы разбираем реальные задачи, вопросы с собеседований, рассказываем истории и делимся рабочими челленджами. Ваша ведущая екате.

1: Ирина Ананьева, давайте начинать.

2: Всем ещё раз привет со мной сегодня в эпизоде Елизавета Акманова и мы будем обсуждать кафку. Я думаю, что многие этот эпизод открытые уроки от меня ждали, просили.

3: И сегодня мы с Лизой собрались для того, чтобы как раз-таки этот вопрос обсудить и как минимум частично закрыть, конечно же, про кафку мы ещё будем многократно говорить в telegram канале сообщества гетена.

4: На открытых вебинарах, на обучениях. И не только я снова рада видеть Лизу. У нас в эпизоде она уже рассказывала про версионирование в api, про идемпотентность в api 2 очень классных технических выпуска, которые я

5: Рекомендую послушать Лиза сейчас является старшим системным аналитиком компании юсте, автором статей, наставником, спикером конференций и лидером комьюнити аналитиков. Лиза, передаю тебе слово и предлагаю.

6: Начинать. Расскажи, пожалуйста, почему эта тема интересна тебе и что нам сегодня ожидать от эпизода? Рада приветствовать в эпизоде. Смотри, Катя, идея мне пришла в голову, когда

7: Стала разбирать инциденты у нас в системе. И оказалось, что некоторые проблемы, они могут быть связаны с кафкой. И когда я стала глубже эту тему изучать, оказывается, все это очень интересно, потому что раньше мы

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

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

10: Как sapi в целом в частности, я бы хотела подметить рест api, когда только только начинались мобильные приложения, переставали делать такие жёсткие монолиты, когда код фронта и.

11: Beck слиты воедино. Аналитикам пришлось разбираться с ресо ипиай для того, чтобы тоже корректно ставить задачи, описывать входные выходные данные, понимать, что картинки на экране 1, но для того, чтобы их вызвать и.

12: Для того, чтобы их, так скажем, отрисовать, нужно вызвать как раз-таки, апи, здесь такая же история. Сначала мы смотрим на кафку, а, ну там есть какая-то очередь сообщений, а когда уже лезем в технические детали, то начинается самое интересное.

13: Потому что в кафке есть определённое устройство этих очередей, есть нюансы, там, брокер, топики, разные сложные слова. И в этом во всем надо разобраться. Я тогда предлагаю погружаться.

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

15: И да, сегодня мы будем разбираться, что такое кафка. И конкретно на своём примере, на системе клиентской поддержки, с чем я, собственно говоря, сталкивалась. Мы эту технологию будем сегодня разбирать сама по себе. Кафка это система обмена. Сообще.

16: Между сервисными приложениями в режиме там, близкому к реальному времени и верхнеуровнево все выглядит следующим образом. У нас есть сама кафка, это некоторый посредник между сервисами.

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

18: Сообщения по мере их появления для нашего случая с системой клиентской поддержки продюсерами могут быть системы, которые инициируют создание обращения клиента, то есть клиент заполнил некоторое обраще.

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

20: Отправить уведомление клиенту по почте, что ваше обращение приняли в работу. Его номер такой, то. Ждите ответа. Вот в заданные сроки. Это клиент requests сервер, где мы, собственно говоря, в нашу базу сохраняем это обращение для его дальнейшей ра.

21: Обработки и сам оркестратор, чтобы запустить все наши внутренние процессы по обращению, там, маршрутизировать его на нужную рабочую группу и назначить ему эсле, и запустить там в наши внутренние процессы, которые на своих

22: Движках тоже настроено. Лиз, у меня такой вопрос. Чисто теоретически я знаю, что мобильные приложения, веб сайты, веб приложения могут подключаться к кафке.

23: Но у меня на практике никогда такого не было, и поэтому даже чисто теоретически я это подтвердить не могу. У меня всегда к кафке подключаются вит сервисы, микросервисы, в общем то.

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

25: В нашем проекте у нас ещё есть прослойка в виде пигги твея, которая эти запросы будет на кафку отправлять. То есть прям напрямую они все-таки не взаимодействуют, но такое чисто технически, конечно, может быть и скорее исключение, чем правило.

26: В теории могу порассуждать, что такой метод взаимодействия может быть, например, в системе чатов, в реальном времени, где у нас сообщения должны буквально моментально доставляться до пользователя. Тут прямое подключение клиента к

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

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

29: Подключались напрямую. К кафке такого ни разу не встречала. Поэтому если кто-то с нами поделится опытом, кто-то такое наживую видел, то будет классно. Оставляйте комментарии к эпизоду. А так да, всегда у нас идёт все в

30: Кафку через какой-то серверный компонент и api gateway это по сути некий сервис микросервис тоже можно так назвать, который их туда кладёт. То есть принимаем запрос по api от наших мобильных и веб клиентов и

31: Затем уже кладём в кафку. Вообще 1 из причин, которая, мне кажется, клиенты в виде фронт систем не используют кафку напрямую. Так это сложность реализации данной функциональности, потому что мобильный

32: Приложением. Тогда при подключении кафки придётся постоянно поддерживать соединение, управлять офсетами. Ну, мы потом будем разбирать понятие офсет, что это такое, и эти сообщения обрабатывать. А так как клиенты чаще всего это

33: Тонкие, которые не содержат большой внутренней логики. Именно поэтому уж желательно использовать такую прослойку, чтобы не нагружать устройство, предположение, считаю, что на 100% верное нам не нужно умное устройство.

34: Нам не нужен толстый клиент, то есть нагруженная логикой приложения. И плюс это все-таки требует определённых мощностей тоже от устройства. Мы не хотим, чтобы оно тормозило нам чем тупее, чем проще фронтент, тем лучше.

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

36: Генерацию, постановку в очередь. Я всегда вот хочу, чтобы какие-то ассоциации складывались и продюсеры. Это как раз-таки производители, поставщики сообщений в кафку. Есть консьюмеры консьюмер с английского перево.

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

38: Прекрасное дополнение к подкасту, а именно сайт эпизода, на котором мы опубликовали слайды презентации и на ней показаны схемы, то есть то, что мы сейчас рассказываем, обсуждаем и 1 слайд, на который стоит посмо.

39: Смотреть это в целом про устройство кафки. Продюсер, консьюмеры и кафка в середине предлагаю двигаться дальше. Важный момент. Брокеры могут использовать 2 разные модели запросов пулл и пуш.

40: В чем разница? Пул, модель это когда консьюмеры сами отправляют запрос в ras н секунд на брокер для получения новой порции сообщений пуш модель это брокер сам делает запрос консьюмеру ***.

41: Ему новую порцию данных. Вот на слайде 3 у нас эта модель представлена. Если вы обратите внимание, то увидите, что стрелка идёт от брокера к консьюмеру при push модели или от консьюмера к брокеру при

42: Paul, в случае с кафкой на слайде 4 у нас используется модель пулл. Значит сервисы сами опрашивают брокер для получения сообщения у кафки модель именно такая используется, то есть в кафке у нас основное

43: Это когда именно сервисы, когда консьюмеры подключаются к ней и слушают очереди, вытягивают оттуда сообщения сами, а не дожидаются, пока сама кафка придёт к ним, оживит их и

44: Соответственно, начнёт с ними работать. Как раз-таки получается, что у нас история с pull моделью. Это когда у нас держится постоянное соединение между сервисами и брокером. Верно, все именно так и работает. Продол.

45: И почему мы вообще выбрали кафку для своего проекта? Обращение клиентов? Для нас это критически важная информация, и мы просто не можем себе позволить её потерять ни в 1 из сценариев. Представьте, что

46: Клиент отправил заявку через приложение или через сайт как угодно. Она должна дойти до нашей системы без каких-либо Сбоев. Здесь возникает проблема с надёжностью. Если мы будем использовать прямые вызовы между сервисами или даже

47: Api шлюзами, то если 1 из сервисов окажется недоступным, например, моргнёт сеть, высокая нагрузка, большой таймаут, то есть причины могут быть абсолютно разные, то мы рискуем этот запрос потерять, а это, в свою очередь, для нас определённые юридические риск.

48: Потому что не отвечать на вопросы клиентов мы не можем. Если обращение было создано, нам необходимо его обработать. В противном случае можно даже и до судебных дел дойти, как эта проблему решает. Поэтому она

49: Выступает в Роли промежуточного такого хранилища, которое может принимать запросы даже при сбое 1 из сервисов в кафке. Обращения могут оставаться до тех пор, пока все необходимые системы не будут готовы его забрать для

50: Обработки. То есть это даёт нам гарантию, что ни 1 сообщение клиента не будет потеряно и все внутренние процессы там от уведомления по емейл серверу до передачи задачи на рабочую группу, все процессы, которые выполняют наши консьюмеры, они

51: Не будут запущены вовремя. Кроме того, кафка позволяет нам распределить нагрузку между системами. Если у нас одновременно пошли 1000 заявок, какой-то массовый сбой в системе и все клиенты пошли жаловаться, то

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

53: Перегружая отдельные сервисы, теперь переходим к самому сложному и для меня самому интересному это внутреннее устройство кафки. У нас есть следующие термины кафка, брокер, топик партии.

54: И сегмент. Это было бы не так сложно, если бы все это собиралось в качестве матрёшки, то есть последовательно друг в друга. Но это не так. Дела обстоят гораздо интереснее. Собирается почти все, кроме топиков, и сейчас будем рассматривать.

55: Это детальнее. У нас есть кафка, самый верхний уровень. Он представляет из себя группу брокеров, а брокер, в свою очередь, это сервер, который отвечает за хранение, обработку и передачу. Сообще.

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

57: Это у нас изображено на слайде 5 как раз темы в контексте кафки. Это топики изображены на слайде 6. То есть топик это некоторое логическое разделение сообщений на группы. Хочу

58: Выделить, что именно логическое, а не физическое. То есть мы создаём топик для сообщения общей группы и стараемся не смешивать их друг с другом. Например, у нас есть сообщения с обращением клиента, они

59: Имеют свою структуру, будут лежать в 1 месте, а есть обращение, допустим, не письменное, а звонок, звонок клиенту в контактный центр. У него свои наборы параметров, они лежат отдельно от письменных обращений.

60: Содержит другую информацию. Это смысловое различие категорий сообщений в топике. Вы пишите сообщения в конец и не разрушаете при этом цепочку старых сообщений. То есть логика у нас такая 1

61: Продюсер может писать в 1 или несколько топиков, 1 консьюмер может читать 1 или несколько топиков, при этом в 1 топик могут писать несколько продюсеров и 1 топик могут.

62: Читать 1 или более консьюмеров ограничений на количество топиков в рамках кластера кафки нет, но есть ограничения самого компьютера, то есть бесконечно выполнять операции на процессоре нельзя и в итоге

63: Все имеет там свой предел, мы не можем увеличивать мощности на производительности машин бесконечно. Мы в какой-то момент упрёмся в потолок, и поэтому топики следует делить на определённые части и эти самые части

64: Называются партиции слайд у нас 7. Переходим на него. Партиции могут находиться на разных серверах, то есть на разных брокерах. И каждый топик состоит из 1 или более партиций. То есть каж

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

66: Мы говорим, что новое сообщение добавлено в топик, то на самом деле оно записывается в 1 из партиций этого топика. У меня есть вопрос. Ты сейчас говорила про то, что у нас есть ограничения мощности, это логично, они есть, наверное, везде.

67: Для всего и конкретно по количеству топиков как понять вообще, сколько топиков может быть в кафке, какое количество нормальное, какое количество нет и что делать, если у нас в проекте много много?

68: Много, много процессов. И нам нужно там, не знаю, 100 топиков, возможно ли это все зависит от вашей бизнес логики, потому что топики это как раз-таки логическое разделение данных. Если по логике, да, нужно, то

69: Куда деваться? Придётся все-таки так делать. Просто единственное, лучше разносить топики на разные брокеры, чтобы мы могли управлять потоком сообщений, тем самым не перегружать нашу систему. Плюс ко всему тут нужно ещё опреде.

70: Делить срок хранения этих сообщений. Если нам нужен какой-то длительный срок, то соответственно мы гораздо быстрее исчерпаем наши лимиты. При этом, если можно этот срок сократить и сообщения хранить чуть.

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

72: Будете хранить и, соответственно, количество топиков, которые вы можете записывать, кто принимает у вас в проекте решение, потому что нужно добавить новый топик, добавить новый брокер, добавить новую партицию. Кто

73: Несёт ответственность системный аналитик, разработчики, архитектор или кто-то ещё за кем конечное решение, как это происходит. За выделение топиков у нас будет отвечать аналитик, потому что это как раз-таки логическое

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

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

76: Инженера. Спасибо за ответ. Движемся дальше. И последний уровень, который мы видим на слайде 8. В партициях хранятся наши месседжи, сообщения, ивенты. Название у них может быть не

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

78: Несколько серверов, то есть брокеров, каждый из них имеет свой набор партиций. Партиции при этом имеют структуру согласно их топику, согласно их логической модели данных и уже в эти партиции

79: Читаются сообщения. Мне кажется, что кафку можно сравнить с матрёшкой и выучить все её, вот эти вот слои, как только они выучатся, как только понимание, за что каждый из компонентов кафки

80: Отвечает, будет вот прям чёткое представление, то уже работать с этой технологией системному аналитику будет гораздо проще. И, конечно же, важное понимание, о котором сказала Лиза, то, что у нас есть здесь

81: Зона ответственности аналитика это за логические части, которые у нас будут организованы в плане топиков, как они будут устраиваться все остальное, да, то есть что

82: Будет касаться нагрузки. Это уже больше будет зона ответственности девопсов, бэкэнд, разработчиков, архитекторов для того, чтобы её выдержать. Но системному аналитику, конечно же, это тоже следует понимать хотя бы на базо.

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

84: Хочется тоже добавить и выделить на слайде 9, что есть лидеры партиций. То есть это партиция, которая работает с клиентом и именно лидер работает с продюсерами.

85: И отдаёт сообщение консьюмеру к лидеру осуществляются все запросы, при этом есть ещее фолловеры, которые подключаются к своим лидерам и хранят реплику всех данных. Партиции, сообщения всегда отправля.

86: Именно лидеру, в общем случае и лидеров читают фолловеры. Это необходимо, чтобы сохранить данные, которые у нас находятся в лидере, и в случае, если лидер в какой-то момент у нас отказывает.

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

88: Способы организации данных относительно времени приоритетов кафка работает по модели фифо first in first out, что это означает, что каждая следующая запись добавляется в конец и не.

89: Меняет предыдущих записей, то есть фактически очередь фифо реализует именно эту модель. У каждого сообщения есть там свой порядковый номер или его ещё называют офсет, которая

90: Тонно увеличивается со временем, и у каждой партиции свой собственный счётчик, и он никак не пересекается с другими партициями, то есть у нас нумерация сохраняется в рамках каждой партиции отдельно, помимо продюсера.

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

92: Сообщения спустя дни, недели, месяцы. То есть тут все зависит от вашей внутренней логики. Срок можно устанавливать самостоятельно. Здесь никакой чёткой привязки нет. А можно уточнить у нас получается

93: Что 1 сообщение могут читать 2 консьюмера, так, да, вполне себе. И давай тогда какой-нибудь конкретный пример нашим зрителям приведём в нашем случае в системе клиентской поддержки.

94: У нас в рамках 1 продюсера есть 2 консьюмера, это конкретно будет имейл, сервер и оркестратор, оркестратор будет работать с внутренней частью системы и запускать наши внутренние процессы, а при этом имейл сервер.

95: Возьмёт сообщение и отправит уведомление клиенту, что оно создано и взято в работу, как на стороне кафки. Мы будем отмечать, что все необходимые сервисы прочитали сообщение и его можно

96: Удалять из очереди. То есть понятно, что у нас кафка работает по pull модели и у нас получается сами консьюмеры, они забирают сообщения из очереди читают, но тогда как в этом случае у нас

97: Мы понимаем, что все можно удалять сообщения из очереди, и оно там больше не нужно. Отличный вопрос. Его можно даже немножко дополнить. Допустим, наш сервер читает какие-то со

98: Остановился, допустим, на 4 позиции, как это у нас показано на слайде 11, и перезагрузился. Мы выпустили новое обновление, соответственно, его вся внутренняя память, она ушла, и мы не знаем, что он остановился именно на 4.

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

100: Партиции, и он монотонно возрастающий, именно этот offset и использует консьюмер для хранения номера обработанного сообщения, то есть консьюмер делает специальный запрос к брокеру, и он называется офсет коммит с

101: Указанием там своей группы. Допустим, я имейл сервер указывает идентификатор топика партиции. То есть обращение, я как эмейл сервер читаю топик с обращениями и, собственно, сам офсет, который должен быть помечен, как

102: Обработанный и брокер эту информацию хранит в своём собственном специальном топике если у нас рестартанули ь консьюмеры и они забудут, какое сообщение считали последним, могут запросить у кафки последний закомиченный офсет, который был им.

103: Произведён для определённой партиции и начать читать сообщения со следующего месседжа. Тоже самое с тем случаем, когда у нас несколько консьюмеров и они читают сообщения из 1 партиции кафки, мы будем

104: Об этом говорить будем коммитить те офсеты, которые были обработаны сервером. И получается, в какой момент мы удаляем сообщения из очереди, когда мы получим коммит от каждого?

105: Сервера, когда каждый сервер нам целенаправленно скажет, что мы сообщения прочитали или можно настроить ручное удаление, когда даже если все сообщения будут прочитаны, они все равно могут храниться. Допустим, для логирования нам нужно

106: Понимать, какие действия были воспроизведены. Тут зависит от внутренней логики реализации, или по всем коммитам, или по сроку. Мне кажется, что здесь, да, вот по всем коммитам, это, наверное, такая стандартная история, если го

107: Говорим о том, что сообщение потом остаётся в очереди, то здесь, да, либо для Логов, либо оно остаётся. Но самое главное, чтобы не навсегда его все равно желательно когда-нибудь удалить, потому что очередь сообщений и вообще

108: Понятие очереди. Мы должны понимать, что это как временная база данных. Не надо там постоянно эти сообщения хранить, иначе смысл именно очереди её гибкости, он немножко теряется. Можно тогда было просто навсегда эти со

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

110: Через 2 недели, через 2 дня, через 2 часа после того, как сообщение будет обработано, то автоматически его можно удалить. Вот после последнего коммита. Спасибо за то, что разобрали этот вопрос. Хочу тебя ещё немножко дополнить у нас

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

112: И расходовать ресурсы зря. Поэтому аналитикам следует задавать как раз-таки период очистки топика, чтобы администраторы кафки его установили конкретные значения в конфигурации абсолютно согласна, потому что

113: Да, можно, но это не имеет смысла, в принципе, да, вот никакого. Продолжим дальше по нашим партициям, по нашим сообщениям, внутренним устройствам на слайде 13.

114: Хочется некоторые термины тоже проговорить начальная позиция, то есть 1 сообщение нашей партиции называется lock start offset, позиция сообщения, которая задана последним, это lock and offset.

115: А позиция консьюмера, где он сейчас находится, какое сообщение он читает это current офсет при разборе инцидентов, с которыми я столкнулась. Я увидела, что у нас слишком большое расстояние между конечным офсетом и

116: Текущим офсетом консьюмера, и этот термин называется лагом, то есть то количество сообщений, которое у нас находится в режиме ожидания прочтения консьюмером, то есть расстояние между log n.

117: И current офсет допустимый лаг для каждого приложения свой это тесно связано с бизнес логикой и требованиями к работе системы, поэтому системным аналитикам тоже нужно будет об этом, в свою очередь, подумать какой

118: Момент. Нам стоит поднимать красный флаг и смотреть, что же с нашими партициями происходит, почему лак наш увеличивается. Теперь самая приятная часть для меня. Из чего же состоят наши сообщения, наши месседжи, которые мы отправляем в

119: Партицию. У нас есть 4 основных компонента ключ, значение таймстемп и опциональный набор метаданных. Он ещё называется хедерами. Каждое сообщение, каждый месседж.

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

121: Объект или вовсе пустой. Значение может быть любым, даже форматом. Джейсон протобаф и его будет наш месседж хранить. Аналитики наши занимаются описанием структуры значе.

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

123: По параметрам, но это может быть что угодно. Мне кажется, основной формат у всех json. То есть я тоже с чем встречалась, с экспертами тоже работаем на обучении. Вот прям все даём. Джейсон, это

124: Основной понятный удобный формат и тоже на проектах, где я работаю это json в общем то реально как бы наверное выбор просто очевиден из за того, что он простой, удобный и rest api в целом его привнёс.

125: И закрепил в наших сердцах про кафку мы поговорили, но у нас же есть ещё 1 распространённый брокер, который называется rabbit, и очень часто кафку сравни.

126: Именно с этой технологией, с rabbitmq я пока ещё не встречала проекта, где эти 2 брокера использовались бы одновременно, но, уверена, такие есть будет здорово, если кто-то из наших слушателей.

127: Поделится таким опытом я предлагаю тоже верхнеуровнево пройтись по их основным отличиям 1 технологии от другой и на основе чего конкретно мы выбирали именно кафку, а не реббит и кафка, и rabbit.

128: Являются брокерами сообщений, главное отличие их друг от друга заключается в модели доставки, то есть kafka у нас добавляет сообщение в журнал, и консьюмер сам забирает информацию из топика, при этом

129: Брокер ребит самостоятельно отправляет сообщения получателям, помещает событие в очередь и отслеживает его статус. В зависимости от вашей бизнес логики, от вашей инфраструктуры вы можете выбрать тот,

130: Или иной вариант, но конкретно на нашем проекте нам больше подходила модель доставки кафка. Она была ближе по бизнес логике, поэтому это была причина номер раз. 2 причина это объём данных. Мы использовали брокеров.

131: В том числе для хранения аудита по нашим обращениям обращения работали достаточно много, было несколько операторов, они могли обращения переводить, менять статусы, добавлять туда задачи и все эти действия.

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

133: Большого количества источников большого количества информации для сборов, Логов, метрик больше подойдёт именно кафка, а не rabbit. Это будет их основное отличие друг от друга. Спасибо за такое.

134: Но пояснение и сравнение в целом кафки и rabbit, потому что очень часто вот аналитики тоже, кто не работал с брокерами, задаются этим вопросом. И здесь у нас, кажется, получился отличный разбор, что для

135: System. Вот на самом деле основной вывод, который хочется сделать вот для систем с высокой нагрузкой, всегда прекрасно подходит кафка. В остальных случаях, где требования к высокой

136: Нагрузки супер высокой нагрузки, масштабируемости не применяются. Там подойдёт и rabbit. То есть мы на проекте использовали рэббит, когда нам нужно было просто, например, отправлять сообщения.

137: Отправлять уведомления во внешние системы. И у нас, получается, сервисы продюсеры клали в брокер ребет события о том, что сообщение о том, что нужно доставить какое-то уведомление. И, соответственно, уже сервис уведомлений, как консьюмер читал их из

138: И дальше рассылал по соответствующим внешним системам там push-уведомления, что ещё у нас емейл СМС и так далее, в зависимости от того, что необходимо было доставить для нашего пользователя. То есть там прекрасно подходи.

139: Rabbit, но в системах, где у нас идёт требование высокое к отказоустойчивости, к асинхронной работе и в целом к высокой производительности, там действительно вот прям можно уже не думать и не анализировать.

140: Очень долго выбирают кафку как идеальное, хорошо масштабируемое решение.

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

142: Можно было ставить постановку разработчикам, и они выполняли её с большим удовольствием. На самом деле, на верхнем уровне нужно знать все, все, о чем мы сегодня проговорили, аналитик.

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

144: В том числе есть сильные разработчики, которые некоторые вопросы могут решать самостоятельно, но никогда не знаешь, в какой команде окажешься. Поэтому нужно быть готовым ко всему. Также вас это самих тоже развивает, подковывает.

145: В техническом плане и 1 из веток развития системных аналитиков это ведь архитектор, и там без этого точно никуда. Давайте пройдёмся по обязательным пунктам. Что конкретно должно быть в вашей задаче? 1.

146: Это определить набор топиков самая важная часть, определить их набор с учётом привязки к бизнес задачам или сущностям, например topic может быть для пользовательских данных для.

147: Системных событий, если мы хотим что-то логгировать и любые другие, то есть это будет в зоне ответственности аналитика. В любом случае, вне зависимости даже от уровня подготовки разработчиков. Дальше необходимо определить, какие приложе

148: Будут у нас источниками, продюсерами. А какие приёмниками, то есть консьюмерами, нужно определить допустимую задержку отправки данных кафки, то есть тот самый

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

150: Данных часть из нефункциональных требований, поскольку кафка записывается, обращение на жёсткий диск. То есть потенциально они могут храниться там большое количество времени. И мы как раз-таки в сегодняшнем эпизоде тоже проговаривали, что

151: Это технически хоть и можно, но является такой плохой практикой. И это время нужно ограничивать. И тут системный аналитик может выставить срок. Сколько же такие вещи должны у нас на кафке храниться и здорово будет.

152: Если при определении топика вы приложите примеры сообщений, схему данных для него и максимальный размер, помня о том, что kafka с большими записями работает плохо, поэтому нужно пони.

153: Примеры, которые действительно будут работать у вас в партициях. У нас была история, когда записывали шаблоны решений на обращение клиентов и некоторые шаблоны могли достигаться нескольких Десятков листов.

154: 4. Это достаточно большой объём данных был и тут разработчикам мы это заранее подсветили, что данных будет много и они могли подготовиться к этому объёму и с точки зрения инфраструктуры тоже все поддержать. Поэтому

155: Данных, ограничения на размер файлов, ограничения на размер мессенджеров, которые будут храниться. Это тоже будет полезно сделать. Мне в целом кажется, что сама структура событий, сообщений это как 1 из основных частей.

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

157: Что мы должны отдать на вход. И, соответственно, что уже соседний сервис, так скажем, не соседний сервис, а консьюмер должен забрать в обработку данные наши все по постанов.

158: Задачи. Есть ли у тебя ещё какие-то рекомендации? Я думаю, основные пункты мы прошли, поэтому здесь все лиса, у меня есть ещё такой вопрос. Чем вы пользуетесь какими техническими средствами, инструментами?

159: Может быть, как системной аналитики, когда работаете с самой кафкой, как-то вы к ней подключаетесь или все в теории, в абстракции и даже не щупаете, а только в теории. Понимаете? Ну да, есть партиции, есть топики, есть.

160: Консьюмеры. Ну, короче, консьюмеры это ладно. В общем, есть топики, партиции и так далее. Кластеры, есть ли у вас возможность наживую на это все посмотреть? Возможность есть. Вот как как раз я столкнулась с

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

162: Через ui for apache kafka мы смотрим, какие у нас брокеры работают, какие в них есть партиции и какие есть сообщения, то есть это целая лог система, которая отображает полностью наше состояние кафки, и мы можем посмотреть.

163: Какие данные там находятся в режиме реального времени? Это все обновляется и смотрим для разбора наших инцидентов и в целом мониторинга состояния кластера. Спасибо тебе большое, что поделилась. Есть также

164: Ещё, кстати, кафка ту, на которой тоже можно посмотреть и другие инструменты для работы с ней. На этом у меня все. Я думаю, что мы сегодня разобрали просто кафку на максимум, насколько это

165: Было возможно, и я бы хотела у тебя попросить рекомендации для наших системных аналитиков. Что делать, если ни разу не работал с кафкой, ни разу не работал с брокерами и только начинае.

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

167: В виде ребита. И что здесь хочется посоветовать из книг. Это app кафка, потоковая обработка и анализ данных. Издатель здесь орейлохе ь техническая, возможно, даже для

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

169: У кого-то на проекте есть кафка, то будет здорово, если вы уже сейчас сможете взять задачи и попробовать реализовать сначала небольшую логику, например доработать какой-то готовый топик и заканчивая более сложной, как

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

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

172: Будет адаптировать. Спасибо тебе огромное за шаблон, который у нас будет прикреплён к эпизоду и за этот подкаст. На самом деле тема очень ценная, очень полезная. Мне кажется, что этот эпизод

173: Просто к переслушивание пересматриванию вместе с картинками презентации многократно, кто смотрел его на YouTube на RuTube все отлично, а те, кто слушал его в записи, то.

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

175: Время в своей практике, в своей работе на этом мы завершаем спасибо за то, что были сегодня с нами подписывайтесь на нас на всех площадках RuTube, YouTube, vk, telegram, яндекс музыка.

176: И других, где вы нас сегодня слушаете? С вами сегодня были. Я, Екатерина Ананьева, ведущая подкаста, и основатель сообщества системных аналитиков гетена иис и Елизавета Акманова, старший системный аналитик компании юсте.

177: До встречи в новых эпизодах.