Джо Рис | Мэтт Хоусли

Основы инженерии данных

Планирование и построение надёжных систем данных


(Fundamentals of Data Engineering)

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

В Главе 3 обсуждалась «хорошая» архитектура данных и почему она важна. Теперь мы объясним, как выбрать правильные технологии для обслуживания этой архитектуры. Инженеры данных должны выбирать хорошие технологии, чтобы сделать наилучший возможный продукт. Мы считаем, что критерии выбора хорошей технологии данных просты: добавляет ли она ценность продукту данных и остальному бизнесу?

Многие путают архитектуру и инструменты. Архитектура — это стратегия, инструменты — это тактика. Иногда мы слышим: «Наша архитектура данных — это инструменты X, Y и Z». Это неправильный способ говорить об архитектуре. Архитектура — это высокоуровневый дизайн, дорожная карта и план систем данных, которые удовлетворяют стратегическим целям бизнеса. Архитектура — это что, почему и когда. Инструменты используются для того, чтобы сделать архитектуру реальностью, инструменты — это как.

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

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

  • Размер и возможности команды
  • Скорость выхода на рынок
  • Совместимость
  • Оптимизация затрат и ценность для бизнеса
  • Сегодня и завтра: неизменяемые технологии против временных
  • Расположение (облако, локально, гибридное облако, мультиоблако)
  • Создание или покупка
  • Монолит или модули
  • Бессерверные или серверные вычисления
  • Оптимизация, производительность и войны бенчмарков
  • Фоновые процессы жизненного цикла инженерии данных
Размер и возможности команды
Первое, что вам нужно оценить, — это размер вашей команды и её технологические возможности. Вы работаете в небольшой команде (возможно, в команде из одного человека) людей, которые, как ожидается, будут исполнять множество обязанностей, или команда достаточно большая, чтобы люди работали в специализированных ролях? Будут ли несколько человек отвечать за несколько этапов жизненного цикла проектирования данных, или люди будут отвечать за определённые ниши? Размер вашей команды повлияет на типы технологий, которые вы будете применять.

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

Проведите инвентаризацию навыков вашей команды. Склоняются ли люди к инструментам с низким кодом или они предпочитают подход code-first? Сильны ли люди в определённых языках, таких как Java, Python или Go? Технологии доступны для удовлетворения любых предпочтений в спектре от low-code до code-heavy. Опять же, мы предлагаем придерживаться технологий и рабочих процессов, с которыми команда знакома. Мы видели, как команды по работе с данными тратили много времени на изучение интересной новой технологии, языка или инструмента данных, только чтобы никогда не использовать их в производстве. Изучение новых технологий, языков и инструментов требует значительных временных вложений, поэтому делайте эти вложения с умом.
Скорость выхода на рынок
Для технологий значима скорость выхода на рынок. Это значит выбор правильных технологий, которые помогут вам быстрее предоставлять функции и данные, сохраняя при этом высокие стандарты качества и безопасности. Это также означает работу в тесном цикле обратной связи запуска, обучения, итерации и внесения улучшений.

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

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

Допустим, вы оцениваете две технологии, A и B. Насколько легко технология A интегрируется с технологией B, если говорить о совместимости? Зачастую это различный уровень сложности: от легкого до трудоемкого. Заложена ли в каждый продукт полная интеграция, упрощающая настройку? Или вам нужно выполнить множество настроек вручную для интеграции этих технологий?
Часто вендоры и проекты с открытым исходным кодом ориентируются на взаимодействие конкретных платформ и систем. Большинство инструментов приёма и визуализации данных имеют встроенную интеграцию с популярными хранилищами данных и озёрами данных. Кроме того, популярные инструменты приёма данных будут интегрироваться с распространенными API и сервисами, такими как CRM, бухгалтерское программное обеспечение и т. д.

Иногда для обеспечения совместимости используют стандарты. Почти все базы данных допускают соединения через Java Database Connectivity (JDBC) или Open Database Connectivity (ODBC), что означает, что вы можете легко подключиться к базе данных, используя эти стандарты. В других случаях взаимодействие происходит при отсутствии стандартов. Representational state transfer (REST) ​​не является настоящим стандартом для API; у каждого REST API есть свои особенности. В этих случаях поставщик или проект программного обеспечения с открытым исходным кодом (OSS) должен обеспечить бесшовную интеграцию с другими технологиями и системами.
Оптимизация затрат
и ценность для бизнеса
В идеальном мире вы могли бы экспериментировать со всеми новейшими, самыми крутыми технологиями, не принимая во внимание стоимость, временные инвестиции или добавленную стоимость для бизнеса. В реальности бюджеты и время конечны, а стоимость является основным ограничением для выбора правильных архитектур и технологий данных. Ваша организация ожидает положительного возврата инвестиций от ваших проектов данных, поэтому вы должны понимать основные расходы, которые вы можете контролировать. Технология является основным драйвером затрат, поэтому ваш выбор технологий и стратегии управления существенно повлияют на ваш бюджет. Мы рассматриваем расходы через три основные призмы: совокупная стоимость владения, альтернативные издержки и FinOps.
Совокупная стоимость владения
Совокупная стоимость владения (Total cost of ownership - TCO) — это общая предполагаемая стоимость инициативы, включая прямые и косвенные затраты на используемые продукты и услуги. Прямые затраты могут быть напрямую отнесены к инициативе. Примерами являются зарплаты команды, работающей над инициативой, или счет AWS за все потреблённые услуги. Косвенные затраты, также известные как накладные расходы, не зависят от инициативы и должны быть оплачены независимо от того, куда они отнесены.
Помимо прямых и косвенных затрат, на способ их учета влияет то, как что-то приобретается. Расходы делятся на две большие группы: капитальные расходы и операционные расходы.

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

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

Инженерам данных нужно быть прагматичными в вопросах гибкости. Ландшафт данных меняется слишком быстро, чтобы инвестировать в долгосрочное оборудование, которое неизбежно устаревает, не может легко масштабироваться и потенциально затрудняет пробу чего-то нового. Учитывая преимущества гибкости и низких первоначальных затрат, мы призываем инженеров данных использовать подход, ориентированный на операционные расходы, с упором на облако и гибкие технологии с оплатой по мере использования.
Совокупная альтернативная
стоимость владения
Любой выбор по своей сути исключает другие возможности. Общая стоимость упущенных возможностей владения (Total opportunity cost of ownership, TOCO) — это стоимость упущенных возможностей, которые мы теряем при выборе технологии, архитектуры или процесса. Обратите внимание, что владение в этой ситуации не требует долгосрочных покупок оборудования или лицензий. Даже в облачной среде мы фактически владеем технологией, стеком или конвейером, как только они становятся основной частью наших процессов обработки производственных данных и от них трудно отказаться. Инженеры данных часто не оценивают TOCO при выполнении нового проекта; по нашему мнению, это огромное слепое пятно.

Если вы выбираете стек данных A, вы выбираете преимущества стека данных A по сравнению со всеми другими вариантами, фактически исключая стеки данных B, C и D. Вы привержены стеку данных A и всему, что с ним связано — команде по его поддержке, обучению, настройке и обслуживанию. Что произойдет, если выбор стека данных A был неудачным? Что произойдет, когда стек данных A устареет? Вы всё равно можете перейти на другие стеки данных?

