Соглашения об именовании тем в Kafka — 5 рекомендаций с примерами

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

В самом начале разработки новых приложений с Apache Kafka возникает важный вопрос: какое имя дать моим Topics? Если у каждой команды или проекта своя схема именования, то, возможно, с этим можно смириться на этапе разработки. Однако это не очень способствует сотрудничеству, если неясно, какая тема будет использоваться и какие данные она несет. В крайнем случае, решение должно быть принято при запуске в эксплуатацию, чтобы предотвратить распространение схем наименования. В конце концов, темы нельзя переименовать: если со временем вы решите выбрать новое имя, вам придется удалить старую тему, создать новую тему с новым именем и адаптировать все зависимые приложения. Как же действовать дальше, что лучше всего подходит и на что следует обратить внимание?

Именование вещей — это всегда очень деликатная тема: Я хорошо помню совещания, на которых нужно было принять решение для общефирменного руководства по программированию, и этот пункт повестки дня просто не исчезал с совещания на совещание из-за споров об именовании переменных. В этой статье я хотел бы предоставить вам основу для принятия решений по именованию тем в вашем проекте или компании на основе нашего опыта в Xeotek. Как поставщик программного обеспечения для исследования и управления потоками данных для Apache Kafka & Amazon Kinesis (Xeotek KaDeck), мы, вероятно, видели и испытали почти все варианты практического использования.

Правило пивной подставки


Представленные здесь «лучшие практики» были получены в ходе реализации различных проектов с самыми разными клиентами и отраслями. Тем не менее, важно одно: не делайте слишком мало, но и не переусердствуйте! Методология, используемая для именования тем, естественно, зависит от размера компании и системного ландшафта. Следует по возможности избегать излишней инженерии: если в конце концов руководство по наименованию тем заполнит страницы и будет понятно лишь небольшой группе людей, то это не принесет пользы. Что касается объема, на ум всегда приходит цитата одного коллеги, которая кажется уместной в данный момент:
«Это должно помещаться на пивной подставке».

Структурный дизайн

Поскольку технически темы нельзя объединить в папки или группы, важно создать структуру для группировки и категоризации, по крайней мере, через название темы. Возникает вопрос, как должны быть разделены различные «папки», «свойства» или просто «компоненты». Это, прежде всего, дело вкуса. Хорошо зарекомендовало себя разделение точкой (.) и структура в смысле обратной нотации доменных имен (reverse-DNS).

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

При разделении точками рекомендуется (как и в случае с доменами) избегать капитализации: писать все в нижнем регистре. Это простое правило позволяет избежать философских вопросов вроде того, какое написание «MyIBMId», «MyIbmId» или «MyIBMid» сейчас лучше.

Как называются данные?

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

Читатели, которые уже сталкивались с попыткой создания единой, общефирменной модели данных (об этом ходит много легенд!), знают, в чем проблема: мало того, что могут существовать различия между техническими и бизнес-именами. Также между разными отделами один и тот же набор данных может иметь совершенно разное название («вездесущий язык»). Поэтому на данном этапе необходимо прояснить вопрос владения данными: кто является производителем данных или кому принадлежат данные? И с точки зрения проектирования, ориентированного на домен (DDD): в каком домене находятся данные?

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

<domain>.<subdomain1>.<subdomain...>.<data>
Вход в полноэкранный режим Выход из полноэкранного режима

Пример:

risk.portfolio.analysis.loans.csvimport or
sales.ecommerce.shoppingcarts
Войти в полноэкранный режим Выход из полноэкранного режима

Как видно из примера, это также вопрос размера компании и системного ландшафта: вам может потребоваться указать только один домен, а может и несколько поддоменов.

Кто может использовать данные?

В предыдущем разделе данные были структурированы на основе доменов и поддоменов. Особенно в крупных компаниях может иметь смысл обозначить междоменные темы и таким образом контролировать доступ и использование. Таким образом, уже из названия темы становится ясно, являются ли это данные, предназначенные только для внутренней обработки в пределах области (домена), или же поток данных (например, после принятия мер по обеспечению качества данных) может быть использован другими лицами в качестве надежного источника данных. Разумеется, это не заменяет управление правами и не предназначено для этого. Однако явная маркировка данных как «частных» или «публичных» с соответствующим префиксом предотвращает ошибочную работу других пользователей с «неофициальными», возможно, даже экспериментальными данными, не зная об этом.
Пример:

public. sales.ecommerce.shoppingcarts
private.risk.portfolio.analysis.loans.csvimport
Вход в полноэкранный режим Выход из полноэкранного режима

