Эта статья не будет технически глубокой. Мы поговорим о 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!

Сегодня бо́льшая часть production-решений продолжает резервировать собственные мощности под базы данных. Да, это надёжно и привычно, но тем не менее всё больше проектов обращается к бессерверным инструментам, в том числе и к базам данных. Создатели находят этим инструментам применение в распределённых приложениях и микросервисах, где важна скорость разработки и возможность масштабирования. 

Бессерверные базы данных развивались последние несколько лет параллельно с бессерверными вычислениями, и сейчас можно условно выделить два типа СУБД: адаптирующие популярные базы данных под бессерверное использование и разработанные под бессерверный режим. В этой статье я расскажу об их особенностях и дам примеры применения.

Рассказываем как перестать переживать о том, что вы не знаете Hadoop и вывести работу с данными в компании на новый уровень, как быстро и без больших затрат создать в аналитическое хранилище, наладить процессы загрузки туда данных, дать возможность аналитикам строить отчеты в современных BI инструментах и применять машинное обучение.

В 2020 году Google работал над своевременной и надежной информацией о здоровье, расширял кампании общественного здравоохранения и помогал некоммерческим организациям оперативно оказывать помощь индийцам, которые в этом нуждались. Теперь компания продолжает уделять особое внимание помощи индийским предприятиям в ускорении их цифровой трансформации, углубляя направления оцифровки и восстановлению экономики Индии. Чтобы поддержать клиентов и государственный сектор в Индии и во всем Азиатско-Тихоокеанском регионе, компания с радостью объявляет об открытии нового облачного региона Google в столичном регионе Дели (NCR).

Регион NCR в Дели, призван помочь как индийским, так и международным компаниям создавать высокодоступные приложения для своих клиентов, является вторым облачным регионом Google в Индии и 10-м в Азиатско-Тихоокеанском регионе.

Что говорят клиенты и партнеры Google

В 2020 году компаниям было нелегко ориентироваться в вопросах, связанных с изменчивыми потребностями клиентов и экономической неопределенностью. Технологии сыграли решающую роль, и компании Google посчастливилось сотрудничать с людьми, компаниями и государственными учреждениями по всему миру и помогать им адаптироваться. Регион Google Cloud в NCR в Дели поможет их клиентам адаптироваться к новым требованиям, новым возможностям и новым способам работы, как и Google помог многим компаниям в этом регионе:

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

Сводные таблицы в Excel являются чрезвычайно мощным инструментом, поскольку позволяют быстро изменять форму данных в пару кликов мышки. Например, вам необходимо построить отчёт продаж по магазинам за год, таким образом, что бы в строках были названия магазинов, а в столбцах месяца. Не проблема, кидай в область столбцов сводной таблицы поле месяц, в область строк поле с названием торговых точек, а в поле значение сумму продаж. Отчёт готов.

До недавних пор реализовать такую операцию в SQL было довольно проблематично, но недавно в функционал Google BigQuery была добавлен оператор PIVOT, о нём и пойдёт речь в этой статье.

Несколько несложных примеров того, как на практике можно использовать продвинутые возможности Helm для эффективной организации безупречной continuous delivery в Kubernetes. Полезные рецепты, чтобы поддерживать конфигурации множества тестовых и production сред - удобно, безопасно, без копипасты и приятно на вид. Методы поддержания целостности сред - чтобы "зелёный" статус пайплайна всегда означал удачный деплоймент, а в случае неудачи среда бы сама восстанавливалась.