Архитектура данных и Теорема CAP где происходит столкновение?

Архитектура данных и Теорема CAP столкновение?

Примечание редактора: Джоэп Коккелер выступит на ODSC West в этом году. Обязательно посмотрите его выступление “Capturing CAP в архитектуре данных Kappa”!

Прежде чем погружаться в различные типы архитектуры данных, давайте сначала сосредоточимся на теореме CAP. Теорема CAP утверждает, что в любой системе (за исключением ACID-транзакций на данный момент) вы можете иметь два из следующих, но никогда все три: согласованность, доступность и отказоустойчивость. Чтобы справиться с этим, вы можете сделать правильный выбор при выборе типа архитектуры.

Когда речь идет об архитектуре, люди всегда предполагают, что они знают, что имеется в виду под тем или иным типом архитектуры. Но что, если вы этого не знаете? Допустим, вы знаете техническую реализацию лямбда-архитектуры, но вы не знаете, что это значит в сравнении с другими реализациями.

• Университет Сан-Франциско Конференция по науке о данных 2023 года Datathon в партнерстве с AWS и лабораторией Amazon SageMaker Studio
• Сохранение Зелени Ускоренная аналитика сокращает затраты и выбросы углерода
• Овладение искусством оптимизации ценообразования – решение науки о данных

Позвольте мне объяснить на простом примере.

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

Монолит

Начнем с монолитной архитектуры. Как следует из названия, это большая, старая архитектура, она занимает много места и, вероятно, она слон. В частности, это африканский буш-слон, самый крупный слон. И есть один старый парень в вашей команде, который знает, как правильно позаботиться о нем, кто знает, какие кнопки он может нажимать, а от каких лучше держаться подальше. Один из стажеров попробовал поработать с этим великим зверем, но после того, как она потушила много пожаров на своем пути, лучше пусть заботится о монолите парень, который родился примерно в то же время, когда было придумано понятие архитектуры.

Микросервис

Следующий тип – это микросервисная архитектура. В микросервисной архитектуре важно создавать сервисы, которые имеют свои собственные обязанности. Иногда эти обязанности перекрываются, и прежде чем вы поймете, вы работаете с мини-монолитом. И попытка направить молодого серого слона туда, куда вы хотите, требует совершенно других навыков, чем работа с микросервисами. Мое лучшее сравнение с микросервисами – это стая волков. Когда они находятся в дикой природе, они движутся прямой линией (чтобы экономить энергию), и каждое место в стае имеет определенную ответственность.

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

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

Каппа

И наконец, каппа-архитектура. Представьте толстого пингвина, одного из тех ребят из “Мадагаскара”. Пингвины всегда должны двигаться в группах, поэтому внутри вашей каппа-архитектуры есть много групп пингвинов, которые просто улыбаются и машут. Но на самом деле мы хотим, чтобы наша архитектура была очень быстрой и умелой. Представьте себе того же пингвина, но с прикрепленной к нему ракетой на спине. Это основа нашей каппа-архитектуры. Много пингвинов с множеством ракет, прикрепленных к ним. Обратите внимание, что для работы с каппа-архитектурой не обязательно быть ракетным ученым.

Заключение

Теперь у нас есть представление о том, с какими зверями мы имеем дело, как мы можем реализовать одну из этих архитектур, чтобы иметь все три компонента теоремы CAP? Чтобы узнать, какой зверь (или пингвин с ракетой) лучше всего подходит для теоремы CAP, приходите ко мне на конференцию ODSC West в Сан-Франциско, чтобы получить более подробное объяснение этой проблемы и увидеть меня вживую продемонстрировать различные реализации.

Об авторе:

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

Он являлся членом программного комитета Teqnation, проводил презентацию о использовании Kafka и Hue во время футбольных матчей, о разработке и развертывании на Hololens, о полном цикле DevOps с использованием GitLab, об эволюции продукта науки о данных, об использовании эластического стека от PoC до внедрения в производство, о использовании Xbox Kinect на велосипеде на конференции Devoxx London.