Я ранее писал про вакансии в Amazon Alexa в Boston. Вакансии есть, кандидатов нет. Кучу индусов которые откликаются, и которых мы собеседуем, ни разу не вариант.
Вот, какой ответ дал нам HR: Как обычно все сложно. Всеми любимая виза H1b не будет доступна до начала следующего года. Так как они провтыкали срок подачи заявок на 2019 году. Если у вас есть виза в США, (наверно рабочая), то они могут вас собеседовать. Обычно это занимает 3-4 недели.
Так что единственный рабочий вариант для гражданина, не являющегося гражданином США, который в настоящее время не имеет действительной визы в США, является O1-A. Эта виза может быть получена, если кандидат отвечает определенным критериям - таким как докторская степень, публикации, цитаты ученых из Google, рецензии, высокие награды, полученные в своей области, и т. Д. Процесс O1-A занимает 3-8 месяцев.
Так что не смотря на то, что в Бостоне есть вакансии к нам в команду для Data Engineers, BI Engineers, Data Scientists/ML engineers, и кандидатов нет, и я пытался продать идею про крутых специалистов за океаном (и идея им понравилась и бизнес готов был рассмотреть кандидатов), то все обломалось из-за отсутствия квоты на H1B. Поэтому если у вас есть Кандидатская и вы крутой специалист, то можно попробовать пройти процесс.
Вот, какой ответ дал нам HR: Как обычно все сложно. Всеми любимая виза H1b не будет доступна до начала следующего года. Так как они провтыкали срок подачи заявок на 2019 году. Если у вас есть виза в США, (наверно рабочая), то они могут вас собеседовать. Обычно это занимает 3-4 недели.
Так что единственный рабочий вариант для гражданина, не являющегося гражданином США, который в настоящее время не имеет действительной визы в США, является O1-A. Эта виза может быть получена, если кандидат отвечает определенным критериям - таким как докторская степень, публикации, цитаты ученых из Google, рецензии, высокие награды, полученные в своей области, и т. Д. Процесс O1-A занимает 3-8 месяцев.
Так что не смотря на то, что в Бостоне есть вакансии к нам в команду для Data Engineers, BI Engineers, Data Scientists/ML engineers, и кандидатов нет, и я пытался продать идею про крутых специалистов за океаном (и идея им понравилась и бизнес готов был рассмотреть кандидатов), то все обломалось из-за отсутствия квоты на H1B. Поэтому если у вас есть Кандидатская и вы крутой специалист, то можно попробовать пройти процесс.
Интересное интервью с CEO QuantumBlack о начале их пути, о аналитики и ценности для бизнеса. QB начинали с F1, собирали данные и оптимизировали траекторию машин, время на пит стопе и тп. Стали экспертами в этой области. Их приобрел McKinsey, и теперь они работают вместе, MK выступает как subject matter expert в бизнес процессах, QB выполняет работу связанную с аналитикой и инжинирингом данных. Много хороших идей в статье, про роль аналитики для организации.
Frontier Enterprise
CEO vision: QuantumBlack's journey from F1 to the enterprise | Frontier Enterprise
QuantumBlack began its operations as a data analytics company focusing on the domain of Formula 1 racing — from car design and testing, to measuring precise locations of cars on the race track within centimetres, and pit stop duration to milliseconds. It…
Если вы еще не видели новый ролик Гугл про 50 лет годовщину высадки на луну, https://youtu.be/t6VpHyKXHBM
YouTube
50th Anniversary of the Moon Landing (English)
50 years ago, NASA’s Apollo 11 mission changed our world and ideas of what is possible by successfully landing humans on the surface of the moon—and bringing them home safely—for the first time in history. Today’s video Doodle celebrates this moment of…
Хотел поделиться небольшой новостью, Rock Your Data попала в список ТОП 20 аналитических компаний - "20 BIG DATA CONSULTING FIRMS THAT THRIVE ON INFORMATION OVERLOAD", среди компаний Slalom, Boston Consulting Group и другие серьезные ребята. И мы единственная компания из Канады в списке. Радует то, что нам прислал ссылку вендор. В описание вообще забавно - "Azure Glue or Prep", должно быть "Azure Data Prep or AWS Glue", но сойдет, чтобы клиентам рассказывать.
Может быть мы не супер большая консалтинговая компания, но маркетинг у нас на высоте и движемся мы в нужном направлении.
Еще есть одна история интересная, называется "Как получить млн долларов от Китайских инвесторов и открыть офис в Китае", меня она даже пугает немного, насколько там все стремительно. Если у вас есть аналитический продукт (аналитическая дата платформа), то можно обсудить. Я отдельно расскажу как-нибудь, когда придем к какому-то решения с Китайскими партнерами.
А еще я проведу следующий месяц в Бостоне в офисе Amazon Alexa, буду тут набираться знаний, говорят тут самые умные люди в Бостоне в Северной Америке. Узнаю как там нужно делать маркетинговую аналитику для умной микроволновки.
Может быть мы не супер большая консалтинговая компания, но маркетинг у нас на высоте и движемся мы в нужном направлении.
Еще есть одна история интересная, называется "Как получить млн долларов от Китайских инвесторов и открыть офис в Китае", меня она даже пугает немного, насколько там все стремительно. Если у вас есть аналитический продукт (аналитическая дата платформа), то можно обсудить. Я отдельно расскажу как-нибудь, когда придем к какому-то решения с Китайскими партнерами.
А еще я проведу следующий месяц в Бостоне в офисе Amazon Alexa, буду тут набираться знаний, говорят тут самые умные люди в Бостоне в Северной Америке. Узнаю как там нужно делать маркетинговую аналитику для умной микроволновки.
Built In
20 Big Data Consulting Firms To Know | Built In
The big data era is here, and these 20 consulting firms are helping the business world make sense of it all.
Когда мы работаем с облачными сервисами, то у нас есть возможность использовать различные типы сервисов (Iaas, Paas, Saas). Я раньше скидывал хороший пример Pizza as Service, на котором видно в чем разница. Один из самых популярных сервисов на AWS - это Lambda функции.
Идея простая. Например, нам нужно выполнить код. Обычно мы создаем виртуальную машину, используем крон (утилита на линукс, чтобы выполнять задачки по расписанию), чтобы запускать наш код по расписанию. Вместо этого, мы можем поместь наш код в Лямбду, и она будет выполнять его по необходимости, то есть
1)Мы экономим, нам не нужно использовать виртуальную машину
2)Мы повышаем устойчивость, так как возможность сбоя виртуальной машины и других компонентов достаточно велика, а если у нас еще много сложных взаимосвязий, то все легко может поломаться.
3)Решение может легко масштабироваться, потому что это сервис, который менеджиться AWS, мы только платим за использование.
Когда создают решение на AWS, очень часто используют Лямбду, для выполнения блоков кода.
Есть понятие Monolithic vs. Microservices Architecture, то есть архитектура нашего решения монолитная или распределенная. Это используется не только для разработки ПО, но и для аналитики. Идея простая, мы хотим иметь независимые элементы системы, которые работают автономно, чтобы повысить производительно и стабильность решения. Особенно удобно для задач ML.
Я пока не использую этот подход, но это важный навык для инженера данных. Из простых примеров - у меня есть Redshift Data Warehouse, для его успешной работы мне нужно собирать статистику таблиц. Я могу использовать вирутальную машину и поставить скрипт на расписание, а могу использовать Лямбду и она будет выполнять мой скрипт по сбору статистики. Таким образом, мне не нужна дополнительная виртуальная машина.
Идея простая. Например, нам нужно выполнить код. Обычно мы создаем виртуальную машину, используем крон (утилита на линукс, чтобы выполнять задачки по расписанию), чтобы запускать наш код по расписанию. Вместо этого, мы можем поместь наш код в Лямбду, и она будет выполнять его по необходимости, то есть
1)Мы экономим, нам не нужно использовать виртуальную машину
2)Мы повышаем устойчивость, так как возможность сбоя виртуальной машины и других компонентов достаточно велика, а если у нас еще много сложных взаимосвязий, то все легко может поломаться.
3)Решение может легко масштабироваться, потому что это сервис, который менеджиться AWS, мы только платим за использование.
Когда создают решение на AWS, очень часто используют Лямбду, для выполнения блоков кода.
Есть понятие Monolithic vs. Microservices Architecture, то есть архитектура нашего решения монолитная или распределенная. Это используется не только для разработки ПО, но и для аналитики. Идея простая, мы хотим иметь независимые элементы системы, которые работают автономно, чтобы повысить производительно и стабильность решения. Особенно удобно для задач ML.
Я пока не использую этот подход, но это важный навык для инженера данных. Из простых примеров - у меня есть Redshift Data Warehouse, для его успешной работы мне нужно собирать статистику таблиц. Я могу использовать вирутальную машину и поставить скрипт на расписание, а могу использовать Лямбду и она будет выполнять мой скрипт по сбору статистики. Таким образом, мне не нужна дополнительная виртуальная машина.
20 августа будет вебинар по Qlik, https://events.webinar.ru/novobi/qlik# Qlik - это одно из BI решений, такое же как Tableau, Power BI. Конечно они все разные. Я работал с Qlik только один раз, это было полностью кастомизированное решение на скриптах Qlik, которое включало в себя элементы ETL/DW, было не просто. Если что, то я за Tableau. Но всегда не плохо узнать про другие продукты и способы их пременения, особенно, если вы работаете с аналитикой и данными.
Zappos - это дочернее предприятие Амазон, находиться в Лас Вегасе. Очень успешные и креативные. Это интеренет магазин обуви, у них супер культура. и они практикуют holacracy А статья про их недавний проект https://venturebeat.com/2019/07/17/zappos-lead-data-scientist-on-the-challenges-of-using-semantic-search/
VentureBeat
Zappos lead data scientist on the challenges of using semantic search
At Transform 2019 in San Francisco, Zappos lead data scientist Ameen Kazerouni talked about how his team successfully implemented semantic search.
Небольшой ролик про девайсы AWS и автомобиль для транспортировки данных в облака. А вы как думали, можно загрузить несколько петабайтов в облако?
YouTube
How Amazon Uses Explosive-Resistant Devices To Transfer Data To AWS
Demand for cloud computing from providers like Amazon Web Services continues to rise from both companies and consumers that rely on remote storage and computing power accessible from anywhere. While other tech giants Google, Microsoft, and IBM are vying to…
👍1
Всем знают, что обычно при создании хранилищ данных, нужно подумать о модели данных. Есть много вариантов - Dimensional Modelling via Kimball, 3rd Normal Form via Inmon, Data Vault and so on. На собеседованиях часто спрашивают в чем разница и какие техники существуют. Вот одна из статей на эту тему.
С другой стороны, бизнесу нужен результат здесь и сейчас, у них нет времени ждать пока вы создадите нужную модель данных. И часто, все модели вообще игнорируются, и это не смертельно. Если вы смоглы помочь бизнесу быстро получить результат, это намного лучше, чем согласовывать модель данных несколько месяцев. Опасность в том, что нет модели = нет порядка, вы создаете хаус внутри хранилища, и только вы знаете, где что находится. Так что это такая грань, и вам решать как быть. Я в этой ситуации использую ELT tool Matillion, который помогает мне разрабатывать быстро и включать в работу бизнес пользователей.
Например в Алексе, где я сейчас, именно такая ситуация, за последние несколько лет мой департамент Applied Modelling and Data Science нагородил много кастомных решений, и теперь все хором говорят, что им нужна правильная модель данных, а что в ней должно быть и почему, никто не знает. Ну я могу им рассказывать, как модель данных важна, и мы понимаем друг друга с полу слова😆 Так же у другой команды есть Redshift кластер, в котором 128 нод, это максимально возможный кластер и он не справляется с объемом и кол-вом запросов. И в этой ситуации решение - это микс хранилища данных и озера данных, то есть уйти от реляционной модели данных, где есть в этом необходимость. Что в принципе и сделал Amazon.com в течение последних трех лет под названием проекта Rolling Stone. Все реляционные базы данных Оракл были заменены на AWS DynamoDB (NoSQL).
И последнее, про модели данных. Как правило, когда мы говорим о модели данных, мы подразумиваем релационную модель данных (Schema on Write), то есть у нас есть система источник, база данных с таблицами, и таргет, хранилище данных с таблицами, с помощью ETL/ELT мы загружаем данные ИЗ сорса В таргет. Если у нас, в таблице в системе источнике добавится столбец, или поменяется тип данных, то все сломается, так как данные изменились, а схема нет. Поэтому есть альтернатива - Schema on Read, то есть мы можем обновлять схему каждый раз, когда меняется источник и ничего не сломается. Обычно это в случие неструктурированных данных. Более подробно можно почитать в Snowflake Ebook.
С другой стороны, бизнесу нужен результат здесь и сейчас, у них нет времени ждать пока вы создадите нужную модель данных. И часто, все модели вообще игнорируются, и это не смертельно. Если вы смоглы помочь бизнесу быстро получить результат, это намного лучше, чем согласовывать модель данных несколько месяцев. Опасность в том, что нет модели = нет порядка, вы создаете хаус внутри хранилища, и только вы знаете, где что находится. Так что это такая грань, и вам решать как быть. Я в этой ситуации использую ELT tool Matillion, который помогает мне разрабатывать быстро и включать в работу бизнес пользователей.
Например в Алексе, где я сейчас, именно такая ситуация, за последние несколько лет мой департамент Applied Modelling and Data Science нагородил много кастомных решений, и теперь все хором говорят, что им нужна правильная модель данных, а что в ней должно быть и почему, никто не знает. Ну я могу им рассказывать, как модель данных важна, и мы понимаем друг друга с полу слова😆 Так же у другой команды есть Redshift кластер, в котором 128 нод, это максимально возможный кластер и он не справляется с объемом и кол-вом запросов. И в этой ситуации решение - это микс хранилища данных и озера данных, то есть уйти от реляционной модели данных, где есть в этом необходимость. Что в принципе и сделал Amazon.com в течение последних трех лет под названием проекта Rolling Stone. Все реляционные базы данных Оракл были заменены на AWS DynamoDB (NoSQL).
И последнее, про модели данных. Как правило, когда мы говорим о модели данных, мы подразумиваем релационную модель данных (Schema on Write), то есть у нас есть система источник, база данных с таблицами, и таргет, хранилище данных с таблицами, с помощью ETL/ELT мы загружаем данные ИЗ сорса В таргет. Если у нас, в таблице в системе источнике добавится столбец, или поменяется тип данных, то все сломается, так как данные изменились, а схема нет. Поэтому есть альтернатива - Schema on Read, то есть мы можем обновлять схему каждый раз, когда меняется источник и ничего не сломается. Обычно это в случие неструктурированных данных. Более подробно можно почитать в Snowflake Ebook.