Как Google использует иерархию серверов и столбцовое хранение данных для обработки массивных наборов данных

Описание

Какую задачу решает

Патент решает проблему масштабируемости хранения и обработки запросов к сверхбольшим объемам данных (порядка сотен терабайт), характерных для data mining и бизнес-аналитики. Он устраняет неэффективность традиционных распределенных баз данных, которые извлекают целые строки данных, когда для обработки запроса требуются только несколько столбцов. Также он преодолевает ограничения распределенных файловых систем, которым не хватает поддержки семантических операций (например, перераспределения данных).

Что запатентовано

Запатентована система распределенного хранения и обработки запросов. Ключевыми особенностями являются хранение данных в виде Column Chunks (столбцовый формат) для эффективного сжатия и извлечения, а также распределение этих фрагментов по множеству серверов с обеспечением избыточности (Parity Column Chunk). Для обработки запросов используется динамическое формирование Hierarchy of Servers (Иерархии серверов), что позволяет выполнять запросы параллельно.

Как это работает

Система работает следующим образом: таблицы данных разбиваются на Column Chunks в соответствии с заданными политиками хранения. Эти фрагменты распределяются (striping) по множеству серверов хранения. Для отказоустойчивости вычисляются и сохраняются фрагменты четности (parity). При получении запроса система трансформирует его в набор подзапросов (sub-queries). Динамически определяется иерархия серверов (например, трехуровневая) для выполнения этих подзапросов. Серверы работают параллельно, часто используя локальные или кэшированные данные. Промежуточные результаты агрегируются вверх по иерархии для формирования итогового ответа.

Актуальность для SEO

Высокая (для инфраструктуры). Описанные принципы — столбцовое хранение, распределенные вычисления, динамическая оптимизация запросов — лежат в основе современных систем обработки больших данных Google (таких как BigQuery/Dremel). Хотя конкретная реализация могла эволюционировать с момента подачи исходной заявки (2005 год), описанный архитектурный подход остается фундаментальным и актуальным.

Важность для SEO

Минимальное (1/10). Патент описывает внутреннюю инфраструктуру Google для хранения и обработки данных (архитектуру баз данных), а не алгоритмы ранжирования, сигналы качества или методы интерпретации контента. Он не дает прямых рекомендаций для SEO-специалистов по оптимизации сайтов. Понимание этой инфраструктуры полезно для общего технического контекста работы поисковой системы, но не влияет на повседневные SEO-задачи.

Детальный разбор

Термины и определения

Column Chunk (Фрагмент столбца)

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

Column Chunk Data Store (Хранилище данных фрагментов столбцов)

Распределенная система хранения, состоящая из множества серверов, хранящих Column Chunks.

Data Domain Compression (Сжатие домена данных)

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

Distribution Policy (Политика распределения)

Правила, определяющие, как Column Chunks распределяются (например, striping) между доступными серверами хранения.

Hierarchy of Servers (Иерархия серверов)

Динамически определяемая структура серверов обработки запросов (например, Level 1, Level 2, Level 3), используемая для распределенного и параллельного выполнения запроса.

Parity Column Chunk (Фрагмент столбца четности)

Специальный фрагмент данных, созданный (например, с помощью операции XOR) на основе двух или более других Column Chunks. Используется для восстановления данных при отказе одного из серверов.

Query Processing Server (Сервер обработки запросов)

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

Storage Policy (Политика хранения)

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

Storage Server (Сервер хранения)

Сервер, физически хранящий Column Chunks и предоставляющий к ним доступ.

Sub-queries (Подзапросы) / Transformed Query

Части исходного запроса, полученные в результате его трансформации для распределенного выполнения на разных серверах.

Ключевые утверждения (Анализ Claims)

Патент описывает внутренние процессы Google без прямых рекомендаций для SEO.

Claim 1 (Независимый пункт): Описывает комплексный метод управления данными и обработки запросов в распределенной системе.

1. Создание первого и второго Column Chunks из таблицы данных. Создание основано на Storage Policy (определяет количество фрагментов) и Distribution Policy (определяет размещение).
2. Создание Parity Column Chunk на основе первого и второго фрагментов для обеспечения возможности восстановления данных.
3. Распределение первого и второго фрагментов для хранения на серверах.
4. Получение запроса к данным.
5. Трансформация исходного запроса в несколько sub-queries (подзапросов).
6. Распределение первого и второго подзапросов на разные серверы обработки запросов (query servers).
7. Получение промежуточных результатов (sub-results) от этих серверов.
8. Объединение промежуточных результатов в итоговый результат (master result).
9. Отправка ответа на запрос.

Claim 2 (Зависимый от 1): Уточняет метод создания Parity Column Chunk.

Создание фрагмента четности включает выполнение побитовой операции XOR над данными первого и второго Column Chunks.

Claim 3 (Зависимый от 1): Уточняет размещение Parity Column Chunk.

Фрагмент четности распределяется для хранения на сервере, отличном от серверов, на которых хранятся исходные первый и второй Column Chunks. Это необходимо для обеспечения отказоустойчивости.

Где и как применяется

Патент описывает инфраструктуру хранения и извлечения данных. Он не описывает стандартные фазы поисковой архитектуры (Ranking, Query Understanding и т.д.), а скорее базовую платформу (Data Store), на которой эти фазы могут оперировать при работе с большими данными.

