📊 Всем SQL

Помню, лет десять назад американские СМИ захватила идея, что «каждый должен научиться программировать». Повсеместно открывались буткампы из серии «от нуля до сеньор-разработчика за 10 дней», и даже президент США делал вид, что учится писать на джаваскрипте.

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

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

Если вы согласны, и чувствуете, что навыки работы с данными стоило бы подтянуть — дальше я расскажу про три курса и один инструмент. Инструментом я пользуюсь каждый день, а курсы проходил лично (один даже сделал сам). Авторы не платили за рекомендации. Хотя, естественно, если вы выберете мой курс — я на этом заработаю.

SQL — это «родной» язык работы с данными. В принципе, можно прожить и без него: в базовом варианте достаточно понимать основы статистики и знать Excel на более глубоком уровне, чем «рисую таблички в рамочке». В этом поможет курс Алексея Куличевского «Данные для бизнеса». Хотя небольшой порции SQL и там не избежать.

Если интересна продуктовая аналитика — курс Анатолия Макаревича SQL Habit. Типа GoPractice, только бодрее и на голом SQL, без Amplitude. Проводит от самых основ до серьезной работы.

Если уже знаете основы SQL и хотите научиться применять его в повседневных задачах — мой курс «SQLite для аналитики». Научитесь загружать и выгружать данные, «чистить» проблемы, находить связи и анализировать показатели, применять аналитические функции и работать с JSON.

А инструмент — Redash. Это веб-интерфейс к любым базам данных, в нем строят отчеты и собирают дашборды. Простая и дешевая замена замороченным BI-инструментам. Из этой же серии есть Metabase и Superset — их многие хвалят, но я не пробовал.

В любом случае — освойте SQL. С ним вы перестанете зависеть от специально обученных людей, к которым ходите на поклон за очередным отчетом. Сможете принимать решения быстрее и увереннее. Да и в целом станете автономнее и ценнее как специалист. Всем SQL!

плюс один канал с инфографикой

Пока в кино Годзилла борется с Кинг-Конгом, на IT-рынке продолжается битва других гигантов — цифровых экосистем. На прошлой неделе стало известно о скором разводе Сбербанка с Mail.ru Group. По информации Financial Times, компании не договорились о стратегии развития. Ждем вестей о том, как они разделят активы, а пока смотрим на общую расстановку сил

Послушать:

Самат Галимов (Запуск Завтра) про технический консалтинг. Как устроено, сколько стоит (много!) и зачем это нужно бизнесу. Полезно послушать, если работаешь в агентстве с разными проектами; при работе в продукте тоже полезно — понимать, что делать, чтобы твоему начальнику не пришлось вызывать стороннюю экспертизу ;-)

Слушать в iTunes и Overcast


* * *

Moscow Python про обучение и работу джунов. Компании в принципе не стремятся набирать зелёных джунов. Понравился тезис, что в компании с налаженными процессами дуну будет проще в 100 раз.

Слушать в iTunes и Overcast


* * *

Флоренс Найтингейл использовала графики для убеждения ещё в 19 веке (место для шутки про мейнстрим). Помимо того, что она работала медсестрой в полевых госпиталях, она изучила статистику, чтобы на реальных данных доказать влияние базовых санитарных мер на смертность солдат.

Слушать в iTunes и Overcast

Почитать про Флоренс Найтингейл: страница подкаста, Википедия на русском и английском

Диаграмма Флоренс Найтингейл «петушиный гребень» (из подкаста выше)

Диаграмма показывает смертность солдат во время крымской войны. Каждый из секторов соответствует одному месяцу (с апреля 1854 по март 1856). Площадь каждого сектора пропорциональна смертности. Голубой слой показывает смертность от болезней, красный слой показывает смертность от ран, и коричневый слой — смертность от других причин.

Две отдельные части изображают ситуацию до и после того, как из Лондона была прислана комиссия по улучшению гигиены (в марте 1855).

Экстрактор данных из Эгеи

Эгея — это движок для блога. Все данные о постах, тэгах, просмотрах, лайках хранятся в базе данных (сюрприз!).

Написал небольшой код, который достаёт из этой базы данных нужное и сохраняет в виде таблицы: в .csv или Google Sheets.

Это код использовал Роман Бунин для визуализации статистики по своим постам [1]; собственно, для этого проекта я и писал код ;-)

Всё оформил в виде Google Colab (это как Jupyter Notebook, только в интернете).

Чтобы всё заработало, нужно:
1. открыть доступ извне к своей базе (у меня это делается через настройки в хостинге)

2. заполнить в коде данные для подключения к базе: хост, название базы, логин и пароль.

3. если нужно сохранить итог в Google Sheets, код попросит авторизацию аккаунта — прямо рядом в соседней вкладке.


Коллеги дата инженеры могут заметить здесь базовый ETL процесс: достать данные из источника, преобразовать их и загрузить в другое место. Было интересно применить рабочие навыки к задаче из внешнего мира.

