Качественная архитектура данных обеспечивает возможность бесперебойного взаимодействия с данными на каждом этапе их жизненного цикла и в фоновых процессах. Мы начнём с определения архитектуры данных, а затем обсудим компоненты и соображения. Затем мы коснёмся конкретных шаблонов пакетной обработки (хранилища данных, озёра данных), шаблонов потоковой передачи и шаблонов, которые объединяют пакетную и потоковую передачу. На протяжении всей главы мы будем подчеркивать использование возможностей облака для обеспечения масштабируемости, доступности и надёжности.

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

Что такое архитектура данных (data architecture)? Когда вы останавливаетесь на выяснении этого, всё становится немного туманно; исследование архитектуры данных даёт много непоследовательных и часто устаревших определений. Это очень похоже на то, как мы определяли инженерию данных в Главе 1 — нет единого мнения. Для области, которая постоянно меняется, это ожидаемо. Так что же мы подразумеваем под архитектурой данных в плоскости этой книги? Прежде чем дать определение термину, важно понять контекст, в котором он находится. Давайте кратко рассмотрим архитектуру предприятия, которая будет задавать наше определение архитектуры данных.

Архитектура предприятия включает множество подразделов, включая бизнес, техническую и прикладную части, данные (рисунок 3-1). Таким образом, архитектуре предприятия посвящено множество фреймворков и ресурсов. По правде говоря, архитектура — это удивительно спорная тема.

Термин «предприятие» вызывает неоднозначную реакцию. Он навевает ассоциации со стерильными корпоративными офисами, командно-административным/водопадным планированием, застойной деловой культурой и пустыми фразами. Тем не менее, мы можем кое-чему здесь поучиться.

Прежде чем определить и описать архитектуру предприятия, давайте разберём этот термин. Давайте посмотрим, как определяется архитектура предприятия некоторыми влиятельными лидерами мысли: TOGAF, Gartner и EABOK.

TOGAF — это The Open Group Architecture Framework, стандарт The Open Group. Он позиционируется как наиболее широко используемый архитектурный фреймворк сегодня. Вот определение TOGAF:

Термин «предприятие» в контексте «архитектуры предприятия» может обозначать целое предприятие — охватывающее все его информационные и технологические услуги, процессы и инфраструктуру — или определённый домен в пределах предприятия. В обоих случаях архитектура пересекает несколько систем и несколько функциональных групп в пределах предприятия.

Gartner — это глобальная исследовательская и консалтинговая компания, которая выпускает исследовательские статьи и отчеты о тенденциях, связанных с предприятиями. Среди прочего, она отвечает за (печально) известный Gartner Hype Cycle. Gartner даёт следующее определение:

Архитектура предприятия (enterprise architecture) — это дисциплина для проактивного и целостного руководства реагированием предприятия на разрушающие силы путём выявления и анализа реализации изменений в направлении желаемого видения и результатов бизнеса. АП обеспечивает ценность, предоставляя руководителям бизнеса и ИТ готовые к выполнению рекомендации по корректировке политик и проектов для достижения целевых бизнес-результатов, которые извлекают выгоду из соответствующих сбоев в бизнесе.

EABOK — это Enterprise Architecture Book of Knowledge, справочник по корпоративной архитектуре, выпущенный корпорацией MITRE. EABOK был выпущен как неполный черновик в 2004 году и с тех пор не обновлялся. Несмотря на то, что EABOK, очевидно, устарел, на него часто ссылаются в описаниях корпоративной архитектуры; мы обнаружили, что многие из его идей полезны при написании этой книги. Вот определение EABOK:

Архитектура предприятия — это организационная модель, абстрактное представление предприятия, которое объединяет стратегию, операции и технологии для создания дорожной карты успеха.

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

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

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

Джеффу Безосу приписывают идею односторонних и двусторонних дверей. Односторонняя дверь (one-way door) — это решение, которое практически невозможно отменить. Например, Amazon могла бы решить продать AWS или закрыть его. Для Amazon было бы практически невозможно восстановить публичное облако с той же позицией на рынке после такого действия.
С другой стороны, двусторонняя дверь (two-way door) — это легко обратимое решение: вы входите и остаетесь, если вам нравится то, что вы видите в комнате, или выходите назад через дверь, если вам не нравится. Amazon может решить потребовать использования DynamoDB для новой базы данных микросервисов. Если эта политика не работает, Amazon имеет возможность отменить её и рефакторинговать некоторые сервисы для использования других баз данных. Поскольку ставки, связанные с каждым обратимым решением (двусторонняя дверь), низки, организации могут принимать больше решений, итерируя, улучшая и быстро собирая данные.

Управление изменениями тесно связано с обратимыми решениями и является центральной темой фреймворков архитектуры предприятия. Даже с акцентом на обратимые решения предприятиям часто приходится предпринимать крупные инициативы. В идеале они разбиваются на более мелкие изменения, каждое из которых само по себе является обратимым решением. Возвращаясь к Amazon, мы отмечаем пятилетний разрыв (с 2007 по 2012 год) между публикацией статьи о концепции DynamoDB и объявлением Вернера Фогелса о сервисе DynamoDB на AWS. За кулисами команды предприняли множество небольших действий, чтобы сделать DynamoDB реальностью для клиентов AWS. Управление такими небольшими действиями лежит в основе управления изменениями.

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

Мы нашли значительное вдохновение в книге «Основы архитектуры программного обеспечения» Марка Ричардса и Нила Форда (O’Reilly). Они подчеркивают, что компромиссы неизбежны и повсеместны в инженерной среде. Иногда относительно текучая природа программного обеспечения и данных заставляет нас верить, что мы свободны от ограничений, с которыми инженеры сталкиваются в жёстком, холодном физическом мире.

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

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

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

TOGAF определяет архитектуру предприятия так:

Описание структуры и взаимодействия основных типов и источников данных предприятия, логических активов данных, физических активов данных и ресурсов управления данными.

DAMA DMBOK определяет архитектуру предприятия так:

Определение потребностей предприятия в данных (независимо от структуры) и разработка и поддержка основных схем для удовлетворения этих потребностей. Использование основных схем для управления интеграцией данных, контроля активов данных и согласования инвестиций в данные с бизнес-стратегией.

Принимая во внимание два предыдущих определения и наш опыт, мы разработали своё определение архитектуры данных:

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

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