Насколько быстро и дешево вы можете перейти на что-то новое и лучшее? Это критически важный вопрос в пространстве данных, где новые технологии и продукты, кажется, появляются всё быстрее. Перейдет ли ваш опыт, накопленный в стеке данных A, на следующую волну? Или вы можете заменить компоненты стека данных A и выиграть себе немного времени и вариантов?
Первый шаг к минимизации альтернативных затрат — это их внимательная оценка. Мы видели, как бесчисленное множество команд по работе с данными застревали на технологиях, которые казались хорошими в то время, но либо не были гибкими для будущего роста, либо просто устарели. Негибкие технологии данных во многом похожи на медвежьи капканы. В них легко попасть и крайне болезненно выбраться.
FinOps
Мы уже затронули FinOps в «Принципе 9: Используйте FinOps». Как мы уже обсуждали, типичные расходы на облако по своей сути являются операционными: компании платят за услуги для запуска критически важных процессов обработки данных, а не делают авансовые покупки и со временем получают прибыль. Цель FinOps — полностью реализовать финансовую отчётность и ценность бизнеса, применяя DevOps-подобные практики мониторинга и динамической настройки систем.

В этой главе мы хотим подчеркнуть одну особенность FinOps, которая хорошо отражена в этой цитате:
Если вам кажется, что FinOps — это экономия денег, подумайте еще раз. FinOps — это зарабатывание денег. Расходы на облако могут увеличить доход, сигнализировать о росте клиентской базы, обеспечить большую скорость выпуска продуктов и функций или даже помочь закрыть центр обработки данных.
В нашей среде инженерии данных способность быстро итерировать и динамически масштабироваться важна для создания бизнес-ценности. Это одна из основных причин переноса рабочих нагрузок данных в облако.
Сегодня и завтра:
неизменяемые технологии против временных
В такой захватывающей области, как инженерия данных, слишком легко сосредоточиться на быстро меняющемся будущем, игнорируя конкретные потребности настоящего. Намерение построить лучшее будущее благородно, но часто приводит к чрезмерной архитектуре и инжинирингу. Инструменты, выбранные для будущего, могут оказаться устаревшими и неактуальными, когда это будущее наступит; будущее часто выглядит совсем не так, как мы представляли себе много лет назад.

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

У нас есть два класса инструментов для рассмотрения: неизменяемые и временные. Неизменяемые технологи (immutable technologies) и могут быть компонентами, лежащими в основе облака или языков и парадигм, которые выдержали испытание временем. В облаке примерами неизменяемых технологий являются объектное хранилище, сетевые технологии, серверы и безопасность. Объектное хранилище, такое как Amazon S3 и Azure Blob Storage, будет существовать сгодня и до конца десятилетия, а может, и намного дольше. Хранение ваших данных в объектном хранилище — мудрый выбор. Объектное хранилище продолжает совершенствоваться различными способами и постоянно предлагает новые возможности, но ваши данные будут в безопасности и пригодны для использования в объектном хранилище независимо от быстрого развития технологий в целом.

Что касается языков, SQL и bash существуют уже много десятилетий, и мы не видим предпосылок к их исчезновению в ближайшее время. Неизменяемые технологии выигрывают от эффекта Линди: чем дольше технология существует, тем дольше она будет использоваться. Подумайте об электросети, реляционных базах данных, языке программирования C или архитектуре процессора x86. Мы предлагаем использовать эффект Линди в качестве лакмусовой бумажки, чтобы определить, является ли технология потенциально неизменяемой.

Временные технологии (Transitory technologies) — это те, которые приходят и уходят. Типичная история начинается с большой шумихи, за которой следует стремительный рост популярности, а затем медленный спуск в безвестность. Набор JavaScript frontend — классический пример. Сколько JavaScript frontend-фреймворков появилось и исчезло в период с 2010 по 2020 год? Backbone.js, Ember.js и Knockout были популярны в начале 2010-х, а React и Vue.js пользуются огромной популярностью сегодня. Какой JavaScript frontend-фреймворк будет популярным через три года? Кто знает.
Каждый день на передовой работы с данными появляются новые хорошо финансируемые участники и проекты с открытым исходным кодом. Каждый поставщик скажет, что его продукт изменит отрасль и «сделает мир лучше». Большинство этих компаний и проектов не получают долгосрочной поддержки и медленно уходят в небытие. Ведущие венчурные капиталисты делают большие ставки, зная, что большинство их инвестиций в инструменты обработки данных потерпят неудачу. Если венчурные капиталисты, вливающие миллионы (или миллиарды) в инвестиции в инструменты обработки данных, не могут сделать это правильно, как вы можете знать, в какие технологии инвестировать для вашей архитектуры данных? Это сложно. Просто подумайте о количестве технологий в (печально) известных описаниях инструментах для МО, ИИ и данных (MAD) Мэтта Терка, которые мы представили в Главе 1 (Рисунок 4-1).

Даже относительно успешные технологии часто быстро уходят в небытие после нескольких лет быстрого внедрения, становясь жертвой своего успеха. Например, в начале 2010-х годов Hive был встречен быстрым принятием, поскольку он позволял и аналитикам, и инженерам запрашивать огромные наборы данных без ручного кодирования сложных заданий MapReduce. Вдохновленные успехом Hive, но желая устранить его недостатки, инженеры разработали Presto и другие технологии. Сейчас Hive появляется в основном в устаревших развёртываниях. Почти каждая технология следует этому неизбежному пути упадка.
Рисунок 4-1. Инструменты для данных MAD Мэтта Терка за 2021 год
Наша рекомендация
Учитывая быстрые темпы изменений в инструментах и ​​передовых практиках, мы предлагаем оценивать инструменты каждые два года (рисунок 4-2). По возможности находите неизменяемые технологии в жизненном цикле проектирования данных и используйте их в качестве базы. Создавайте временные инструменты вокруг неизменяемых.
Рисунок 4-2. Используйте двухлетний временной горизонт для переоценки вашего технологического выбора
Учитывая разумную вероятность сбоя для многих технологий обработки данных, необходимо подумать, насколько легко уйти от выбранной технологии. Каковы препятствия для ухода? Как упоминалось ранее в нашем обсуждении альтернативной стоимости, избегайте «медвежьих капканов». Идите в новую технологию с широко открытыми глазами, зная, что проект может быть заброшен, компания может оказаться нежизнеспособной или технология просто перестанет подходить.
Расположение
Сейчас у компаний есть множество вариантов при принятии решения о том, где реализовать свои технологические стеки. Медленный переход к облаку завершается настоящим наплывом компаний, наращивающих рабочие нагрузки на AWS, Azure и Google Cloud Platform (GCP). За последнее десятилетие многие технические директора стали рассматривать свои решения относительно хостинга технологий как имеющие экзистенциальное значение для своих организаций. Если они будут двигаться слишком медленно, они рискуют остаться позади своих более гибких конкурентов; с другой стороны, плохо спланированная миграция в облако может привести к технологическому сбою и катастрофическим затратам.

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

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

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

