Ús de Stream Processing a EventHub (ksqlDB / Flink)

Navegació

⬅️ Ús de Connectors	➡️ Ús de Cluster Linking

---

Ús de Stream Processing a EventHub (ksqlDB / Flink)

Canigó – Guia per a aplicacions

Aquesta pàgina explica què ha de fer una aplicació per sol·licitar, modificar o retirar processament en temps real sobre EventHub mitjançant ksqlDB o Flink.

---

1. Quan necessites Stream Processing?

Necessites Stream Processing si:

• Has de transformar esdeveniments en temps real.
• Necessites enriquiments, agregacions o joins.
• Vols generar nous topics derivats a partir d’altres.

❌ No facis servir Stream Processing si:

• El cas d’ús és batch.
• La lògica es pot resoldre en el productor o el consumidor.
• No existeix un cas d’ús funcional clar.

---

2. Quina tecnologia utilitzar?

ksqlDB

Utilitza ksqlDB si:

• El processament és simple o mitjà.
• La lògica es pot expressar en SQL.
• Necessites menor complexitat operativa.
• L’entorn és on‑premise o cloud.

Flink

Utilitza Flink si:

• El processament és complex.
• Requereixes estat avançat, finestres complexes o lògica elaborada.
• L’entorn és cloud (Flink només disponible en cloud).

⚠️ Flink requereix revisió tècnica automàtica per part de l’Oficina EventHub.

---

3. Alta de Stream Processing: què has de fer

Pas 1. Omplir la plantilla de sol·licitud (obligatori)

• Plantilla oficial: Plantillas_Solicitud_EventHub
• Pestanya Solicitud_StreamProcessing, una fila per pipeline/workspace.

Camps que ha d’omplir l’aplicació:

Camp	Descripció
Entorno	INT / PRE / PRO
Tipo	ksqlDB o Flink
Nombre_Pipeline	Nom descriptiu del flux o job
Topics_Entrada	Topics d’entrada (separats per comes)
Topics_Salida	Topics de sortida (separats per comes)
Topics_Intermedios	Topics intermedis creats pel flux (si n’hi ha)
Volumen_Estimado_MBs	Throughput estimat en MB/s
Tamano_Medio_Msg_Bytes	Mida mitjana del missatge en bytes
Justificacion	Justificació de la tecnologia escollida i del cas d’ús

Notes importants:

• En ksqlDB, un pipeline pot contenir múltiples queries.
• En Flink, un projecte pot tenir múltiples workspaces.
• Els topics intermedis han d’estar governats com qualsevol altre topic.

Pas 2-4. Sol·licitud, validació i desplegament

Flux estàndard: tiquet JIRA → validació Oficina → CRQ en PRE/PRO quan apliqui.

---

4. Gestió de queries ksqlDB

Afegir una nova query

Les noves queries es despleguen des del Control Center (secció ksqlDB → Editor) o via petició a l’Oficina. La query es pega a l’editor i s’executa amb “Run query”.

Actualitzar queries existents

⚠️ L’actualització de queries ksqlDB requereix un ordre concret degut a les dependències entre queries:

1. Identificar dependències: les queries poden estar anidades (una query depèn del resultat d’una altra). Per conèixer les dependències de les teves queries, contacta amb l’Oficina EventHub, que té accés al Control Center i pot proporcionar l’ordre d’eliminació correcte.
2. Eliminar queries dependents primer: si una query B depèn d’una query A, cal eliminar B abans de poder modificar A.
3. Ordre d’eliminació: l’Oficina EventHub gestiona l’eliminació i recreació de queries en el Control Center. Proporciona a l’Oficina el fitxer .sql amb les noves queries en l’ordre d’execució correcte.
4. Recrear les queries: l’Oficina executa les noves sentències en l’ordre correcte un cop eliminades les anteriors.

Bones pràctiques amb ksqlDB

• Documentar les dependències entre queries.
• Proporcionar les queries en un fitxer .sql amb l’ordre d’execució indicat.
• Provar sempre en INT abans de PRE/PRO.
• Els canvis en queries de PRO requereixen CRQ.

---

5. Què decideix la plataforma (no l’aplicació)

La plataforma defineix:

• Tecnologia final a utilitzar.
• Configuració de recursos.
• Necessitat de CRQ i finestra de desplegament.

---

6. Revisió tècnica automàtica

La plantilla marca automàticament com a “Revisió tècnica requerida” si:

• Tipo = Flink

---

7. Canvis sobre Stream Processing

Es consideren canvis:

• Modificar la lògica del processament.
• Afegir, eliminar o modificar queries ksqlDB.
• Canviar els topics d’entrada o sortida.
• Canviar de tecnologia (ksqlDB ↔ Flink).

Què cal fer:

1. Actualitzar la fitxa.
2. Obrir tiquet JIRA.
3. Per a ksqlDB: adjuntar el fitxer .sql amb les queries actualitzades.
4. Tramitar CRQ si aplica (obligatòria en PRE/PRO).

---

8. Retirada d’un flux o job

• Confirmació formal de no ús.
• Avaluació d’impacte.
• Aturada controlada del processament.
• CRQ en PRO quan aplica.

La retirada no implica l’eliminació automàtica dels topics associats.

---

9. Errors habituals (evita’ls)

• Utilitzar Flink per a casos simples (ksqlDB és suficient).
• No justificar la tecnologia escollida.
• Duplicar fluxos existents.
• Canviar lògica en producció sense CRQ.
• Oblidar declarar els topics intermedis.
• Intentar actualitzar queries ksqlDB sense eliminar dependències primer.
• No proporcionar el fitxer .sql amb l’ordre d’execució.

---

10. Documentació de referència

• Plantillas_Solicitud_EventHub
• Decisió: ksqlDB vs Flink
• ksqlDB Overview (Confluent)
• Flink on Confluent Cloud

---

I ara què?

• -> Estàndards i validació
• -> Autoservei governat
• -> Canvi i desplegament