Оптимизация файловых данных для облачных data lakes: практическое руководство

Стратегия облачного data lake — естественная эволюция для data-heavy enterprise IT организаций, переходящих в облако, так как она поднимает облако от дешевого хранилища данных к месту, где данные могут быть использованы для новой ценности и монетизированы.

Если 2020 и 2021 были годами быстрого облачного ускорения, 2022 будет годом, когда предприятия начнут серьезно относиться к приведению неструктурированных файловых данных в облачные data lakes. Есть несколько причин за этим трендом. Во-первых, организации сидят на петабайтах неструктурированных данных, которые составляют не менее 80% из 64 зеттабайт данных (и растущих) в хранилище по всему миру сегодня. Большинство этого — файловые данные — от медицинских изображений до стримингового видео, сенсорных данных от электромобилей и IoT продуктов и документов, которые люди используют в каждом секторе для коллаборации и ведения бизнеса.

Во-вторых, файловые данные становятся неуправляемыми, дорогими для хранения, и CIO знают, что они сидят на потенциальной золотой жиле инсайтов, если только они могли бы определить, как получить их в правильные места для анализа. Наконец, крупные облачные платформы массово инвестируют в инструменты аналитики/ML/AI и более дешевые object storage tiers для поддержки data lake проектов.

Смотрите также: Data Lakes, Time-Series Data, и Industrial Analytics

Созревание data lakes в облаке

Включение data lakes — одна из топ целей, которые ИТ-менеджеры приоритизируют, вместе с безопасностью, управлением затратами и видимостью, согласно недавнему исследованию, которое мы провели. Облако перевернуло традиционные data lake стратегии, которые начались, когда компании захотели анализировать semi-structured данные, такие как CSV и log файлы. В 2006 году родился Hadoop и получил широкое принятие именно в то время, когда разговоры о Big Data начинали циркулировать. Однако Hadoop в конечном счете оказалось медленнее и дороже ожидаемого, сложным для настройки, масштабирования и управления и в основном предназначенным для batch processing. Для решения этих проблем на сцену вышел Apache Spark, работающий до 100x быстрее для некоторых рабочих нагрузок и хорошо подходящий для real-time анализа. Важно, что фокус компаний вроде Databricks был на запуске Spark в облаке, в то время как Hadoop в основном реализовывался on-premises.

В последние несколько годы облачные data lake платформы созрели и теперь готовы для prime time. Облачные провайдеры более дешевые scale-out object storage доставляют платформу для массивных, петабайт-масштабных проектов, которые просто не жизнеспособны on-premises. Next-generation data lakes построены на Apache Spark для поддержки S3 или object data storage, делая возможным ingest и процесс semi-structured и unstructured данных. Файловое хранилище также переходит в облако и должно быть использовано как часть облачного data lake, так что не все данные могут быть в object storage.

Стратегия облачного data lake — естественная эволюция для data-heavy enterprise IT организаций, переходящих в облако, так как она поднимает облако от дешевого хранилища данных к месту, где данные могут быть использованы для новой ценности и монетизированы.

Как приручить облачный data lake

Пока это все еще ранние дни для облачных data lakes, включение файловых данных в ваш data lake императивно, так как machine learning модели требуют большие количества его для генерации значимых результатов. Тем не менее, эти неструктурированные данные не стандартизированы между типами файлов: видео файлы, аудио файлы, сенсорные данные, логи не делят общую структуру. И сбрасывание всех этих файловых данных вразброс в облачную data lake платформу — не мудрая стратегия, а бардак для очистки позже. Несмотря на их обещание, есть много рисков с data lakes, варьирующих от высоких затрат управления, пробелов в навыках, проблем безопасности и governance, проблем портабельности при перемещении данных между облаками и хранилищными платформами и давно стоящей заботы о data lake становящемся swamp, когда данные становятся слишком большими и запутанными для поиска и анализа.

Вот некоторые соображения при отправлении на приведение файловых данных в облачный data lake для избежания или минимизации страданий.