Компании в конкурентных секторах, как правило, не имеют возможности стоять на месте. Конкуренция жесткая, и всегда есть угроза быть «раздавленной» более гибкой конкуренцией, часто подкрепленной большой кучей венчурных инвестиций. Каждая компания должна поддерживать эффективность работы своих существующих систем, одновременно решая, какие шаги предпринять дальше. Это может включать принятие новых практик DevOps, таких как контейнеры, Kubernetes, микросервисы и непрерывное развёртывание с сохранением работоспособности оборудования на предприятии. Это может включать полную миграцию в облако, как обсуждается далее.
Облако
Облако переворачивает локальную модель с ног на голову. Вместо того чтобы покупать оборудование, вы просто арендуете оборудование и управляемые сервисы у облачного провайдера (такого как AWS, Azure или Google Cloud). Эти ресурсы часто можно зарезервировать на чрезвычайно краткосрочной основе; виртуальные машины разворачиваются менее чем за минуту, а последующее использование оплачивается посекундно. Это позволяет пользователям облака динамически масштабировать ресурсы, которые были недосягаемы с локальными серверами.

В облачной среде инженеры могут быстро запускать проекты и экспериментировать, не беспокоясь о длительном процессе планирования оборудования. Они могут начать запускать серверы, как только их код будет готов к развёртыванию. Это делает облачную модель чрезвычайно привлекательной для стартапов, которые ограничены бюджетом и временем.
В раннюю эру облаков доминировали предложения инфраструктуры как услуги (infrastructure as a service, IaaS) — такие продукты, как виртуальные машины и виртуальные диски, которые по сути являются арендованными фрагментами оборудования. Постепенно проиошел сдвиг в сторону платформы как услуги (platform as a service, PaaS), в то время как продукты SaaS продолжают расти быстрыми темпами.

PaaS включает продукты IaaS, но добавляет более сложные управляемые сервисы для поддержки приложений. Примерами являются управляемые базы данных, такие как Amazon Relational Database Service (RDS) и Google Cloud SQL, управляемые потоковые платформы, такие как Amazon Kinesis и Simple Queue Service (SQS), и управляемые Kubernetes, такие как Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS). Сервисы PaaS позволяют инженерам игнорировать операционные детали управления отдельными машинами и развёртывания фреймворков в распределённых системах. Они предоставляют готовый доступ к сложным, автоматически масштабируемым системам с минимальными операционными издержками.

Предложения SaaS поднимаются на одну ступеньку выше по лестнице абстракции. SaaS обычно предоставляет полностью функционирующую корпоративную программную платформу с небольшим операционным управлением. Примерами SaaS являются Salesforce, Google Workspace, Microsoft 365, Zoom и Fivetran. Платформы SaaS предлагают и основные публичные облака, и сторонние компании. SaaS охватывает весь спектр корпоративных доменов, включая видеоконференции, управление данными, рекламные технологии, офисные приложения и CRM-системы.
В этой главе также обсуждается бессерверная технология (serverless), приобретающая важность в предложениях PaaS и SaaS. Serverless-продукты обычно предлагают автоматическое масштабирование от нуля до чрезвычайно высоких показателей использования. Они оплачиваются по факту использования и позволяют инженерам работать без операционной осведомленности о базовых серверах. Многие люди придираются к термину serverless; в конце концов, код должен где-то работать. На практике serverless обычно означает множество невидимых серверов.

Облачные сервисы становятся всё более привлекательными для устоявшихся предприятий с существующими центрами обработки данных и ИТ-инфраструктурой. Динамическое, плавное масштабирование чрезвычайно ценно для предприятий, которые имеют дело с сезонностью (например, розничные предприятия, справляющиеся с нагрузкой Черной пятницы) и всплесками нагрузки веб-трафика. Появление COVID-19 в 2020 году стало основным драйвером внедрения облака, поскольку компании осознали ценность быстрого масштабирования процессов обработки данных для получения информации в крайне неопределённом деловом климате; предприятиям также пришлось справляться с существенно возросшей нагрузкой из-за всплеска онлайн-покупок, использования веб-приложений и удалённой работы.

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

Краткий экскурс в экономику облаков

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

Облачные сервисы и кредитные дефолтные свопы
Давайте немного поговорим о кредитных дефолтных свопах (credit default swaps). Не волнуйтесь, немного позже вы всё поймёте. Вспомните, что кредитные дефолтные свопы приобрели дурную славу после мирового финансового кризиса 2007 года. Кредитный дефолтный своп был механизмом продажи различных уровней риска, привязанных к активу (например, ипотеке). Мы не намерены описывать это явление детально, скорее предложить аналогию, в которой многие облачные сервисы похожи на финансовые деривативы; поставщики облачных услуг не только разделяют аппаратные активы на мелкие части посредством виртуализации, но и продают эти части с различными техническими характеристиками и сопутствующими рисками. Хотя поставщики крайне скрытны в отношении деталей своих внутренних систем, существуют огромные возможности для оптимизации и масштабирования путем понимания ценообразования в облаке и обмена информацией с другими пользователями.

Взгляните на пример архивного облачного хранилища. На момент написания этой статьи GCP открыто признает, что ее архивное хранилище работает на тех же кластерах, что и стандартное облачное хранилище, однако цена за гигабайт в месяц для архивного хранилища составляет примерно 1/17 цены стандартного хранилища. Как это возможно?

Вот наше обоснованное предположение. При покупке облачного хранилища каждый диск в кластере хранения имеет три актива, которые используют поставщики и потребители облачных услуг. Во-первых, он имеет определённую ёмкость хранилища — скажем, 10 ТБ. Во-вторых, он поддерживает определённое количество операций ввода-вывода (IOP) в секунду — скажем, 100. В-третьих, диски поддерживают определённую максимальную пропускную способность, максимальную скорость чтения для оптимально организованных файлов. Магнитный диск может иметь возможность чтения со скоростью 200 МБ/с.

Любое из этих ограничений (IOP, ёмкость хранилища, пропускная способность) является потенциальным узким местом для облачного провайдера. Например, у облачного провайдера может быть диск, хранящий 3 ТБ данных, но достигающий максимального IOP. Альтернативой тому, чтобы оставить оставшиеся 7 ТБ пустыми, является продажа пустого пространства без продажи IOP. Или, более конкретно, продажа дешёвого дискового пространства и дорогих IOP, чтобы препятствовать чтению.
Подобно трейдерам финансовых деривативов, поставщики облачных услуг также имеют дело с риском. В случае архивного хранения поставщики продают своего рода страховку, но такую, которая выплачивается страховщику, а не покупателю полиса в случае катастрофы. Хотя ежемесячные расходы на хранение данных чрезвычайно низки, я рискую заплатить высокую цену, если мне когда-нибудь понадобится извлечь данные. Но это цена, которую я с радостью заплачу в действительно чрезвычайной ситуации.
Аналогичные соображения применимы практически к любому облачному сервису. Хотя локальные серверы по сути продаются как обычное оборудование, модель затрат в облаке более тонкая. Вместо того чтобы просто взимать плату за ядра ЦП, память и функции, поставщики облачных услуг монетизируют такие характеристики, как долговечность, надёжность, долговечность и предсказуемость; различные вычислительные платформы делают скидки на свои предложения для рабочих нагрузок, которые являются эфемерными или могут быть произвольно прерваны, когда мощность требуется в другом месте.

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

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

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

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

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

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

