En el subcapítol anterior vam construir un data lake per analitzar dades emmagatzemades. Però moltes dades arriben en temps real, de forma contínua: clics en una web mentre els usuaris naveguen, lectures de sensors cada segon, transaccions a mesura que ocorren... Com captures i processes aquest flux continu de dades en el moment, sense perdre res? Per això existeix Amazon Kinesis, el servei d’AWS per a dades en temps real (streaming). Veurem els seus dos components principals: Kinesis Data Streams i Kinesis Data Firehose.
El problema: dades que arriben sense parar, ara mateix
Hi ha dades que no arriben «de tant en tant» en arxius, sinó com un raig continu que no para:
Exemples de dades en temps real (streaming): - Clics i navegació de milers d’usuaris en una web (cada segon) - Lectures de sensors d’IoT (temperatura, GPS...) cada segon - Transaccions financeres a mesura que ocorren - Esdeveniments d’una aplicació en viu
Processar això planteja reptes: arriba constantment i en gran volum, no pots perdre dades, i sovint vols reaccionar a l’instant (detectar un frau mentre ocorre, no l’endemà). Necessites alguna cosa capaç de capturar i moure aquest flux continu de manera fiable i escalable.
Què és el processament en streaming
El processament de dades en temps real (streaming) consisteix a capturar i processar les dades a mesura que es generen, de forma contínua, en lloc d’esperar a tenir un lot gran i processar-lo després (el que seria processament «per lots» o batch).
Processament per lots: esperes → ajuntes moltes dades → processes (després) Processament en streaming: les dades arriben → les processes JA (al moment)
Analogia: la diferència és com entre una presa i un riu. El processament per lots és com una presa: acumules l’aigua i la deixes anar de cop cada cert temps. L’streaming és com un riu que flueix sense parar: l’aigua (les dades) passa contínuament i l’aprofites segons flueix. Kinesis és el «llit» preparat per gestionar aquest riu de dades sense que es desbordi ni es perdi.
Què és Kinesis
Amazon Kinesis és la família de serveis d’AWS per capturar, processar i analitzar dades en temps real (streaming) a gran escala. Et permet ingerir fluxos enormes de dades contínues de manera fiable. Té diversos components; veurem els dos principals.
Kinesis Data Streams: el flux en temps real
Kinesis Data Streams captura un flux continu de dades en temps real i el posa a disposició perquè les teves aplicacions el processin a l’instant. Les dades entren al «stream» i els teus consumidors (per exemple, Lambdas, recorda que Kinesis pot ser un trigger de Lambda, subcapítol 14.2) les llegeixen i processen al moment.
Productors (web, sensors...) → Kinesis Data Streams → Consumidors
envien dades sense parar (el flux en viu) processen AL INSTANT
(Lambda, analítica...)- Per a què: quan necessites reaccionar en temps real a les dades (detectar frau a l’instant, alertar d’una anomalia d’un sensor, actualitzar un panell en viu).
- Clau: les dades estan disponibles per processar-se immediatament, amb mínima latència.
Analogia: Kinesis Data Streams és com una cinta transportadora en viu en què van passant les dades, i els teus treballadors (aplicacions) les van agafant i processant a mesura que passen, sense esperar. Ideal quan cada dada importa ara.
Kinesis Data Firehose: carregar el flux en un destí
Kinesis Data Firehose se centra en una altra cosa: recollir un flux de dades i lliurar-lo automàticament en un destí d’emmagatzematge o anàlisi (com S3 —el teu data lake del subcapítol 29.1—, Redshift, etc.), sense que hagis de programar res per gestionar-ho. És la forma més senzilla de carregar dades de streaming en un lloc on guardar-les o analitzar-les.
Productors → Kinesis Data Firehose → lliura automàticament a S3 / Redshift / ... dades contínues (recull i carrega) (el teu data lake, magatzem de dades...)
- Per a què: quan vols portar un flux de dades al teu data lake (S3) o un altre destí de manera automàtica i senzilla, sense necessitat de processar-lo a l’instant.
- Clau: és totalment gestionat i molt fàcil: configures l’origen i el destí, i Firehose s’encarrega de moure les dades (pot fins i tot transformar-les o agrupar-les pel camí).
Analogia: si Data Streams és una cinta transportadora en viu, Firehose (el nom significa «mànega de bomber») és com una mànega que canalitza el raig de dades directament fins al dipòsit (S3). No t’has de preocupar de gestionar la cinta ni els treballadors: només connectes la mànega al dipòsit i les dades hi flueixen automàticament.
Streams vs Firehose: quan cada un
| Kinesis Data Streams | Kinesis Data Firehose | |
|---|---|---|
| Per a què | Processar el flux en temps real | Lliurar el flux a un destí (S3, etc.) |
| Reacció | Immediata (processes al moment) | No immediata (carrega les dades per després) |
| Gestió | Tu programes els consumidors | Totalment gestionat (només configures) |
| Ideal per a | Detecció de frau, alertes en viu | Omplir el data lake amb dades de streaming |
💡 Regla pràctica: si necessites reaccionar a l’instant a les dades, fes servir Data Streams. Si només vols portar les dades de streaming a un lloc (com el teu data lake a S3) de manera fàcil i automàtica, fes servir Firehose. Sovint s’usen junts: Streams per reaccionar en viu i Firehose per arxivar el mateix flux a S3.
Com connecta amb el data lake
Kinesis és sovint la porta d’entrada de dades en temps real cap al data lake del subcapítol 29.1:
Dades en temps real → Kinesis Firehose → S3 (data lake)
│
Glue cataloga, Athena consulta
→ les dades de streaming acaben analitzables juntament amb la restaAixí, les dades que arriben contínuament acaben al teu data lake, a punt per analitzar-se juntament amb les altres. Streaming (Kinesis) i data lake (S3+Glue+Athena) es combinen en una plataforma de dades completa.
Exemple del món real: una plataforma de videojocs online vol analitzar el comportament dels jugadors en temps real i també guardar-lo per a anàlisis posteriors. Usen Kinesis Data Streams per capturar cada acció dels jugadors (milions per minut) i processar-les a l’instant amb Lambdas que, per exemple, detecten trampes o ajusten la dificultat en viu. Alhora, usen Kinesis Data Firehose per bolcar aquest mateix flux d’esdeveniments a S3 (el seu data lake), on després l’analitzen amb Athena per entendre tendències a llarg termini. Streaming per reaccionar ara, data lake per entendre l’històric: el millor dels dos mons.
El que has de recordar
- Moltes dades arriben en temps real, de forma contínua (clics, sensors, transaccions); processar-les requereix capturar aquest flux continu sense perdre res, sovint per reaccionar a l’instant.
- El processament en streaming tracta les dades a mesura que es generen (com un riu que flueix), enfront del processament per lots (com una presa que acumula i deixa anar).
- Amazon Kinesis captura, processa i analitza dades en temps real a gran escala. Dos components principals:
- Kinesis Data Streams: captura un flux en viu per processar-lo a l’instant (reaccionar en temps real: frau, alertes). Com una cinta transportadora en viu.
- Kinesis Data Firehose: recull un flux i el lliura automàticament en un destí (S3, Redshift...), totalment gestionat. Com una mànega cap al dipòsit.
- 💡 Data Streams per reaccionar a l’instant; Firehose per portar dades a un destí fàcilment. Sovint s’usen junts.
- Kinesis és la porta d’entrada de dades en temps real cap al data lake (S3), combinant streaming i històric.
En el següent subcapítol veurem l’altre gran pilar de l’analítica: el magatzem de dades optimitzat per a consultes a gran escala, Redshift.
Cloud, AWS & Terraform — De zero a expert
Capítol 1 · Què és el cloud computing
- 1.1 El model client-servidor tradicional
- 1.2 Problemes que venia a resoldre el núvol
- 1.3 On-premise vs cloud vs híbrid
- 1.4 Els tres models de servei: IaaS, PaaS, SaaS
- 1.5 Els cinc pilars del cloud (segons NIST)
- 1.6 Avantatges reals: elasticitat, pagament per ús, disponibilitat global
Capítol 2 · El mercat cloud i els grans proveïdors
- 2.1 AWS, Azure i GCP: diferències i quotes de mercat
- 2.2 Per què aprendre AWS primer
- 2.3 Conceptes que són universals entre proveïdors
Capítol 3 · Regions, zones de disponibilitat i edge
- 3.1 Què és una regió AWS i com triar-la
- 3.2 Availability Zones: alta disponibilitat des del disseny
- 3.3 Edge locations i CloudFront
- 3.4 Latència, resiliència i sobirania de dades
Capítol 4 · Càlcul: EC2
- 4.1 Instàncies: tipus, famílies i quan triar cadascuna
- 4.2 AMIs, key pairs i Security Groups
- 4.3 Cicle de vida d'una instància
- 4.4 Elastic IPs i Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítol 5 · Emmagatzematge: S3
- 5.1 Buckets, objectes i claus
- 5.2 Classes d'emmagatzematge (Standard, IA, Glacier…)
- 5.3 Versionat i cicle de vida d'objectes
- 5.4 Polítiques de bucket i ACLs
- 5.5 Hosting de llocs web estàtics
Capítol 6 · Xarxes: VPC
- 6.1 Què és una VPC i per què la necessites
- 6.2 Subxarxes públiques i privades
- 6.3 Internet Gateway i NAT Gateway
- 6.4 Route Tables i Network ACLs
- 6.5 VPC Peering i endpoints
Capítol 7 · Identitat i accés: IAM
- 7.1 Usuaris, grups, rols i polítiques
- 7.2 El principi de mínim privilegi
- 7.3 Polítiques basades en identitat vs en recurs
- 7.4 MFA i credencials temporals (STS)
- 7.5 Bones pràctiques de seguretat IAM
Capítol 8 · Bases de dades gestionades
- 8.1 RDS: motors, Multi-AZ i rèpliques de lectura
- 8.2 Aurora i els seus avantatges sobre RDS vanilla
- 8.3 DynamoDB: model clau-valor / documents
- 8.4 ElastiCache per a memòria cau en memòria
- 8.5 Quan utilitzar cada tipus de base de dades
Capítol 9 · Per què Infraestructura com a Codi
- 9.1 Problemes del provisionament manual
- 9.2 IaC declaratiu vs imperatiu
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El cicle plan → apply → destroy
Capítol 10 · HCL: el llenguatge de Terraform
- 10.1 Blocs resource, variable, output, locals
- 10.2 Tipus de dades: string, number, bool, list, map, object
- 10.3 Expressions, referències i funcions built-in
- 10.4 Condicionals i bucles (count, for_each, for)
Capítol 11 · Providers i estat
- 11.1 Com funciona el provider d'AWS
- 11.2 El fitxer terraform.tfstate i la seva importància
- 11.3 State local vs state remot (S3 + DynamoDB)
- 11.4 Comandes essencials: init, plan, apply, destroy, fmt, validate
Capítol 12 · La teva primera infraestructura real amb Terraform
- 12.1 Crear una VPC amb subxarxes des de zero
- 12.2 Posar en marxa una instància EC2 pública
- 12.3 Associar un Security Group i una Elastic IP
- 12.4 Outputs i referències entre recursos
- 12.5 Flux de treball en equip: PR review de plans
Capítol 13 · Balanceig de càrrega i autoescalat
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners i regles
- 13.3 Auto Scaling Groups: polítiques i mètriques
- 13.4 Warm pools i lifecycle hooks
Capítol 14 · Serverless amb Lambda
- 14.1 El model d'execució de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestió de dependències i capes (Layers)
- 14.4 Cold starts i estratègies per reduir-los
- 14.5 Límits i antipatrones
Capítol 15 · Missatgeria i esdeveniments
- 15.1 SQS: cues estàndard vs FIFO, DLQ
- 15.2 SNS: topics, subscripcions, fan-out
- 15.3 EventBridge: event buses i regles
- 15.4 Patrons: pub/sub, desacoblament, saga
Capítol 16 · Lliurament de contingut i DNS
- 16.1 Route 53: tipus de registres i routing policies
- 16.2 CloudFront: distribucions, memòries cau i origins
- 16.3 ACM: certificats SSL/TLS gratuïts
- 16.4 WAF integrat amb CloudFront
Capítol 17 · Contenidors a AWS
- 17.1 Docker: repàs exprés de conceptes clau
- 17.2 ECR: registre privat d'imatges
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: quan Kubernetes i quan no
Capítol 18 · Mòduls: reutilització i composició
- 18.1 Anatomia d'un mòdul Terraform
- 18.2 Variables d'entrada, outputs i dependències
- 18.3 Mòduls locals vs mòduls del Terraform Registry
- 18.4 Versionat de mòduls amb Git tags
- 18.5 Disseny de mòduls genèrics vs específics de domini
Capítol 19 · Workspaces i gestió d'entorns
- 19.1 Workspaces de Terraform: casos d'ús i limitacions
- 19.2 Estratègia de directoris per entorn (dev/stg/prod)
- 19.3 Terragrunt: DRY per a configuracions d'entorn
- 19.4 Variables d'entorn i fitxers .tfvars
Capítol 20 · Backends remots i locking
- 20.1 Configurar S3 + DynamoDB com a backend
- 20.2 State locking: evitar corrupció en equip
- 20.3 Migració d'estat entre backends
- 20.4 terraform import: portar recursos existents a l'estat
Capítol 21 · Testing d'infraestructura
- 21.1 Terraform validate i fmt en CI
- 21.2 Checkov i tfsec: anàlisi de seguretat estàtica
- 21.3 Terratest: tests d'integració en Go
- 21.4 Contract testing entre mòduls
Capítol 22 · Terraform en CI/CD
- 22.1 Pipeline bàsic: lint → plan → apply a GitHub Actions
- 22.2 Atlantis: GitOps per a Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection i reconciliació automàtica
Capítol 23 · Seguretat en profunditat
- 23.1 AWS Organizations i Service Control Policies
- 23.2 AWS Config: compliment continu
- 23.3 GuardDuty: detecció d'amenaces
- 23.4 Security Hub: visió centralitzada
- 23.5 KMS: gestió de claus i rotació
- 23.6 Secrets Manager vs Parameter Store
Capítol 24 · Observabilitat: logs, mètriques i traces
- 24.1 CloudWatch Logs, mètriques i alarmes
- 24.2 CloudWatch Dashboards i Contributor Insights
- 24.3 X-Ray: traçat distribuït
- 24.4 OpenTelemetry a AWS
- 24.5 Managed Grafana i Managed Prometheus
Capítol 25 · Optimització de costos
- 25.1 AWS Cost Explorer i pressupostos amb alertes
- 25.2 Trusted Advisor i Compute Optimizer
- 25.3 Rightsizing: com detectar sobredimensionament
- 25.4 Savings Plans vs Reserved Instances: decisió estratègica
- 25.5 FinOps: cultura i processos per controlar la despesa
Capítol 26 · Alta disponibilitat i disaster recovery
- 26.1 RTO i RPO: definir els objectius
- 26.2 Estratègies: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks i failover automàtic
- 26.4 AWS Backup: política centralitzada de còpies
Capítol 27 · Well-Architected Framework d'AWS
- 27.1 Els sis pilars: excel·lència operacional, seguretat, fiabilitat, eficiència de rendiment, optimització de costos, sostenibilitat
- 27.2 Well-Architected Tool: revisions formals
- 27.3 Com aplicar el framework en decisions de disseny
Capítol 28 · Arquitectures serverless a escala
- 28.1 Event-driven architecture amb Lambda + EventBridge
- 28.2 Saga pattern per a transaccions distribuïdes
- 28.3 Step Functions: orquestració de workflows complexos
- 28.4 Lambda@Edge i CloudFront Functions
Capítol 29 · Plataformes de dades a AWS
- 29.1 Data Lake amb S3, Glue i Athena
- 29.2 Kinesis Data Streams i Firehose per a streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: govern del dada
Capítol 30 · Multi-compte i landing zones
- 30.1 Per què separar workloads en comptes diferents
- 30.2 AWS Control Tower i Account Factory
- 30.3 Gestió centralitzada de logs i seguretat
- 30.4 Terraform a escala multi-compte amb mòduls compartits
Capítol 31 · Platform Engineering i Internal Developer Platform
- 31.1 Golden paths i abstraccions sobre Terraform
- 31.2 Service Catalog d'AWS
- 31.3 Backstage com a portal de desenvolupadors
- 31.4 Mòduls Terraform com a producte intern
Capítol 32 · Certificacions AWS rellevants
- 32.1 Cloud Practitioner: val la pena?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Capítol 33 · Projectes per consolidar el que s'ha après
- 33.1 Projecte 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Projecte 2: API REST amb ECS Fargate + RDS + ALB
- 33.3 Projecte 3: plataforma de dades amb Glue + Athena + Redshift
- 33.4 Projecte 4: landing zone multi-compte amb Terraform i Control Tower
