Это данные, тупица, и почему администраторы баз данных важны как никогда?

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

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

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

NoSQL базы данных не требуют предопределённой схемы данных, а многие репликации встроены по умолчанию. Подготовку новых серверов к работе можно свести к нажатию нескольких переключателей (радио-баттонов) и выставлению галочек на веб-странице. Команды разработчиков просто выбирают точку в облачном хранилище, таком как Amazon Web Services Simple Storage Service (S3), и идут отдыхать (roll). И даже разработчики реляционных БД, таких как Oracle, Microsoft и IBM, подталкивают клиентов к data-as-a-service (DaaS) моделям, кардинально упрощающим доступность и управление оборудованием.

Вы могли подумать, что от этого работа админов БД становится легче. Отнюдь.

«Я думаю, что их задачи [админов БД] стали значительно более сложными, — сказал Крис Лалонд, вице-президент и генеральный менеджер по работе с данными компании Rackspace. — Пока у нас не будет определённо большей автоматизации и технологической оснастки (инструментария), многие новые технологии будут менее зрелыми и их нужно будет холить и лелеять (они требуют больше ухода и кормления). Я хочу сказать, что многие из традиционных задач админов БД всё ещё существуют или должны существовать».

На самом деле все эти великолепные новые технологии подчёркивают профессионала в области данных, будь то администратор БД, архитектор данных, data engineer или даже, в некоторых случаях, data scientist. «Сегодня данные ещё более важны, — сказал Кенни Горман, ветеран БД и соучредитель Eventador (сервис для передачи данных в режиме реального времени). — Компании привыкли полагаться на базы данных, чтобы быть «на подъёме» (to be sound), работать гладко и давать хорошую отчётность. Но сегодня данные и вправду делают вас более конкурентоспособным, и существует больше разных профессий, связанных с данными, и больше технологий, их использующих. И профессионал по БД — в самом центре».

На шаг вперёд...

Нереляционные платформы пообещали снизить нагрузку на администраторов БД. В некотором роде они, действительно, сделали это. Рави Мэюрем, старший вице-президент Couchbase Inc. по продуктам и разработкам, сравнил сдвиг в обязанностях АБД с изменением вождения автомобиля (на протяжении многих лет): давным-давно «для того, чтобы водить машину, вы должны были по существу быть инженером; и когда что-то шло не так, вам нужно было сворачивать с дороги и лезть под капот. Теперь вещи сами заботятся о себе, но я бессилен их исправить».

Такие базы данных как MongoDB и CouchBase, хоть они и не реляционные, поддерживают SQL запросы. У них есть и другие аспекты, вызывающие благосклонность опытных админов БД. Но они также предоставляют «возможности динамического развёртывания, которых нет у реляционных систем, — утверждает Мэюрем. — А добавление новых структур данных обычно требует изменения схемы и влечёт к простою».

Данные как некая Услуга были отданы «на откуп компаний, — считает Мэюрем. — Большинство компаний не держат в облаке критически важную информацию».

В то время как большая реляционная система управления базами данных требует понимания всего аппаратного и программного обеспечения, «следующее поколение АБД будет вовлечено в это намного меньше, — объясняет Мэюрем. — К админу БД будет предъявляться, например, такое требование: всеобъемлюще разбираться в базах данных, но не только», чтобы сосредоточиться на таких задачах как планирование мощностей. АБД будущего должен будет знать, когда следует снабдить бо́льшим количеством серверов, а когда изымать их из обращения.

Такого рода динамическая масштабируемость и привела к выбору облачных сервисов данных на основе специализированных БД и «Data-as-a-Service схем» (размещённым либо у себя, либо на постороннем хостинге ^[1]). В любом случае — сервисы снабжения могут позаботиться о настройке аппаратных средств, сети и системы хранения данных. Теоретически АБД должны сконцентрироваться на выяснении того, когда приложению потребуется больше возможностей (бо́льшие объёмы) баз данных. «Это пример функции DevOps, а иметь дело с динамическим снабжением — это немного другой профиль, — говорит Мэюрем. — Для большей эффективности им не нужно так много навыков АБД, они скорее должны уметь планировать мощности и лучше разбираться в разработке».

Для тех, кто не знает, DevOps — это практика, которая сегодня широко используется в Web’е и разработке сервисов. Она описывает, как команды разработчиков приложений работают совместно с айтишниками, чтобы постоянно повышать производительность, автоматизацию и масштабируемость программного обеспечения и систем. DevOps подход стал основным двигателем перехода на NoSQL базы данных и другие нетрадиционные технологии хранения данных и запросов. DevOps привёл к развитию Data-as-a-Service — в основном из-за необходимости автоматизировать масштабирование ёмкостей баз данных. Но даже в сугубо реляционном мире сдвиг в сторону превращения баз данных в облачные сервисы сводит к минимуму необходимость (и даже саму возможность) мелкомодульного контроля аппаратной конфигурации со стороны АБД.

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

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