Такая схема размещения аналитики в облаке красива, поскольку данные движутся преимущественно в одном направлении, что минимизирует затраты на исходящие данные (рис. 4-3). То есть локальные приложения генерируют данные о событиях, которые можно отправить в облако по сути бесплатно. Основная часть данных остаётся в облаке, где они анализируются, в то время как меньшие объёмы данных возвращаются в локальную среду для развёртывания моделей в приложениях, обратного ETL и т. д.
Рисунок 4-3. Поток данных гибридного облака, минимизирующий исходящие затраты
Мультиоблако
Под мультиоблаком (multicloud) подразумевается развёртывание рабочих нагрузок в нескольких общедоступных облаках. У компаний может быть несколько мотивов для развёртывания в нескольких облаках. Платформы SaaS часто предлагают услуги, близкие к существующим рабочим нагрузкам в облаке своих клиентов. Snowflake и Databricks предоставляют свои предложения SaaS в нескольких облаках по этой причине. Это особенно важно для приложений с интенсивным использованием данных, где задержка сети и ограничения полосы пропускания снижают производительность, а затраты на вывод данных могут быть непомерно высокими.

Другой распространённой мотивацией для использования подхода мультиоблачности является использование лучших сервисов в нескольких облаках. Например, компания может захотеть обрабатывать свои данные Google Ads и Analytics в Google Cloud и развертывать Kubernetes через GKE. И компания также может использовать Azure специально для рабочих нагрузок Microsoft. Кроме того, компании может понравиться AWS, потому что у неё есть несколько лучших в своем классе сервисов (например, AWS Lambda) и она пользуется огромной популярностью, что позволяет относительно легко нанимать инженеров, владеющих AWS. Возможно любое сочетание различных сервисов облачных поставщиков. Учитывая острую конкуренцию между крупными поставщиками облачных услуг, можно ожидать, что они будут предлагать больше лучших в своем классе услуг, что делает мультиоблако более привлекательным.

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

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

Новое поколение сервисов «облако облаков» направлено на упрощение мультиоблачной среды за счёт предложения услуг в облаках и беспрепятственной репликации данных между облаками или управления рабочими нагрузками в нескольких облаках через единую панель. Приведем один пример: учётная запись Snowflake работает в одном облачном регионе, но клиенты могут легко развернуть другие учётные записи в GCP, AWS или Azure. Snowflake обеспечивает простую репликацию данных по расписанию между различными облачными учётными записями. Интерфейс Snowflake по сути одинаков во всех этих учётных записях, что устраняет необходимость обучения переключению между облачными сервисами.

Пространство «облака облаков» быстро развивается; в течение нескольких лет после публикации этой книги станет доступно гораздо больше таких сервисов. Инженерам и архитекторам данных было бы полезно поддерживать осведомлённость об этом быстро меняющемся наборе облаков.
Децентрализованность:
блокчейн и периферия
Хотя сейчас это не так широко используется, стоит кратко упомянуть о новой тенденции, которая может стать популярной в течение следующего десятилетия: децентрализованные вычисления. В то время как сегодняшние приложения в основном работают локально и в облаке, рост блокчейна, Web 3.0 и периферийных вычислений может перевернуть эту парадигму. На данный момент децентрализованные платформы оказались чрезвычайно популярными, но не оказали существенного влияния на пространство данных; тем не менее, присматриваться к этим платформам стоит при оценке технологических решений.
Наша рекомендация
С нашей точки зрения, мы всё ещё находимся в начале перехода к облаку. Таким образом, доказательства и аргументы по поводу размещения и миграции рабочей нагрузки ещё формируются. Само облако меняется, переходя от модели IaaS, построенной вокруг Amazon EC2, которая стимулировала ранний рост AWS, и в целом к ​​более управляемым сервисным предложениям, таким как AWS Glue, Google BigQuery и Snowflake.

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

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

С другой стороны, у вас должен быть запасной план. Как мы уже подчёркивали ранее, каждая технология — даже программное обеспечение с открытым исходным кодом — имеет некоторую возможность блокировки. Стратегия с одним облаком имеет значительные преимущества простоты и интеграции, но также имеет значительную привязку. В данном случае мы говорим о гибкости ума, гибкости оценки текущего состояния мира и представления альтернатив. В идеале ваш запасной план останется “в столе”, но подготовка этого плана поможет вам принимать более обоснованные решения в настоящем и поможет найти выход, если что-то пойдет не так в будущем.
Аргументы в пользу
облачной репатриации
Когда мы писали эту книгу, Сара Ванг и Мартин Касадо опубликовали статью «The Cost of Cloud, a Trillion Dollar Paradox», которая вызвала значительный шум и споры в технопространстве. Читатели широко интерпретировали статью как призыв к репатриации облачных рабочих нагрузок на локальные серверы. Они приводят несколько более тонкий аргумент о том, что компании должны тратить значительные ресурсы на контроль расходов на облако и должны рассматривать репатриацию как возможный вариант.

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

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

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

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

Среди других часто упоминаемых историй успеха, созданных компаниями за пределами облака, — Backblaze и Cloudflare, но они демонстрируют схожие уроки. Backblaze начинался как продукт для резервного копирования персональных данных в облаке, но с тех пор начал предлагать B2, сервис хранения объектов, похожий на Amazon S3. Backblaze в настоящее время хранит более эксабайта данных. Cloudflare утверждает, что предоставляет услуги для более чем 25 миллионов интернет-объектов с точками присутствия в более чем 200 городах и 51 терабит в секунду (Тбит/с) общей сетевой емкости.

Netflix является ещё одним полезным примером. Компания известна тем, что реализует свой технологический стек на AWS, но это верно лишь отчасти. Netflix действительно использует транскодирование видео на AWS, что составляет примерно 70% её вычислительных потребностей в 2017 году. Netflix также реализует бэкенд приложений и аналитику данных на AWS. Однако вместо того, чтобы использовать сеть распространения контента AWS, Netflix создала собственную CDN в сотрудничестве с поставщиками интернет-услуг, используя узкоспециализированную комбинацию программного и аппаратного обеспечения. Для компании, которая потребляет значительную часть всего интернет-трафика, создание этой критически важной инфраструктуры позволило доставлять высококачественное видео огромной клиентской базе с минимальными затратами.

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

Рассмотрите возможность продолжения выполнения рабочих нагрузок локально или репатриации облачных рабочих нагрузок, если вы запускаете действительно масштабируемую в облаке службу. Что такое масштаб облака? Вы можете находиться в масштабе облака, если вы храните эксабайт данных или обрабатываете терабит трафика в секунду в Интернет и из него. (Достичь терабита в секунду внутреннего сетевого трафика довольно легко.) Кроме того, рассмотрите возможность владения своими серверами, если расходы на исходящие данные являются основным фактором для вашего бизнеса. Приводя конкретный пример облачных рабочих нагрузок, которые могут выиграть от репатриации: Apple может получить значительное финансовое и производительное преимущество, перенеся хранилище iCloud на свои собственные серверы.
Создание или покупка
Спор «создать или купить» в сфере технологий длится уже много лет. Аргумент в пользу создания заключается в том, что у вас есть сквозной контроль над решением, и вы не находитесь во власти поставщика или сообщества разработчиков ПО с открытым исходным кодом. Аргумент в пользу покупки сводится к ограниченности ресурсов и экспертным знаниям; есть ли у вас экспертные знания, чтобы создать лучшее решение, чем то, что уже доступно? Любое решение сводится к TCO, TOCO и тому, обеспечивает ли решение конкурентное преимущество вашей организации.

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

