Повысьте уровень своих конвейеров данных!
Все: Чем занимаются инженеры по обработке данных?
Я: Мы строим конвейеры.
Все: Вы имеете в виду, как сантехник?
Что-то в этом роде, но вместо воды, протекающей по трубам, данные текут по нашим конвейерам.
Специалисты по анализу данных создают модели, а специалисты по анализу данных передают данные заинтересованным сторонам. Итак, для чего нам нужны инженеры по данным?
Мало ли они знают, что без инженеров по обработке данных моделей вообще не было бы. Никаких данных для передачи не будет. Инженеры по обработке данных создают хранилища и конвейеры, позволяющие данным проходить через организацию. Соединяем точки.
Специалист по данным - самая быстрорастущая вакансия в 2019 году, рост на 50% г / г, что выше, чем рост числа должностей специалиста по данным, составивший 32% г / г.
Поэтому я здесь, чтобы пролить свет на некоторые повседневные задачи, которые ставит перед специалистом по обработке данных. Data Pipelines - лишь одна из них.
Трубопроводы ETL / ELT
ETL - извлечение, преобразование, загрузка
ELT - извлечение, загрузка, преобразование
Что они означают и чем они отличаются друг от друга?
В мире конвейера данных есть источник и место назначения. В простейшей форме источник - это то, откуда инженеры данных получают данные, а место назначения - это место, куда они хотят загрузить данные.
Чаще всего требуется какая-то обработка данных где-то посередине. Это может быть связано с множеством причин, которые включают, но не ограничиваются:
- Разница в типах хранилищ данных
- Цель данных
- Управление данными / качество
Специалисты по обработке данных называют обработку данных преобразованиями. Именно здесь они совершают чудеса, преобразуя все виды данных в желаемую форму.
В конвейерах данных ETL инженеры данных выполняют преобразования перед загрузкой данных в место назначения. Если между таблицами есть реляционные преобразования, они происходят внутри самого источника. В моем случае источником была база данных Postgres. Следовательно, мы выполнили реляционные соединения в источнике для получения требуемых данных, а затем загрузили их в место назначения.
В конвейерах данных ELT инженеры данных загружают данные в необработанные данные назначения.
Затем они выполняют любые реляционные преобразования внутри самого места назначения.
В этой статье мы поговорим о том, как я преобразовал более 100+ конвейеров ETL в своей организации в конвейеры ELT, а также рассмотрим причины, по которым я это сделал.
Как я это сделал
Первоначально конвейеры запускались с использованием заданий Linux cron. Задания Cron похожи на ваши традиционные планировщики задач, они инициализируются с помощью терминала Linux. Это самый простой способ планирования программ без каких-либо функций, таких как -
- Установка зависимостей
- Установка динамических переменных
- Соединения зданий
Это было первое, что нужно было сделать, так как это вызывало слишком много проблем. Нам нужно было масштабироваться. Для этого нам нужно было создать правильную систему управления рабочим процессом.
Мы выбрали Apache Airflow. Я все об этом написал здесь.
Первоначально Airflow был создан ребятами из Airbnb с открытым исходным кодом. Он также используется популярными компаниями, такими как Twitter, в качестве своей системы управления конвейером. Вы можете прочитать все о преимуществах Airflow выше.
После того, как с этим разобрались, нам пришлось изменить способ извлечения данных. Команда предложила преобразовать наши конвейеры ETL в конвейеры ELT. Подробнее о том, зачем мы это сделали, позже.
Вот пример конвейера до его изменения. Источником, с которым мы имели дело, была база данных Postgres. Следовательно, чтобы получить данные в предполагаемой форме, нам пришлось выполнить соединения в исходной базе данных.
Select a.user_id, b.country, a.revenue from transactions a left join users b on a.user_id = b.user_id
Это запрос, выполненный в исходной базе данных. Конечно, я упростил примеры до самой тупой формы, фактические запросы состояли из более чем 400 строк SQL.
Результаты запроса были сохранены в файле CSV, а затем загружены в место назначения, которым в нашем случае является база данных Google Bigquery. Вот как это выглядело в Apache Airflow:
Это простой пример конвейера ETL. Он работал, как и предполагалось, но команда осознала преимущества преобразования его в конвейер ELT. Подробнее об этом позже.
Вот пример конвейера после его изменения. Наблюдал, как таблицы переносятся в пункт назначения как есть. После того, как все таблицы были успешно извлечены, мы выполняем реляционные преобразования в месте назначения.
--transactions Select * from transactions -- Select * from users
Это запрос, выполненный в исходной базе данных. Большинство извлечений используют операторы «Select *» без каких-либо объединений. Для добавления заданий мы включаем условия где для правильного разделения данных.
Точно так же результаты запроса были сохранены в файле CSV, а затем загружены в базу данных Google Bigquery. Затем мы создали отдельный тег для заданий преобразования, установив зависимости в Apache Airflow. Это необходимо для того, чтобы все задания извлечения были завершены перед запуском заданий преобразования.
Мы устанавливаем зависимости с помощью датчиков воздушного потока. О них можно прочитать здесь.
Почему я это сделал
Теперь, когда вы понимаете, как я это сделал, мы переходим к вопросу почему -
Почему именно мы переписали весь наш ETL в конвейеры ELT?
Расходы
Работа с нашим старым конвейером стоила нашей команде ресурсов, в частности времени, усилий и денег.
Чтобы понять стоимостной аспект вещей, вы должны понимать, что наша исходная база данных (Postgres) была древней машиной, созданной еще в 2008 году. Она размещалась локально. Также была запущена старая версия Postgres, что еще больше усложняло ситуацию.
Только в последние годы организация осознала потребность в централизованном хранилище данных для ученых и аналитиков. Именно тогда они начали строить старые конвейеры для задач cron. Поскольку количество рабочих мест увеличивалось, это истощало ресурсы машины.
Соединения SQL, написанные предыдущими аналитиками данных, также были повсюду. В одном запросе в некоторых конвейерах было более 20 соединений, и мы приближались к более чем 100 конвейерам. Наши задачи начинались в полночь, обычно заканчивались около 13–14 часов, что составляло примерно 12+ часов, что абсолютно недопустимо.
Для тех из вас, кто не знает, соединения SQL - одна из самых ресурсоемких команд для выполнения. Это приведет к экспоненциальному увеличению времени выполнения запроса по мере увеличения количества объединений.
С тех пор, как мы перешли на Google Cloud, команда поняла, что Google Bigquery молниеносно выполняет SQL-запросы. Все об этом можно прочитать здесь.
Следовательно, весь смысл состоит в том, чтобы запускать только простые операторы «Select *» в источнике и выполнять все соединения в Google Cloud.
Это более чем удвоило эффективность и скорость наших конвейеров данных.
Масштабируемость
По мере роста бизнеса растут и его инструменты и технологии.
Перейдя на Google Cloud, мы можем легко масштабировать наши машины и конвейеры, не беспокоясь особо.
Google Cloud использует Cloud Monitoring, который представляет собой инструмент, который собирает показатели, события и метаданные ваших облачных технологий Google, таких как Google Cloud Composer, Dataflow, Bigquery и многих других. Вы можете отслеживать все виды точек данных, которые включают, но не ограничиваются:
- Стоимость виртуальных машин
- Стоимость каждого запроса, выполняемого в Google Bigquery.
- Размер каждого запроса, выполняемого в Google Bigquery.
- Продолжительность конвейеров данных
Это сделало мониторинг для нас легким делом. Следовательно, выполняя все преобразования в Google Bigquery, мы можем точно отслеживать размер, продолжительность и стоимость нашего запроса при масштабировании.
Даже когда мы увеличиваем размеры наших машин, хранилищ данных, конвейеров данных и т. Д., Мы полностью понимаем связанные с этим затраты и преимущества и полностью контролируем их включение и при необходимости выключите.
Это спасло и избавит нас от множества головных болей.
Заключение
Если вы дочитали до этого момента, значит, вам действительно нужны данные.
Вы должны!
Мы уже сделали ETL и ELT. Кто знает, какие трубопроводы мы будем строить в будущем?
В этой статье мы говорили о -
- Что такое конвейеры данных ELT / ETL?
- Как я переделал ETL на конвейеры ELT
- Почему я это сделал
Как обычно, заканчиваю цитатой.
Данные - это новая наука. Ответы на вопросы - большие данные - Pet Gelsinger
Подпишитесь на мою рассылку, чтобы оставаться на связи.
Вы также можете поддержать меня, подписавшись на среднее членство через мою ссылку. Вы сможете прочитать неограниченное количество рассказов от меня и других невероятных писателей!
Я работаю над другими историями, статьями и руководствами в индустрии данных. Вы можете ожидать большего количества подобных сообщений. А пока не стесняйтесь читать мои другие статьи, чтобы временно утолить свой голод по данным.
Спасибо за чтение! Если вы хотите связаться со мной, не стесняйтесь обращаться ко мне по адресу [email protected] или в моем профиле LinkedIn. Вы также можете просмотреть код из предыдущих статей в моем Github.
