Избавьтесь от этих тревожных привычек и начните путь к мастерству в озере данных.
Вступление
Озера данных предлагают заманчивый потенциал роста производительности, что является основной причиной их высокого уровня распространения. Однако иногда обещание технологической производительности может затмить неприятный опыт разработчика.
Это неприятно, так как я считаю, что опыт разработчика так же, если не больше, важен для доказательства ценности технологии или парадигмы.
При создании и обслуживании сложной системы, такой как озеро данных, недружественные пользовательские рабочие процессы и интерфейсы могут подорвать производительность, подобно приложению со слишком большим техническим долгом или плохой документацией.
Антипаттерн # 1
Вы часто щелкаете по консоли хранилища S3 (или аналогичной)
Один из симптомов недружелюбных рабочих процессов с озером данных - слишком много времени проводить в выбранном сервисе хранения озера.
Ранее в моей карьере это было озеро данных S3, и однажды я понял, сколько времени тратит на то, чтобы копаться в консоли AWS, чтобы увидеть количество файлов, присутствующих в разделе, или по какому пути хранились данные определенной таблицы. … Это было нездорово.
Для сравнения: никто не заглядывает во внутреннее устройство своей базы данных, чтобы увидеть, где в B-дереве хранится таблица.
Тактика смягчения:
проблемы неизбежно возникнут в вашем озере данных. Однажды у поставщика возникнет проблема с отправкой файла данных. Кто-то случайно перезапустит задание приема несколько раз, чего не должно быть.
И в процессе отладки таких проблем (или, в некоторых случаях, ложных срабатываний) будет полезно сыграть в детектив и исследовать доказательства того, что произошло, проверяяlast_modified_date файлов или количество строк в сегодняшнем разделе.
Мой совет сделать этот процесс более дружелюбным:
- Поддерживайте внутреннюю страницу руководства по отладке, на которой указываются возникающие проблемы и подробно описываются шаги, предпринятые для их выявления и решения. Это помогает предотвратить накопление знаний в команде и позволяет избежать того, чтобы всякая бедняга из-за того, что им приходилось придумывать наилучшие способы решения проблемы.
- Когда появляются общие шаблоны отладки, такие как количество проверок файлов, разработайте способ автоматизации отчетности по этим показателям во внутренней таблице или информационной панели. В следующий раз, когда возникнет проблема, у вас должен быть вид с одной панелью, который быстро показывает недавнее поведение вашего озера.
Цель этих практик - избавить вас от необходимости проверять, что происходит в консоли хранилища, при возникновении большинства проблем. И сделайте это простое, быстрое и целенаправленное расследование, когда вы это сделаете.
Антипаттерн # 2
Вы физически копируете файлы для создания нескольких версий одного и того же набора данных.
Если вы откроете консоль своего хранилища объектов и увидите такую структуру каталогов, я сразу пойму, что вы любитель озера данных.
Я бы знал, потому что физическое копирование файлов - утомительный процесс, требующий ненужных затрат. И это проблема, которая растет вместе с масштабом ваших данных.
Что, если бы вы могли написать одну команду оболочки и получить тот же эффект вместо копирования файлов?
> lakectl branch create <branch uri>Как это работает?
К счастью, эта проблема в основном решается подключением инструмента git-for-data поверх вашего озера.
Используя метаданные о файлах и их содержимом в вашем озере, становятся возможными знакомые операции, такие как ветвление или фиксация коллекций. Итерации и эксперименты с озером данных будут быстрее и безопаснее, если в вашем распоряжении есть эти действия.
Для получения дополнительной информации посетите проект с открытым исходным кодом lakeFS и его страницы с документацией!
Антипаттерн # 3
У вас сложная логика обработки данных на основе шаблонов путей к файлам
Подобно Еве, стоящей перед яблоней, у вас возникнет соблазн использовать логику в строке пути к файлу объекта, чтобы определить его судьбу в вашем озере данных.
НЕ ДЕЛАЙТЕ ЭТОГО!
Если вы используете код, как в приведенном выше примере, да, вам удалось написать одну функцию, которая обрабатывает перемещение различных наборов данных в соответствующее место в озере данных.
Однако на самом деле вы увеличили цикломатическую сложность кода обработки данных и усложнили его обслуживание.
Каждый раз, когда добавляется новый источник данных, вы должны продумать последствия того, где он будет размещен, и, основываясь на этой централизованной функции, где он окажется. Любые изменения в одном наборе данных требуют понимания, если есть непреднамеренные воздействия на другие.
Что делать вместо этого:
Решение простое - используйте отдельные методы для обработки каждого набора данных в вашем озере. Общие вспомогательные функции по-прежнему должны использоваться в этих методах для простых действий, таких как копирование файла с одного ключа S3 на другой.
Чтобы быть ясным, некоторая логика в строках пути к файлу неизбежна. Однако будьте осторожны с вложенной логикой и сделайте код максимально понятным и читабельным.
Подведение итогов
В этой статье мы обсудили, почему это тревожный знак, если вы:
- Щелкая мышью вокруг консоли хранилища, чтобы отладить каждую проблему.
- Физическое копирование файлов в озеро данных.
- Чрезмерно зависит от имен файловых путей в коде обработки.
Избегайте этих анти-шаблонов и вместо этого следуйте лучшим практикам, чтобы упростить обслуживание озера данных!
Примечание. Эта статья была изначально опубликована в блоге lakeFS.