Как мы часто спрашиваем: «Если вам нужны новые шины для вашего автомобиля, вы будете покупать сырье, создавать шины с нуля и устанавливать их самостоятельно?» Как и большинство людей, вы, вероятно, покупаете шины и просите кого-то их установить. Тот же аргумент применим к выбору “создать или купить”. Мы видели команды, которые создавали свои базы данных с нуля. Простая СУРБД с открытым исходным кодом удовлетворила бы их потребности гораздо лучше при более близком рассмотрении. Представьте себе количество времени и денег, вложенных в эту самодельную базу данных. Поговорите о низкой рентабельности инвестиций в совокупную стоимость владения и альтернативных издержках.

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

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

Давайте рассмотрим некоторые варианты решений с открытым исходным кодом и проприетарных решений.
Программное обеспечение
с открытым исходным кодом
Программное обеспечение с открытым исходным кодом, открытое программное обеспечение (Open source software, OSS) — это модель распространения программного обеспечения, в которой программное обеспечение и лежащая в его основе кодовая база предоставляются для общего пользования, как правило, на определенных условиях лицензирования. Часто открытое программное обеспечение (ОПО) создается и поддерживается распределённой командой соавторов. ОПО можно использовать, изменять и распространять большую часть времени, но с определёнными оговорками. Например, многие лицензии требуют, чтобы исходный код ОПО был включён в комплект поставки программного обеспечения.

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

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

Ниже приведены факторы, которые следует учитывать при работе с управляем сообществом ОПО:

Узнаваемость
Избегайте внедрения проектов ОПО, которые не имеют поддержки и популярности. Посмотрите на количество звезд GitHub, форков, объём и новизну коммитов. Ещё одна вещь, на которую следует обратить внимание, — это активность сообщества в связанных чатах и ​​форумах. Есть ли в проекте сильное чувство общности? Сильное сообщество создает благоприятные условия для активного внедрения. Это также означает, что вам будет легче получить техническую помощь и найти квалифицированные кадры для работы с фреймворком.

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

Устранение неполадок
Как вам придется решать проблемы, если они возникнут? Вы будете устранять неполадки самостоятельно или сообщество может помочь вам решить вашу проблему?

Управление проектами
Посмотрите на проблемы в Git и на то, как они решаются. Быстро ли они решаются? Если да, то какова процедура оповещения о проблеме и её решения?

Команда
Является ли компания спонсором проекта ОПО? Кто основные участники?

Отношения с разработчиками и управление сообществом
Что делает проект для стимулирования внедрения? Есть ли активное чат-сообщество (например, в Slack), которое обеспечивает поощрение и поддержку?

Вклад
Поощряет ли и принимает ли проект запросы на редактирование? Каковы процесс и сроки принятия запросов на редактирование основной кодовой базы?

Дорожная карта
Есть ли дорожная карта у проекта? Если да, то ясна ли она и прозрачна?

Самостоятельное размещение и обслуживание
Есть ли у вас ресурсы для размещения и обслуживания решения ОПО? Если да, то каковы TCO и TOCO по сравнению с покупкой управляемой услуги у поставщика ОПО?

Обратная связь
Если вам нравится проект и вы активно его используете, рассмотрите возможность инвестирования в него. Вы можете внести свой вклад в кодовую базу, помочь устранить проблемы и дать совет на форумах и в чатах сообщества. Если проект допускает пожертвования, рассмотрите возможность сделать их. Многие проекты ОПО по сути являются проектами на общественных началах, и сопровождающие часто имеют постоянную работу в дополнение к помощи в проекте ОПО. К сожалению, часто это работа по любви, которая не позволяет сопровождающему зарабатывать. Если вы можете позволить себе пожертвовать средства, пожалуйста, сделайте это.
Коммерческое ОПО
Иногда ОПО имеет некоторые недостатки. Например, вы должны разместить и поддерживать решение в своей среде. Это может быть тривиально или чрезвычайно сложно и обременительно, в зависимости от приложения ОПО. Коммерческие поставщики пытаются решить эту головную боль управления, размещая решение ОПО, как правило, как облачное предложение SaaS. Примерами таких поставщиков являются Databricks (Spark), Confluent (Kafka), DBT Labs (dbt) и многие, многие другие.

Эта модель называется коммерческой ОПО (КОПО). Обычно поставщик предлагает «ядро» ОПО бесплатно, взимая плату за улучшения, курируемые дистрибутивы кода или полностью управляемые услуги.

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

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

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

Модель доставки
Как вы получаете доступ к услуге? Доступен ли продукт через загрузку, API или веб-/мобильный пользовательский интерфейс? Убедитесь, что вы можете легко получить доступ к первоначальной версии и последующим выпускам.

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

Выпуски и исправления ошибок
Информирует ли поставщик в плане графика выпуска, улучшений и исправлений ошибок? Легко ли вам доступны эти обновления?

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

Финансы компании
Жизнеспособна ли компания? Если компания привлекла венчурные капиталы, вы можете проверить их финансирование на таких сайтах, как Crunchbase. Какой у компании потенциал для взлета и будет ли она все еще работать через пару лет?

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

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

Обратите внимание также на то, что облака предлагают собственные управляемые продукты с открытым исходным кодом. Если поставщик облачных услуг видит успех определённого продукта или проекта, ожидайте, что поставщик предложит свою версию. Это может варьироваться от простых примеров (Linux с открытым исходным кодом, предлагаемый на виртуальных машинах) до чрезвычайно сложных управляемых услуг (полностью управляемый Kafka). Смысл этих предложений прост: облака зарабатывают деньги за счёт потребления. Больше предложений в облачной экосистеме означает большую вероятность «прилипания» и увеличения расходов клиентов.
Проприетарные закрытые системы
Несмотря на повсеместное распространение ОПО, существует большой рынок и для технологий, не связанных с ним. Некоторые крупнейшие компании в сфере обработки данных продают продукты с закрытым исходным кодом. Давайте рассмотрим два основных типа закрытых систем, независимые компании и предложения облачных платформ.
Независимые решения
За последние несколько лет рынок инструментов обработки данных демонстрировал экспоненциальный рост. Каждый день появляются новые независимые предложения для инструментов обработки данных. Имея возможность привлекать средства от венчурных капиталистов, эти компании, работающие с данными, могут масштабироваться и нанимать отличные инженерные, торговые и маркетинговые команды. Это ситуация, когда пользователи имеют отличный выбор продуктов на рынке, в то время как им приходится продираться через бесконечный беспорядок в продажах и маркетинге. На момент написания этой статьи время свободно доступного капитала для компаний, работающих с данными, подходят к концу, но это уже другая долгая история, последствия которой все ещё не раскрыты.

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

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

