Web scraping orquestrado

2019-05-14 · Caio Lente

O objetivo principal do pacote Kuber é ajudar com computações massivamente paralelas. Ele usa o kubernetes e o docker de modo a criar um contêiner que automaticamente executa tarefas em paralelo via expansão. Se você já usa o Google Cloud Platform, o Kuber também consegue automaticamente criar clusters, executar computações e gerenciar o seu progresso com o Google cloud SDK.

Se você nunca ouviu falar sobre orquestração de contêineres, armazenamento persistente na nuvem ou computação paralela, pode ser que esse tutorial pareça avançado demais. Você não precisa ser nenhum especialista nesses assuntos, mas ajuda pelo menos saber o que significam esses termos.

Esse tutorial vai te ajudar a criar a sua primeira tarefa do Kuber. Antes de começar, certifique-se de que você instalou todos os requisitos corretamente com a vignette “Getting started”

A tarefa em si

A principal vantagem do Kuber em relação a outros pacotes de paralelização (como Parallel ou Future/Furrr) é que ele automaticamente cria um cluster de computadores que executa a sua tarefa via orquestração de contêineres. Isso pode ser muito útil para web scraping, por exemplo, porque (1) cada máquina tem um IP diferente, (2) salvar os HTMLs raspados é fácil com o Google Cloud Storage e (3) o processo pode ser facilmente ativado/desativado a qualquer momento.

Neste tutorial a função a ser paralelizada é a seguinte:

# Scrapear um vetor de caracteres de URLs
scrape_urls <- function(urls) {

  # Criar um diretório
  dir <- fs::dir_create("scraped")

  # Iterar nos URLs
  paths <- c()
  for (url in urls) {
    path <- paste0(dir, "/", stringr::str_remove_all(url, "[^a-z]"), ".html")
    paths <- append(paths, path)

    httr::GET(url, httr::write_disk(path, overwrite = TRUE))
  }

  return(paths)
}

Em suma, essa função recebe um vetor de URLs, os raspa e salva os HTMLs resultantes em um diretório local.

Criando o cluster

Agora para o Kuber. Se tudo estiver instalado corretamente, você deveria ser capaz de criar um cluster simples com o seguinte comando:

library(kuber)

kub_create_cluster("toy-cluster", machine_type = "f1-micro")
#> ✔  Creating cluster

Vá para o Kubernetes console para ver se tudo funcionou corretamente. Não se preocupe se você receber um monte de alertas, a maioria deles é referente à versão do SDK.

Criando a tarefa

A função mais importante do Kuber provavelmente é a próxima. Ela cria um diretório na sua máquina local que descreve a computação paralela e seus cluster, pacote, imagem e conta de serviço. Para executar o comando abaixo, apenas toy-key.json (a chave da conta de serviço baixada na vignette “Getting started”) já precisa existir no caminho indicado; o resto é todo criado para você.

kub_create_task("~/toy-dir", "toy-cluster", "toy-bucket", "toy-image", "~/toy-key.json")
#> ✔  Fetching cluster information
#> ✔  Fetching bucket information
#> ✔  Creating bucket
#> ●  Edit `~/toy-dir/exec.R`
#> ●  Create `~/toy-dir/list.rds` with usable parameters
#> ●  Run `kub_push_task("~/toy-dir")`

Editando o exec.R e o list.rds

O diretório criado por kub_create_task() tem alguns arquivos que são explorados em detalhe na documentação da própria função, mas os dois mais importantes são exec.R e list.rds. O primeiro contém o arquivo R a ser executado pela imagem docker, enquanto o segundo tem todos os objetos que cada máquina precisa para rodar o seu próprio exec.R.

Começando pelo exec.R, o arquivo já está populado com um exemplo simples:

#!/usr/bin/env Rscript
args <- commandArgs(trailingOnly = TRUE)

# Arguments
idx <- as.numeric(args[1])
bucket <- as.character(args[2])

# Use this function to save your results
save_path <- function(path) {
  system(paste0("gsutil cp -r ", file_, " gs://", bucket, "/", gsub("/.+", "", file_)))
  do.call(file.remove, list(list.files(path, full.names = TRUE)))
  return(path)
}

# Get object passed in list[[idx]]
obj <- readRDS("list.rds")[[idx]]

###########################
## INSERT YOUR CODE HERE ##
###########################

Como você pode ver, é um Rscript que recebe dois argumentos: um índice e o nome de um bucket GCS. O código em seguida descreve uma função a ser usada quando salvando os resultados; ela envia o arquivo/diretório no path para o bucket especificado e então o deleta do disco da máquina. Finalmente, o script lê list.rds e seleciona o objeto guardado no índice idx.

Agora é hora de adicionar scrape_urls() para o arquivo. Não há muitas mudanças na função em si, apenas em como os arquivos resultantes são gerenciados. Aqui está a versão final do exec.R:

#!/usr/bin/env Rscript
args <- commandArgs(trailingOnly = TRUE)

# Arguments
idx <- as.numeric(args[1])
bucket <- as.character(args[2])

# Use this function to save your results
save_path <- function(path) {
  system(paste0("gsutil cp -r ", file_, " gs://", bucket, "/", gsub("/.+", "", file_)))
  do.call(file.remove, list(list.files(path, full.names = TRUE)))
  return(path)
}

# Get object passed in list[[idx]]
obj <- readRDS("list.rds")[[idx]]

# Scrapear um vetor de caracteres de URLs
scrape_urls <- function(urls) {

  # Criar um diretório
  dir <- fs::dir_create("scraped")

  # Iterar nos URLs
  paths <- c()
  for (url in urls) {
    path <- paste0(dir, "/", stringr::str_remove_all(url, "[^a-z]"), ".html")
    paths <- append(paths, path)

    httr::GET(url, httr::write_disk(path, overwrite = TRUE))
  }

  return(paths)
}

# Rodar o scraper
paths <- scrape_urls(obj)

# Salvar os HTMLs no GCS
for (path in paths) {
  save_path(path)
}

Como você já pode imaginar pelos chamados acima, obj contém os URLs a serem raspados. Isso faz sentido porque, como descrito anteriormente, list.rds tem todo objeto que cada máquina precisa para seu próprio exec.R; neste caso, cada máquina precisa de um vetor de URLs a serem scrapeados e idx é simplesmente o índice de cada máquina (para que duas máquinas nunca raspem os mesmos URLs). É só isso.

Agora a única coisa que falta é criar o list.rds, ou seja, a lista de URLs quebrada em um bloco para cada máquina. Como neste exemplo toy-cluster foi criado com o número padrão de máquinas (3), list.rds vai ser uma lista com 3 elementos. Os comandos a seguir devem ser rodados na sua máquina local:

# URLs a serem raspados, blocados por máquina
url_list <- list(
  c("google.com", "duckduckgo.com"),
  c("wikipedia.org"),
  c("facebook.com", "twitter.com", "instagram.com")
)

# Sobrescrever o list.rds com a lista de URLs
readr::write_rds(url_list, "~/toy-dir/list.rds")

Com esse list.rds, o primeiro nó vai raspar motores de busca, o segundo vai raspar a Wikipédia e o terceiro vai raspar mídias sociais.

Dando push e executando a tarefa

Por último mas não menos importante, a tarefa deve ser pushada para o Google Container Registry (GCR), que é onde as imagens docker do Kuber vão ficar guardadas. Isso garante controle de versão para todas as tarefas e permitem que elas sejam executadas de outro computador, mas pode levar um bom tempo para rodar da primeira vez que você cria uma tarefa.

kub_push_task("~/toy-dir")
#> ✔  Building image
#> ✔  Authenticating
#> ✔  Pushing image
#> ✔  Removing old jobs
#> ✔  Creating new jobs

Se tudo funcionou até agora, o último comando obrigatório é executar a tarefa:

kub_run_task("~/toy-dir")
#> ✔  Authenticating
#> ✔  Setting cluster context
#> ✔  Creating jobs
#> ●  Run `kub_list_pods()` to follow up on the pods

Gerenciando o progresso da tarefa

A duas formas principais de gerenciar o progresso de uma tarefa: listando os pods atualmente ativos e listando os arquivos guardados em um bucket. As letras estranhas no nome de cada processo é um identificador único gerado pelo Kuber para gerenciar aqueles pods.

kub_list_pods("~/toy-dir")
#> ✔  Setting cluster context
#> ✔  Fetching pods
#>                          NAME READY  STATUS RESTARTS AGE
#> 1 process-mkewsr-item-1-8kpg7   1/1 Running        0  1m
#> 2 process-mkewsr-item-2-cph8z   1/1 Running        0  1m
#> 3 process-mkewsr-item-3-kpn5f   1/1 Running        0  1m

Se o status dos seus pods indicar algo ruim, pode ser que você precise depurar o seu arquivo exec.R. Isso é absolutamente normal e pode ser que sejam necessárias várias tentativas até que a sua tarefa esteja rodando corretamente. Se você precisar de ajuda na depuração da sua tarefa, dê uma olhada na vignette “Debugging exec.R”.

O comando abaixo lista todo arquivo em um bucket. Você também pode especificar o diretório dentro do bucket e se a listagem deve ser feita recursivamente. Aqui é possível ver que todo download terminou de rodar corretamente.

kub_list_bucket("~/toy-dir", folder = "scraped")
#> ✔  Listing content
#> [1] "googlecom.html"     "duckduckgocom.html" "wikipediaorg.html"
#> [4] "facebookcom.html"   "twittercom.html"    "instagramcom.html"

#r #cloud #hpc

Responda a este post por email ↪