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

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

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


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

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


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

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

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

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

Рекомендация1


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

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

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

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

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

Выйти из полноэкранного режима

Пример:

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

Выйти из полноэкранного режима

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

Рекомендация2


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

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

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

Выйти из полноэкранного режима

Описание изображения


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

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

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

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

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

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

Выйти из полноэкранного режима

Рекомендация4


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

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

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

Выйти из полноэкранного режима

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

Рекомендация5


Применение правил именования тем и административных задач

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

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

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


Вывод

Программное обеспечение Кадек

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

Бен