Когда SQL недостаточно: управление огромными новыми центрами обработки данных

Автор: Judy Howell
Дата создания: 3 Июль 2021
Дата обновления: 1 Июль 2024
Anonim
PostgreSQL: практические примеры оптимизации SQL-запросов /  Иван Фролков (Postgres Professional)
Видео: PostgreSQL: практические примеры оптимизации SQL-запросов / Иван Фролков (Postgres Professional)

Содержание



вынос:

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

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

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


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

Файловая система Google: большой пример

Запатентованная технология, которую Google использует для доступа к своим центрам обработки данных, является одним из лучших примеров распространенных моделей для обработки больших данных и администрирования нескольких центров обработки данных. Файловая система Google (GFS), разработанная в 2003 году, предназначена для поддержки огромного объема высокоскоростных поправок к системам данных, которые являются частью получения столь большого количества новой информации на одной платформе и из нее, когда миллионы пользователей нажимают на в то же время. Эксперты называют это распределенной файловой системой и используют термин «хранилище объектов данных» для описания этих очень сложных методов. В действительности, однако, эти термины даже не касаются поверхности с точки зрения описания того, что работает.


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

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

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

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

Нет ошибок, нет стресса - ваше пошаговое руководство по созданию изменяющего жизнь программного обеспечения без разрушения вашей жизни

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

"То, что вы в конечном итоге пропустили, это все крутой фактор как они делают то, что делают ", - сказал Лебель.

Если вы отойдете от технических деталей и просто подумаете об основной идее распределенной файловой системы, «крутой фактор», о котором говорит Лебель, очевиден. Эти системы обработки больших данных заменяют старые системы файлов / папок структурами, которые включают в себя не только несколько систем доставки, но и «объектно-ориентированный» подход, при котором огромное количество устройств разбросано здесь и там, чтобы избежать узких мест.

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

Взгляд на основную технологию

Статья Шона Галлахера, появившаяся на Ars Technica, разбивает дизайн GFS на несколько более управляемые части и намекает на то, что находится под таблицей в Google.

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

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

Как другие большие системы достигают этого?

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

«Например, создание метаданных (данных о данных) на каждом диске позволяет этому диску перестроить его правильную структуру данных, если его зеркальная копия повреждена», - сказал Михайлов. «Кроме того, уровни RAID можно использовать для борьбы со сбоями хранилища либо на уровне агрегатора файловой системы, либо на уровне менеджера общих томов».

Обсуждая другую модель согласованности, Лебель фокусируется на системе, называемой распределенной файловой системой Hadoop (HDFS), которую он называет «отраслевым стандартом де-факто».

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

Все это поддерживает виды «чистых данных», которые так важны для целостности одной из этих систем массовых данных.

Поддержание DFS

Еще один совершенно иной взгляд на GFS взят из статьи за октябрь 2012 года автора Wired Стивена Леви. Гораздо короче охарактеризовать программный подход для коллективной обработки нисходящей сети Google.

«За прошедшие годы, - пишет Леви, - Google также создала программную систему, которая позволяет ей управлять своими бесчисленными серверами, как если бы они были одной гигантской сущностью. Ее собственные разработчики могут действовать как марионеточные мастера, отправляя тысячи компьютеров для выполнения». задачи так же легко, как запуск одной машины ".

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

Леви также упоминает дополнительные технологии для GFS, такие как MapReduce, инструмент облачных приложений, и Hadoop, механизм аналитики, который разделяет некоторые принципы проектирования с GFS. Эти инструменты имеют свое влияние на то, как разрабатываются большие системы обработки данных, и что может появиться в будущем. (Узнайте больше об этих технологиях в «Эволюции больших данных».)

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

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

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

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