INDEXING – Индексирование (Хранение данных)
Описанная система предназначена для хранения массивных наборов данных, собранных и обработанных в процессе индексирования (например, индекс ссылок, логи поведения пользователей, Content Warehouse). Механизмы Column Chunks, Data Domain Compression и распределенное хранение с Parity Column Chunk применяются при записи данных в хранилище.

RANKING – Ранжирование (Обработка запросов к данным)
Когда алгоритмам ранжирования требуется доступ к этим массивным наборам данных для анализа или извлечения признаков, система обработки запросов (Query Processing Servers) использует описанную Hierarchy of Servers для эффективного извлечения и агрегации информации.

Входные данные:

• Таблицы данных (для загрузки в хранилище).
• Storage Policy и Distribution Policy.
• Запрос (Query) к данным в хранилище.

Выходные данные:

• Сохраненные и распределенные Column Chunks и Parity Column Chunks.
• Итоговый результат выполнения запроса (Master Result).

На что влияет

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

Когда применяется

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

Пошаговый алгоритм

Процесс А: Хранение данных

1. Доступ к политике: Система получает доступ к Storage Policy для определения метода разделения таблицы и уровня избыточности.
2. Разделение данных: Таблица данных разделяется на Column Chunks (например, с использованием range, list или hash partitioning).
3. Сжатие: К фрагментам применяется Data Domain Compression.
4. Вычисление четности: Система вычисляет Parity Column Chunks (например, через XOR) для обеспечения отказоустойчивости.
5. Распределение: На основе Distribution Policy, фрагменты данных и фрагменты четности распределяются (striping) по разным серверам хранения (Storage Servers).

Процесс Б: Обработка запроса

1. Получение запроса: Клиент отправляет запрос на сервер обработки запросов (например, Level 3).
2. Парсинг и Анализ: Сервер проверяет синтаксис и семантику запроса.
3. Оптимизация и Трансформация: Оптимизатор запросов определяет шаги выполнения и трансформирует запрос в набор подзапросов (sub-queries) для распределенного выполнения.
4. Определение Иерархии: Система динамически определяет иерархию серверов (Level 1, Level 2) для выполнения подзапросов. Выбор серверов может основываться на расположении необходимых Column Chunks (включая кэшированные данные).
5. Распределение подзапросов: Подзапросы и инструкции по обработке отправляются вниз по иерархии (например, с Level 3 на Level 2, затем на Level 1).
6. Параллельное выполнение (Level 1): Серверы нижнего уровня выполняют подзапросы, извлекая необходимые Column Chunks (из кэша или с серверов хранения) и обрабатывая их.
7. Агрегация промежуточных результатов (Level 2): Серверы среднего уровня получают промежуточные результаты от серверов нижнего уровня и объединяют (combine) их согласно инструкциям.
8. Финальная агрегация (Level 3): Головной сервер получает результаты от среднего уровня, выполняет финальное объединение и формирует итоговый ответ (master result).
9. Возврат результата: Ответ отправляется клиенту.

Какие данные и как использует

Данные на входе

Патент фокусируется на инфраструктуре и не упоминает конкретные SEO-факторы (контентные, ссылочные, поведенческие, временные и т.д.). Он оперирует следующими типами данных:

• Структурные данные: Таблицы данных, состоящие из строк и столбцов, которые преобразуются в Column Chunks.
• Системные данные (Метаданные): Информация о физическом расположении Column Chunks, политиках хранения (Storage Policy), политиках распределения (Distribution Policy), состоянии серверов (нагрузка, доступность) и наличии кэшированных данных на серверах обработки запросов.

Какие метрики используются и как они считаются

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

• Размер результатов: Оценка размера промежуточных результатов выполнения подзапросов. Это используется для определения того, как лучше всего агрегировать данные на среднем уровне иерархии (Level 2).
• Локальность данных: Учет того, какие серверы (Query Processing Servers) уже кэшируют необходимые Column Chunks. Оптимизация направлена на выполнение вычислений на тех серверах, где данные уже присутствуют, для минимизации передачи данных по сети.

Выводы

Патент описывает внутренние процессы Google, связанные с инфраструктурой хранения и обработки больших данных, без прямых рекомендаций для SEO.

1. Столбцовое хранение (Columnar Storage): Google использует формат Column Chunks для хранения массивных наборов данных. Это позволяет применять высокоэффективное сжатие, специфичное для типа данных (Data Domain Compression), и оптимизировать извлечение данных, читая только необходимые для запроса столбцы, а не целые строки.
2. Отказоустойчивость через избыточность: Система обеспечивает целостность данных и возможность восстановления при сбоях оборудования с помощью вычисления и хранения Parity Column Chunks (используя операцию XOR). Эти фрагменты четности хранятся отдельно от исходных данных.
3. Масштабируемая обработка запросов: Для обработки запросов к большим данным используется динамически формируемая Hierarchy of Servers. Запросы трансформируются в подзапросы (sub-queries) и выполняются параллельно на множестве серверов с последующей агрегацией результатов.
4. Оптимизация через кэширование: При формировании иерархии и планировании выполнения запроса система стремится использовать кэшированные Column Chunks на серверах обработки запросов для ускорения работы и снижения нагрузки на сеть и дисковую подсистему.

Практика

Патент является инфраструктурным и не дает практических выводов или рекомендаций для SEO-специалистов по оптимизации сайтов.

Best practices (это мы делаем)

Информации в патенте нет.

Worst practices (это делать не надо)

Информации в патенте нет.

Стратегическое значение

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

Практические примеры

Практических примеров применения данного патента в SEO-работе нет, так как он описывает архитектуру и принципы работы распределенных баз данных.

Вопросы и ответы