DataLakes и DataWarehouses: как они используются в SEO
Опубликовано: 2021-02-16Хотя концепции DataWarehouses и DataLakes уже давно стали частью повседневного языка аналитиков данных и специалистов по данным, в других отраслях мы слышим о них только последние несколько лет.
Например, веб-аналитики и эксперты по поисковой оптимизации начинают серьезно относиться к этим концепциям из-за характера своей работы и тесной связи между тем, что они делают, и манипулированием данными. Во многих недавних статьях говорится об интересе к внедрению SEO DataLake или SEO DataWarehouse, рассматривая эти два термина как взаимозаменяемые и не делая различий между ними.
В этой статье мы поможем вам определить различия между DataLakes и DataWarehouses, чтобы понять их цели и варианты использования в SEO и веб-аналитике.
DataWarehouse: структурированное хранилище данных
Первое использование термина «хранилище данных» относится к 1988 году в статье Пола Мерфи и Барри Делвина «Архитектура для бизнеса и информационных систем ». В этой статье мы даем первое определение концепции легкодоступной среды реляционной базы данных, объединяющей все бизнес-данные, необходимые для принятия стратегических решений.
Что содержит хранилище данных?
Хранилище данных используется для сбора бизнес-данных, полезных для принятия стратегических решений в компании, в одном месте. Мы говорим о бизнес-данных, которые могут охватывать что угодно: от данных о клиентах до информации о запасах, конверсиях на коммерческом веб-сайте или обычных посещениях (например, из поисковой системы, такой как Google).
Общепринято, что данные, отправляемые в DataWarehouse, представляют собой структурированные, предварительно обработанные данные, используемые для разгрузки операционных баз данных, что в конечном итоге позволяет как можно реже запрашивать эти рабочие базы данных для запросов.
Основная цель хранилища данных и тех, кто его администрирует, состоит в том, чтобы собирать данные из различных разнородных источников (как внутренних, так и внешних) для их стандартизации, чтобы различные источники могли взаимодействовать друг с другом. Конечная цель — использовать эти данные для проведения анализа, отчетности, поддержки принятия решений и т. д.
Кто является ежедневными пользователями хранилища данных?
Из-за характера DataWarehouse, формата и типа содержащихся в нем данных это идеальная площадка для аналитиков данных и веб-аналитиков.
Аналитики данных работают вместе с администратором хранилища данных (или группой администраторов). Они определяют потребности бизнеса и варианты использования. Они определяют источники данных и действия, необходимые для обработки данных вверх по течению. Затем эти данные будут использоваться аналитиками данных в конце цепочки.
Как пользователи взаимодействуют с хранилищем данных?
Как только источники данных определены, а данные обработаны, загружены и связаны в DataWarehouse, аналитик данных может использовать эти данные в анализе и для создания новых комбинаций данных. Этот процесс можно использовать для обслуживания информационных панелей отчетов, информационных панелей предупреждений и т. д.
Наиболее часто используемый язык программирования для запросов в DataWarehouse — это SQL (или SQL-подобные языки). SQL позволяет аналитикам данных манипулировать и обрабатывать данные для удовлетворения потребностей бизнеса: мониторинг, принятие стратегических решений и т. д.
Какие варианты использования и типы проектов обслуживают хранилища данных?
Невозможно составить исчерпывающий список вариантов использования, связанных с использованием DataWarehouse. Однако вот несколько примеров проектов, над которыми может работать аналитик данных:
Улучшение хранилища данных:
Этот тип проекта часто встречается при настройке хранилища данных, а также при выявлении новой потребности или бизнес-варианта использования.
Здесь речь идет о добавлении новых данных в СХД (опять же, это могут быть внутренние или внешние данные).
В этом случае мы часто говорим о процессе ETL (извлечение-преобразование-загрузка):
- Добыча:
Первый шаг состоит в выявлении и сборе данных из различных источников, необходимых для дальнейших операций. - Трансформация:
Этот второй шаг очень важен, потому что без настройки, без стандартизации вообще невозможно использовать новые данные и заставить их общаться с уже существующими в СХД.
Таким образом, это этап необходимой стандартизации, который иногда может быть осложнен жесткостью, налагаемой DWH с точки зрения форматирования и схемы таблицы. - Загрузка:
Фаза приема данных, обработанных (и, таким образом, структурированных) в DWH.
Проведение статистических анализов:
Это очень частое использование DWH. Цель может состоять в том, чтобы доказать X или Y с помощью данных, получить статистику на основе имеющихся исторических данных или установить причинно-следственные связи для объяснения открытия и т. д.
Отчетность и оповещение:
Это, еще раз, очень частый случай использования. На самом деле, поскольку данные в DWH хорошо структурированы и отформатированы (используя фиксированную и предопределенную схему), все они подходят для передачи данных на информационные панели отчетов или предупреждений.
Это повторяющийся запрос от высшего руководства, которому необходимо иметь возможность отслеживать операционные команды и состояние результатов, продаж и т. д. самым простым и быстрым способом.
Если обобщить все это, у нас есть более или менее 2 типа проектов: проекты сбора и интеграции данных (которые также можно сравнить с формой хранения и историзации данных) и проекты анализа и оценки данных (посредством мониторинга/панели мониторинга и оповещения). ).
Понятие СХД давно присутствует в повседневном языке тех, кто работает с данными. То, как это работает, и его многочисленные варианты использования давно подтверждены, и DWH можно найти во многих компаниях разной степени зрелости, когда речь идет о вопросах управления данными.
В меньшей степени это относится к концепции DataLakes, которая гораздо моложе и менее распространена.
Данные при сканировании³
DataLake: озеро мегаданных (BigData)
Происхождение этой концепции приписывается Джеймсу Диксону, техническому директору Penthao, который определяет ее как решение для хранения и использования больших объемов данных без предварительной обработки и без обязательного конкретного варианта использования… В отличие от DWH, которые очень сильно ориентированы на к немедленной активации.
DL пытается заполнить пробел, который становится все более и более важным с появлением BigData, в том, что делать со всей этой массой данных, которые мы можем собрать сегодня, и как этим воспользоваться.
Что содержит DataLake?
Я начну с цитаты Джеймса Диксона, который использует очень вызывающее воспоминания сравнение, служащее одновременно объяснением названия его концепции «озеро» и дифференциацией с DWH:
«Если вы думаете о витрине данных как о магазине бутилированной воды — очищенной, упакованной и структурированной для удобного потребления, — озеро данных представляет собой большой водоем в более естественном состоянии. Содержимое озера данных поступает из источника, чтобы наполнить озеро, и различные пользователи озера могут приходить, чтобы исследовать, погрузиться или взять образцы».
Эта цитата прекрасно иллюстрирует разницу между типом данных, содержащихся в DWH, которые структурированы и организованы в таблицы с точными, фиксированными шаблонами, и типом данных, содержащихся в DataLake, которые являются необработанными, без предварительной обработки, доступными для использования. образцы по мере необходимости, будь то исследовательские или нет.
Там, где DWH ограничено размещением структурированных данных, DataLake создан для хранения всех видов необработанных данных (структурированных или нет). Дебаты между Тамарой Дулл (Amazon Web Service) и Энн Бафф (Microsoft SAS) дают нам более конкретное представление о содержимом DataLake:
«Озеро данных — это репозиторий, в котором хранится огромное количество необработанных данных в их собственном формате, включая структурированные, полуструктурированные и неструктурированные данные. Структура данных и требования не определены до тех пор, пока данные не потребуются».
Кто ежедневно пользуется DataLakes?
В то время как аналитик данных идеально подходит для работы со структурированными данными, содержащимися в DHW, необработанные данные вместо этого являются специальностью специалистов по данным, которые часто лучше подготовлены для манипулирования данными этого типа.
Это изменение в профиле данных и основном пользователе также приводит к различным языкам программирования и вариантам использования.
Какие варианты использования и типы проектов обслуживают DataLakes?
Из-за своей неструктурированной природы и значительного объема данных, которые может содержать DataLake, варианты использования могут сильно отличаться от тех, которые ранее встречались в структуре DWH, например:
- Внедрение алгоритмов машинного обучения для создания добавленной стоимости для BigData:
Мы часто говорим здесь о прогнозном анализе, основанном на алгоритмах машинного обучения, использующих все виды данных.
Чтобы взять более конкретный пример, давайте представим, что компания в финансовом секторе (банковское дело и страхование) хочет определить вероятность того, что финансовая транзакция X является мошеннической. Это может потребовать специалистов по данным, способных создавать алгоритмы машинного обучения, которые будут обучаться на астрономическом количестве данных, содержащихся в DataLake (количество, дата, частота, обычный профиль транзакций, выполняемых владельцем учетной записи и т. д.). Цель состоит в том, чтобы провести прогнозное исследование, которое будет использоваться для выявления потенциально мошеннических транзакций и, таким образом, позволит компании сократить время реакции на их обнаружение и в конечном итоге избежать больших потерь для них и их клиентов.
Это простой пример, который регулярно используется для иллюстрации интереса и добавленной стоимости машинного обучения, но существует столько других, сколько вы можете себе представить. - DataLakes как источник данных для DataWarehouse:
Проще говоря, DataLake может действовать как транзитная зона между вашими различными внутренними и внешними источниками данных и вашим DWH. Сам принцип DataLake заключается в централизации всех видов данных, структурированных или неструктурированных, для проведения прогнозных исследований с помощью машинного обучения или для извлечения в качестве образцов для анализа. Таким образом, DWH кажется очень подходящим для этой второй категории проектов и использует DataLake как потенциальный источник (при условии, что данные DataLake импортируются структурированным образом посредством предварительной обработки, если это необходимо). - От DataLake до программного обеспечения BI (Business Intelligence):
Мы можем рассматривать это как использование, подобное тому, которое мы видели с DataWarehouses, хотя существуют определенные особенности использования DataLake для этой цели. DataLake позволит вам делать несколько более экзотические визуализации (из-за разнообразия содержащихся в нем данных) с помощью таких инструментов, как Tableau, Qlikview, Google Data Studio, Microstrategy и т. д.
Как пользователи взаимодействуют с DataLake?
Учитывая варианты использования и пользователей (аналитиков данных), мы очень часто находим такие языки программирования, как Python, Java, R, Scala и т. д.…
По большей части эти языки уже давно присутствуют в области науки о данных.
Таким образом, DataLake — это инструмент для управления большими данными. Он опирается на массивное хранилище необработанных данных для расширенного анализа и визуализации, что позволяет улучшать данные, которые ранее не использовались широко.