Другие аспекты архитектуры данных, о которых вам следует знать, — операционные и технические (рисунок 3-2). Операционная архитектура охватывает функциональные требования к тому, что должно произойти в отношении людей, процессов и технологий. Например, какие бизнес-процессы обслуживают данные? Как организация управляет качеством данных? Каковы требования к времени с момента создания данных до момента, когда они становятся доступны для запроса? Техническая архитектура описывает, как данные принимаются, хранятся, преобразуются и обслуживаются в течение жизненного цикла проектирования данных. Например, как вы будете перемещать 10 ТБ данных каждый час из исходной базы данных в свое озеро данных? Короче говоря, операционная архитектура описывает, что необходимо сделать, а техническая архитектура подробно описывает, как это будет происходить.

Теперь, когда у нас есть рабочее определение архитектуры данных, давайте рассмотрим элементы «хорошей» архитектуры данных.

По словам Грэди Буча, «Архитектура представляет собой значимые проектные решения, которые формируют систему, где значимость измеряется стоимостью изменений». Архитекторы данных стремятся принимать значимые решения, которые станут качественной архитектурой на базовом уровне.

Что мы подразумеваем под «качественной» архитектурой данных? Перефразируя старое клише: как только увидишь — сразу поймешь. Хорошая архитектура данных удовлетворяет бизнес-требованиям с помощью общего, широко используемого набора строительных блоков, сохраняя гибкость и делая соответствующие компромиссы. Плохая архитектура авторитарна и пытается втиснуть кучу универсальных решений в большой ком грязи.

Гибкость — основа хорошей архитектуры данных; она признаёт, что мир изменчив. Хорошая архитектура данных гибка и проста в обслуживании. Она развивается в ответ на изменения в бизнесе и новые технологии и практики, которые могут открыть ещё большую ценность в будущем. Бизнес и его варианты использования данных постоянно развиваются. Мир динамичен, и темпы изменений в пространстве данных ускоряются. Архитектура данных прошлого года, которая хорошо вам служила, может оказаться недостаточной для сегодняшнего дня, не говоря уже о следующем году.

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

Фоновые процессы жизненного цикла инженерии данных формируют основу хорошей архитектуры данных для компаний на любой стадии зрелости данных. Напомним, эти эти фоновые процессы — это безопасность, управление данными, DataOps, архитектура данных, оркестровка и программная инженерия.

Хорошая архитектура данных — это живое, дышащее существо. Она никогда не заканчивается. Фактически, согласно нашему определению, изменение и эволюция являются центральными для смысла и цели архитектуры данных. Давайте теперь рассмотрим принципы хорошей архитектуры данных.

В этом разделе мы взглянем на архитектуру сверху, сосредоточившись на принципах — ключевых идеях, полезных при оценке основных архитектурных решений и практик. Мы черпаем вдохновение для наших архитектурных принципов из нескольких источников, например из AWS Well-Architected Framework и Google Cloud’s Five Principles for Cloud-Native Architecture.

AWS Well-Architected Framework состоит из шести столпов:

• Эксплуатационное совершенство
• Безопасность
• Надёжность
• Эффективность работы
• Оптимизация затрат
• Устойчивость

Пять принципов Google Cloud для облачной архитектуры таковы:

• Проектируйте для автоматизации.
• Разумно подходите к состоянию.
• Отдавайте предпочтение управляемым сервисам.
• Практикуйте глубокую защиту.
• Всегда занимайтесь архитектурой.

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

1. Выбирайте общие компоненты разумно.
2. Планируйте сбои.
3. Разрабатывайте архитектуру для масштабируемости.
4. Архитектура — это лидерство.
5. Всегда занимайтесь архитектурой.
6. Создавайте слабосвязанные системы.
7. Принимайте обратимые решения.
8. Приоритезируйте безопасность.
9. Используйте FinOps.

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

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

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

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

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

Доступность
Процент времени, в течение которого ИТ-услуга или компонент находится в работоспособном состоянии.

Надёжность
Вероятность соответствия системы определённым стандартам при выполнении ею своей предполагаемой функции в течение определённого интервала времени.

Целевое время восстановления
Максимально приемлемое время для сбоя сервиса или системы. Целевое время восстановления (recovery time objective) обычно устанавливается путём определения влияния сбоя на бизнес. ЦВВ в один день может быть приемлемым для внутренней системы отчетности. Сбой веб-сайта всего на пять минут может иметь значительные неблагоприятные последствия для интернет-магазина.

Целевая точка восстановления
Приемлемое состояние после восстановления. В системах данных данные часто теряются во время сбоя. В этом случае целевая точка восстановления (recovery point objective) относится к максимально допустимой потере данных.
Инженерам необходимо учитывать приемлемую надёжность, доступность, ЦВВ и ЦТВ при планировании сбоев. Они будут определять их архитектурные решения при оценке возможных сценариев сбоев.

Масштабируемость в системах данных охватывает две основные возможности. Во-первых, масштабируемые системы могут масштабироваться для обработки значительных объёмов данных. Нам может потребоваться развернуть большой кластер для обучения модели на петабайте данных клиентов или масштабировать потоковую систему приёма для обработки кратковременного скачка нагрузки. Наша способность к масштабированию позволяет нам временно справляться с экстремальными нагрузками. Во-вторых, масштабируемые системы могут масштабироваться в меньшую сторону. Как только скачок нагрузки спадает, мы должны автоматически удалять емкость, чтобы сократить расходы. (Это связано с принципом 9.) Эластичная система может масштабироваться динамически в ответ на нагрузку, в идеале в автоматическом режиме.

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

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

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

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

Возвращаясь к понятию технического лидерства, Мартин Фаулер описывает определённый архетип идеального архитектора программного обеспечения, хорошо воплощенный в его коллеге Дэйве Райсе:

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

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

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

Мы заимствуем этот принцип напрямую из Five Principles for Cloud-
Native Architecture от Google Cloud. Архитекторы данных не просто выполняют свою роль, чтобы поддерживать существующее состояние; вместо этого они постоянно проектируют новые и захватывающие вещи в ответ на изменения в бизнесе и технологиях. Согласно EABOK, работа архитектора заключается в том, чтобы развивать глубокие знания базовой архитектуры (текущего состояния), разрабатывать целевую архитектуру и составлять план последовательности для определения приоритетов и порядка изменений архитектуры.

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

В 2002 году Безос написал электронное письмо сотрудникам Amazon, которое стало известно как «Мандат Безоса по API»:

1. Все команды отныне будут предоставлять свои данные и функциональность через интерфейсы служб.
2. Команды должны общаться друг с другом через эти интерфейсы.
3. Не будет разрешена никакая другая форма межпроцессного взаимодействия: никаких прямых ссылок, никаких прямых чтений хранилища данных другой команды, никакой модели общей памяти, никаких бэкдоров вообще. Единственное разрешенное взаимодействие — это вызовы интерфейсов служб по сети.
4. Неважно, какую технологию они используют. HTTP, Corba, Pubsub, пользовательские протоколы — неважно.
5. Все интерфейсы служб без исключения должны быть спроектированы с нуля так, чтобы их можно было вынести наружу. То есть команда должна планировать и проектировать так, чтобы иметь возможность предоставлять интерфейс разработчикам во внешнем мире. Исключений нет.