Доля внимания и доля рынка
Является ли решение популярным? Имеет ли оно присутствие на рынке? Имеет ли оно положительные отзывы клиентов?

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

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

Долговечность
Просуществует ли компания достаточно долго, чтобы вы смогли получить выгоду от её продукта? Если компания привлекла деньги, поищите информацию о ее ситуации с финансированием. Посмотрите отзывы пользователей. Спросите друзей и разместите вопросы в социальных сетях об опыте пользователей с продуктом. Убедитесь, что вы знаете, на что идете.
Собственные сервисные решения облачной платформы
Поставщики облачных услуг разрабатывают и продают свои фирменные сервисы для хранения, баз данных и многого другого. Многие из этих решений являются внутренними инструментами, используемыми соответствующими родственными компаниями. Например, Amazon создала базу данных DynamoDB, чтобы преодолеть ограничения традиционных реляционных баз данных и обрабатывать большие объёмы данных о пользователях и заказах, поскольку Amazon.com превратился в гиганта. Позже Amazon предложила сервис DynamoDB исключительно на AWS; теперь это продукт с самым высоким рейтингом, используемый компаниями всех размеров и уровней зрелости. Поставщики облачных услуг часто объединяют свои продукты для совместной работы. Каждое облако может создать привязку к своей пользовательской базе, создав сильную интегрированную экосистему.

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

Сравнение производительности и цены
Является ли облачное решение существенно лучше, чем независимая или ОПО-версия? Какова совокупная стоимость владения при выборе облачного предложения?

Соображения при покупке
Оплата «по требованию» может быть высокой. Можно ли снизить расходы, купив зарезервированную ёмкость или заключив долгосрочное соглашение о обязательствах?
Наша рекомендация
Решение «создать или купить» возвращает нас к пониманию вашего конкурентного преимущества и того, где имеет смысл инвестировать ресурсы в кастомизацию. В целом, мы по умолчанию отдаём предпочтение ОПО и КОПО, что освобождает вас для того, чтобы сосредоточиться на улучшении тех областей, где этих вариантов недостаточно. Сосредоточьтесь на нескольких областях, где создание чего-либо добавит значительную ценность или существенно снизит напряжение.

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

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

Какой подход следует использовать в вашем стеке инженерии данных? Давайте рассмотрим компромиссы.
Монолит
Монолит (рисунок 4-4) был технологической опорой на протяжении десятилетий. В старые времена водопадной модели релизы программного обеспечения были огромными, тесно связанными и продвигались медленно. Большие команды работали вместе, чтобы предоставить единую рабочую кодовую базу. Монолитные системы данных продолжают существовать и по сей день у старых поставщиков программного обеспечения, таких как Informatica, и фреймворков с открытым исходным кодом, таких как Spark.

Плюсы монолита в том, что о нём легко рассуждать, и он требует меньшей когнитивной нагрузки и переключения контекста, поскольку всё является самодостаточным. Вместо того, чтобы иметь дело с десятками технологий, вы имеете дело с «одной» технологией и, как правило, одним основным языком программирования. Монолиты — отличный вариант, если вам нужна простота в рассуждениях об архитектуре и процессах.
Рисунок 4-4. Монолит тесно связывает свои сервисы
Конечно, у монолита есть минусы. Во-первых, монолиты хрупкие. Из-за огромного количества подвижных частей обновления и релизы занимают больше времени и, как правило, «готовятся» в «кухонной раковине». Если в системе есть ошибка — надеюсь, программное обеспечение было тщательно протестировано перед выпуском! — это может навредить всей системе.

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

Мультиарендность в монолитной системе также может стать серьёзной проблемой. Может быть сложно изолировать рабочие нагрузки нескольких пользователей. В локальном хранилище данных одна пользовательская функция может потреблять достаточно ресурсов ЦП, чтобы замедлить работу системы для других пользователей. Конфликты между зависимостями и конкуренция за ресурсы являются частыми источниками головной боли.
Еще один минус монолитов в том, что переход на новую систему будет болезненным, если поставщик или проект с открытым исходным кодом перестанет существовать. Поскольку все ваши процессы содержатся в монолите, извлечение себя из этой системы на новую платформу будет затратным как по времени, так и по деньгам.
Модульность
Модульность (Modularity) (рисунок 4-5) — это старая концепция в программной инженерии, но модульные распределенные системы действительно вошли в моду с появлением микросервисов. Вместо того чтобы полагаться на огромный монолит для обработки ваших потребностей, почему бы не разбить системы и процессы на их автономные области интересов? Микросервисы могут взаимодействовать через API, позволяя разработчикам сосредоточиться на своих доменах, делая свои приложения доступными для других микросервисов. Это тенденция в программной инженерии, и она все чаще наблюдается в современных системах данных.
Рисунок 4-5. Благодаря модульности все сервисы отделены друг от друга
Крупные технологические компании стали ключевыми движущими силами для микросервисов. Знаменитый API mandate Безоса уменьшает связанность между приложениями, позволяя проводить рефакторинг и декомпозицию. Безос также ввел правило двух пицц (никакая команда не должна быть настолько большой, чтобы две пиццы не могли накормить всю группу). Фактически это означает, что в команде будет не более пяти участников. Это ограничение также ограничивает сложность области ответственности команды, в частности, кодовой базы, которой она может управлять. В то время как обширное монолитное приложение может потребовать группу из ста человек, разделение разработчиков на небольшие группы по пять человек требует, чтобы это приложение было разбито на небольшие, управляемые, слабосвязанные части.

В модульной микросервисной среде компоненты можно заменять, и можно создать приложение-полиглот (мультипрограммирование на разных языках); сервис на Java может заменить сервис, написанный на Python. Клиентам сервиса нужно беспокоиться только о технических характеристиках API сервиса, а не о скрытых деталях реализации.

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

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

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

Эта проблема заставила нас выделить оркестровку в отдельный фоновый процесс вместо того, чтобы поместить её в управление данными. Оркестровка также важна для монолитных архитектур данных; посмотрите на успех таких инструментов, как Control-M от BMC Software в традиционном пространстве хранилищ данных. Но оркестровка пяти или десяти инструментов значительно сложнее, чем оркестровка одного. Оркестровка становится клеем, который связывает модули стека данных вместе.
Паттерн распределённого монолита
Паттерн распределённого монолита (distributed monolith pattern) — это распределённая архитектура, которая все еще страдает от многих ограничений монолитной архитектуры. Основная идея заключается в том, что кто-то запускает распределённую систему со службами для выполнения различных задач. Тем не менее, службы и узлы разделяют общий набор зависимостей или общую кодовую базу.

Одним из стандартных примеров является традиционный кластер Hadoop. Кластер Hadoop может одновременно размещать несколько фреймворков, таких как Hive, Pig или Spark. Кластер также имеет множество внутренних зависимостей. Кроме того, кластер запускает основные компоненты Hadoop: общие библиотеки Hadoop, HDFS, YARN и Java. На практике кластер часто имеет одну установленную версию каждого компонента.

