На ресурсе 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

Отличный совет - хочешь отдохнуть в выходные, не делай deploy на прод в пятницу. Вы не представляете сколько раз я нарушал это правило и все ломал. Иногда обновляя BI Server, иногда ETL, иногда дашборд и многое другое. Пятница для fun work можно поучиться или просто в игры настольные с коллегами поиграть🎏 А вы как по пятницам - "move fast, break things"?😎

1991 год, реклама хранилищ данных в журнале/газете.

У вас есть свое определение Аналитики? Если нет, то может использовать вот это определение.

Analytics is using data by asking questions to gain insights for decision making.

🤑

Часто возникает вопрос - кто со стороны бизнеса будет драйвить внедрение и адаптацию аналитики. SAP выпустил книгу и перевел ее на русский язык - Финансовый Директор как Интегратор Бизнеса. Много интересных примеров.