Появление Мандат Безоса по API часто рассматривается как переломный момент для Amazon. Размещение данных и сервисов за API позволило реализовать слабую связанность и в конечном итоге привело к AWS, какой мы её знаем сейчас. Стремление Google к слабой связанности позволило ей расширить свои системы до необычайных масштабов.
С точки зрения архитектуры программного обеспечения слабосвязанная система обладает следующими свойствами:

1. Системы разбиты на множество небольших компонентов.
2. Эти системы взаимодействуют с другими службами через уровни абстракции, такие как шина обмена сообщениями или API. Эти уровни абстракции скрывают и защищают внутренние детали службы, такие как бэкенд базы данных или внутренние классы и вызовы методов.
3. Как следствие свойства 2, внутренние изменения компонента системы не требуют изменений в других частях. Подробности обновлений кода скрыты за стабильными API. Каждая часть может развиваться и улучшаться отдельно.
4. Как следствие свойства 3, нет каскадного, глобального цикла выпуска для всей системы. Вместо этого каждый компонент обновляется отдельно по мере внесения изменений и улучшений.

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

1. Много небольших команд проектируют большую сложную систему. Каждая команда занимается проектированием, обслуживанием и улучшением отдельных компонентов системы.
2. Эти команды передают абстрактные детали своих компонентов другим командам через определения API, схемы сообщений и т. д. Командам не нужно беспокоиться о компонентах других команд; они просто используют опубликованные спецификации API или сообщений для вызова этих компонентов. Они повторяют свою часть, чтобы со временем улучшить свою производительность и возможности. Они также могут публиковать новые возможности по мере их добавления или запрашивать новые материалы у других команд. Опять же, последнее происходит без необходимости командам беспокоиться о внутренних технических деталях запрашиваемых функций. Команды работают вместе посредством слабосвязанной коммуникации.
3. Вследствие характеристики 2 каждая команда может быстро развивать и улучшать свой компонент независимо от работы других команд.
4. В частности, характеристика 3 подразумевает, что команды могут выпускать обновления своих компонентов с минимальным временем простоя. Команды выпускают релизы непрерывно в течение обычных рабочих часов, чтобы вносить изменения в код и тестировать их.

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

Ландшафт данных быстро меняется. Сегодняшние популярные технологии или стеки — завтра такими быть перестанут. Популярное мнение быстро меняется. Вам следует стремиться к обратимым решениям, поскольку они, как правило, упрощают вашу архитектуру и сохраняют ее гибкость.

Как писал Фаулер, «Одной из важнейших задач архитектора является устранение архитектуры путём поиска способов устранения необратимости в проектах программного обеспечения». То, что было верно, когда Фаулер написал это в 2003 году, так же верно и сегодня.

Как мы уже говорили ранее, Безос называет обратимые решения «двусторонними дверями». Как он говорит: «Если вы заходите и вам не нравится то, что вы видите на другой стороне, вы не можете вернуться к прежнему. Мы можем назвать это решениями типа 1. Но большинство решений не такие — они изменяемы, обратимы — это двусторонние двери». Стремитесь к ним, когда это возможно.

Учитывая темпы изменений — и разъединение/модуляризацию технологий в архитектуре данных — всегда стремитесь выбирать лучшие в своем классе решения, которые работают сегодня. Также будьте готовы к обновлению или внедрению лучших практик по мере развития ландшафта.

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

Модели безопасности с усиленным периметром и нулевым доверием
Чтобы определить безопасность с нулевым доверием, полезно начать с понимания традиционной модели безопасности жесткого периметра и ее ограничений, как подробно описано в Пяти принципах Google Cloud:

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

Фильм 1996 года «Миссия невыполнима» представляет собой прекрасный пример модели безопасности с жёстким периметром и её ограничений. В фильме ЦРУ размещает высокочувствительные данные в системе хранения внутри комнаты с чрезвычайно жёсткой физической безопасностью. Итан Хант проникает в штаб-квартиру ЦРУ и использует живую мишень, чтобы получить физический доступ к системе хранения. Попав в защищенную комнату, он может относительно легко извлечь данные.

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

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

Amazon делает акцент на модели разделения ответственности, которая разделяет безопасность на безопасность облака и безопасность в облаке. AWS отвечает за безопасность облака:

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

Пользователи AWS несут ответственность за безопасность в облаке:

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

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

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

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

Давайте начнём с рассмотрения пары определений FinOps. Во-первых, FinOps Foundation предлагает следующее:

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

Кроме того, Дж. Р. Сормент и Майк Фуллер дают следующее определение в книге Cloud FinOps:

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

Структура расходов на данные претерпела существенные изменения в эпоху облачных вычислений. В локальной среде системы данных обычно приобретаются с капитальными затратами (подробнее см. в Главе 4) на новую систему каждые несколько лет. Ответственные стороны должны сбалансировать свой бюджет с желаемой вычислительной мощностью и ёмкостью хранения. Чрезмерная закупка влечет за собой потерю денег, в то время как недостаточная означает затруднение будущих проектов по работе с данными и значительные затраты времени персонала на контроль нагрузки на систему и размера данных; недостаточная закупка может потребовать более быстрых циклов обновления технологий с соответствующими дополнительными расходами.

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

Облачные инструменты требуют набора процессов для управления расходами и ресурсами. В прошлом инженеры данных мыслили в терминах проектирования производительности — максимизации производительности для процессов обработки данных на фиксированном наборе ресурсов и покупки адекватных ресурсов для будущих потребностей. С FinOps инженерам нужно научиться думать о структурах затрат облачных систем. Например, каково подходящее сочетание спотовых экземпляров AWS при работе распределённого кластера? Какой подход является наиболее подходящим для выполнения значительной ежедневной работы с точки зрения экономической эффективности и производительности? Когда компании следует переходить с модели оплаты за запрос на зарезервированную емкость?

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

Команды Ops также должны думать в терминах атак затрат. Так же, как распределёная атака «отказ в обслуживании» (DDoS) может заблокировать доступ к веб-серверу, многие компании обнаружили, к своему огорчению, что чрезмерные загрузки из S3-корзин могут привести к заоблачным расходам и поставить небольшой стартап под угрозу банкротства. При публичном обмене данными команды по работе с данными могут решать эти проблемы, устанавливая политику «платит запрашивающая сторона» или просто отслеживая чрезмерные расходы на доступ к данным и быстро блокируя доступ, если расходы начинают расти до неприемлемых уровней.

