Еще один новый канал по AI/ML и по развитию персонального бренда. Allie работает в AWS в роли sales для стартапов. Насколько я понял, она закончила MBA связанную с AI/ML и активно рассказывает в linkedin про свой опыт за что и получила популярность. Рассказывает очень позитивно.

Как вы понимаете, без английского языка в нашей профессии никуда. Для вас мы нашли интересного спикера, которые занимается обучение языка уже много лет. Сам вебинар про IELTS, это своего рода продолжение темы про Иммиграцию в Канаду, чтобы полностью осветить этот вопрос. Но даже если вы не планируете сдавать IELTS, вам будет полезно узнать про структуру экзамены, про материалы для изучения языка и много другого. Через 10 минут начало! https://youtu.be/qV89JpCshaI

Я часто ссылался на облачный ETL - Matillion. Я начал работать с ними с 2017 и теперь они попали в квадрант гартнера. Кто смотрел мои уроки по BI на datalearn, уже знает, что такое квадрант и кто туда попадает. На модуле 4 будем как раз с ETL/ELT разбираться. Я думаю ещё недели 2-3 и смогу продолжить.

Это что-то невероятное

Анатолий Карпов @data_karpov берет интервью у Алексея Никушина @a_nikushin

Говорим про образование, курсы, настроения в @analysts_hunter, Матемаркетинг @MateMarketing_official и нелегкую жизнь аналитиков

https://www.youtube.com/watch?v=mome3DWQqg0

Интересная статья про Data-Driven подход. В ней автор делится историями про подход Амазон. Сейчас у меня тоже интересные проекты. Я уже месяц с новой командой, но пока не доконца разобрался как все работает. С точки зрения бизнеса у нас 2 основных проекта - это feature attribution model (то есть все кампании на главной странице амазон) и customer perception. Science команда использует AWS Elastic Map Reduce (Hadoop) + Spark + Zeppelin для heavy liftin трансформаций - этот процесс называется feature engineering. Используется Hadoop потому что, объем кликстрима это сотни терабайтов. Дальше, используют GPU виртульную машину для моделей deep learning. Помимо этого есть еще много A/B тестов. В ближайше перспективе мне нужно будет найти и устранить причину в существующих data pipelines, которые берут начала из центрального озера данных и мы используем еще один EMR+Spark, чтобы копировать к себе нужные данные в формате parquet.
Другая моя инциатива заменить существующие подход EMR + GPU виртуальную машину, на Amazon Sage Maker. Как я понял с 2021 года Amazon планирует повсеместно использовать этот сервис для ML/AI.

Пока не очень понял как все это работает, но технические уже более менее понятно откуда данные приходят и куда уходят.

“There are no solutions. There are only trade-offs.” by Thomas Sowell. Что значит не бывает решений, а есть только компромиссы. При построении аналитических решений и продуктов это фраза очень кстати. Всегда мы слышим - "Мы можем это сделать, но...". Или " у нас вот есть 2 варианта, у каждого свои +/-".

22 сентября расскажут про Databricks + Lakehouse. Я очень хотел бы поработать на databrics и создать lakehouse. То есть это полная альтернатива традиционному хранилищу данных. Так же Spark даст возможность использовать библиотеки для ML, ноутбуки для визуализации и дашбордов, и библиотеки для стриминга. Кто-то делал проект на databricks? https://databricks.com/p/webinar/cloud-data-platform-virtual-event-lakehouse

А вот еще интересное мероприятия - DBT проводит онлайн конференцию в декабре. Интересное решения, для тех кто любит хранить все тбизнес дата трансформации в SQL (может и pyhton поддерживает). https://www.getdbt.com/coalesce/

Сегодня опытный человек лет 40 поделился со мной интересной идеей. В современной корпоративной культуре, человек подобен виртуальной машине. Так как мы с ним в амазоне, соответственно это EC2 instance, который работает, а когда что-то не так, его просто отключают и удаляют на всегда, или он сам сдувается и отваливается. Мне понравилось такое сравнение. Другой комментарий про отсутствие empathy (эмпатия - осознанное сопереживание текущему эмоциональному состоянию другого человека без потери ощущения происхождения этого переживания). Люди настолько заняты и перегружены работой, что не остается места эмпатии. Как у вас с эмпатией на рабочем месте?