Стандартная локальная система Hadoop подразумевает управление общей средой, которая работает для всех пользователей и всех задач. Управление обновлениями и установками является серьезной проблемой. Принуждение задач к обновлению зависимостей рискует их поломать; поддержание двух версий фреймворка влечёт за собой дополнительную сложность.

Некоторые современные технологии оркестровки на основе Python, например Apache Airflow, также страдают от этой проблемы. Хотя они используют сильно развязанную и асинхронную архитектуру, каждая служба запускает одну и ту же кодовую базу с одинаковыми зависимостями. Любой исполнитель может выполнить любую задачу, поэтому клиентская библиотека для одной задачи, запущенной в одной DAG, должна быть установлена ​​на всем кластере. Оркестровка многих инструментов влечёт за собой установку клиентских библиотек для множества API. Конфликты зависимостей являются постоянной проблемой.

Одним из решений проблем распределённого монолита является эфемерная инфраструктура в облачной среде. Каждое задание получает свой собственный временный сервер или кластер, установленный с зависимостями. Каждый кластер остаётся монолитным, но разделение задач значительно снижает конфликты. Например, этот шаблон теперь довольно распространён для Spark с такими сервисами, как Amazon EMR и Google Cloud Dataproc.

Второе решение — правильно разложить распределённый монолит на несколько программных сред с использованием контейнеров. Мы можем рассказать больше о контейнерах в разделе «Бессерверные или серверные вычисления».
Наша рекомендация
Хотя монолиты привлекательны из-за простоты понимания и снижения сложности, у этого высокая цена. А именно потенциальная потеря гибкости, альтернативные издержки и циклы разработки с большим количеством разногласий.

Вот некоторые моменты, которые следует учитывать при оценке монолитных и модульных вариантов:

Взаимодействие
Архитектор для совместного использования и взаимодействия.

Избегание «медвежьей ловушки»
То, во что легко попасть, может быть болезненным или невозможным для избегания.

Гибкость
Сейчас в пространстве данных всё движется очень быстро. Приверженность монолиту снижает гибкость и обратимость решений.
Бессерверные или серверные вычисления
Важной тенденцией для поставщиков облачных услуг является бессерверность (serverless), что позволяет разработчикам и инженерам по обработке данных запускать приложения без управления серверами за кулисами. Бессерверность обеспечивает быстроту оценки для правильных вариантов использования. Для других случаев это может быть не очень хорошо. Давайте рассмотрим, как оценить, подходит ли вам бессерверность.
Бессерверность
Хотя бессерверность существует уже довольно давно, эта тенденция в полную силу реализовалась в AWS Lambda в 2014 году. С обещанием выполнения небольших фрагментов кода по мере необходимости без необходимости управлять сервером, бессерверность стал пользоваться огромной популярностью. Главные причины этого — стоимость и удобство. Вместо того чтобы оплачивать стоимость сервера, почему бы просто не платить, когда ваш код вызывается?

Бессерверность имеет много разновидностей. Хотя функция как услуга (FaaS) пользуется огромной популярностью, бессерверные системы появились ещё до появления AWS Lambda. Например, BigQuery от Google Cloud является бессерверной в том смысле, что инженерам по данным не нужно управлять внутренней инфраструктурой, а система масштабируется до нуля и автоматически масштабируется для обработки больших запросов. Просто загрузите данные в систему и начните выполнять запросы. Вы платите за объём данных, потребляемых вашим запросом, и небольшую стоимость хранения ваших данных. Эта модель оплаты — оплата потребления и хранения — становится всё более распространённой.

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

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

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

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

Контейнеры предоставляют частичное решение проблем распределённого монолита, упомянутых ранее в этой главе. Например, Hadoop теперь поддерживает контейнеры, позволяя каждому заданию иметь собственные изолированные зависимости.
  • Кластеры контейнеров не обеспечивают ту же безопасность и изоляцию, что и полноценные виртуальные машины. Выход из контейнера — в широком смысле, класс эксплойтов, посредством которых код в контейнере получает привилегии за пределами контейнера на уровне ОС — достаточно распространён, чтобы считаться риском для многопользовательской среды. В то время как Amazon EC2 является действительно многопользовательской средой с виртуальными машинами многих клиентов, размещенными на одном и том же оборудовании, кластер Kubernetes должен размещать код только в среде взаимного доверия (например, внутри стен одной компании). Кроме того, процессы проверки кода и сканирования уязвимостей имеют решающее значение для того, чтобы гарантировать, что разработчик не создаст дыру в безопасности.
Различные варианты контейнерных платформ добавляют дополнительные бессерверные функции. Контейнерные функциональные платформы запускают контейнеры как эфемерные единицы, запускаемые событиями, а не как постоянные сервисы. Это даёт пользователям простоту AWS Lambda с полной гибкостью контейнерной среды вместо крайне ограничительной среды выполнения Lambda. А такие сервисы, как AWS Fargate и Google App Engine, запускают контейнеры без управления вычислительным кластером, необходимым для Kubernetes. Эти сервисы также полностью изолируют контейнеры, предотвращая проблемы безопасности, связанные с многопользовательской арендой.

Абстракция продолжит свой путь по стеку данных. Рассмотрим влияние Kubernetes на управление кластером. Хотя вы можете управлять своим кластером Kubernetes — и многие инженерные команды так делают — даже Kubernetes широко доступен как управляемая служба. Что будет после Kubernetes? Мы так же, как и вы, с нетерпением ждем возможности узнать.
Как оценить серверные и бессерверные решения
Зачем вам использовать собственные серверы вместо бессерверных? Есть несколько причин. Стоимость — важный фактор. Бесерверность становится менее целесообразной, когда использование и стоимость превышают текущие расходы на эксплуатацию и обслуживание сервера (рисунок 4-6). Однако при определённом масштабе ее экономические преимущества могут уменьшиться, и запуск серверов становится более привлекательным.
Рисунок 4-6. Стоимость бессерверной архитектуры по сравнению с использованием сервера
Настройка, мощность и контроль — другие основные причины отдать предпочтение серверам, а не бессерверным вычислениям. Некоторые бессерверные фреймворки могут быть недостаточно мощными или ограниченными для определённых сценариев использования. Вот некоторые вещи, которые следует учитывать при использовании серверов, особенно в облаке, где ресурсы сервера являются эфемерными:

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

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

Относитесь к своей инфраструктуре как к коду
Автоматизация применяется не только к серверам и должна распространяться на вашу инфраструктуру, когда это возможно. Разверните свою инфраструктуру (серверы или иное) с помощью менеджеров развёртывания, таких как Terraform, AWS CloudFormation и Google Cloud Deployment Manager.

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

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

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

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

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

Ограничения времени выполнения
Бессерверные платформы не дают вам полных абстракций операционной системы. Вместо этого вы ограничены определённым образом времени выполнения.

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

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

  • 787 Business Jet
— Дальность: 9945 морских миль (с 25 пассажирами)
— Максимальная скорость: 0,90 Маха
— Крейсерская скорость: 0,85 Маха
— Запас топлива: 101 323 килограмма
— Максимальный взлетный вес: 227 930 килограммов
— Максимальная тяга: 128 000 фунтов
  • Tesla Model S Plaid
