Вы сказали что комбинировать разрезы в свободной форме нельзя, а что мешает загрузить в аналитический репозиторий код, в котором датасет будет собираться с помощью методов cube/rollup/grouping sets? Понятно что это тот вариант, который сильно нагрузит расчеты, но интересно, не встречалось ли подобных примеров и что делать если в репозитории появляется такой код?
А возможен такой вариант что пересчет данных для экспа в кумулятивной таблице ещё не завершен, а уже пришло время готовить новый отчет по результатам экспериментов? Если да, то что будет в отчете? И по третьему вопросу получается что сведения о стране локации и тд не содержатся в кумулятивной таблице и скорее будут получены из dependencies? И когда вы сказали что при заведении эксперимента можно выбрать какие разрезы нужны, имели ввиду что эксперимент можно раскатить на несколько платформ, стран и тд? Или как ещё в расчетах участвует выбор разрезов при заведении эксперимента?
Спасибо что поделились! Помогите, пожалуйста, разобраться с несколькими вопросами:
Можно ли править метрики через несколько дней после заведения? Например, если оказалось что в sql события для метрики нужно добавить ещё одно условие, то и в кумулятивной таблице число хитов нужно пересчитать. Если можно, то как выстроен процесс обновления исторических данных?
Происходит ли во время заведения эксперимента в raw mode проверка правильности описания sql события и других полей? Когда пользователь или админ АБ-платформы узнают что в sql события есть синтаксическая ошибка (например, пропустили одну букву в имени функции или забыли скобку)?
Возможно ли посчитать значения метрик в разных комбинациях срезов? Например, узнать значение метрики эксперимента для любого сочетания платформы, страны, и других разрезов, включая выборку по всем, если эксперимент аффектит указанные срезы
Можно ли каким то образом при помощи Omicron посчитать сколько пользователей в тестовой и контрольной группе прошли цепочку действий (важно чтобы одно событие обязательно наступало после другого) и сколько отсеилось на каждом шаге? Например, 100 человек посмотрели рекламное сообщение -> 30 человек перешли на лендинг с промо акцией -> 10 человек оформили покупку по акции
Airflow + Spark это связка оркестратора и вычислительного движка. Сам по себе Airflow обычно не обрабатывает данные, а только запускает по определенным правилам те или иные задачи (можно назвать его cron-ом на стероидах), например, как в рассматриваемом примере, запускает Spark джобы, которые уже непосредственно занимаются вычислениями. Pentaho DI же является именно ETL тулом, который позволяет c помощью собственного графического интерфейса построить пайплайн, работа с данными в котором будет самой же Pentaho-й и выполняться. Одну и ту же задачу можно решить разными путями, а использовать Pentaho или Airflow+Spark - вопрос выбора инструментов под конкретные задачи.
При изучении Spark-a главнее всего понять как этот фреймворк работает под капотом и каким образом обращается с данными, а на каком языке общаться с ним и писать под него джобы (Python, Scala и пр.), по моему мнению, на старте не так уж важно, можно выбрать любой вариант.
Что касается линукса, то мнения встречаются разные. Поэтому я не так много включил в пункты для изучения, буквально то, что можно освоить за один-два подхода. Часто бывает так, что вещи, связанные с терминалом, постоянно приходится гуглить и учиться заново) С инмоном/кимбаллом примерно всё тоже самое, nice to have. Часто затрагивают эту тему в курсах, часто спрашивают на собесах.
Понятно, спасибо большое!
Вы сказали что комбинировать разрезы в свободной форме нельзя, а что мешает загрузить в аналитический репозиторий код, в котором датасет будет собираться с помощью методов cube/rollup/grouping sets? Понятно что это тот вариант, который сильно нагрузит расчеты, но интересно, не встречалось ли подобных примеров и что делать если в репозитории появляется такой код?
А возможен такой вариант что пересчет данных для экспа в кумулятивной таблице ещё не завершен, а уже пришло время готовить новый отчет по результатам экспериментов? Если да, то что будет в отчете?
И по третьему вопросу получается что сведения о стране локации и тд не содержатся в кумулятивной таблице и скорее будут получены из dependencies? И когда вы сказали что при заведении эксперимента можно выбрать какие разрезы нужны, имели ввиду что эксперимент можно раскатить на несколько платформ, стран и тд? Или как ещё в расчетах участвует выбор разрезов при заведении эксперимента?
Спасибо что поделились!
Помогите, пожалуйста, разобраться с несколькими вопросами:
Можно ли править метрики через несколько дней после заведения? Например, если оказалось что в sql события для метрики нужно добавить ещё одно условие, то и в кумулятивной таблице число хитов нужно пересчитать. Если можно, то как выстроен процесс обновления исторических данных?
Происходит ли во время заведения эксперимента в raw mode проверка правильности описания sql события и других полей? Когда пользователь или админ АБ-платформы узнают что в sql события есть синтаксическая ошибка (например, пропустили одну букву в имени функции или забыли скобку)?
Возможно ли посчитать значения метрик в разных комбинациях срезов? Например, узнать значение метрики эксперимента для любого сочетания платформы, страны, и других разрезов, включая выборку по всем, если эксперимент аффектит указанные срезы
Можно ли каким то образом при помощи Omicron посчитать сколько пользователей в тестовой и контрольной группе прошли цепочку действий (важно чтобы одно событие обязательно наступало после другого) и сколько отсеилось на каждом шаге? Например, 100 человек посмотрели рекламное сообщение -> 30 человек перешли на лендинг с промо акцией -> 10 человек оформили покупку по акции
Airflow + Spark это связка оркестратора и вычислительного движка. Сам по себе Airflow обычно не обрабатывает данные, а только запускает по определенным правилам те или иные задачи (можно назвать его cron-ом на стероидах), например, как в рассматриваемом примере, запускает Spark джобы, которые уже непосредственно занимаются вычислениями. Pentaho DI же является именно ETL тулом, который позволяет c помощью собственного графического интерфейса построить пайплайн, работа с данными в котором будет самой же Pentaho-й и выполняться. Одну и ту же задачу можно решить разными путями, а использовать Pentaho или Airflow+Spark - вопрос выбора инструментов под конкретные задачи.
При изучении Spark-a главнее всего понять как этот фреймворк работает под капотом и каким образом обращается с данными, а на каком языке общаться с ним и писать под него джобы (Python, Scala и пр.), по моему мнению, на старте не так уж важно, можно выбрать любой вариант.
Да, хороший материал! Местами тоже есть моменты для джуна может не такие необходимые, но всё равно полезные.
Можно попробовать, но какой будет вывод по итогам собеса - непонятно)
Вакансии именно джунов тоже есть, хотя, конечно, и не так часто попадаются как middle-senior.
Что касается линукса, то мнения встречаются разные. Поэтому я не так много включил в пункты для изучения, буквально то, что можно освоить за один-два подхода. Часто бывает так, что вещи, связанные с терминалом, постоянно приходится гуглить и учиться заново)
С инмоном/кимбаллом примерно всё тоже самое, nice to have. Часто затрагивают эту тему в курсах, часто спрашивают на собесах.
По вашему мнению, что из перечисленного не относится к знаниям, достаточным для джуна?