На момент написания этой книги FinOps — это недавно формализованная практика. Фонд FinOps был запущен только в 2019 году. Однако мы настоятельно рекомендуем вам начать думать о FinOps заранее, до того, как вы столкнетесь с высокими счетами за облачные вычисления. Начните свой путь с FinOps Foundation и O’Reilly’s Cloud FinOps. Мы также предлагаем инженерам данных включиться в процесс сообщества по созданию практик FinOps для обработки данных — в такой новой области практики ещё многое предстоит охватить.

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

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

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

Домен может содержать несколько сервисов. Например, у вас может быть домен продаж с тремя сервисами: заказы, выставление счетов и продукты. У каждого сервиса есть определённые задачи, которые поддерживают домен продаж. Другие домены также могут совместно использовать сервисы (рисунок 3-3). В этом случае домен бухгалтерского учета отвечает за основные функции бухгалтерского учета: выставление счетов, расчёт заработной платы и дебиторскую задолженность (ДЗ). Обратите внимание, что домен бухгалтерского учёта разделяет службу счетов с доменом продаж, поскольку продажа генерирует счёт, а бухгалтерский учёт должен отслеживать счета, чтобы гарантировать получение оплаты. Продажи и бухгалтерский учёт владеют своими соответствующими доменами.

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

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

Обсуждение в этом разделе связано с нашими вторым и третьим принципами архитектуры инженерии данных, которые обсуждались ранее: план на случай отказа и архитектор для масштабируемости. Как инженеры данных, мы заинтересованы в четырёх тесно связанных характеристиках систем данных (доступность и надёжность упоминались ранее, но мы повторяем их здесь для полноты):

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

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

Доступность
Процент времени, в течение которого ИТ-услуга или компонент находится в работоспособном состоянии.

Надёжность
Вероятность соответствия системы определённым стандартам при выполнении ею своей предполагаемой функции в течение определённого интервала времени.

Как связаны эти характеристики? Если система не соответствует требованиям производительности в течение определённого интервала, она может перестать отзываться. Таким образом, низкая надёжность может привести к низкой доступности. С другой стороны, динамическое масштабирование помогает обеспечить адекватную производительность без ручного вмешательства инженеров — эластичность повышает надёжность.

Масштабируемость может быть реализована различными способами. Что касается ваших сервисов и доменов, всё ли обрабатывает одна машина? Одна машина может масштабироваться вертикально; вы можете увеличивать ресурсы (ЦП, диск, память, ввод-вывод). Но существуют жёсткие ограничения на возможные ресурсы на одной машине. Кроме того, что произойдёт, если эта машина сломается? При достаточном количестве времени некоторые компоненты в конечном итоге выйдут из строя. Каков ваш план резервного копирования и аварийного переключения? Отдельные машины, как правило, не могут обеспечить высокую доступность и надёжность.

Мы используем распределённую систему для реализации более высокой общей масштабируемой ёмкости и повышенной доступности и надёжности. Горизонтальное масштабирование позволяет добавлять больше машин для удовлетворения требований к нагрузке и ресурсам (рисунок 3-4). Обычные горизонтально масштабируемые системы имеют ведущий узел, который выступает в качестве основной точки контакта для создания экземпляра, выполнения и завершения рабочих нагрузок. Когда рабочая нагрузка запускается, ведущий узел распределяет задачи по рабочим узлам в своей системе, завершая задачи и возвращая результаты ведущему узлу. Типичные современные распределённые архитектуры также создают избыточность. Данные реплицируются, так что если машина выходит из строя, другие машины могут продолжить работу с того места, на котором остановился отсутствующий сервер; кластер может добавлять больше машин для восстановления ёмкости.

Распределённые системы широко распространены в различных технологиях данных, которые вы будете использовать в своей архитектуре. Почти каждая система хранения объектов облачного хранилища данных, которую вы используете, имеет некоторое представление о распределении под капотом. Детали управления распределённой системой, как правило, абстрагируются, что позволяет вам сосредоточиться на архитектуре высокого уровня, а не на внутренних механизмах низкого уровня. Тем не менее, мы настоятельно рекомендуем вам узнать больше о распределённых системах, поскольку эти детали могут быть чрезвычайно полезны для понимания и повышения производительности ваших конвейеров; «Проектирование высоконагруженных приложений» Мартина Клеппмана (O’Reilly) — отличный ресурс.

При проектировании архитектуры данных вы выбираете, сколько взаимозависимости вы хотите включить в свои домены, сервисы и ресурсы. С одной стороны вы можете выбрать чрезвычайно централизованные зависимости и рабочие процессы. Каждая часть домена и сервиса жизненно зависит от каждого другого домена и сервиса. Этот шаблон известен как сильно связанный (tightly coupled).

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

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

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

Одноуровневая архитектура. В одноуровневой архитектуре ваша база данных и приложение сильно связаны и находятся на одном сервере (рисунок 3-5). Этим сервером может быть ваш ноутбук или одна виртуальная машина (ВМ) в облаке. Сильная связь означает, что если сервер, база данных или приложение выходят из строя, вся архитектура выходит из строя. Хотя одноуровневые архитектуры хороши для создания прототипов и разработки, они не рекомендуются для производственных сред из-за очевидных рисков сбоев.

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

Многоуровневая архитектура. Проблемы сильно связанной одноуровневой архитектуры решаются путём разделения данных и приложения. Многоуровневая (также известная как n-уровневая) архитектура состоит из отдельных слоёв: данные, приложение, бизнес-логика, представление и т. д. Эти слои являются восходящими и иерархическими, что означает, что нижний слой не обязательно зависит от верхних слоев; верхние слои зависят от нижних слоев. Идея заключается в том, чтобы отделить данные от приложения, а приложение от представления.

Распространённая многоуровневая архитектура — это трехуровневая архитектура, широко используемая клиент-серверная конструкция. Трехуровневая архитектура состоит из уровней данных, прикладной логики и представления (рисунок 3-6). Каждый уровень изолирован от другого, что позволяет разделить проблемы. С трехуровневой архитектурой вы можете использовать любые технологии, которые предпочитаете, на каждом уровне без необходимости сосредоточиться на монолите.

Мы видели много одноуровневых архитектур в производстве. Одноуровневые архитектуры предлагают простоту, но также и серьёзные ограничения. В конце концов, организация или приложение перерастают эту схему; она работает хорошо до поры. Например, в одноуровневой архитектуре уровни данных и логики совместно используют и конкурируют за ресурсы (диск, ЦП и память) способами, которых просто избегают в многоуровневой архитектуре. Ресурсы распределены по разным уровням. Инженеры по работе с данными должны использовать уровни для оценки своей многоуровневой архитектуры и способа обработки зависимостей. Опять же, начните с простого и постепенно добавляйте дополнительные уровни по мере усложнения архитектуры.

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

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