Чего следует избегать?

В дополнение к приведенным выше рекомендациям, которые хорошо работали в прошлом, существует также ряд подходов, которые работают не так хорошо. У вас должны быть веские причины для применения этих подходов (а они вполне могут быть), в противном случае их лучше избегать.

Одним из таких негативных опытов я считаю добавление номера версии к названию темы. Такой подход приводит не только к тому, что быстро создается бесчисленное количество тем, которые, возможно, не удастся так же быстро удалить. Особенно при наличии ограничения на количество тем или разделов, что характерно для многих управляемых провайдеров Apache Kafka, это может привести к настоящей проблеме. Кроме того, в худшем случае другим пользователям темы придется развертывать по одному экземпляру на каждую версию темы, если приложение может читать/писать только из одной темы. Если приложение может читать из нескольких тем одновременно (например, из всех версий), то при записи данных обратно в тему уже возникает следующая проблема: писать только в одну тему или снова разделить исходящие темы на соответствующие версии, поскольку последующие процессы могут иметь прямую зависимость от различных версий темы? Как видите, это быстро выведет вас на чистую воду. Лучший способ — добавить номер версии используемой схемы как часть заголовка к соответствующей записи. Это не решает проблему обработки версий в последующих процессах, но обзор не теряется. Еще лучше использовать реестр схем, в котором вся информация о схеме, версиях и совместимости хранится централизованно.

Использование имен приложений в качестве части имени темы также может быть проблематичным: более тесная связь вряд ли возможна. Однако и здесь есть исключения, например, для приложений компании, которые в любом случае являются неизменными. В таком случае нет смысла создавать большой слой абстракции, особенно если все в компании все равно запрашивают данные приложения X, а «нейтральное» имя вызывает путаницу. Однако имя доменной службы (например, «pricingengine») часто можно использовать в качестве хорошей альтернативы в смысле Domain-Driven Design.

Пример: Использование «pricingengine» в качестве имени приложения во избежание путаницы.

private.risk.portfolio.pricingengine.assetpricing
Вход в полноэкранный режим Выход из полноэкранного режима

Что насчет пространств имен или имен компаний?

Пространства имен следует использовать только в том случае, если нет другого выхода. Например, если у вас есть разные клиенты в среде Apache Kafka, имеет смысл добавлять название компании, например:

public.com.xeotek.sales.ecommerce.shoppingcarts
Войти в полноэкранный режим Выйти из полноэкранного режима

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

Обеспечение соблюдения правил именования тем и административные задачи

Чтобы обеспечить соблюдение правил именования тем, обязательно установите параметр auto.create.topics.enable для вашего брокера Apache Kafka в значение false. Это означает, что темы могут быть созданы только вручную, что с организационной точки зрения требует выполнения прикладного процесса. Например, ответственная команда инфраструктуры может рассматриваться как контакт для ручного создания тем. Для создания тем можно использовать консольное приложение «create-topic», поставляемое вместе с Apache Kafka, хотя рекомендуется обратить внимание на другие сторонние инструменты с графическим интерфейсом, не только из-за понятности, но, прежде всего, из-за огромной экономии времени на выполнение этой и других типичных задач.

В KaDeck Web, например, различным командам могут быть предоставлены права на самостоятельное создание тем, при условии, что темы соответствуют определенной схеме именования. Это означает, что команды в пределах своей области (домена) могут избежать бюрократического процесса и создавать и удалять темы по первому требованию, например, в целях тестирования, без привлечения сторонней помощи. Пользователь, действие и затронутая тема могут быть отслежены через журнал аудита, встроенный в KaDeck.

Кстати, Apache Kafka вообще поддерживает подстановочные знаки при выборе тем, например, при потреблении данных (т.е. в потребителе) или при назначении прав через ACL. Предложенная схема именования тем очень хорошо работает в этой комбинации: как рекомендуемое разделение «частных» и «публичных» тем, так и использование доменных имен в качестве части имени, позволяют создавать и контролировать доступ для команд из разных доменов очень интуитивно и быстро.

Заключение

Эта статья представляет собой список рекомендаций, которые оказались полезными в прошлом при именовании тем. Исключение подтверждает правило: возможно, имеет смысл использовать другое измерение для структурирования ваших тем, или некоторые из идей, которые я внес в список подходов, которых следует избегать, имеют смысл в вашем случае. Не стесняйтесь, дайте мне знать (Twitter: @benjaminbuick или команда Xeotek через @xeotekgmbh)!

Бен

Оцените статью
devanswers.ru
Добавить комментарий