Google за три года мощно вырастил штат сотрудников, до 187 000 человек. В Сбербанке, например, работает на треть больше. Но найм очень неравномерный. Можно сделать вывод про приоритеты компании. Продажи, облака, и ещё раз продажи!

BigQuery и другие аналитические хранилища в сочетании с современными BI инструментами перевернули работу с данными за последние годы. Возможность обрабатывать терабайты информации за секунды, интерактивные дашборды в DataStudio и PowerBI, сделали работу очень комфортной.

Однако если посмотреть глубже, можно увидеть - выиграли от этих изменений в основном профессионалы, владеющие SQL и Python и бизнес пользователи на руководящих позициях, для которых разрабатываются дашборды.
А как быть с сотнями миллионов сотрудников, для которых главным инструментом анализа был и остается Microsoft Excel?

Привет Хабр!

Недавно я был на одном интересном воркшопе от компании iTechArt и хотел бы сегодня поделится тем, что мы там делали, а точнее писали CD Pipeline с интеграцией Docker, Kubernetes и Jenkins в Google Cloud (GCE/GKE).

Как быть, если случайно удалил или повредил таблицу в BigQuery? Первое о чем нужно помнить: BigQuery хранит состояние вашей существующей таблицы на любой момент времени в течение прошедших 7 дней + у вас есть 2 суток, чтобы восстановить случайно удаленную таблицу. Рассмотрим, как это все провернуть.

Я уже много лет пользуюсь Гугл календарём и Гугл контактами и единственная вещь которая мне не нравится это отдельный календарь, который не отображает возраст, а показывает только сам факт дня рождения. Ещё в 2019 году я написал скрипт, который решает эту проблему, но прошло 3 года и с помощью одного из читателей Хабра мы добавили склонения слов на русском языке при обозначения возраста и ещё несколько технических функций.

А ещё обновили похожий скрипт для детей: это когда каждый месяц скрипт автоматически создаёт событие в Гугл календаре, в заголовке к которому указано сколько исполнилось годов и месяцев вашему малышу (работает с самого рождения, 0 лет), а в описании указан возраст (годы и месяцы) каждого из родителей. Я сам обычно не помню даты и эти скрипты стали для меня настоящим спасением. 

Эта статья не будет технически глубокой. Мы поговорим о Data Lake и Data Warehouse, важных принципах, которые следует учитывать, и о том, какие сервисы GCP можно использовать для создания такой системы. Мы коснёмся каждого из GCP сервисов и поймём почему они будут полезны при создании Data Lake и Warehouse.

Прежде чем перейти к своей версии Data Lake и Data Warehouse, я хотел бы привести несколько известных архитектур, с которыми вы, возможно, уже знакомы, если интересуетесь этой темой. Архитектура, которую я бы предложил, будет более общей, чем эти: Cloud Storage as a data lake и Architecture: Marketing Data Warehouse.

В своей более общей версии Data Lake и Data Warehouse я расскажу о таких сервисах GCP, как Data Transfer Service, Dataproc, Cloud Storage, Cloud Scheduler, BigQuery, и Cloud SQL.

В этой статье рассмотрим использование компилятора для js-кода облачных функций.

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

Google Maps API — это набор интерфейсов прикладного программирования, который позволяет клиенту взаимодействовать с интегрированными сервисами. Это дает возможность создавать простые приложения для более сложных программных решений на основе местоположения для Интернета, iOS и Android.

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

Осенью 2021 года я задумался о бесплатных инструментах аналитики и построения отчетности, доступных простым пользователям. В том или ином виде можно использовать Power BI или Tableau, но почему бы не попробовать что-то более простое? 

Небольшой дисклеймер: датасет, о котором далее пойдет речь, был загружен осенью 2021 года. Сейчас датасет другой, возможно более чистый. Загружать новые данные счел нерациональным, поскольку серия постов будет про простейшие визуализации, а не про актуальные исследования или сложные диаграммы. И нет, это не подробная методичка по возможностям GDS, это только общий обзор решения и разбор одного кейса.

Нас интересует только сторона работы обычного аналитика, насколько это возможно (и насколько я себе это представляю), поэтому я буду стараться искать самые простые пути решения проблемы. Понимаю, что некоторые методы вроде использования промежуточной базы данных не выглядят простыми для кого-то, но с тем же успехом можно использовать таблицы от Google. У меня БД просто была под рукой, да и выстроить полноценный ETL-процесс без неё не выйдет. 

Это вторая часть статьи про голосового помощника. Первую часть можно наути тут.

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

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

Как работают популярные счетчики веб или мобильной аналитики, например, Google Analytics или AppsFlyer? На сайт устанавливаются их коды или в приложение интегрируется мобильное SDK. Потом при каждом действии клиента отправляется http запрос на сервер аналитики.