Кстати в библиографической книге про Стив Джобса, говориться что Бил Гейтс совершенно не обладает эмпатией, а вот его предшественние новый CEO наоборот. Сейчас большой тренд на эмпатия в западных компаниях, новые CEO Uber и ряда других крупных компаний.

Altinity выпустили обзор сравнения перфоманса Clickhouse и Redshift, несколько ключевых выводов:
+ В Clickhouse появилась возможность загружать данные из S3 табличной функцией s3()
+ Clickhouse на одной ноде несколько проигрывает Redshift по скорости выполнения запросов, но выигрывает на сопоставивом количестве нод
+ Стоимость операционного использования Clickhouse ощутимо ниже, чем Redshift (однако в статье не указан необходимый ресурс на поддержку того и иного решения)
+ В Clickhouse по-прежнему остаются ряд особенностей, которые следует учитывать при построении запроса.
Например, использование конструкции с JOIN до сих пор неэффективно, а замена JOIN на подзапросы дает значительный прирост в скорости.

Написал заметку о том как быть, когда заказчик просит «таблицу как в Эксель» и никаких графиков. Показал для каких задач и как работают таблицы. Описал семь кейсов, которые обычно прячутся за такими запросами, и какие решения я использую.

https://revealthedata.com/blog/all/tablica-ili-grafik-kak-ubedit-zakazchika/

#статья

Будем считать, что на канале и на datalearn мы сажаем семена знаний😜

нужны ли алгоритмы программистам?

холиварный выпуск Moscow Python подкаста: Григорий Петров и Злата Обуховская накидывали на вентилятор, направленный на Асю Воронцову из Яндекса.

Тезис №1: знание алгоритмов нужны только тем, кто работает с высоконагруженными сервисами, где важна эффективности. Типа ядра Линукса или поисковика Яндекса. (важно отметить: даже в самом Яндексе не все работают с хайлоадом)

Тезис №2: внедрение алгоритмов в код ухудшает его читаемость. Это важно, т.к. код больше читается, чем пишется.

Тезис №3: времязатраты на написание эффективного кода не всегда окупается. Можно потратить две недели на код, который даёт всего 5% в сравнении с уже готовой библиотекой.

Тезис №4: профилировщик — лучший друг программиста. Это снимает большинство вопросов с эффективностью. Например, он подскажет, если вдруг код зайдёт в цикл.

Тезис №5: в больших компаниях спрашивают знание алгоритмов (и умение их писать на бумажке) не только ради самого знания, но и просто как ещё один фильтр, чтобы отсеять людей, которые уже приложили усилия и вызубрили редко используемую информацию.


Подкаст в iTunes и overcast

Самая главная книга про Spark от его создателей. Теория + практика на Scala и Python. Я себе купил такую книга, где-то за 50$, но мне амазон вернет, а вам нет. Но оказывается есть и в PDF -> https://www.pdfdrive.com/spark-the-definitive-guide-big-data-processing-made-simple-e184791342.html

А это уже advanced уровень, для серьезного использования приложения. Я тоже купил. Я где-то покупаю по 2 книги в месяц, лучше бы я столько читал в месяц. 🤔 PDF -> https://www.pdfdrive.com/high-performance-spark-best-practices-for-scaling-and-optimizing-apache-spark-e158286073.html

В обще это 2 топ книги по spark. Но нужно еще знать Python или Scala для Spark. И не забывать, что есть 2 типа инженера данных - hardcore и gentle. В зависимости от задач и целей, можно двигаться от одного к другому. Я вот ощущаю себя gentle, и теперь хочу развиваться в hardcore, поэтому и фокусируюсь на python, spark. Даже не смотря на то, что на работе могу решать все задачи без Spark/Python.