И еще один сервис, который вы можете запустить бесплатно (на облачные кредиты) - Yandex Data Proc. То есть вы можете запустить кластер Hadoop со Spark. Отличный вариант потренироваться на больших данных и Spark. То есть вместо того, чтобы учить как настраивать hadoop, hdfs, как крутить всякие настройки, вы можете сразу перейти к делу и сосредоточиться на решение проблемы. Пару кликов, и вы можете уже писать PySpark или Scala для обработки массива данных. Мне кажется хорошая история для собеседования, рассказать как вы интересуетесь современными технологиями и сравнили AWS EMR и Yandex Data Proc. https://cloud.yandex.com/docs/data-proc/concepts/

Линейная регрессия на sql? Не вопрос! До этого я только в табло ее делал😬

Все слышали про IP адрес? Вы можете всегда узнать какой у вас IP адрес, набрав в google "What's my IP", и получите что-то вроде 205.251.233.106, цифры могут быть любые. Когда мы делали домашнее задание по 3му модулю - подключение БД postgres к локальному клиенту, то мы просто открывали firewall между нашей БД и клиентом SQL полностью (public access). Так никогда не делают, обычно прописывают конкретный range IP адрессов, для этого используют CIDR Notation. Вы на практике познакомитесь с ней в модуле 5 (облачные вычисления) и 6 (облачное хранилище данных. А вот пока для ознакомления статья, как это работает.

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

На ресурсе datalearn мы хотим собрать информацию о самых лучших телеграм или youtube каналах, блогах или сообществах для наших студентов, подписчиков и посетителей сайта.

Много талантливых ребят делятся опытом и рассказываю об интересных проектах, мероприятиях и вакансиях связанных с аналитикой. Мы решили собрать их вместе! Если у вас есть телеграмм канал и в нем больше 500 подписчиков, значит у вас хороший контент и им необходимо поделиться со всеми!

Пожалуйста, заполните опрос или перешлите кому будет интересно.

Интересная статья про technical debt для ML, написанная сотрудниками google.

Technical debt - это метафара, которую ввели в 1992 году, она обозначает стоимость решения на долгой перспективе. То есть, чтобы быстро строить решения, двигаться быстро (fast time to market, quick wins). Вы сможете показать быстрый результат, особенно при использовании облачных вычислений, но со временем вам это встанет в копеечку, так как поддерживать систему будет все сложнее. И это не пусты слова, прямо сейчас я наблюдаю такую картину у нас в команде, нам необходимо создавать Onsite Feature Attributiin модель для маркетологов, чтобы они могли измерять эффективность кампаний. Мы двигаемся быстро, а это значит сотни ТБ данных разбросаны по AWS аккаунтам, и я все добавляю новые данные (даже не думаю, чтобы что-то ненужное удалить - потом удалю). Это стоимость хранения данных, которая еще не очень большая. А вот стоимость вычислений (compute) - сканировать данные (processing, querying) - это уже дорого, особенно если это GPU.

Поэтому моя роль как data engineer, на основе информации выше, разбираться с этим, чтобы на выходе я мог написать что-то вроде (взял у Facebook data engineer и немного изменил):
- Managed a 10 PB+ data platform
- Consolidated and conformed company-wide growth metrics (across Amazon Events and marketing efforts) into a single, company-wide view.
- Optimized machine learning feature set generation pipelines (200+ TB/day) from having a 4 day latency to having a 1 day latency. While also dropping compute costs for those pipelines 4x.
- Reduced core notification data set latencies from 36 hours to < 8 hours.
- Migrated 50% of notifications pipelines from using Hive to use Spark, Presto, or real-time streaming.
- Cut compute cost from notifications pipelines by 40% over the course of 9 months.

+ надо обязательно упомянуть Privacy (GDPR, и все другие вещи, про удаление клиентских данных и compliance)

Вышла новая книга по созданию и управление аналитическими командами - Data Teams. Я уже заказал. https://www.amazon.com/Data-Teams-Management-Successful-Data-Focused/dp/1484262271/ref=sr_1_1?dchild=1&keywords=data+teams&qid=1601141315&sr=8-1

Интересная статья, которая сравнивает Azure Synapse (их хранилище данных) и Azure Databricks (Spark) - рассматривается что, для чего используется. На самом деле даже без Azure, можно просмо посмотрят, что когда используется. Это же самое важно, выбрать правильную технологию.

Статья про delta lake. Кто-то уже строил такое?

Табло организует Tableau Day на русском 1 Октября.

Оказывается, если на работе у вас есть лучшие друзья, то вы в 7 раз более эффективно работаете. Я с этим согласен, вспоминаю веселые проекты в России, где все дружили. За 5 лет в Амазоне у меня нет ни одного друга из Амазона🤨 Наверно поэтому я работаю в 7 раз хуже чем мог бы)))

Apache Airflow 2.0 (это инструмент для создания Data Piplelines и он бесплатный, то есть open source). Многие инженеры используют его. Есть команды в Амазоне, которые его используют. Очень хочется сделать вебинар на data learn про Airflow для чайников. Если вы используете его на своей работе или проекте, может быть сделаете вебинар?

Amazon Plans Vancouver Expansion Where Talent Is Cheap - Причем Ванкувер один из самых дорогих городов в мире.

Теперь могу говорить, знакомьтесь, меня зовут Дмитрий, я талантливой и беру недорого🙌

Инженеры данных часто задают вопрос: «Грузить данные в реальном времени (real time streaming) или пачками (batch)»

Если спросить у бизнес заказчика, то мы получим ответ - «нам нужно в режиме реального времени отслеживать данные и быстро реагировать!» Иногда это правда, а иногда нет.

При выборе решения следует задавать следующие вопросы:
«Кто будет поддерживать data pipeline? Понимает ли моя команда, как починить этот datapipeline, когда он сломается? » - Стрминговые решения часто сложнее классчической загрузки данных раз в день/раз в час.

Другой вопрос - «Будет ли кто-нибудь действительно просматривать эти данные в нерабочее время?» - если это правда, то в отчетах в реальном времени больше смысла. Если нет, то им, вероятно, можно обойтись без streaming решения.

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

У вас есть кейсы, когда вы создавали стриминговое решение? Может быть есть история, когда бизнес просил real time metrics, а на самом деле им не нужно было?

Никто не пробовал? https://vc.ru/finance/162560-razrabotchik-otkrytoy-platformy-dlya-sozdaniya-servisov-analitiki-cube-dev-s-osnovatelyami-iz-rossii-privlek-6-2-mln