У использования стандартных счетчиков/пикселей есть минусы:

• некоторые посетители используют анонимайзеры, которые блокируют такие запросы;

• их сложно кастомизировать под себя.

В этой статье мы напишем собственный простой счетчик, который будет решать эти проблемы. Встроим его в PowerBI отчеты. Но принцип одинаков, его можно будет использовать и на веб-сайте, и в приложении, и в других  устройствах с доступом к интернету. Попробуем две точки сбора событий, чтобы изучить больше технологий: Google Cloud Function, которая будет писать события в Google BigQuery, и Amazon Lambda Functions с записью событий в Snowflake.

В нашей компании (GFN.ru) мы очень сильно опираемся на данные. По каждой игровой сессии мы анализируем десятки параметров. Постройка и содержание системы метрик и алертов - очень затратная вещь и со временем ее поддержка становится трудоемкой и появляется риск забивания. С помощью ML мы решили эту проблему.

Про colab знают, наверное, все. Этот инструмент позволяет независимым исследователям использовать облачную инфраструктуру с GPU и TPU бесплатно или почти бесплатно.

Как всегда, проблемы возникают на больших данных. Если ваш датасэт лежит в google drive (он же Диск), то вы можете обращаться к нему напрямую из colab. Однако, если файл велик, например, 70+ GiB, то процесс обучения будет существенно медленнее, чем если бы этот же файл лежал в локальном хранилище, которое выделяется при создании инстанса.

Выход - скопировать файл с Диска в локальное хранилище (обучение станет быстрее в несколько раз!). Но дело в том, что colab и вся инфраструктура очень умная, файлы с Диска кэшируются каким то неуправляемым вами алгоритмом. И если у вашего инстанса, допустим, доступно ~120 GiB, то 70 GiB с Диска вы не скопируете, у вас закончится свободное место как раз из-за системы кэширования. То есть, команда cp не отработает корректно. И rsync то же. И tar. Кэширование работает на уровне драйвера. По сути файл копируется в локальное хранилище дважды. Шах и мат!

Так что вот вам небольшой костылёк:

Рассмотрим задачу хостинга статичного веб-сайта, например, Leaflet карты с заранее посчитанными данными на ней или статичной 3D модели. Для этих целей можно воспользоваться статическим хостингом файлов на Google Cloud Storage. Кроме того, этот способ позволяет весьма просто ограничить доступ к сайту в веб-интерфейсе Google Cloud, указывая емайлы пользователей, которым доступ разрешен. За счет Google CDN и кэширования файлов можно не беспокоиться об обработке большой нагрузки, а добавление или удаление файлов доступно с помощью консольной утилиты gsutil и в веб-интерфейсе Google Cloud. Также не нужно заниматься получением и обновлением SSL сертификатов и созданием для них доменных имен. Буквально в несколько консольных команд получается масштабируемое и легко поддерживаемое решение с хранением данных в облаке Google и гарантией защиты данных.

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

Что мы имели и о чем вообще речь? А имели мы стартап-проект с примерно 2-летней историей разработки из advertisement  области. Проект изначально строился как микросервисный, и серверная его часть написана на Symfony + немного Laravel, Django и нативного NodeJs. Сервисы представляют из себя в основном API для мобильных клиентов (их в проекте 3) и нашего собственного SDK для IOS (встраивается в приложения наших кастомеров), а также веб-интерфейсы и разные дашборды этих самых кастомеров. Все сервисы были изначально докеризированы и работали под управлением docker-compose.

Правда, docker-compose использовался не везде, а только в локальном окружении у разработчиков, на тестовом сервере и внутри pipeline при сборке и тестировании сервисов. А вот в production окружении использовался Google Kubernetes Engine (GKE). Причем настройку GKE на старте проекта мы делали полностью через его web-интерфейс, что было довольно быстро и, как нам тогда казалось, удобно. Автоматизирован тут был только процесс сборки docker images для запуска сервисов в GKE.

Развёртывание в Kubernetes из GitLab

Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.

А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.

Желательны но необязательны базовые знания

• Docker;
• Kubernetes;
• Git;
• Node.js;
• React;
• Bash.

В дальнейшем мы сделаем следующее.

• 🧱 Познакомимся c нашим приложением, обсудим из чего оно состоит.
• 🐳 Докеризуем наше приложение.
• ☸️ Развернём наше приложение в Kubernetes локально на Docker Desktop.
• ☁️ Обсудим особенности GCP и как нужно изменить наше приложение, а затем ещё раз развернём наше приложение в Kubernetes но уже в GCP.
• 🦊 Завершим наш туториал созданием конвейера для развертывания приложения в GCP при помощи GitLab.

We are programmed to receive
You can check out any time you like
But you can never leave!