Я оказался слишком наивным, когда выше писал про курсы. И был совершенно не прав. Все эти школы онлайн курсов - бесполезный треш. И это не мои слова, а слова основателя Skillbox, который продал его Mail Ru, и открыл успешный бизнес в Бразилии. По такой же модели.

Ключевое слово - "Бизнес" с высокой капитализацией. Более подробно тут https://youtu.be/tSuF0hDy2pA?t=715 (спасибо за ссылку, у меня какраз есть подписка на epic seasons, потому что я там тоже буду учавствовать). Как я понимаю вторая часть уже доступна за деньги. Каждая 2ая фраза это цитата.

Как заметил один из топов SkyPro в этом диалоге - он вроде бы хочет следовать миссии (значит делать контент хороший и учить людей), но в тоже время его партнеры хотят рубить бабло. Так что надо выбирать МИССИЯ или БАБЛО, нельзя и то и другое.

Ex основатель Skilbox объясняет нам почему же все таки бизнес успешный, а курсы лажи. А все потому-что 80% людей, "глупые", они не хотят развиваться и напрягаться, им приятно просто видосики посмотреть для собственного самоудовлетворения.

На вопрос "обман онлайн курсы или нет", он отвечает, что люди не хотят знать правду, у них есть право на не знание. Если бы писали на автомобили, что он опасен, разве это было бы хорошо?

Другой интересный момент - им вообще пофиг сколько людей закончило курс, так как всегда найдутся умные люди, которые дойдут курс до конца и найдут работу. Причем они сделали бы это и без помощи онлайн курсов. А их success stories, уже используют, чтобы впарить дальше.

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

Список аргументов из этого супер выпуска можно продолжать долго, но факт, что платные курсы, в частности всех программы DS, DE, аналитики и тп - это развод людей на деньги.

Самое интересное, что большинство людей, которые сидят в телеграм каналах по аналитике, читаю хабр - уже не глупые, им не нужны курсы, они сами выучаться и найдут работу. Поэтому реклама в телеге всяких курсов - чаще деньги на ветер. Для всех этих курсов нужна другая аудитория. Как сказал создатель skillbox - "глупые люди, которые не хотят самостоятельно учиться и курсы им не помогут".

Теперь я могу смело сказать Data Learn - это не курсы, это просто видео учебник по аналитике. Может быть даже видео энциклопедия. Но слово курсы - ТАБУ. Потому что это кидалово и развод людей на деньги. А рекламировать курсы в своих каналах это как продавать совесть. 🤢

Если вы сомневались раньше - покупать курс или нет, то теперь вы знаете как быть.

PS
1)судя по клиентам Яндекс партикум не плох, но даже в видео на него много ссылаются, у ним есть возможность сжигать деньги и стараться делать норм курсы.

2) Люди, которые делают и продают авторские курсы, не попадают в эту группу компаний, которые хотят любой ценой варить курс.

3) MIT и другие дорогие западные курсы - честно хз. Я бы сам хотел бы в MBA MIT Sloan, ради опыта, знакомств и среды, в которой учиться (оффлайн). А вот их мини курсы, я не уверен.

В общем, идея простая, вы сами можете все выучить и все будет хорошо. Но всегда будут люди, которые готовы платить за услуги и товары, которые "так себе". Вот вредно же пить алкоголь? А я пью. Опасно водить машину? А я езжу на машине и ТД.

Тему закрою про онлайн курсы. Спасибо Эрику за хорошее видео, обязательно посмотрите.

Все чаще в сети встречается 2 словосочетания - "Analytics Engineer" и "Modern Data Stack", самое интересное, что Analytics Engineer происходит от одной компании Fishtown Analytics, создателей dbt tool. Очень классно они вписались в индустрию.

А вот еще выступление 5 Founders define the Modern Data Stack https://youtu.be/vbo7KlJZOLk

SQLGlot is a no dependency Python SQL parser and transpiler. It can be used to format SQL or translate between different dialects like Presto, Spark, and Hive. It aims to read a wide variety of SQL inputs and output syntatically correct SQL in the targeted dialects.

Пост про Giving more tools to software engineers: the reorganization of the factory рассказывает про эволючию SDE и примеры как инструменты и практики делают их работу эффективней и лучше.

I've worked on or close to:

- Spotify built a whole P2P architecture in C++ in order to distribute streaming music to listeners, something which today is a trivial problem (put the data on a CDN).
- I used to write custom mapreduce jobs to pull basic stats, then wait for hours for those jobs to finish. Today these would be SQL queries in a datawarehouse that would run in a few seconds.
- I once ran a web shop and spent a week implementing credit card payments. Today it's 15 minutes using Stripe.

Not to mention the changes in developer processes:

- Unit tests were really rare in the industry — I first encountered it working at Google in 2006.
-When git was new, git-flow was the prevalent workflow, and many developers I worked with spent an inordinate fraction of their time (like, 20-30%) just rebasing.
-CI systems were fragile, CD basically didn't exist, and deployments were scary manual affairs.

Автор упоминает причины, почему никто не хочет работать с инженерами (из бизнес пользователей):
1. Iteration speed: The cost of explaining to an engineer what you need makes it not worth doing it
2. The engineering resources are not available (or too expensive, or whatever)
3. You just need a fraction of an engineer but that market does not exist
4. There's some special domain knowledge needed to build something
5. Engineers are weird and smell funny (🤪неужели это еще актуально?)

PS Я нашел этот пост в блоге про аналитику. Все больше и больше происходит overlap между техническими ролями и не техническими. Например в Амазоне BI роль всегда была не технической, соответственно зп вилка меньше была. В прошлом году, BI инженер стала технической ролью. В целом именно благодаря tools роли могу относительно легко трансформировать в более технические. Но одних tools не хватает, приходится дополнительно изучать git, командную строку, networking и тп. Но все должно быть по порядку, от простого к сложному.

Цена для решения Big Data часто важна, особенно если вы не работает в AWS, Azure, GCP (где у вас и скидка 40% и никто особо не считает, сколько вы там потратили). В статье Cost-Efficient Open Source Big Data Platform at Uber рассказывают про оптимизацию стоимости решения на:
- Apache® Hadoop® File System (HDFS)
- Apache Hive ™
- Parquet and ORC file formats
- Apache Hudi
- Hive-on-Spark, Spark, and Presto

В последнее время в блога стали писать не просто Hadoop, а Apache® Hadoop®, или Apache Hive ™), не понятно зачем писать все эти trade marks или другие абревеатуры):

- The symbol ™ (trademark) is sometimes used when a trademark has been filed (applied for) but not yet registered.
- The symbol "R" in a circle signifies that a trademark has been registered in the U.S. Patent and Trademark Office for the goods inside the package.

Раньше в моем мире была такая градация:
Engineer -> Senior Engineer -> Principal Engineer (для технических специальностей), но оказывается Staff Engineer это тоже крутая позиция (которой нет в Amazon/Microsoft).

Новый день и новый пост про Modern Data Stack. Уже даже забавно видеть этот загловок в посте🥱скучно, хотим "хлеба и зрелищ", как у Xsolla про кейсы big data, а не список очередных вендоров, диаграм с кубиками из логотипов и sales pitch. Еще обазательно - было/СТАЛО - „Жить стало лучше, жить стало веселей“ - еще сам Сталин так говорил.

https://medium.com/@jordan_volz/five-predictions-for-the-future-of-the-modern-data-stack-435b4e911413

Кстати надо поддержать Сергея с комментами, можно написать свой коммент, предложить помощь, сказать что пора мигрировать Big Data на Modern Data Stack!

Ссылка, чтобы отзыв оставить https://bit.ly/2WbDafE

Этот товарищ очень подробно расписывает modern data stack, прикладывает много интересных ссылок и мыслей.

Попался пост 2014 года - The Future of Data Engineering (Я например узнал что такое data engineering в конце 2016, до этого это было смутные представление про ETL разработчика и Big Data разработчика. )

I believe SQL would:
Exist in 5 years,
Exist as legacy in 10 years, and
Go extinct in 15 years.

То есть автор, еще в 2014 году хотел предугадать как повернется судьба SQL. Хотя в то время многие говорил, что время DW прошло, и теперь вот будет big data, data lake и все такое. В итоге SQL остался и даже наоборот! Теперь SQL используется везде, где только можно! Но 15 лет еще не прошло...

After this happens, we would have the world where machine learning engineers and data scientists would have the “time to market” of their features shrinked from weeks and months to hours and days.

Дима привет😉
Уже по традиции, закидываю к тебе анонс позиции BI аналитика в Новартис.

Стек достаточно интересный, думаю, что в сообществе точно кто-то заинтересуется.

https://colossal-baroness-b09.notion.site/We-are-hiring-BI-Analyst-d87cae78ee914fbc8db630f607650b75

Кто закончил даталерн до 5го модуля и сделал задание, тому преимущество на собеседование✌️

Что такое Data Linage - это термин из ETL, теперь уже data engineering.

Data lineage refers to the ability to trace how and where data sources are used. In the first years of a company, data lineage is easy to fully understand: a company with only a handful of data pipelines doesn’t need to worry much about data lineage since they can count the number of tables with their fingers. However, as datasets become more complex and the number of contributors grow, it becomes more and more difficult to understand the relationships between different data sources.

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

В статье Data Lineage at Slack вы можете узнать про How we automate building and maintaining data lineage at Slack

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