Связывание внутри монолитов можно рассматривать двумя способами: техническое связывание и доменное связывание. Техническое связывание (technical coupling) относится к архитектурным уровням, в то время как доменное связывание (domain coupling) относится к способу, которым домены связаны друг с другом. Монолит имеет различные степени связывания между технологиями и доменами. У вас может быть приложение с различными слоями, разделёнными в многоуровневой архитектуре, но при этом совместно использующими несколько доменов. Или у вас может быть одноуровневая архитектура, обслуживающая один домен.

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

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

По сравнению с атрибутами монолита — переплетёнными сервисами, централизацией и сильной связью между сервисами — микросервисы являются полной противоположностью. Микросервисная архитектура (microservices architecture) включает отдельные, децентрализованные и слабосвязанные сервисы. Каждый сервис имеет определенную функцию и отделён от других сервисов, работающих в его домене. Если один сервис временно выходит из строя, это не повлияет на способность других сервисов продолжать функционировать.

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

Если вы хотите узнать больше о том, как разбить монолит на части, мы рекомендуем вам прочитать замечательное и практичное руководство «Архитектура программного обеспечения: сложные детали» Нила Форда и др. (O’Reilly).

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

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

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

Как видно на рисунке 3-7, вы разделяете компоненты своей архитектуры на различные уровни интереса в вертикальном направлении. Хотя многоуровневая архитектура решает технические проблемы разделения общих ресурсов, она не решает сложность совместного использования доменов. В соответствии с принципами одно- и многоуровневой архитектуры, вам также следует рассмотреть, как вы разделяете домены вашей архитектуры данных. Например, ваша аналитическая группа может полагаться на данные по продажам и запасам. Домены продаж и запасов различны и должны рассматриваться как отдельные.

Одним из подходов к этой проблеме является централизация: одна команда отвечает за сбор данных из всех доменов и согласование их для потребления в рамках всей организации. (Это распространенный подход в традиционном хранилище данных.) Другой подход — сетка данных. С сеткой данных каждая команда разработчиков программного обеспечения отвечает за подготовку своих данных для потребления в рамках всей остальной организации. Мы расскажем больше о сетке данных позже в этой главе.

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

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

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

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

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

Событийно-ориентированный (event-driven) рабочий процесс (рисунок 3-8), охватывает возможность создания, обновления и асинхронного перемещения событий по различным частям жизненного цикла проектирования данных. Этот рабочий процесс сводится к трём основным областям: производство событий, маршрутизация и потребление. Событие должно быть произведено и направлено к чему-то, что его потребляет, без сильно связанных зависимостей между производителем, маршрутизатором событий и потребителем.

Событийно-ориентированная архитектура (event-driven architecture) (рисунок 3-9), охватывает рабочий процесс, управляемый событиями, и использует его для взаимодействия между различными сервисами. Преимущество событийно-ориентированной архитектуры заключается в том, что она распределяет состояние события по нескольким службам. Это полезно, если служба отключается, узел выходит из строя в распределённой системе или вы хотите, чтобы несколько потребителей или служб имели доступ к одним и тем же событиям. Всякий раз, когда у вас есть слабосвязанные службы, это кандидат на событийно-ориентированную архитектуру. Многие из примеров, которые мы опишем далее в этой главе, включают некоторую форму такой архитектуры.

Подробнее о событийно-ориентированных системах потоковой передачи и обмена сообщениями вы узнаете в Главе 5.

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

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

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

Важно отметить, что отказ от поддержки может оказаться советом «башни из слоновой кости», а не практичным или достижимым. Отказ от поддержки устаревших технологий или архитектуры может быть невозможен, если вы работаете в крупной организации. Кто-то где-то использует эти устаревшие компоненты. Как кто-то однажды сказал: «Легаси — это снисходительный способ описать то, что приносит деньги».

Если вы можете отказаться от старой архитектуры, поймите, что есть множество способов это сделать. Крайне важно продемонстрировать ценность новой платформы, постепенно увеличивая её зрелость, чтобы предъявить доказательства успеха, а затем следовать плану выхода, чтобы закрыть старые системы.

На противоположном конце спектра greenfield-проект позволяет вам начать все сначала, не ограничиваясь историей или легаси предыдущей архитектуры. Greenfield-проекты, как правило, проще brownfield-проектов, и многие архитекторы и инженеры данных находят их более интересными! У вас есть возможность попробовать новейшие и самые крутые инструменты и архитектурные шаблоны. Что может быть более захватывающим?

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

Независимо от того, работаете ли вы над brownfield или greenfield проектом, всегда сосредотачивайтесь на принципах «хорошей» архитектуры данных. Оценивайте компромиссы, принимайте гибкие и обратимые решения и стремитесь к положительной окупаемости инвестиций.

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

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

Хранилище данных (data warehouse) — это центральный узел данных, используемый для отчётности и анализа. Данные в хранилище данных обычно сильно отформатированы и структурированы для аналитических случаев использования. Это одна из старейших и наиболее устоявшихся архитектур данных.

В 1989 году Билл Инмон сформулировал понятие хранилища данных, которое он описал как «предметно-ориентированный, энергонезависимый, интегрированный, изменяющийся во времени набор данных для поддержки управленческих решений». Хотя технические аспекты хранилища данных значительно изменились, мы считаем, что это первоначальное определение по-прежнему сохраняет свою актуальность и сегодня.

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

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

Организационная архитектура хранилища данных имеет две основных характеристики:

Разделяет аналитическую онлайн-обработку (OLAP) и производственные базы данных (онлайн-обработка транзакций)

Это разделение имеет решающее значение по мере роста бизнеса. Перемещение данных в отдельную физическую систему отводит нагрузку от производственных систем и повышает производительность аналитики.

Традиционно хранилище данных извлекает данные из систем приложений с помощью ETL. Фаза извлечения вытягивает данные из исходных систем. Фаза преобразования очищает и стандартизирует данные, организуя и навязывая бизнес-логику в высокомоделированной форме. (Глава 8 охватывает преобразования и модели данных.) Фаза загрузки помещает данные в целевую систему базы данных хранилища данных. Данные загружаются в несколько витрин данных, которые обслуживают аналитические потребности для определенных линий или бизнеса и отделов. На рисунке 3-10 показан общий рабочий процесс. Хранилище данных и ETL идут рука об руку с определёнными бизнес-структурами, включая группы разработчиков DBA и ETL, которые реализуют указания руководителей бизнеса, чтобы гарантировать, что данные для отчётности и аналитики соответствуют бизнес-процессам.