Ниже приведена схема базы данных для MediaWiki — платформы, используемой Wikipedia. Некоторые специализированные базы данных не требуют схем в явном виде, но схема живёт по-другому, и понимание структур данных остаётся важным.

Схема MediaWiki

Слухи о смерти сильно преувеличены

В декабре 2013 года Кенни Горман написал статью с провокационным заглавием «Администратор БД мёртв». Но заключил её торжественным заявлением «Администратору БД — многие лета».

«Смысл этого высказывания в том, что АБД по-прежнему важен», — недавно сообщил Горман компании Ars. Как давнишний администратор баз данных Oracle и архитектор данных в компаниях, работающих с PayPal и eBay, Горман оказался погружённым в MongoDB на Shutterfly, да ещё и адептом NoSQL. В статье, которую он написал, будучи главным архитектором data-as-a-service провайдера ObjectRocket, Горман отметил: «Большинство наших клиентов не имеют в штате администраторов БД». Но это не значит, что работы для них не осталось.

«По мере продвижения к облаку, — объясняет Горман, — с дата-сервисами, микросервисами и всем «бессерверным» движением (сервисы типа Amazon Web Services' Lambda и Google Cloud Functions), мир обработки данных продолжает эволюционировать. Он изменил и роль админа БД — это уже не тот парень, который управляет сервером Oracle в дата-центре для конкретной компании. Теперь есть технологии хранения данных, существующие по всему облаку в различных формах, которыми он должен управлять.

Несмотря на то, что многие из этих новых технологий баз данных автоматизировали большую часть того, что обычно делал АБД, это вовсе не означает, что произошло уменьшение нагрузки на админов БД. «Я считаю, что автоматизация уменьшила потребность в традиционных Ops’ах, так как они помогают масштабировать аппаратное обеспечение и, следовательно, объёмы запросов, — сказал Лалонд. — Но существует не так много инструментов, помогающих находить и исправлять медленные запросы, а также выбирать наилучший shard key, — пояснил он. — Я уверен, что автоматизация позволит работать в больших масштабах с меньшими ресурсами, но в конечном итоге вам по-прежнему нужен эксперт, разбирающийся во всём этом».

Горман считает, что сложность новой среды обработки данных делает работу администраторов БД не легче, а ещё труднее, чем раньше. Это отчасти потому, что админы БД уже не могут быть столь узко специализированными, как они были когда-то. «Когда-то я запускал серверы баз данных для PayPal и eBay за один день, — объясняет он, — и у нас была одна-две технологии, а не 50. Если ты знал Oracle, ты мог, возможно, разобраться с Microsoft SQL сервером — эти технологии дополняют друг друга». Теперь всё не так, утверждает Горман. Сегодня вы должны понимать разницу между Elasticsearch, Hadoop, [Apache] Kafka и Oracle — чем они отличаются, и почему в конкретном случае одна из них лучше, чем другая».

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

«Наша профессия постепенно эволюционировала, оставив позади системы управления и хранения данных в роде БД, — сказал Горман. Oracle была явно базой данных. Но в наши дни само понятие о том, что такое база данных, изменилась. К примеру, Hadoop — это база данных?» В ObjectRocket Горман выстроил дата-сервисы вокруг MongoDB. «Довольно очевидно, что это база данных, — сказал он, — но наш новый стартап основан на [Apache] Kafka — а это база данных?» (Kafka — это сервер, именуемый брокером, который поставляет приложениям реального времени потоки данных из «подписок» запросов) «Ну да, она обладает свойствами базы данных. То есть перетасовывает данные в режиме реального времени. Таким образом, это сумасшедшая эволюция, при которой мы даже не знаем, является ли вообще продукт или инфраструктура данных — базой данных. Вода очень мутна. Теперь это реально системы обработки данных, и у каждой из них есть свои нюансы и компоненты».

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

В результате, подытожил Лалонд, админы БД «должны иметь те же навыки, которые они имели всегда. Конечно, современные админы должны быть более гибкими, понимать весь спектр технологий, а также хорошо себя чувствовать в гибкой методологии разработки (agile). В общем, мы ожидаем того, кто действительно понимает основы теории баз данных, потому что понимание этих основ прекрасно транслируется сквозь разные технологии».

И всё же, кто такой АБД?

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

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

«Я думаю, что роли разработчика, DevOp’а и специалиста по данным — это может быть data engineer, АБД или data scientist — должны справляться с множеством новых технологий, — считает Горман. Каждая из этих технологий имеет свой собственный спектр зрелости, функций и возможностей». А это значит, что каждая из этих ролей теперь требует по крайней мере некоторых навыков АБД.

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

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

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

Автор: JustRamil

Источник ^[2]