[1] — пост Романа

Дополнено: инструкция от Романа как засунуть собранные данные в Tableau

Послушать:

Про генеративные алгоритмы на практике

как при помощи машинного обучения создавать текст, музыку и визуальный дизайн? есть ли разница, кто сделал работу, если задача решена?

Рассказывают композитор приложения Endel и создатель Николая Иронова.

Слушать в iTunes и Overcast

***

Про мощь алгоритмов и полезность математики

о применение алгоритмов к прогнозированию беспорядков в городе для помощи полиции и как сделать математику более человечной.

Слушать в iTunes и Overcast

выжимки и ссылки на странице проекта

***

Мы вас услышали. Как машина научилась понимать нашу речь

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

В очередном выпуске рассказали про эволюцию алгоритмов для понимания и воспроизведения человеческой речи.

Слушать в iTunes и Overcast

Шаблон Tableau для визуализации данных из блога на Эгее

Роман Бунин опубликовал шаблон и написал инструкцию как заполнить его своими данными (которые предварительно достали из БД Эгеи с помощью простого кода ^)

на данных из моего блога получилось такая визуализация

Блог у меня с 2017 года, но, видимо, что-то криво поставил и просмотры начали считаться только после последней переустановки на последнюю версию 2.10.

По динамике просмотров выделяются три заметки:
1. Детективная история как я делал тестовое задание по анализу данных
2. Моё резюме в виде большой заметки (на момент обучения в Яндекс.Практикуме)
3. Отчёт-инструкция как я парсил сайт через встроенные функции в Гугл-таблицах (ещё до того как познакомился с Python)

Ещё заметил, что постов стало в принципе меньше (как и свободного времени, хе-хе)

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

Как в Postgres раздать юзерам выборочные права на разные схемы:

https://towardsdatascience.com/how-to-handle-privileges-in-postgresql-with-specific-use-case-and-code-458fbdb67a73

Data Science — это направление знаний

это что-то такое крупное; типа «медицины».

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

но вот если какая-нибудь больница опубликует вакансию о поиске «медика», то к ним придут все: от акушера до нейрохирурга — спасибо, что не администратор в приёмную!

В компании с налаженными процессами порог входа ниже

Сидят в отделе пять бородатых миддлов и всё у них слажено: все всё знают где что лежит, работа идёт, таски закрываются.

Но вот приходит новенький и изображает Траволту из известного мема: «где тут у вас что?»

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

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

Почему же не наладить процессы? Всё банально — это надо кому-то делать: решить, придумать, спланировать, реализовать. Поэтому в среднем у компаний процессы не описаны — так тупо проще.

И поэтому компании не любят нанимать джунов (пусть даже с горящими глазами) — ведь на них придётся выделять отдельного старичка, чтобы водить за ручку.


---
вдохновлено подкастом Moscow Python
https://news.1rj.ru/str/data_days/135

Мета-Архитектура для работы с данными — исследование Andreessen & Horowitz на основне опроса сотен стартапов

[оригинал, перевод]

интересен общая схема и список всех участников. Выписал ребят из последней колонки:

Output — итог, «конечная станция» для данных

Dashboards
Looker
Superset
Mode
Tableau

Embedded Analytics
Sisense
Looker
cube.js

Augmented Analytics
Thoughtspot
Outlier
Anodot
Sisu

App Frameworks
Plotly Dash
Streamlit

Custom Apps
…


via @data_days

хайрезы в ПДФ

Данные из Google Analytics можно экспортировать в BigQuery. Сам экспорт — стандартная функция GA и ничего не стоит; тарификация идёт по нормам BigQuery: за количество просканированных байт.

Разбирался сегодня со структурой этих данных: колонок всего 22, но их них 10 со вложенной структурой (если всё разложить, будет 176!). Чтобы добраться до нужных значений внутри, приходится прибегать к ухищрениям типа UNNEST. И всё не мог понять зачем это нужно, пока не нашёл гайд как сделать из этого экспорта плоский формат.

Оказывается, изначальная задумка вложенного формата в том, чтобы в одну таблицу «запихнуть» как бы четыре нормализованные… Когда стал ясен смысл, то и на данные смотреть теперь проще.

А вот делать плоские таблицы всё таки не стоит: у меня из одной таблицы на 30Гб получилось три на 30, 60, 30Гб ¯\_(ツ)_/¯ Но хоть можно посмотреть все имеющиеся колонки в одном месте.

https://www.ga4bigquery.com/tutorial-how-to-flatten-the-ga4-bigquery-export-schema-for-relational-databases-using-unnest/

комментарии в канале у Красинского — золото

Да, это хорошая идея вообще, потихоничку описываем.

К сожалению, это не маленький список регшений и в формате комментариев к посту я не знаю как его уложить.

Ключевые метрики описывают свои классы проблем, например, низкая конверсия – описывает проблемы продажи – то как плохо мы продаем и причины этого.