Что касается технической архитектуры хранилища данных, то первые системы MPP из конца 1970-х годов стали популярными в 1980-х годах. MPP поддерживают по сути ту же семантику SQL, которая используется в реляционных базах данных приложений. Тем не менее, они оптимизированы для параллельного сканирования огромных объёмов данных и, таким образом, позволяют выполнять высокопроизводительную агрегацию и статистические вычисления. В последние годы системы MPP все чаще переходят от строчной к столбчатой ​​архитектуре, чтобы облегчить обработку еще больших данных и запросов, особенно в облачных хранилищах данных. MPP незаменимы для выполнения производительных запросов для крупных предприятий по мере роста потребностей в данных и отчетности.

Одной из вариаций ETL является ELT. С архитектурой хранилища данных ELT данные перемещаются более или менее напрямую из производственных систем в промежуточную область в хранилище данных. Промежуточное хранение в этой настройке указывает на то, что данные находятся в необработанном виде. Вместо использования внешней системы преобразования обрабатываются непосредственно в хранилище данных. Цель состоит в том, чтобы воспользоваться огромной вычислительной мощностью облачных хранилищ данных и инструментов обработки данных. Данные обрабатываются пакетами, а преобразованные выходные данные записываются в таблицы и представления для аналитики. На рисунке 3-11 показан общий процесс. ELT также популярен в потоковом расположении, поскольку события передаются потоком из процесса CDC, сохраняются в промежуточной области, а затем впоследствии преобразуются в хранилище данных.

Вторая версия ELT была популяризирована во время роста больших данных в экосистеме Hadoop. Это ELT с преобразованием при чтении, который мы обсуждаем в разделе «Озеро данных».

Облачные хранилища данных (cloud data warehouse) представляют собой значительную эволюцию архитектуры локальных хранилищ данных и, таким образом, привели к видимым изменениям в организационной архитектуре. Amazon Redshift положил начало революции облачных хранилищ данных. Вместо того, чтобы соответствующим образом определять размер системы MPP на следующие несколько лет и подписывать многомиллионный контракт на закупку системы, компании имели возможность развернуть кластер Redshift по требованию, масштабируя его со временем по мере роста спроса на данные и аналитику. Они даже могли развернуть новые кластеры Redshift по требованию для обслуживания определённых рабочих нагрузок и быстро удалять кластеры, когда они больше не нужны.

Google BigQuery, Snowflake и другие конкуренты популяризировали идею разделения вычислений и хранения. В этой архитектуре данные размещаются в объектном хранилище, что обеспечивает практически безграничное хранение. Это также дает пользователям возможность наращивать вычислительную мощность по требованию, предоставляя специальные возможности для больших данных без долгосрочных затрат на тысячи узлов.
Облачные хранилища данных расширяют возможности систем MPP, чтобы охватить множество случаев использования больших данных, для которых в недавнем прошлом требовался кластер Hadoop. Они могут легко обрабатывать петабайты данных в одном запросе. Обычно они поддерживают структуры данных, которые позволяют хранить десятки мегабайт необработанных текстовых данных на строку или чрезвычайно насыщенные и сложные документы JSON. По мере развития облачных хранилищ данных (и озер данных) граница между хранилищем данных и озером данных будет продолжать размываться.

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

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

Витрины данных существуют по двум причинам. Во-первых, киоски данных делают данные более доступными для аналитиков и разработчиков отчётов. Во-вторых, витрины данных обеспечивают дополнительный этап преобразования помимо того, который обеспечивается первоначальными конвейерами ETL или ELT. Производительность может быть значительно повышена, если отчёты или аналитические запросы требуют сложных объединений и агрегаций данных, особенно когда необработанные данные велики. Процессы преобразования могут заполнять витрины данных объединенными и агрегированными данными для повышения производительности для живых запросов. На рисунке 3-12 показан общий рабочий процесс. Мы обсуждаем витрины данных и моделирование данных для них в Главе 8.

Среди самых популярных архитектур, появившихся в эпоху больших данных, — озеро данных (data lake). Вместо того чтобы накладывать жесткие структурные ограничения на данные, почему бы просто не сбросить все свои данные — структурированные и неструктурированные — в одно место? Озеро данных обещало стать демократизирующей силой, освободив бизнес, чтобы он мог пить из фонтана безграничных данных. Озеро данных первого поколения, «озеро данных 1.0», внесло весомый вклад, но в целом не смогло выполнить свое обещание.

Data lake 1.0 начинался с HDFS. По мере роста популярности облака эти озёра данных перешли в облачное хранилище объектов с чрезвычайно низкой стоимостью хранения и практически безграничной ёмкостью. Вместо того чтобы полагаться на монолитное хранилище данных, где хранение и вычисления тесно связаны, озеро данных позволяет хранить огромное количество данных любого размера и типа. Когда эти данные необходимо запросить или преобразовать, у вас есть доступ к практически неограниченной вычислительной мощности; развернув кластер по требованию, вы можете выбрать любимую технологию обработки данных для текущей задачи — MapReduce, Spark, Ray, Presto, Hive и т. д.

Несмотря на обещания и шумиху, озеро данных 1.0 имело серьёзные недостатки. Озеро данных стало свалкой; такие термины, как «болото данных», «темные данные» и «WORN» были придуманы, когда изначально многообещающие проекты по работе с данными потерпели неудачу. Данные выросли до неуправляемых размеров, при этом было мало инструментов для управления схемами, каталогизации данных и обнаружения. Кроме того, первоначальная концепция озера данных была по сути только для записи, что создало огромные проблемы с появлением таких правил, как GDPR, которые требовали целенаправленного удаления записей пользователей.

Обработка данных также была сложной задачей. Относительно банальные преобразования данных, такие как объединения, были огромной головной болью для кодирования в виде заданий MapReduce. Более поздние фреймворки, такие как Pig и Hive, несколько улучшили ситуацию с обработкой данных, но мало что сделали для решения основных проблем управления данными. Простые операции языка манипулирования данными (DML), распространенные в SQL — удаление или обновление строк — были болезненными для реализации, как правило, достигались путём создания совершенно новых таблиц. В то время как инженеры больших данных излучали особое презрение к своим коллегам из области хранилищ данных, последние могли указать, что хранилища данных предоставляют базовые возможности управления данными из коробки, и что SQL является эффективным инструментом для написания сложных, производительных запросов и преобразований.

