Как в 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/

эмпирически-оптимальное соотноешение: 2-3 дата инженеров на одного мл-инженера. Если дата инженеров меньше, то, получается, их работу делают мл-инженеры [а могли бы модели делать что-нибудь своё МЛ-ное].

https://twitter.com/dsunderhood/status/1420769858053103617

когда 2 года назад выбирал профессию, ориентировался именно на это соотношение. Кажется, не прогадал)

https://sashamikhailov.ru/blog/all/data-analyst-and-data-scientist/

Уровни аналитиков

Женя Козлов описал опыт Яндекса по формализации грейдов для аналитиков. Написано очень чётко, можно использовать как шпаргалку для команд или личного развития.

Понравилось чёткое разделение каждого грейда в разрезе подхода к задачам (мелко разжованные а в конце просто глобальное направление).

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

Ниже надёргал абзацев из каждого раздела, рекомендую почитать целиком:

----

Аналитик данных – это человек, который помогает команде:
• Принимать решения более объективно, основываясь на фактах и данных (в противовес мнению, интуиции и опыту).
• Искать точки роста продукта и бизнеса.


Продукт аналитика — это ответы на заданные и незаданные вопросы, создание мыслительных моделей и фреймворков, и выведенные из них рекомендации, которые приводят к росту показателей бизнеса.


1. Аналитик-стажер (trainee data analyst)

Аналитик-стажер работает на уровне четко сформулированных и хорошо формализованных задач. Задачи стажеру ставит исключительно старший товарищ-аналитик (наставник или руководитель). Он же проверяет результаты выполнения этих задач перед тем, как отдать эти данные куда-либо еще.


2. Младший аналитик (junior data analyst)

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

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


3. Аналитик 1 (Middle data analyst 1 step)

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

Аналитик 1 всё чаще и чаще докапывается до сути идей и вопросов, с которыми к нему пришли. Думает про задачи в терминах решений, которые будут приняты, а не в терминах работы с данными.


4. Аналитик 2 (Middle data analyst – 2 step)

Аналитик 2 — автономный аналитический юнит. Наносит пользу бизнесу. Это более опытная версия предыдущего грейда, но есть и отличия, которые являются качественными, существенными: это понимание контекста и выросший уровень рефлексии.

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

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


5. Старший аналитик (Senior data analyst)

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


6. Ведущий аналитик (Lead data analyst)

Аналитик-легенда. Таких единицы. Ведущий аналитик – это супер-эксперт в своей предметной наукоемкой области (как пример, алгоритмы диспетчеризации или поведенческая экономика).


https://gopractice.ru/data_analysts_levels/

Два подкаста про игры с точки зрения машинного обучения

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

Особенно понравилась вставка про Доту с интернешнала с живыми криками комментатора. Фанфакт: перед матчем с Денди машина тренировалась 2500 лет игрового времени.

Слушать в iTunes и Overcast


Второй подкаст — уже серьёзный разговор с инженером из Google Deepmind о том что там под капотом у этого процесса и где эти навыки можно применить в реальном мире.

Ссылки на подкаст в посте автора