Когда я пришел в Google в качестве поставщика в 2019 году, у меня уже был опыт работы в области здравоохранении и технологическом секторе. Тем не менее меня удивило совершенство инструментария, разработанного Google.
Нет ничего удивительного в том, что Google располагает развитой инфраструктурой управления данными. Но нельзя не поразиться тому, как быстро и легко эти инструменты позволяют инженерам по обработке данных создавать дополнительную стоимость продукта, управлять релизами и поддерживать массивный репозиторий монолитного кода.
Я считаю, что Google рассматривает инженерию данных не как продолжение аналитики, а как глубоко техническое и ценное направление, на которое рассчитывают многие бизнес-подразделения.
1. Платформа данных
За последние 10 или более лет Google разработала собственную платформу данных мирового класса. Эта платформа включает в себя множество отличных функций: IDE, хранение и визуализацию данных, кодовую базу и интерпретационный слой. Подобные платформы могут получать доступ к данным с помощью нескольких удаленных обработчиков, таких как плоские файлы и BigQuery.
Плоские файлы являются предпоследней версией формата файлов parquet. Они представляют собой аналитически организованные файлы с постоянными данными.
Работать с этой платформой данных довольно удобно. Здесь есть встроенный функционал для написания запросов, которые включают или охватывают несколько файлов в папке таблиц, что позволяет легко объединять файлы в запросах.
В чем минус плоских файлов? Как уже упоминалось, они могут быть неизменяемыми, что делает невозможным методы вставки (INSERT) и удаления (DELETE) данных. Однако для решения этой проблемы есть обходные пути, например вставка новых записей в другие таблицы и объединение результатов.
Различные вычислительные машины могут более эффективно оптимизировать вариативные типы запросов, например инструмент по обработке больших данных BigQuery, также разработанный Google.
2. Контроль среды
Огромные масштабы экосистемы Google подразумевают наличие продвинутого инструментария для ее поддержки. Сложная инфраструктура требует внедрения масштабного процесса CI/CD. Для создания активов в нескольких средах можно использовать специальные переменные. Хотя принимаются любые их типы, для обозначения конвейеров, существующих в различных средах, могут применяться уникальные переменные.
На интерпретационном уровне возможно вводить переменные во время выполнения управляющей программой конвейера в зависимости от релиза промежуточной среды. Затем все таблицы поддерживаются в средах нескольких релизов. Сначала происходит интеграция в среду разработки, затем в среду тестирования, а интеграцию в производственную среду осуществляют в последнюю очередь или по мере необходимости.
3. Автоматизация, встроенная в основную инфраструктуру
У каждого из нас есть любимый cron (не исключено, что кое-кто даже создал свой собственный). Но cron от Google несколько отличается от остальных. Автоматизацию задач можно подключать к основной инфраструктуре — даже к той, которая запускает выполнение процессов по всей организации.
В Google прежде всего заботятся о данных. Тщательная разработка компании собственного инструментария — яркое тому подтверждение.
Простое создание и выполнение конвейеров данных не требует особых усилий. После разработки конвейеров их можно запускать средствами основной инфраструктуры. Она считывает предоставленные метаданные, выполняет запрос, который может считывать данные из различных медиаисточников, и размещает данные в указанном месте.
Ключевые преимущества этого процесса — глубоко интегрированное логирование и система оповещения. Если что-то идет не так, уведомления об этом отправляются мгновенно. Система оперативно сообщает о любых сбоях для быстрой сортировки и устранения неполадок.
Автоматически управляемая централизованная инфраструктура использует вычисления из централизованного пула, на котором могут работать многие сервисы. Одним из главных преимуществ такого расклада является снижение затрат на обслуживание системы. Если обнаруживаются сбои в автоматизации или в процессе выполнения, проблемы, скорее всего, распространятся повсеместно и быстро будут отсортированы для обеспечения непрерывной работы систем, зависящих от автоматизации.
4. Бизнес-ценность важнее оптимизации кода
В первые дни работы в Google я нашел отличный вариант для создания медленно меняющегося измерения. Мне нужно было отследить изменение показателей и то, исчезло ли конкретное измерение (то есть достигло ли значения “0”) посредством мягкого удаления.
Я поделился своим решением со старшим инженером. Он мне возразил: “Зачем заморачиваться, если можно просто делать снимки таблицы каждые 10 минут?”. Я не сразу понял, о чем шла речь, но вскоре взял этот способ на вооружение.
Google использует множество инструментов для обработки запросов и хранения данных. Стоимость инженерных ресурсов во много раз превышает возросшие затраты на вычисления и хранение данных. Инженеры Google по обработке данных ориентированы прежде всего на создание дополнительной ценности для своего продукта. Они хорошо понимают актуальные бизнес-требования, поэтому работают с активами данных, чтобы быстро повышать ценность, а не увязать в тонкой настройке ради незначительного снижения потребления вычислительной мощности.
Это важный момент: инженерные ресурсы важнее, чем оптимизация запросов. Раньше я тратил дни, а иногда и недели на тонкую настройку запроса, чтобы он выполнялся на 20% быстрее. Проще говоря, я считаю, что время инженера стоит дороже, чем слегка увеличенный счет за облачные вычисления.
5. Чистота кода
В культуре Google преобладает инженерный подход. Код оформляется таким образом, чтобы его было легко понять и усвоить. При его отправке происходит автоматическая проверка на соответствие стандартам программирования, а рецензенты тщательно проверяют читабельность и соответствие соглашению об именах.
Проще говоря, кодовая база Google доступна для восприятия. Быстро прочитать и понять код довольно легко.
С помощью таких инструментов, как DBT, макросы и функции можно хранить в файлах и импортировать подобно пакетам. Это существенно облегчает работу, когда необходимо решать конкретные задачи, относящиеся к определенным рабочим процессам, исходным системам или командам.
После того, как вы напишете макрофайл, содержащий один или несколько макросов, другие авторы могут положиться на функциональность платформы данных для импорта макросов. Им понадобится только SQL. Затем макросы выполняются на интерпретационном уровне, до оценки или выполнения кода.
Сначала я задавался вопросом: какова цена чистоты кода? Много лет назад, после написания каждого запроса, я тратил время на переформатирование кода, исправление наименований переменных и интервалов, пока не добивался идеального результата.
Уже через несколько месяцев написание кода в соответствии с рекомендациями по форматированию стало для меня привычным делом. Теперь, когда у меня за плечами большой опыт, мой код стал однородным и легко усваиваемым для другого инженера, которому предстоит понять и изменить его.
Читайте также:
- Эпоха Больших данных
- Тестирование больших данных: руководство для начинающих
- Как за секунды обрабатывать DataFrame с миллиардами строк
Перевод статьи Galen B: 5 Ways Google Does Data Engineering Differently