Озеро данных 1.0 также не выполнило ещё одно основное обещание движения больших данных. Программное обеспечение с открытым исходным кодом в экосистеме Apache рекламировалось как средство избежать многомиллионных контрактов для фирменных систем MPP. Дешёвое готовое оборудование заменило бы индивидуальные решения поставщиков. В действительности затраты на большие данные резко возросли, поскольку сложность управления кластерами Hadoop вынудила компании нанимать большие команды инженеров с высокими зарплатами. Компании часто предпочитали приобретать лицензионные, настроенные версии Hadoop у поставщиков, чтобы избежать оголенных проводов и острых краев сырой кодовой базы Apache и приобрести набор инструментов для создания инструментов, чтобы сделать Hadoop более удобным для пользователя. Даже компании, которые избегали управления кластерами Hadoop с помощью облачного хранилища, должны были тратить большие средства на специалистов для написания заданий MapReduce.

Мы должны быть осторожны, чтобы не недооценивать полезность и мощь озер данных первого поколения. Многие организации обнаружили значительную ценность в озёрах данных, особенно огромные, сильно ориентированные на данные технологические компании Кремниевой долины, такие как Netflix и Facebook. У этих компаний были ресурсы для создания успешных практик работы с данными и создания собственных инструментов и улучшений на основе Hadoop. Но для многих организаций озера данных превратились во внутренний суперфонд отходов, разочарований и растущих расходов.

В ответ на ограничения озёр данных первого поколения различные игроки пытались усовершенствовать концепцию, чтобы полностью реализовать её обещания. Например, Databricks представила понятие озера-хранилища данных (data lakehouse). Озеро-хранилище включает в себя элементы управления, управление данными и структуры данных, имеющиеся в хранилище данных, при этом по-прежнему размещая данные в объектном хранилище и поддерживая различные механизмы запросов и преобразований. В частности, озеро-хранилище данных поддерживает транзакции атомарности, согласованности, изоляции и долговечности (ACID), что является большим отхождением от исходного озера данных, в которое вы просто вливаете данные и никогда не обновляете и не удаляете их. Термин озеро-хранилище данных предполагает совмещение между озёрами данных и хранилищами данных.

Техническая архитектура облачных хранилищ данных развилась до такой степени, что стала очень похожа на архитектуру озера данных. Облачные хранилища данных разделяют вычисления и хранение, поддерживают запросы петабайтного масштаба, хранят различные неструктурированные данные и полуструктурированные объекты и интегрируются с передовыми технологиями обработки, такими как Spark или Beam.

Мы считаем, что тенденция к конвергенции будет только продолжаться. Озеро данных и хранилище данных по-прежнему будут существовать как разные архитектуры. На практике их возможности будут сходиться, так что лишь немногие пользователи заметят границу между ними в своей повседневной работе. Теперь мы видим несколько поставщиков, предлагающих платформы данных, которые объединяют возможности озера данных и хранилища данных. С нашей точки зрения, AWS, Azure, Google Cloud, Snowflake и Databricks являются лидерами в своем классе, каждый из которых предлагает набор интегрированных инструментов для работы с данными, охватывая диапазон от реляционных до полностью неструктурированных. Вместо того чтобы выбирать между архитектурой озера данных или хранилища данных, будущие инженеры по данным будут иметь возможность выбрать конвергентную платформу данных на основе различных факторов, включая поставщика, экосистему и относительную открытость.

Современный стек данных (рисунок 3-13) в настоящее время является модной аналитической архитектурой, которая подчеркивает тип абстракции, который, как мы ожидаем, будет более широко использоваться в течение следующих нескольких лет. В то время как старые стеки данных полагались на дорогие, монолитные наборы инструментов, основная цель современного стека данных заключается в использовании облачных, подключаемых, простых в использовании, готовых компонентов для создания модульной и экономически эффективной архитектуры данных. Эти компоненты включают конвейеры данных, хранение, преобразование, управление/контроль данными, мониторинг, визуализацию и исследование. Домен всё ещё находится в движении, и конкретные инструменты быстро меняются и развиваются, но основная цель останется прежней: уменьшить сложность и увеличить модуляризацию. Обратите внимание, что понятие современного стека данных хорошо интегрируется с идеей конвергентной платформы данных из предыдущего раздела.

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

Независимо от того, как развивается «современный» (мы делимся своими идеями в Главе 11), мы считаем, что ключевая концепция модульности plug-and-play с понятным ценообразованием и реализацией — это путь будущего. Особенно в аналитической инженерии современный стек данных есть и будет оставаться выбором по умолчанию архитектуры данных. На протяжении всей книги архитектура, на которую мы ссылаемся, содержит части современного стека данных, такие как облачные и plug-and-play модульные компоненты.

В «старые времена» (с начала до середины 2010-х годов) популярность работы с потоковыми данными резко возросла с появлением Kafka как высокомасштабируемой очереди сообщений и таких фреймворков, как Apache Storm и Samza для потоковой/реального времени аналитики. Эти технологии позволили компаниям выполнять новые типы аналитики и моделирования на больших объёмах данных, агрегации и ранжирования пользователей, а также рекомендаций по продуктам. Инженерам по данным нужно было выяснить, как согласовать пакетные и потоковые данные в единую архитектуру. Лямбда-архитектура была одним из первых популярных ответов на эту проблему.

В лямбда-архитектуре (рисунок 3-14) у вас есть системы, работающие независимо друг от друга — пакетная, потоковая и обслуживающая. Исходная система в идеале неизменяема и предназначена только для добавления, отправляя данные в два пункта назначения для обработки: потоковая и пакетная. Потоковая обработка предназначена для обслуживания данных с минимально возможной задержкой в ​​«быстром» слое, обычно в базе данных NoSQL. В пакетном слое данные обрабатываются и преобразуются в системе, такой как хранилище данных, создавая предварительно вычисленные и агрегированные представления данных. Обслуживающий слой обеспечивает объединенное представление путем агрегации результатов запросов из двух слоев.

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

Мы упоминаем лямбда-архитектуру, потому что она по-прежнему привлекает внимание и популярна в результатах выдачи поисковика по запросу «архитектура данных». Лямбда — не главная наша рекомендация, если вы пытаетесь объединить потоковые и пакетные данные для аналитики. Технологии и практики продвинулись вперёд.

Далее давайте рассмотрим реакцию на лямбда-архитектуру, каппа-архитектуру.

В ответ на недостатки лямбда-архитектуры Джей Крепс предложил альтернативу, названную каппа-архитектурой (рисунок 3-15). Центральный тезис таков: почему бы просто не использовать платформу потоковой обработки в качестве основы для всей обработки данных — приёма, хранения и обслуживания? Это способствует созданию настоящей событийно-ориентированной архитектуры. Обработка в реальном времени и пакетная обработка могут быть легко применены к одним и тем же данным путем прямого считывания потока живых событий и воспроизведения больших фрагментов данных для пакетной обработки.

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