1. Оптимизируйте data lake. Прежде чем какие-либо данные могут быть проанализированы, они должны быть очищены, нормализованы и классифицированы, что может быть высокорутинным процессом, способствующим перерасходам затрат и медленному time to value. Это всегда было вызовом для data warehouse инициативы и то же самое применяется к data lakes и data lakehouses. Data lakes привлекательны тем, что они могут ingest данные в их native формате; требуя оптимизации перед помещением данных в озеро разрушает эту ease-of-use. Как вы можете автоматически оптимизировать файловые данные без требования изменения поведения пользователя? Ключ к оптимизации файловых данных — метаданные: информация о типах файлов, датах создания и последнего доступа, владельцах, проектах и локации. Способность автоматически индексировать и тегать файлы по свойствам метаданных избежит data swamp проблем и сделает легче поиск и сегментацию позже, в отличие от просто оставления data lakes неуправляемыми.
2. Используйте метаданные индексирования для поиска точных наборов данных для конкретных нужд. Инструменты, которые могут индексировать файлы и искать метаданные через хранилище (включая on-premises, edge и cloud локации) могут сузить миллиарды файлов до нескольких тысяч, так что вы отправляете только точные файлы, которые вы хотите проанализировать, в облако.
3. Тегайте данные по мере движения для улучшенной поисковости и удобства использования. Как только вы находите файлы, которые вам нужны, вы можете затем использовать machine learning систему для дальнейшего уточнения поиска с большим количеством тегов. Этот процесс должен быть непрерывным и автоматизированным, так что со временем дополнительная структура развивается и легче поисковость приходит к вашему data lake вместе с более высоким качеством в целом.
4. Примите во внимание edge. По мере того как edge computing растет из-за новых use cases от сенсорных данных, стриминг данных с edge станет невыносимым. Как вы можете обработать больше данных на edge и взять только то, что вам нужно, в облачный data lake? Edge pre-processing станет более критичным по мере роста объемов edge данных.
5. Создайте таксономии по отраслям. Нет стандартной номенклатуры тегирования для каждой отрасли. Наличие некоторых общих классификаций тегирования по сектору сделает данные легче для поиска и извлечения, особенно в коллаборативных средах, таких как research и life sciences.
6. Адресуйте мобильность данных. Чтобы быть по-настоящему мобильными, данные должны иметь возможность находиться в разных системах через гибридные облачные среды, в то время как также нативно получать доступ к сервисам в тех средах. Разблокировка данных от проприетарных хранилищных систем дает контроль обратно IT и устраняет сборы и хлопоты перемещения данных с одной платформы на другую. Способ, которым данные используются и доступны и их ценность меняются со временем. Future-proofing ваши данные вы можете адаптироваться к изменениям и новым требованиям. Независимые data mobility и management решения могут помочь здесь.
7. Постройте правильную культуру. Ведущие IT организации продолжают идентифицировать культуру — людей, процессы, организацию, change management — как самое большое препятствие к становлению data-driven организациями, согласно 2021 исследованию New Vantage Partners. Data-driven культура должна охватывать не только аналитиков и линии бизнеса, но и IT инфраструктурные команды. IT лидеры будут играть роль в помощи data storage, server и networking профессионалам переориентировать их ответственности и ежедневные задачи к data-centric decision-making фреймворку. Инструменты и процессы должны быть cross-functional, позволяя holistic вид на данные активы организации и коллаборацию вокруг стратегий управления этими активами для организационного выигрыша.

Облачные data lakes набрали популярность, потому что данные могут быть ingested в их native формате без обширной предобработки, нужной для data warehouses. Обратная сторона в том, что data lakes стали data swamps особенно для неструктурированных файловых данных, так как эти данные не имеют общей структуры. Анализ файловых данных становится более критичным с подъемом AI/ML движков, которые на них полагаются. Облачные data lakes могут быть оптимизированы для неструктурированных данных без разрушения их привлекательности ingesting данных в native формате путем автоматизации индексирования, поиска, сбора и оптимизации файловых данных.