В статье автор сравнивает ETL и ELT. В канале я уже много раз ссылался на эти абреавиатуры. Согласно википедии, ETL уже используется с 1970х. Главное отличие ETL от ELT, что нам нужны вычислительные мощности (computing) чтобы, читать данные и трансформировать, то есть мы все данные пропускаем через приложение ETL. Поэтому это дорого (нужно сервер и нужно его обслуживать), во-вторых это может быть узким местом во времени обработки. Самые популярные решения это Informatica Power Center, MS SSIS, SAP BODI и другие аналоги от IBM, Oracle, SAS.

В противовес, есть концепт ELT, когда мы используем вычислительные мощности аналитического хранилища данных (Teradata, Exadata, Netezza, Redshift, Snowflake and so on). По сути все трансформации описаны с помощью SQL, а сам ELT иснтрумент оркестрируют, в какой очереди запускать трансформации и какие зависимости. Как результат, дешевле, быстрее и более гибкий.

В конце концов, не важно, что вы используете, лишь бы работало хорошо, обеспечивало SLA, проверяло качество загруженных данных и сообщало о поломках.

В Alexa я использую Matillion ETL для всех бизнес трансформаций и метрик. Наши product managers очень довольны, так как сами могу делать трансформации. Athena для SQL интерфейса в озеров данных на S3. Так же частично Amazon Glue для сбора метаданных озера данных. Из интересного, хотел бы использовать Apache Airflow, но нет времени с ним ковыряться.

Так же работаю иногна со Spark, когда много данных и нужно Big Data Computing. Причем трансформации описываю на SQL. Данные в озере данных всегда в Parquet формате и обязательно партиционированы. С новой фичей Redshift - UNLOAD to Parquet стало легче выгружать данные из Redshift в озеро данных.

В в Alexa очень итересно с точки зрения данных, в качестве источника дынных для меня это Redshift 128 нод (максимальный размер) и озеро данных, то есть миллиарды строк, все это дело надо соединить и посчитать метрики качества на уровне событий и сохранить результат в своем кластере Redshift. А часть данных нады выгрузить в свое озеро данных для front end сервисов. Главная цель, помочь внутренним бизнес подразделениям выявлять проблемы в поведении Alexa и качества моделей.

PS хотел про ETL/ELT написать, а получась гораздо больше, теперь я точно могу сказать, я работал с большими данными, и они растут по экспоненте.

Последние новости про Amazon, хотя на фотке Маск)) Я был на презентации этого проекта, и даже подумал, может им нужен Data Engineer? С точки зрения карьеры в корпорации, чтобы вырасти, нужно попасть в начале, то есть например с Alexa, если в нее попасть лет 5 назад, шансы на рост есть. Это как стартап, либо он рванет и все вырастут вместе с ним, либо будешь маленьким винтиком в большой машине. Вообще тема с аналитикой спутников, солнечных батарей и ветряных мельниц очень перспективная.

"Data without analysis is a wasted asset. Analytics without action is wasted effort." (c)

AWSOME days - онлайн конференция от AWS, где можно узнать про AWS и облачные вычисления, такой entry level.

баян наверное, но мне нравиться карлсон

Попалась вакансия Junior Data Engineer в Москве, в компанию Welltory и добавили 3 часа назад, хороший старт. https://vc.ru/s/welltory/98550-junior-data-engineer

Вчера я писал про Alexa. Последние несколько дней я засел с задачей, с одной стороны простой, но с другой стороны требующей множества итерация. Каждая итерация занимает почти 1 день. Из 3х Redshift clusters так как данные храняться по AWS Regions, нужно выгрузить данные и поместить в parquet формат в озеро данных и партиционировать. При этом нужно обогатитт данные метриками из других источников.

К сожалению у меня нет возможности использовать UNLOAD команду и приходится, использовать внутренний ELT инструемент, который может загружать данные в мой Redshift. Дальше, я могу обогатить мои данные и сделать UNLOAD to Parquet with PARTITIONS. Использовать Glue (сбор метаданных) и Athena как SQL. При этом мне нужно быть удалять устаревгие данные. Для Glue Crawler я использую BOTO3 (python) библиотека AWS и удаляю файлы, именно для этого мне нужны партиции, чтобы удалять старые данные.

Есть и альтернативный метод, я его пробовал, но отказался из-за отсутствия партиционирования. Через ELT сервис внутренный я могу сохранить на внутренний S3, дальше использовать EMR+Spark SQL (внутренний) и сделать тоже самое, но в конфигурации SQL нет возможности выгрузки в партиции и неудобно скрещивать со своими данными и еще не понятно, кто будет Glue запускать и удалить старые данные.

Так как мой Redshift очень маленький, то все очень медленно. В общем сейчас я воспользуюсь преимущетсвом облака, я просто увеличу размер клстера в 2 раза и перейду с DS (storage optimized) на DC (compute optimized), это займет прилично времени, но зато потом сохранит много времение, и добавит нам места и скорости.

На DC не перейду, там вместо 2TB HDD, 160GB SSD, 2,5 TB SSD будет в 10 раз дороже. Я тогда просто удвою количество нод. За 10 минут все сделал!

Сегодня местное рождество! Всех с праздником! PS как хорошо когда есть талантливый график дизайнер, кстати не кому не нужен на проект?:)

Я не написал про еще один event, который мы сделали в Москве вместе с Moscow School of Business Analytics в офисе Крок. Митап был про AWS, Azure, проекты, которые я делал, эмиграция, зарплаты и тп, было классно Вот видео.

А сегодня ребята на Хабре написали интересную статью про выступление, спасибо им за труды!

Если вы интересуетесь Google Cloud Platform или используете ее, то вот список все новшеств связанных с аналитикой в 2019.

Кейс американской финансовой организации - миграция на AWS. В 30 раз дешевле, и в 20 раз чаще деплоймент. Действительно, когда переносим все в облаком с on-premise, все становится быстрей и дешевле. Жалко таких кейсов не будет в России. Кстати кто-нибудь может поделиться информацией про Яндекс, меил или крок облако? Я бы тут расшарил.

Data engineers vs. data scientists

The two positions are not interchangeable—and misperceptions of their roles can hurt teams and compromise productivity. https://www.oreilly.com/radar/data-engineers-vs-data-scientists/?utm_source=linkedin&utm_medium=matillion

Вакансия попалась Engineer Hadoop в Краснодаре, там же тепло!

Годное описание вакансии, Москва