И лямбда, и каппа стремились устранить ограничения экосистемы Hadoop 2010-х годов, пытаясь склеить вместе сложные инструменты, которые, вероятно, изначально не подходили друг другу. Центральная проблема объединения пакетных и потоковых данных оставалась, и лямбда и каппа вдохновили и заложили основу для дальнейшего прогресса в этом направлении.

Одной из центральных проблем управления пакетной и потоковой обработкой является унификация нескольких путей кода. Хотя архитектура каппа опирается на унифицированный уровень очередей и хранения, всё равно приходится сталкиваться с использованием различных инструментов для сбора статистики в реальном времени или запуска заданий пакетной агрегации. Сегодня инженеры пытаются решить эту проблему несколькими способами. Google оставил свой след, разработав модель Dataflow и фреймворк Apache Beam, который реализует эту модель.

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

Философия «пакетной обработки как особого случая потоковой передачи» теперь более распространена. Различные фреймворки, такие как Flink и Spark, приняли аналогичный подход.

Интернет вещей (Internet of Things - IoT) — это распределённая коллекция устройств, также известных как вещи (things) — компьютеры, датчики, мобильные устройства, устройства для умного дома и все остальное, что имеет подключение к Интернету. Вместо того, чтобы генерировать данные путём прямого ввода данных человеком (например, ввод данных с клавиатуры), данные IoT генерируются устройствами, которые периодически или непрерывно собирают данные из окружающей среды и передают их в пункт назначения. Устройства IoT часто маломощны и работают в средах с низкими ресурсами/низкой пропускной способностью.

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

Наличие поверхностного понимания архитектуры IoT поможет вам понять более широкие тенденции архитектуры данных. Давайте кратко рассмотрим некоторые концепции архитектуры IoT.

Устройства (также известные как вещи) — это физическое оборудование, подключённое к Интернету, считывающее окружающую среду вокруг себя, собирающее и передающее данные в пункт назначения. Эти устройства могут использоваться в потребительских приложениях, таких как камера дверного звонка, умные часы или термостат. Устройство может быть камерой на базе искусственного интеллекта, которая отслеживает сборочную линию на предмет дефектных компонентов, GPS-трекером для записи местоположений транспортных средств или Raspberry Pi, запрограммированным на загрузку последних твитов и приготовление кофе. Любое устройство, способное собирать данные из своей среды, является устройством IoT.

Устройства должны быть минимально способны собирать и передавать данные. Однако устройство может также обрабатывать данные или выполнять машинное обучение на собранных данных перед их отправкой дальше — периферийные вычисления и периферийное машинное обучение соответственно.

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

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

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

Новые стандарты WiFi с низким энергопотреблением призваны сделать шлюзы IoT менее критичными в будущем, но сейчас они только внедряются. Обычно рой устройств использует много шлюзов IoT, по одному в каждом физическом месте, где присутствуют устройства (рисунок 3-16).

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

Конечно, возможны и другие шаблоны. Например, шлюз может накапливать данные и загружать их партиями для последующей аналитической обработки. В удалённых физических средах шлюзы могут не иметь подключения к сети большую часть времени. Они могут загружать все данные только тогда, когда они попадают в зону действия сотовой или Wi-Fi сети. Дело в том, что разнообразие систем и сред IoT создаёт сложности, например, поступление данных с опозданием, несоответствия структуры данных и схемы, повреждение данных и нарушение соединения, которые инженеры должны учитывать в своих архитектурах и нисходящей аналитике.

Хранение. Требования к хранению будут во многом зависеть от требований к задержке для устройств IoT в системе. Например, для удалённых датчиков, собирающих научные данные для анализа в более позднее время, пакетное хранение объектов может быть вполне приемлемым. Однако от системного бэкэнда, который постоянно анализирует данные в решении для домашнего мониторинга и автоматизации, можно ожидать ответов, близких к реальному времени. В этом случае более подходящим вариантом будет очередь сообщений или база данных временных рядов. Мы более подробно обсудим системы хранения в Главе 6.

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

Один из важных шаблонов обслуживания для IoT выглядит как обратный ETL (рисунок 3-17), хотя мы, как правило, не используем этот термин в контексте IoT. Подумайте о таком сценарии: данные с датчиков на производственных устройствах собираются и анализируются. Результаты этих измерений обрабатываются для поиска оптимизаций, которые позволят оборудованию работать более эффективно. Данные отправляются обратно для перенастройки устройств и их оптимизации.

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

Сеть данных (data mesh) — это недавний ответ на разрастающиеся монолитные платформы данных, такие как централизованные озёра данных и хранилища данных, а также «великий разрыв данных», когда ландшафт разделен между операционными данными и аналитическими данными. Сеть данных пытается инвертировать проблемы централизованной архитектуры данных, беря концепции проектирования на основе доменов (обычно используемые в архитектурах программного обеспечения) и применяя их к архитектуре данных. Поскольку сеть данных привлекла много внимания в последнее время, вы должны знать о ней.

Как отметила Жамак Дехгани в своей новаторской статье на эту тему, децентрализация является важной частью сети данных:

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

Позднее Дехгани выделила четыре ключевых компонента сети данных:

• Доменно-ориентированное децентрализованное владение данными и архитектура
• Данные как продукт
• Инфраструктура самообслуживания данных как платформа
• Федеральное вычислительное управление

Рисунок 3-18 показывает упрощенную версию архитектуры сети данных. Вы можете узнать больше о сетке данных в книге Дехгани «Сеть данных» (O’Reilly).

Архитектуры данных имеют бесчисленное множество других вариаций, таких как data fabric, data hub, scaled architecture, metadata-first architecture, event-driven architecture, live data stack (глава 11) и многие другие. И новые архитектуры будут продолжать появляться по мере консолидации и развития практик, а также упрощения и улучшения инструментов. Мы сосредоточились на нескольких наиболее важных шаблонах архитектуры данных, которые чрезвычайно хорошо устоялись, быстро развиваются или всё это вместе.

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

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

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

При проектировании архитектуры вы будете работать вместе с заинтересованными сторонами бизнеса, чтобы оценить компромиссы. Какие компромиссы присущи использованию облачного хранилища данных по сравнению с озером данных? Каковы компромиссы различных облачных платформ? Когда унифицированная пакетная/потоковая среда (Beam, Flink) может быть подходящим выбором? Изучение этих вариантов в абстрактном плане подготовит вас к принятию конкретных, ценных решений.

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

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