Подводя итог, вот таблица дифференцирующих элементов, установленных с начала этой статьи:
Хранилище данных | DataLake | |
---|---|---|
Тип данных | Структурированные, предварительно обработанные данные, организованные в таблицы с определенными схемами | Необработанные данные, хранящиеся в структурированном или неструктурированном виде |
Пользователи | Аналитики данных, веб-аналитики | Специалисты по данным (иногда аналитики данных) |
Объем данных | Маленький большой (в зависимости от необходимости и варианта использования) | Потенциально очень большой (Большие данные) |
Используемый язык программирования | SQL или похожий на SQL | Python, R, Java, Scala и другие |
Тип проекта | Аналитические и статистические проекты, отчеты, оповещения, проекты типа ELT (экспорт, преобразование, загрузка), некоторые прогнозные и основанные на данных анализы | Предиктивный анализ, машинное обучение, транзитная зона между источниками данных и СХД, расширенная визуализация — BI, анализ на основе данных |
Предиктивный анализ, машинное обучение, транзитная зона между источниками данных и СХД, расширенная визуализация — BI, анализ на основе данных
Именно эти различия делают эти две концепции взаимодополняющими инструментами. Во многих случаях, в зависимости от зрелости управления компанией и управления данными, они могут полагаться на комбинацию этих двух инструментов.
DWH в основном используется для традиционной отчетности и анализа, тогда как DataLake служит источником данных, прежде чем полностью раскрыть свой потенциал, поскольку компания приближается к зрелости в отношении субъектов данных.
На мой взгляд, DataLakes — это скорее ответ на новые проблемы с данными 21 века, особенно с появлением BigData и растущими возможностями компаний по сбору данных, чем замена DWH, как некоторые могут подумать.
Оба имеют свои преимущества, недостатки, сильные и слабые стороны. Лучший способ получить максимальную отдачу от обоих — это по-прежнему использовать оба вместе, чтобы иметь возможность справиться с любой неожиданностью и удовлетворить более широкий спектр потребностей.
Теперь, когда мы четко определили концепции, мы, наконец, сосредоточимся на использовании DataWarehouses и DataLakes для маркетинга и, более конкретно, для SEO (даже если во многих случаях то, что верно для первого, будет верно для второго, и наоборот). наоборот).
DataWarehouse и DataLake SEO
Здесь мы поговорим о DataWarehouse или DataLake (или о том и другом), где по крайней мере часть имеющихся данных может быть использована для вариантов использования SEO.
Зачем связывать DataLakes и DataWarehouse с маркетингом и SEO?
SEO (и, в более общем смысле, маркетинг) в последние годы уже сделал очень заметный поворот в сторону данных. Все больше задач требуют использования различных источников данных:
- Аналитические данные (Google Analytics, AT internet и т.д.)
- Данные об эффективности (Google Search Console, Analytics)
- Данные журнала, очень большой «источник» данных для некоторых сайтов, который требует высокой частоты обновления и большой емкости хранилища.
- Сетевые данные (Majestic, Ahrefs, Babbar)
- Данные о местоположении (SEMRush, Monitorank и т. д.)
- Данные сканирования (OnCrawl и т. д.)
- Иногда также деловые/отраслевые данные
К этому списку мы также должны добавить использование API таких инструментов, как Search Console, Majestic, Google Analytics, например, что, естественно, подталкивает нас к решениям, описанным ранее в этой статье.
Именно эта прочная связь между SEO и данными побуждает все больше и больше веб-аналитиков и экспертов по SEO узнавать о новых способах организации конвейера данных.
Однако движущие силы этого перехода связаны не только с потенциалом и взаимосвязью SEO и данных. Многие повседневные варианты использования перекликаются с перечисленными выше типами проектов для DWH и DL.
Примеры использования SEO DataWarehouse или SEO DataLake.
Сначала я начну с проблем, с которыми обычно сталкиваются SEO-эксперты, а затем объясню, как использование DataLake или DataWarehouse является ответом, который следует учитывать при их решении.
Среди основных болевых точек выделяются следующие:
- Размножение файлов Excel (бумага с вкладными листами нашего десятилетия) и связанное с этим копирование и вставка:
Для многих SEO это все еще является нормой, но давайте будем честными, это отнимает много времени, ограничивает и очень способствует человеческим ошибкам. Для этого хранилище данных является идеальным решением. Хранилища данных не только позволяют собирать все KPI, необходимые для выполнения тех или иных аудитов/анализов из различных доступных источников данных, но и позволяют автоматизировать обработку, необходимую для достижения ожидаемого результата.
По мере создания DataWarehouse выявляется все больше и больше вариантов использования и решается все больше и больше проблем, что со временем приводит к все более значительной экономии времени. - Ограничения емкости (напоминаем, что Excel может открыть весь файл только в том случае, если он не превышает 1 048 576 строк. Это кажется большим, но на самом деле не так уж много в сегодняшних объемах): здесь нет особого варианта использования, потому что в в целом, как DataLakes, так и DataWarehouses не страдают от такого рода ограничений. Оба они предлагают средства для запроса больших объемов данных для любого типа потребностей. В данном конкретном случае важно иметь в виду, что в зависимости от необходимости тот или иной вариант позволит вам освободиться от ограничений возможностей и, в конечном счете, более легко решать эти ситуации.
- Реагировать на потребность в истории данных
Спойлер: одним из вариантов использования может быть, например, сохранение истории данных из Google Search Console в хранилище SEO DataWarehouse, а не копирование и разбивка его данных в Google Sheets каждую неделю для ведения панели управления Data Studio. По моему мнению, у нас есть один из самых распространенных вариантов использования среди экспертов по SEO, будь то в агентствах или внутри компании: историзация данных. Действительно, многие SEO-аналитики смотрят на исторические данные и делают на их основе выводы.
Пример, который, возможно, сразу пришел вам на ум, — это Google Search Console. Сегодня он предоставляет доступ только к 16-месячной истории (даже через API). И если ручное отставание по-прежнему возможно с помощью экспорта для вставки в Google Sheets каждую неделю (или другими непонятными методами), это значительная трата времени в дополнение к тому, что это болезненно и скучно.
Это хорошо, потому что это относительно простая проблема, которую можно решить с помощью DataWarehouse. Все, что вам нужно сделать, это настроить автоматическое подключение к API Google Search Console, определить различные возможные комбинации предварительной обработки и данных, необходимые для получения данных с реальной добавленной стоимостью, и, наконец, автоматизировать вызовы API. - Желание продолжить анализ, объединить или «перекрестно проанализировать» данные сканирования, данные об аудитории, журналы и т. д. промышленным способом.
Потому что небольшое конкурентное преимущество никогда не помешает. Приведенные нами описания DataWarehouse и DataLake говорят сами за себя. Одной из основных целей обоих инструментов является открытие новых возможностей для анализа посредством сбора данных и перекрестного анализа и/или машинного обучения.
Чтобы привести только один очень показательный пример; использование алгоритмов машинного обучения, таких как Random Forest или XG-Boost, для прогнозирования рейтинга в Google.
Проще говоря, идея состоит в том, чтобы обучить алгоритм большому количеству результатов поиска Google (страниц результатов) и всем показателям SEO, которые можно собрать для этих результатов поиска, чтобы определить на основе тех же показателей потенциал ранжирования данного URL (и поэтому, даже более конкретно, для определения наиболее важных показателей для ранжирования в конкретном секторе/теме).
→ Вы найдете полную методологию в статье Винсента Терраси, директора по продукту Oncrawl, «Успешное прогнозирование рейтинга Google на переднем крае науки о данных» , 2018. - Желание максимально автоматизировать отчетность, чтобы сосредоточиться на задачах с высокой добавленной стоимостью. Опять же, это буквально относится к классическим вариантам использования хранилища данных. Он дает возможность полностью автоматизировать восстановление и обработку различных источников данных и идеально решает эту проблему. После настройки таблица будет автоматически загружена в DWH и может использоваться в качестве подключения к программному обеспечению BI для создания информационных панелей, будь то мониторинг, оповещение и т. д. Конечно, автоматизация не ограничивается созданием отчетов только по проектам. И DWH, и DL можно использовать для многих автоматизированных SEO-оптимизаций. Например, динамические обновления внутренних блоков ссылок по рангу, краулинговому бюджету, SEO-аудитории и т. д. (все данные содержатся в DWH).
- Желание раз и навсегда покончить с заботами о безопасности (мы знаем, кто что сделал и где их найти) и не тратить время на обслуживание. Строго говоря, мы заканчиваем здесь на аспекте, более ориентированном на процесс, чем на вариант использования.
И DataLakes, и DataWarehouses подразумевают реализацию определенных процессов, которые можно представить в следующем упрощенном виде:- Отправной точкой является наблюдение, которое разбито на формулировку потребностей (бизнес-команда / SEO — аналитик данных).
- Затем это преобразуется в более техническую спецификацию, которая позволит команде, управляющей инструментом, понять, что нужно сделать и как это нужно сделать.
- Эта же административная группа выполняет запрос.
- Бизнес-группа и аналитики данных создают процедурный вариант использования для выполненной работы.
- Существует непрерывный процесс, в котором два конца цепочки (бизнес-группа и административная группа DataWarehouse или DataLake) следят за тем, чтобы ничего не менялось с точки зрения ввода и вывода.
В частности, это относится к DWH, который отклоняет любые данные, не являющиеся частью структуры (заранее определенной схемы).
Опять же, это неполный список болевых точек и возможных вариантов использования DataWarehouse — DataLake SEO. Ограничения возникают скорее из-за отсутствия воображения у тех, кто их использует, чем из-за самих инструментов.
Выбор DataWarehouse или DataLake для использования в SEO
В заключение, вопреки тому, что вы часто слышите или читаете, DataWarehouses и DataLakes — это отдельные структуры для хранения и сбора данных, и они не являются несовместимыми. Нет необходимости выбирать одно над другим, как раз наоборот. У обоих разные варианты использования, и есть даже некоторые сходства.
Случай с поисковой оптимизацией является красноречивым примером и усиливает потребность в хранилищах данных и озерах данных в целом. Данные вездесущи в SEO: нам приходится манипулировать огромными объемами данных из разных источников. Поэтому неудивительно, что мы говорим о хранилищах данных и озерах данных в этом контексте. Мы можем представить множество вариантов использования DataWarehouses или DataLakes в SEO, будь то для целей автоматизации, для выполнения «расширенного» анализа данных или просто для решения повторяющихся проблем (болевых точек).