The Information: There’s a debate going on in the enterprise tech industry about whether using cloud providers remains cost-effective after a company reaches a certain scale, and whether it’s better to repatriate certain computing jobs to private data centers.

Компания Pinterest рассказала как они научились лучше контролировать и прогнозировать расходы AWS.

Расскажу про один из проектов про миграцию. Но не из on-premise в облако. А из облако в облако.

В качестве big data processing инструмента у нас был HDInsight (это аналог AWS EMR, PaaS Hadoop. Если вы смотрели модуль 5, то знаете, что такое PaaS). Его задача читать данный телеметрии (именно так называется поток данных от клиента), как правило это JSON файлы, которые сыпятся в Blob Storage (Аналог у AWS S3). Мне нужно было смигрировать одну табличку, там данных за 3 года, по 20Тб в год.

Вместе с HDInsight использовался Hive SQL, на нем была описана вся логика и с помощью Azure Data Factory (аналог Airflow от Azure - то есть оркестратор, у AWS есть Glue, но это не тоже самое, так как Glue имеет Spark и мы сразу пишем трансформации на Python или Scala, а в ADF мы просто выбираем компоненты - где хранить данные, чем обрабатывать и тп). Результат обработки JSON - ORC формат и Hive Metastore (для конечного пользователя это просто как база SQL данных). А дальше уже другой стек для расчета таблиц фактов.

Куда мигрировать: Azure Databricks Delta Lake

Почему мигрировать: Тут несколько факторов, прежде всего, можно было ничего не делать, так как и так все работает, но я не могу просто так работать с legacy, если на рынке востребованы другие технологии. Я лично стал активно пушить Databricks и Delta Lake. Это дает нам преимущества и удобства, но прежде всего это крутой опыт и история для меня и мне приятно рабоать с лучшими технологиями на рынке и всегда люблю пробовать новые решения. Такая стратегия всегда помогает развивать карьеру и находить интересные проекты.

Альтернативы: Конечно они есть. Как я сказал, можно вообще ничего не делать. Но можно еще использовать HDInsight+Spark (вместо Hive), чтобы использовать Delta Lake. Можно использовать аналоги - Hudi и Iceberg, но как то Azure не пиарит их совсем, только Spark и Delta. И меня всем устраивает Spark+Delta, мне бы с ними разобраться. Еще есть Azure Synapse - но они пока отстают по функциональности от Databricks. Но агресивно развиваются.

Теперь про сам процесс миграции, все очень straightforward. Создаю цикл, в котором выполняю запрос за 1 день или час.
1) Выполняю SQL запрос для одной партиции в качестве WHERE условия и создаю DataFrame
2) Модифицирую dataframe, чтобы изменить схему таблицу, добавить полей и тп
3) Пишу data frame в новый location, но уже Azure Data Lake Storage (Вместо Blob storage) USING DELTA

Например в 1 день может быть 700Gb данных, и вроде бы задача простая, но очень долгая. Я использовал кластер Spark:
- 3 Worker nodes сумарно 768gb оперативки, 192 cores
- 1 Driver nodes 128gb, 32 cores

Например 700gb он считал 2часа+. Кластер я выбирал пальцем в небо, было лишь ограничение на кол-во ядер для моего аккаунта в Azure.

Самое печальное, что я просчитал 2 года из 3х, и нашел маленькую ошибку, скопировал одно и тоже поле 2 раза=(

Цена Databricks в Databricks Units (DBUs) based on the VM instance
selected

В моем случае я трачу 42DBU в час, то есть 42DBU*0.55$=23.1$ в час.

По цене за storage я посмотрел, 600Gb в месяц стоит 107$, а 60Tb в месяц стоит 10k. В данный момент я плачу по двойному тарифу за HDInsight и за Databricks + 2x storage.

Согласно исследованию 2020 - Brown, Anicich & Galinskya - Compensatory conspicuous communication: Low status increases jargon use, ученые, которые используют много жаргона чувствуют себя неуверенно и пытаются компенсировать незнание/непонимание жаргонными словечками.

Я кстати совсем перестал пытаться использовать модные слова в моей тематике, чем проще и понятней тем лучше, а вот лет 5 назад, очень даже старался быть в тренде.

Хорошая "библиотека". Из книги Python Crash Course, считается одной из лучших по Питону. Сейчас читаю, очень много мелких деталей, которых раньше не встречал.

Методология и практика нагрузочного тестирования. Опыт Miro
Интересно можно применять нагрузочное тестировае в инжиниринге данных. С играми особенно, пока делаем новую игру, данных килобайты. В бето тестировании - мегабайты. А в день запуска это как Amazon prime day, пик нагрузки максимальный, то есть к вопросу того же размера кластера Databricks например.

Кстати согласно статье, Miro использует Looker (SaaS BI).

Делаете НТ для аналитики и инжиниринга данных?