Architecture unifiée Data + IA¶
La thèse derrière AKKO : big data et IA ne sont pas deux stacks séparés. Ils partagent la même infrastructure. L'industrie a coupé les deux en deux depuis 2023 parce que la vague IA est arrivée tard ; le coût de ce split c'est de la plomberie dupliquée, de la gouvernance fragmentée, et deux équipes qui ne se parlent pas.
AKKO recolle le tout.
Les 5 besoins communs¶
Tout pipeline data — qu'il s'agisse d'un ELT sur 10 milliards de transactions ou d'un RAG sur 10 millions de PDFs — passe par ces 5 couches :
| Couche | Besoin | Composant AKKO |
|---|---|---|
| Stockage | Object store durable + formats colonnes | MinIO + Iceberg + Polaris |
| Calcul | Distribué, container-native, schedulable | Spark + Trino |
| Orchestration | DAGs cron ou event, retries, audit | Airflow 3 |
| Gouvernance | SSO, RBAC, policies row/column, audit | Keycloak + OPA + OpenMetadata |
| Observabilité | Métriques, traces, logs, lineage | Grafana / VictoriaMetrics + Tempo + Loki + OpenMetadata |
Les couches spécifiques à l'IA — embeddings, vector search, model registry, serving LLM — sont des ajouts à l'infra, pas des remplacements :
| Besoin IA | Composant AKKO |
|---|---|
| Hébergement modèles d'embedding | Ollama (local) + LiteLLM (bridge cloud) |
| Vector store (petit) | pgvector dans akko-postgresql-data |
| Vector store (moyen) | OpenSearch dense_vector (déjà bundled) |
| Vector store (énorme) | Tables Iceberg avec colonnes VECTOR + Trino |
| Model registry | MLflow |
| Serving | Services FastAPI custom (akko-ai-service, futur akko-rag) |
| Extraction documents | Docling (IBM Research, MIT) |
| ASR (audio → texte) | Whisper |
| SQL LLM-native | ADEN (AKKO Data-Engine Native) + plugin Trino AI |
Chacun tourne sur le même Kubernetes, s'authentifie via le même Keycloak, est gouverné par les mêmes policies OPA, et son lineage est enregistré dans le même graphe OpenMetadata.
Trois tiers de volume, une seule API¶
Pour le cas d'usage document intelligence (PDFs à grande échelle), AKKO grandit gracieusement du cabinet de 10 personnes aux volumes d'archives nationales. Le côté consommateur (APIs, UI cockpit, dialecte SQL) ne change jamais — seul le backend est substitué :
Tier 1 — Petit (jusqu'à ~1 000 PDFs ≈ 250k chunks)
├─ pgvector dans akko-postgresql-data
├─ ingestion FastAPI directe
├─ latence query < 50 ms
└─ Target : PME, cabinets d'avocats, démos commerciales
Tier 2 — Moyen (jusqu'à ~100 000 PDFs ≈ 25M chunks)
├─ OpenSearch dense_vector (bundled dans AKKO)
├─ ingestion Airflow nightly batch
├─ hybrid search BM25 keyword + dense vector
├─ latence query < 100 ms
└─ Target : assureurs régionaux, cabinets conseil, middle market
Tier 3 — Big data (millions de PDFs ≈ milliards de chunks)
├─ Tables Iceberg sur MinIO (cold tier)
├─ OpenSearch hot tier (12 derniers mois)
├─ Spark batch embedding distribué sur cluster
├─ Trino SQL pour queries vector + structuré hybrides
├─ Qdrant optionnel pour latence ultra-basse sur hot set
└─ Target : pharma, grandes banques, État/fisc, médias
Backend sélectionné via values.yaml. La page cockpit, l'API REST, le
dialecte SQL restent identiques. Le client peut démarrer Tier 1 et monter
à Tier 3 sans réarchitecturer.
Pourquoi c'est commercialement décisif¶
Les concurrents forcent le client dans une catégorie dès l'achat :
| Vendor | Oblige le client à |
|---|---|
| Databricks Vector Search | Être gros dès le jour 1 (cher) ; pas d'on-prem |
| Pinecone | Être en SaaS only ; pas souverain ; licence propriétaire |
| Snowflake Cortex | Être all-in sur Snowflake ; lock-in propriétaire |
| Weaviate Cloud / Qdrant Cloud | Juste le vector store ; le reste reste ton problème |
| Elasticsearch + "un peu d'IA" | Split dépassé, licence Elastic bloque le SaaS |
AKKO grandit avec le client. Démarre Tier 1 sur une seule VM, grandit
à Tier 3 sur un cluster k8s de 50 nœuds, même API. Tier 1 bundled en Lab
edition ; Tier 2 unlocked en Data edition ; Tier 3 unlocked en Enterprise.
L'upgrade = changer une valeur dans values.yaml + redeploy. Pas de
migration de schéma, pas de réécriture du contrat API.
Un pipeline concret : du PDF au dashboard¶
Exemple bancaire. Les agences uploadent des PDFs d'audit dans MinIO. Les analystes demandent "montre-moi les clients à risque avec des mentions historiques dans les audits". Le chemin :
Agence upload PDF ──► MinIO bucket ◄─── event S3
│
▼ Airflow DAG
┌────────────────┐
│ Docling extract│
└────────────────┘
│ markdown + tables + OCR
▼
┌────────────────┐
│ Spark job: │
│ chunk + embed │
│ via UDF Ollama │
└────────────────┘
│ milliards de (text, vec) rows
▼
┌────────────────────────────────────┐
│ Iceberg table rag.banking_chunks │
│ partitionné par year + quarter │
└────────────────────────────────────┘
│
┌──────────────────────────────────────┼──────────────────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────────────┐ ┌───────────────────┐
│ Trino SQL │ │ OpenSearch hot tier │ │ akko-rag service │
│ JOIN chunks │ │ 12 derniers mois │ │ chat cockpit │
│ + customers │ │ BM25 + dense hybrid │ │ avec citations │
│ + loans │ └──────────────────────┘ └───────────────────┘
│ + transactions│ │ │
└──────────────┘ └──────────┬───────────────────┘
│
┌──────────▼───────────┐
│ ADEN (langage nat) │
│ → SQL → exec → chart │
└──────────────────────┘
│
▼
Dashboard Superset,
filtré row-level par OPA,
publié depuis Jupyter
Une seule requête SQL peut donner :
SELECT c.customer_id, c.name,
SUM(t.amount) AS volume_12m,
COUNT(DISTINCT l.loan_id) AS active_loans,
(SELECT COUNT(*)
FROM iceberg.rag.rag_chunks
WHERE metadata->>'document_type' = 'audit_report'
AND text ILIKE '%' || c.customer_id || '%') AS audit_mentions
FROM iceberg.banking_prod.customers c
LEFT JOIN iceberg.banking_prod.transactions t USING (customer_id)
LEFT JOIN iceberg.banking_prod.loans l USING (customer_id)
WHERE c.risk_rating IN ('HIGH', 'CRITICAL')
GROUP BY c.customer_id, c.name
ORDER BY audit_mentions DESC
LIMIT 50;
Une seule requête, 50 ms de latence, qui joint données clients, historique transactions, portefeuille crédit, et recherche sémantique sur un corpus de PDFs audit. C'est ce que l'architecture unifiée livre. Tous les autres vendors forcent à faire trois requêtes séparées (leur moteur SQL, leur vector DB, leur outil BI) puis à recoller les résultats en code applicatif.
Gouvernance partagée = vraie gouvernance¶
Parce que tout vit dans un seul maillage, une seule policy OPA protège :
- Qui peut requêter une table Trino
- Qui peut lire une partition Iceberg
- Qui peut récupérer un chunk RAG
- Qui peut voir une ligne de dashboard Superset
- Qui peut appeler un modèle MLflow
Cette policy est versionnée dans Git (helm/akko/charts/akko-opa/). Elle
est appliquée à chaque chemin de lecture sans contournement possible.
L'audit trail couvre tout le pipeline de bout en bout — un régulateur qui
demande « qui a accédé aux données de ce client sur les 12 derniers mois »
obtient une réponse complète en une requête, pas un stitching manuel sur
5 systèmes.
Ce qu'il faut retenir¶
- Big data et IA sont le même problème — bouger la donnée à travers des pipelines de calcul avec gouvernance et observabilité.
- AKKO bundle les primitives une fois et les compose pour les deux mondes.
- La stratégie 3 tiers de volume fait qu'la même API sert un cabinet de 10 personnes et une pharma de 10 000.
- Gouvernance et lineage sont inhérents, pas des ajouts — c'est le défaut quand les composants partagent auth, catalogue et métriques.
Liens¶
- CI/CD Pipeline — comment tous ces changements se déploient
- Control Plane — API unifiée sur Datasets / Workspaces / Pipelines / Agents
- AI Stack — détail de la couche IA
- Data Flow — détail pipeline structuré only