И смириться с нескончаемым потоком дрянных водных метафор
Упустить из виду более масштабные тенденции, формирующие экосистему данных, легко, когда вы погрузитесь в окопы повседневной рутины. Из-за этого я люблю посещать конференции, которые служат вдохновляющей подставкой для ног, с которой можно легко увидеть полную картину ландшафта.
Первая в истории конференция Subsurface Cloud Data Lake Conference, состоявшаяся практически в июле, стала отличной возможностью для этого, поскольку на ней был представлен впечатляющий состав докладчиков, которые вдумчиво контекстуализировали то, где мы находимся с данными в 2020 году.
Лекция №1: Будущее открыто - Возвышение озера данных в облаке
Томер Ширан, соучредитель и главный исполнительный директор, Dremio
Все мероприятие было организовано Dremio и началось с потрясающей вступительной речи одного из его основателей, который сделал обзор того, как архитектуры данных развивались за последние 10 лет.
Основная идея заключается в следующем: мы перешли от проприетарных монолитных аналитических архитектур, основанных на дорогостоящей базе данных с лицензией Oracle или кластере Hadoop… к архитектурам, определяемым гибкими технологиями с открытым исходным кодом на четырех основных уровнях. стека данных: уровень хранения, уровень данных, уровень вычислений и уровень клиента.
Основа стека - уровень хранения - поддерживается важнейшим развитием облачных технологий, таких как S3 и ADLS, которые предлагают бесконечно масштабируемое, высокодоступное, глобально распределенное, легко подключаемое и невероятно дешевое облачное хранилище.
Возможность агностически использовать эти большие двоичные объекты хранилища для отделения хранилища данных от специализированных вычислительных механизмов (таких как Spark, Snowflake и Athena) является доминирующей архитектурной тенденцией, о которой упоминалось почти во всех выступлениях.
Так что, по крайней мере, оставьте эту статью ясной в своем уме.
Обсуждение №2: Apache Arrow: новый золотой стандарт для передачи наборов данных
Уэс Маккинни, директор, Ursa Labs
Уэс начал с объяснения проблемы, когда у вас есть несколько различных систем, обрабатывающих данные, каждая из которых может иметь свои собственные протоколы хранения и транспортировки. Проблема заключается в «комбинаторном росте парных соединителей данных», как он это называет, который проявляется в том, что разработчики должны создавать дорогостоящие в реализации настраиваемые соединители данных, если они хотят эффективно транспортировать данные в своих конвейерах данных или приложениях.
Это одна из немногих проблем, которые послужили источником вдохновения для проекта Apache Arrow. Остальные:
- Ненужное время ЦП, потраченное на сериализацию и десериализацию данных
- Дорогая запись на диск / хранилище BLOB-объектов в качестве посредника
- Снижение производительности из-за узких мест узлов-исполнителей в распределенных системах
Итак, Уэс продолжил, объясняя некоторые технические концепции, лежащие в основе решения этих проблем Arrow.
Конечным результатом является, в основном, скрытая библиотека, которая делает, например, преобразование между Spark и Parquet более эффективным, а всех нас - более продуктивными в долгосрочной перспективе.
В моей голове прояснилось, как Arrow стремится быть посредником в памяти между системами, точно так же, как многие люди используют S3 (из-за отсутствия лучшего варианта) для этой цели.
Доклад № 3: Функциональная инженерия данных: набор передовых методов
Максим Бичемин, генеральный директор и основатель, Preset
Наконец, Максим сделал интересный доклад о том, как принципы функционального программирования могут быть применены к дисциплине инженерии данных для создания надежных конвейеров данных.
Вот эти три принципа:
1. Чистые функции - одинаковый ввод = одинаковый вывод
2. Неизменяемость - никогда не изменять значение однажды присвоенных переменных
3. Идемпотентность - возможность повторить операцию без изменения результата.
В контексте инженерии данных Бошемин рекомендует писать задачи ETL, которые являются «чистыми». Это означает, что при одинаковых входных данных они будут выводить один и тот же раздел данных, который вы можете ВСТАВИТЬ ПЕРЕЗАПИСАТЬ в свое озеро данных (идемпотентная операция по сравнению с изменяемым UPSERT).
Не вдаваясь в слишком много деталей, я вдохновлен использовать эти концепции, чтобы добавить структуру в то, как я думаю о своих задачах ETL, вместо запутанного беспорядка логики, результаты которого я мало понимаю.
Спасибо за чтение и с нетерпением ждем итогов не менее интересной конференции Future Data на следующей неделе!
