Armazenar, catalogar e processar grandes quantidades de dados exigem novas ferramentas e novos processos.
Nesta apresentação, mostraremos o conceito (e a prática) de como realizar estas ações de maneira moderna, modular e escalável, utilizando um Data Lake e a Arquitetura Lambda.
Palestra realizada no:
-GDG Datafest (Campinas-SP) 2019
Uma arquitetura de Big Data costuma possuir várias camadas específicas, cada uma com uma função diferente.
De maneira geral, as camadas são:
– Entrada do pedido
– Orquestração
– Processamento
– Predição
– Retorno da informação
Nesta apresentação, trazemos uma jornada de análise de arquiteturas serverless para se utilizar com um micro-serviço de machine learning.
Analisamos vários pontos, mostrando os prós e contras de cada solução.
Como operar um ambiente de Big Data em Multi-Cloud? E como fazer este ambiente servir a diversos propósitos, seja para um BI, para um trabalho de Análise e Mineração de Dados ou para alimentar a criação de Modelos de Machine Learning?
Aprenda como a AME Digital resolveu este problema neste webinar da campdata: https://www.youtube.com/channel/UCePbMP6CDVtRVkTon3USpRg
Aproveite!
Você sabe o que é DataOps?
Acredito que ainda não exista uma definição formal.
Mas a comunidade de Data tem sedimentado este conceito com competências que envolvem:
-DevOps (version control, CI, CD, etc)
-Data Governance (data lineage, reproducibilidade, LGPD, etc)
-Data Quality (monitoramento, tratamento, etc)
-Data Pipeline (monitoramento, evolução, testes, etc)
-Dentre outros
Para me aprofundar no assunto, recebi a indicação do “The DataOps Cookbook”. Recomendo a leitura!
Link: https://datakitchen.io/content/DataKitchen_dataops_cookbook.pdf
Quem trabalha com geolocalização já deve ter ouvido falar do Postgis.
Ele é um framework muito robusto e usado por diversas empresas de classe global ao redor do mundo.
Para realizar usa instalação, porém, o caminho pode ser tortuoso. Principalmente se você quiser instalar via código-fonte.
Abaixo segue uma receita de como fazer isso em um CentOS 7.
Receita:
INSTALANDO O POSTGRES
cd /usr/local/src
wget https://ftp.postgresql.org/pub/source/v12.3/postgresql-12.3.tar.gz
tar zxf postgresql-12.3.tar.gz
cd postgresql-12.3/
yum groupinstall “Development Tools”
yum install readline-devel libxml2-devel openssl-devel
./configure –prefix=/usr/local/pgsql-12.3 –with-openssl –with-libxml –without-ldap
make -j16
make install
cd /usr/local
ln -s pgsql-12.3/ pgsql
vi /etc/profile.d/postgresql.sh
export PATH=/usr/local/pgsql/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/pgsql/lib:$LD_LIBRARY_PATH
export PGDATA=/pasta/pgdata
source /etc/profile.d/postgresql.sh
cd /usr/local/src/postgresql-12.3/contrib/
make -j10
make install
cd start-scripts/
cp linux /etc/init.d/postgresql
chmod +x /etc/init.d/postgresql
chkconfig postgresql on
vi /etc/init.d/postgresql
PGDATA=/pasta/pgdata
useradd –system –user-group –create-home –comment “PostgreSQL Admin User” –shell /bin/bash postgres
mkdir -p $PGDATA
chown -R postgres. /dados/
chmod -R 700 /dados/pgdata
su – postgres
chmod 700 $PGDATA
cd $PGDATA
initdb -E utf8 –locale=pt_BR.utf-8 -D $PGDATA
ROOT:
/etc/init.d/postgresql start
INICIANDO INSTALAÇÃO DO POSTGIS
cd /usr/local/src
wget https://download.osgeo.org/postgis/source/postgis-3.0.1.tar.gzyum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum install epel-release-latest-7.noarch.rpm
INSTALANDO BIBLIOTECAS POSTGIS
yum –showduplicates list geos | expand
yum install geos38.x86_64 geos38-devel.x86_64
yum install proj proj-devel
yum install gdal gdal-devel
yum install cmake
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/json-c-devel-0.11-4.el7_0.x86_64.rpm
sudo yum install json-c-devel-0.11-4.el7_0.x86_64.rpm
wget https://github.com/protobuf-c/protobuf-c/releases/download/v1.1.1/protobuf-c-1.1.1.tar.gz
tar zxf protobuf-c-1.1.1.tar.gz
wget https://github.com/protocolbuffers/protobuf/releases/download/v2.6.0/protobuf-2.6.0.tar.gz
tar zxf protobuf-2.6.0.tar.gz
cd protobuf-2.6.0/
./autogen.sh
./configure
make
make install
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
cd ../protobuf-c-1.1.1/
./configure
make
make install
FINALMENTE INSTALANDO O POSTGIS
cd ../
tar zxf postgis-3.0.1.tar.gz
cd postgis-3.0.1/
make clean SE FOR DA SEGUNDA VEZ EM DIANTE
./configure –with-geosconfig=/usr/geos38/bin/geos-config
make
make install
reiniciar pg
/etc/init.d/postgresql stop
/etc/init.d/postgresql start
TESTANDO O POSTGIS
psql -U postgres
create extension postgis;
SELECT encode(ST_AsGeobuf(q, ‘geom’), ‘base64’) FROM (SELECT ST_GeomFromText(‘POLYGON((0 0,0 1,1 1,1 0,0 0))’) AS geom) AS q;
OUTRAS BIBLIOTECAS:
PG_CRON
wget https://github.com/citusdata/pg_cron/archive/master.zip
mv master.zip pg_cron-master.zip
unzip pg_cron-master.zip
cd pg_cron-master/
make
make install
postgresql.conf
shared_preload_libraries = ‘pg_cron’
cron.database_name = ‘postgres’
reiniciar pg
/etc/init.d/postgresql stop
/etc/init.d/postgresql start
ORACLE_FDW
rpm -i oracle-instantclient19.5-basic-19.5.0.0.0-1.x86_64.rpm
rpm -i oracle-instantclient19.5-devel-19.5.0.0.0-1.x86_64.rpm
rpm -i oracle-instantclient19.5-tools-19.5.0.0.0-1.x86_64.rpm
wget https://github.com/laurenz/oracle_fdw/archive/master.zip
mv master.zip oracle_fdw.zip
unzip oracle_fdw.zip
cd oracle_fdw-master/
ls -l /usr/include/oracle/
OPCAO 1
cp Makefile orig_makefile
sed -i ‘s/19.6/19.5/g’ Makefile
OPCAO 2:
Add the following to Makefile yourself:
To PG_CPPFLAGS add -I/usr/include/oracle/XX.X/client64, and to SHLIB_LINK add -L/usr/lib/oracle/XX.X/client64/lib.
make
make install
TDS-FDW (SQL SERVER)
sudo yum install epel-release
sudo yum install freetds-devel
sudo yum install centos-release-scl
sudo yum install llvm-toolset-7-clang llvm5.0
yum install git
cd /usr/local/src
git clone https://github.com/tds-fdw/tds_fdw.git
cd tds_fdw
make USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_config
sudo make USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_config install
Existem diversos padrões de de arquitetura para Big Data e Data Pipelines.
Uma delas é a Arquitetura Lambda. Ela permite que um mesmo dado seja processado em real time para visualização rápida, ao mesmo tempo em que este dado vai para uma área de dados históricos, onde será processado de outras maneiras.
Nesta palestra demonstramos como construir uma Arquitetura Lambda na prática na Amazon Web Services (AWS).
Construir um modelo de Machine Learning é um desafio. Porém, apenas a existência de um modelo, não é o suficiente para criar um produto de dados.
Este modelo precisa ser alocado dentro de uma Arquitetura que conterá um Data Pipeline (responsável por obter e transformar os dados) que por sua vez irá entregar os dados transformados para o modelo de Machine Learning.
Este Data Pipeline envolve uma arquitetura razoavelmente complexa, com diversas tecnologias.
Nesta palestra, focamos em como construir um arquitetura de Data Pipeline na Nuvem, analisando opções concorrentes, com os prós e contras de cada ferramenta presente na Arquitetura.
Trabalhar com Bancos de Dados pode ser um trabalho muito manual e “artesanal”.
Porém, existem ferramentas e processos que podem tornar o trabalho do DBA mais ágil e evolutivo, sem que com isso ele tenha que abrir mão da segurança.
Nesta palestra, propomos maneiras de unir o mundo dos Bancos de Dados ao mundo de Devops. Link: https://www.infoq.com/br/presentations/meu-dna-nao-e-agil-e-agora/
Existem diversas formas de se orquestrar um pipeline de dados. Uma das menos óbvias seja usar o Jenkins para isso, dado que sua função mais conhecida é a de orquestrar deploys de software.
Porém, com os plugins corretos, é possível construir um data pipeline robusto e de fácil gerenciamento, dado que quase tudo pode ser feito via interface gráfica na web.
Tive o prazer de fazer uma palestra no SPIN Campinas sobre este assunto, o tema do encontro era DevOps.
O nome da palestra é: “Automação de infraestrutura utilizando o Jenkins”.
Link para os slides: http://pt.slideshare.net/FelipeSantos292/automatizao-de-infraestrutura-com-jenkins
O PgBouncer se define como um “pool de conexões leve para PostgreSQL” (site do projeto aqui).
Seu primeiro release púbico, a versão 1.0, ocorreu em Março de 2007. Atualmente ele possui versões para Windows e Linux (código-fonte e instruções para instalação aqui).
A principal função do PgBouncer é ser um pool de conexões.
O conceito geral é bastante simples: os clientes (usuários e sistemas) apontam suas connection strings para o IP/Porta do PgBouncer, usando um usuário especificamente criado para esta conexão (que pode ou não ser o mesmo do banco de dados), eles são introduzidos em uma fila e esta fila é executada pelo banco de dados através de uma conexão entre o pool e o banco de dados.
Até aqui nenhuma novidade, afinal, esta é a forma como o sistema se conectaria ao banco de dados de maneira geral. Os benefícios desta arquitetura começam com os parâmetros de gerenciamento de conexões oferecidos pelo PgBouncer, dentre eles:
Pool_Mode: Define o modo pelo qual as instruções enviadas pelos clientes são processadas pelo banco de dados. Existem 3 modos:
Session: A conexão entre o pool e o banco de dados só é encerrada quando a sessão do usuário desconecta, é o valor padrão e é o comportamento normal em um banco de dados sem pool de conexões.
Transaction: A conexão é encerrada com o fim de uma transação. É importante lembrar que a conexão entre o cliente final e o pool se mantém, dando a ilusão de conexão ativa, mas o pool, para este cliente em específico, não estará mais conectado ao banco de dados até que uma nova transação se inicie e comece a ser executada. Este comportamento nos ajuda a não manter no banco de dados conexões abertas sem necessidade, visto que cada conexão utiliza recursos que, se não estiverem em uso, poderiam ser melhor utilizados por outras sessões ativas.
Statement: A conexão entre o pool e o banco de dados se encerra após a execução de um statement, ou seja, de um comando qualquer. Este tipo de configuração acaba impedindo a execução de transações, esta opção é recomendada com cautela.
Max_Client_Conn: Define o número máximo de pessoas que podem se conectar ao pool de conexões. Não confundir com a quantidade de conexões efetivamente abertas entre o pool e o banco de dados.
Default_Pool_Size: O tamanho padrão do pool para cada combinação usuário/banco de dados. Pode ser sobrescrita na configuração individual do banco de dados. Este é o valor máximo de conexões que serão abertas pelo pool para executar queries no banco de dados, dentro do modo de pool escolhido em Pool_Mode.
Min_Pool_Size: Este é um parâmetro interessante. Como abrir uma conexão com o banco de dados pode ser algo custoso, você pode definir um mínimo de conexões abertas entre o pool e o banco de dados, e estas ficaram abertas, mesmo que em idle, para que quando uma nova solicitação de execução de query chegar, o pool não tenha o overhead de ter que abrir a conexão.
Server_Check_Delay: O tempo em que uma conexão entre o pool e o banco de dados permanecerá aberta após o fim da execução das queries. Assim como a configuração anterior, esta configuração tenta ajudar a evitar o overhead de criação/destruição de conexões com o banco de dados.
Server_Lifetime: Tempo máximo de uma conexão entre o pool e o banco de dados. Cuidado com esta configuração, este time-out funciona até para conexões ativas. Para matar apenas conexões idle, veja a configuração abaixo.
Server_Idle_Timeout: Tempo máximo em que uma conexão idle será mantida entre o pool e o banco de dados.
Client_Idle_Timeout: Desta vez estamos falando da conexão entre o cliente/usuário e o pool de conexões. As conexões com mais do que este tempo em estado idle serão mortas.
Idle_Transcation_Timeout: O mesmo que o parâmetro anterior, porém para conexões no estado “Idle in Transaction”.
Estas são algumas das configurações disponíveis no PgBouncer e que tornam a conexão através do pool melhor gerenciável do que as feitas diretamente entre o cliente e o banco de dados.
Outro ponto importante é a Segurança. Você pode criar um usuário específico para que todos os clientes possam se autenticar no banco de dados, porém, este usuário não precisa ter nenhum privilégio no banco de dados. Desta forma, você pode distribuir este usuário/senha para seus clientes internos e externos e estes apenas poderão se conectar ao banco de dados através do pool de conexões, com todas as regras aplicadas. Outro ponto importante é que a conexão entre o pool e o banco de dados é feita por uma connection string interna, escondendo do usuário final o usuário que realmente está se conectando à base de dados. Desta forma ele não terá acesso a esta informação.
Este recurso é particularmente importante pois, infelizmente, muitos clientes distribuem a senha do super usuário Postgres para todos os sistemas e clientes internos, dando acessos desnecessários à todo o cluster, ao inveś de fechar os privilégios por banco de dados. Através desta técnica do PgBouncer, você pode alterar os usuários e privilégios da conexão com o banco de dados sem ter que informar seus clientes finais, que continuarão usando o usuário de conexão ao pool.
Por fim, mas não menos importante, é a habilidade do pool em realizar o failover de um cluster de banco de dados. O PostgreSQL nos dá, nativamente, a capacidade de replicar o banco de dados principal para um ou mais bancos de dados secundários, que podem ficar disponíveis apenas para leitura. No caso de falha do servidor primário, o servidor secundário pode ser promovido a primário e continuar a servir os sistemas e clientes.
Em uma conexão direta ao banco de dados, os sistemas e clientes teriam que refazer a connection string, ou a equipe de infraestrutura teria que ter a capacidade de alterar o DNS/IP das máquinas, fazendo com que os clientes acessem o secundário através do IP que antes pertencia ao primário. Esta técnica é muito utilizado e possui um downtime relativamente baixo, provavelmente de alguns minutos dependendo das condições e equipes envolvidas.
Com o PgBouncer, basta alterar a configuração interna para que a connection string do antigo secundário seja agora a do primário. Esta alteração requer um reload da configuração e o processo todo pode ser realizado em alguns segundos, sem que os usuários tenham que se reconectar à base de dados. Obviamente, aqueles usuários que estavam executando uma transação no momento da queda, perceberão a queda, porém os que estavam apenas conectados, estavam apenas conectados ao pool e desta forma, ao enviar uma nova query, ela será direcionada para o novo primário, sem que o cliente final perceba o failover.
Todo este processo diminui drasticamente o downtime do serviço, aumentando o SLA como um todo.
Com isso, indicamos o uso do PgBouncer em seu ambiente para que você possa usufruir de todos estes benefícios!
Veja uma palestra completa sobre o assunto em: https://www.infoq.com/br/presentations/pgbouncer-pool-seguranca-e-disaster