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

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

Написал небольшой код, который достаёт из этой базы данных нужное и сохраняет в виде таблицы: в .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) и команды — надо зарегистрироваться на сайте и пришлют ссылку.

Recommended Reading, Listening, Watching from Meltano Team

подборка дата- рассылок, блогов, ресурсов и комьюнити

https://meltano.com/handbook/resources/

Подкаст с Лёшей Никушиным

https://news.1rj.ru/str/internetanalytics/3641

Алексей известен как автор канала Интернет-аналитика ^^ и основатель конференции Матемаркетинг.

Понравился подход к делу:

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

И дальше череда событий:
тут же вечером — он проходит курс по программированию на Пайтоне на Степике

утром в субботу — у него созвон с Ильёй Красинским, чтобы тот объяснил ему куда смотреть в Гугл Аналитиксе

днём в субботу — такой же созвон с человеком из Яндекс Метрики — рассказ как работае и помогает в настройке коннектора к АПИ через Пайтон.

в воскресение — созвон с ребятами из канал про эксель, чтобы помогли всё правильно настроить в таблице и собрать отчёт в одно.

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

-----

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

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

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

Слушать подкаст в iTunes и Overcast

реальный мир — единственный источник практических знаний

«Как стать X?» или «Что качать, чтобы прокачаться в Y?»

можно взять гигантский роадмап и пойти по порядку — через год будет результат (если дойдёшь и не умрёшь с голоду).

мне нравится подход из мира стартапов: любая идея — теоретическая туфта, пока не пройдёт испытание на реальных клиентах. Именно конечные клиенты — единственный источник реальных знаний.

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

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

Следующий шаг — пройти дцать собеседований:
⁃ во-первых, придётся выбрать в какие компании идти: уже надо подумать куда хочется.
⁃ во-вторых, может придётся поделать тестовые — тоже отличный опыт; лучше синтетических задач из интернетов.
⁃ в-третьих, на собеседовании будет технический специалист не ниже миддла, который уже работает по этой специальности — вот он-то и расскажет ЧТО ИМЕННО НУЖНО на эту конкретную должность в этой конкретной компании.
⁃ PROFIT!

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

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

источник

когда пишу в SQL запросах GROUP BY 1, 2 вместо полного наименования колонок, меня всегда тревожила мысль, что я халавлю и недоделываю НОРМАЛЬНЫЙ КОД.

Прочитал, что в dbt делают так же и успокоился: писать через «1» проще и понятнее (заскринил пример ^). Если что, буду показывать эту заметку 🌚


So why do I still group by 1? Well, there's a few reasons:
…
- 1 is a single character (and I'm lazy, OK?!).


https://blog.getdbt.com/write-better-sql-a-defense-of-group-by-1/