— Запас хода: 560 километров
— Максимальная скорость: 322 километра/час
— Разгон от 0 до 100 километров/час: 2,1 секунды
— Емкость аккумулятора: 100 киловатт-часов
— Время круга на Нюрбургринге: 7 минут, 30,9 секунды
— Мощность: 1020
— Крутящий момент: 1050 фунт-фут

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

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

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

Для тестирования реальных сценариев использования необходимо смоделировать ожидаемые реальные данные и размер запроса. Оцените производительность запросов и затраты ресурсов на основе подробной оценки ваших потребностей.
Бессмысленные сравнения затрат
Бессмысленные сравнения затрат — стандартный приём при анализе соотношения цены и производительности или совокупной стоимости владения. Например, многие системы MPP не могут быть легко созданы и удалены, даже если они находятся в облачной среде; эти системы работают годами после настройки. Другие базы данных поддерживают динамическую модель вычислений и взимают плату либо за запрос, либо за секунду использования. Сравнение эфемерных и неэфемерных систем на основе стоимости за секунду бессмысленно, но мы постоянно видим это в бенчмарках.
Асимметричная оптимизация
Обман асимметричной оптимизации проявляется во многих обличьях, но вот один пример. Часто поставщик сравнивает систему MPP на основе строк с базой данных столбцов, используя бенчмарк, который запускает сложные запросы на соединение с высоконормализованными данными. Нормализованная модель данных оптимальна для системы на основе строк, но система столбцов реализует весь свой потенциал только с некоторыми изменениями схемы. Чтобы сделать ситуацию ещё хуже, поставщики накачивают свои системы дополнительной порцией оптимизации соединений (например, прединдексируя соединения) без применения сопоставимой настройки в конкурирующей базе данных (например, помещая соединения в материализованное представление).
Caveat Emptor (лат.)
Пусть покупатель остерегается
Как и во всем, что касается технологий обработки данных, пусть покупатель будет осторожен. Проделайте домашнюю работу, прежде чем слепо полагаться на показатели поставщиков для оценки и выбора технологий.
Фоновые процессы
и их влияние на выбор технологий
Как видно из этой главы, инженеру данных нужно многое учесть при оценке технологий. Какую бы технологию вы ни выбрали, обязательно узнайте, как она поддерживает фоновые процессы жизненного цикла инженерии данных. Давайте кратко рассмотрим их ещё раз.
Управление данными
Управление данными — это обширная область, и, что касается технологий, не всегда очевидно, рассматривает ли технология управление данными как основную задачу. Например, за кулисами сторонний поставщик может использовать лучшие практики управления данными — соответствие нормативным требованиям, безопасность, конфиденциальность, качество данных и управление — но скрывать эти детали за ограниченным слоем пользовательского интерфейса. В этом случае при оценке продукта полезно спросить компанию о её практиках управления данными. Вот несколько примеров вопросов, которые вам следует задать:
  • Как вы защищаете данные от нарушений, как извне, так и изнутри?
  • Насколько ваш продукт соответствует GDPR, CCPA и другим правилам конфиденциальности данных?
  • Разрешаете ли вы мне размещать мои данные в соответствии с этими правилами?
  • Как вы обеспечиваете качество данных и то, что я просматриваю правильные данные в вашем решении?
Есть много других вопросов, которые нужно задать, и это лишь некоторые из способов думать об управлении данными, поскольку это касается выбора правильных технологий. Эти же вопросы должны также относиться к решениям ОПО, которые вы рассматриваете.
DataOps
Проблемы произойдут. Они просто будут. Сервер или база данных могут выйти из строя, часть облака может выйти из строя, вы можете развернуть ошибочный код, в ваше хранилище данных могут быть введены неверные данные, и могут возникнуть другие непредвиденные проблемы.

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

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

Архитектура данных
Как обсуждалось в Главе 3, хорошая архитектура данных означает оценку компромиссов и выбор лучших инструментов для работы, сохраняя при этом обратимость решений. Поскольку ландшафт данных меняется с невероятной скоростью, лучшим инструментом для работы является движущаяся цель. Главные цели — избежать ненужной блокировки, обеспечить совместимость по всему стеку данных и обеспечить высокую окупаемость инвестиций. Выбирайте свои технологии соответствующим образом.
Пример оркестровки: Airflow
На протяжении большей части этой главы мы активно избегали слишком подробного обсуждения какой-либо конкретной технологии. Мы делаем исключение для оркестровки, поскольку в этой области в настоящее время доминирует одна технология с открытым исходным кодом — Apache Airflow.
Максим Бошмен запустил проект Airflow в Airbnb в 2014 году. Airflow изначально разрабатывался как некоммерческий проект с открытым исходным кодом. Фреймворк быстро приобрел значительную популярность за пределами Airbnb, став проектом Apache Incubator в 2016 году и полностью спонсируемым Apache проектом в 2019 году.

Airflow имеет много преимуществ, в основном из-за его доминирующего положения на рынке открытого исходного кода. Во-первых, проект с открытым исходным кодом Airflow чрезвычайно активен, с высоким уровнем коммитов и быстрым временем реагирования на ошибки и проблемы безопасности, и проект недавно выпустил Airflow 2, крупный рефакторинг кодовой базы. Во-вторых, Airflow пользуется огромной популярностью. Airflow имеет яркое, активное сообщество на многих коммуникационных платформах, включая Slack, Stack Overflow и GitHub. Пользователи могут легко находить ответы на вопросы и проблемы. В-третьих, Airflow доступен на коммерческой основе как управляемая услуга или дистрибутив программного обеспечения через многих поставщиков, включая GCP, AWS и Astronomer.io.

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

Мы не пытаемся здесь дать исчерпывающее обсуждение альтернатив Airflow, а просто упоминаем пару ключевых претендентов на оркестровку на момент написания статьи. Prefect и Dagster стремятся решить некоторые из проблем, обсуждавшихся ранее, путём переосмысления компонентов архитектуры Airflow. Будут ли другие фреймворки и технологии оркестровки, не обсуждаемые здесь? Можете на это рассчитывать.

Мы настоятельно рекомендуем всем, кто выбирает технологию оркестровки, изучить обсуждаемые здесь варианты. Им также следует ознакомиться с деятельностью в этой области, поскольку к тому времени, как вы это прочтете, наверняка появятся новые разработки.
Программная инженерия
Как инженер данных, вы должны стремиться к упрощению и абстракции во всем стеке данных. Покупайте или используйте готовые решения с открытым исходным кодом, когда это возможно. Устранение недифференцированной тяжелой работы должно быть вашей главной целью. Сосредоточьте свои ресурсы — пользовательское кодирование и инструменты — на областях, которые дают вам надёжное конкурентное преимущество. Например, является ли ручное кодирование соединения базы данных между вашей производственной базой данных и вашим облачным хранилищем данных конкурентным преимуществом для вас? Вероятно, нет. Это вполне решённая проблема. Выберите вместо этого готовое решение (с открытым исходным кодом или управляемое SaaS). Миру не нужен миллионный +1 коннектор базы данных в облачное хранилище данных.

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