Но это в идеальном мире, где метрики независимы – то есть базис метрик ортогонален друг другу. В реальном мире есть много проблем, например, проблема усреднения: эффективные когорты, каналы, кампании, посадочные страницы скрывают (усредняют) проблемы не эффективных.

Конверсия зависит на части сегментов от ср. чека – выше ср. чек, сложнее решение о покупке, потенциально ниже конверсия – а на некоторых не зависит (услово, у сегмента пользователей в пределах садового кольца стоимость денег ниже, чем в регионах и он меньше смотрит на чек в ресторанах или других сервисах). Конверсия так же ассиметрична по каналам и кампаниям и т.д.

Мы начали с конверсии. А есть и другие ключевые метрики CPUser, Users, Leads, Buyers, AvPrice, AvPaymentCount, Margin, COGS, Activation, Retention, еще лучше DailyUsage, виральность и расчетные AMPPU, AMPU и т.д.

Их соотношения дают классы проблем: в маркетинге, продажах в диджитал части (сайт, приложение), проблемы в отделе/команде продаж (если есть), в операционных процессах и издержках, в ценообразовании и сегментации по цене, в цикле сделки и CJM сделки и процессе продаж, в монетизации и т.д.

В каждом классе проблем свои вопросы:
- Почему мы делаем плановое число продаж?
- проблема у новых пользователей или у старых?
- У нас низкая конверсия у новых?
- низкая конверсия на посадочных?
- на шагах воронки на сайте? (или в приложении?)
- низкая конверсия в отделе продаж?
- Какие есть блокеры, что мешают пользователям купить?
- Какие возражения пользователей или вопросы необходимые для покупки мы не отрабатываем?
- какие воронки, события, шаги ведут к продаже, а какие мешают? Какие события триггеры, а какие анти-триггеры?
- есть ли ассиметрия по устройствам? по городам, регионам? доменам? и почему?

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

Продолжаю разбираться с вложенными данными в BigQuery — читаю наглядное пояснение (только посмотрите на эти гифки!) как и зачем применять к ним UNNEST:

> The problem here is that event_params is essentially an array (actually in BigQuery parlance it’s a “repeated record”, but you can think of it as an array). …

This is where the UNNEST function comes in. It basically lets you take elements in an array and expand each one of these individual elements. You can then join your original row against each unnested element to add them to your table.


автор плавно подводит к выводу, что UNNEST — это как CROSS JOIN, только запись короче (потому что так looks cooler):

> You’ll find that in practice, though, most BigQuery developers will replace the CROSS JOIN with a comma … It still does the same thing, it just looks cooler. (BigQuery developers are all about looking cool.)

https://medium.com/firebase-developers/using-the-unnest-function-in-bigquery-to-analyze-event-parameters-in-analytics-fb828f890b42

Не «если», а «когда»

когда только начинал, было страшно браться за работу — ведь любая работа делалась впервые. Поднять Постгрес на голой Убунте? → «Ну не знаю, смогу ли…»

сейчас с этим проще — во-первых, уже много чего успел поделать, а во-вторых, понял, что всегда будут попадаться задачи, которые придётся делать первый раз. И это нормально! Типа «поднять для проекта инфру с нуля в облаке на кубере и настроить туда доступ облачному BI» — пфф! легко!
(на самом деле совсем не легко, но опустим это))

навеяно:
⁃ известный архитектор тоже не знает как он будет строить заказанный у него небоскрёб (но, конечно, предусмотрительно не говорит об это клиенту) (прочитал у Бабаевой https://news.1rj.ru/str/changemarketing/718)
⁃ Артемий Лебедев старается брать проекты, где как минимум 50% придется делать впервые (типа зачем делать одно и тоже?)

Получается, там где джун не уверен сможет ли, миддл просто называет срок.

(математики в чате могут сказать, что джун тоже «называет срок» — ∞)

выводы из того что надо делать новые проекта

по-любому в работе встретиться новая неведомая хрень — к всему не подготовишься, но важно уметь работать в режиме неопределённости:

1. надо уметь искать ответы — да, пресловутый гугл и стэковерфлоу. Лучше сразу на английском: там по определению больше информации и проще формулировать (язык-то устроен проще).

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

3. знать, к кому обратиться с вопросом — коллеги, кто занимался похожим; эксперты, кто рассказывал про такое же: блогеры, спикеры с конференций, эксперты с рынка, авторы курсов — всем им можно написать и спросить совета (да-да, вот прям взять и написать).

Тут же в тему буду профильные сообщества и чатики в телеграме: там все на одной волне и встречаются с одинаковыми проблемами на своём пути. Вот как раз в чате про дата инжиниринг собрали известные:
- @deordie_chat
- @dataeng_chat
- @hadoopusers
- @moscowspark

и ещё в Слаке есть сообщество проекта DataLearn от Дмитрия Аношина (@rockyourdata) и команды — надо зарегистрироваться на сайте и пришлют ссылку.