EA SAP HANA: Podstawowe narzędzie do zarządzania bazą

 SAP HANA to potężna platforma bazodanowa, której efektywne zarządzanie wymaga odpowiednich narzędzi administracyjnych. Najważniejszymi z nich są SAP HANA Cockpit oraz SAP HANA Studio – oba oferują dostęp do kluczowych funkcji monitorowania, konfiguracji, tworzenia kopii zapasowych i analizy wydajności. W tym artykule przyjrzymy się bliżej ich możliwościom, różnicom oraz praktycznym scenariuszom użycia.

SAP HANA Cockpit – nowoczesne zarządzanie przez przeglądarkę

Co to jest SAP HANA Cockpit?

SAP HANA Cockpit to webowe, oparte na HTML5 narzędzie administracyjne działające w architekturze XS Advanced. Służy do zarządzania wieloma systemami SAP HANA z jednego miejsca. Umożliwia pracę w przeglądarce i nie wymaga instalacji lokalnej.

Najważniejsze funkcje Cockpita:

• Monitoring zużycia CPU, pamięci, dysku

• Zarządzanie bazami tenantowymi (tworzenie, start/stop, backup)

• Przegląd alertów i konfiguracja reguł powiadomień

• Zarządzanie użytkownikami i rolami

• Wgląd w konfigurację systemu (parametry, warstwy .ini)

• Tworzenie kopii zapasowych i odtwarzanie danych

Interfejs użytkownika:

• Tiles Dashboard: intuicyjne kafelki pokazujące stan systemu

• Resource Groups: organizacja środowiska według grup (np. produkcja/test)

• Drill-down do szczegółowych metryk

Wymagania:

• Zainstalowany komponent SAP HANA Cockpit 2.0

• Użytkownik techniczny z rolą: CATALOG READ, MONITOR ADMIN, INIFILE ADMIN

SAP HANA Studio – klasyczne narzędzie desktopowe

Co to jest SAP HANA Studio?

To starsze, ale wciąż bardzo użyteczne środowisko typu IDE oparte na Eclipse. Pozwala na zarządzanie bazą danych SAP HANA oraz tworzenie i modelowanie danych.

Główne funkcje SAP HANA Studio:

• Podgląd i zarządzanie strukturą danych

• SQL Console – wykonywanie zapytań SQL

• Przegląd i modyfikacja konfiguracji .ini

• Zarządzanie użytkownikami i rolami

• Monitoring zasobów i wykorzystania systemu

• Zarządzanie kopiami zapasowymi

Dostępne „perspektywy”:

• Administration Console – do administracji systemem

• Modeler – do tworzenia modeli danych

• Lifecycle Management – do instalacji aktualizacji i transportów

SAP HANA Cockpit vs Studio – porównanie

Funkcja	SAP HANA Cockpit	SAP HANA Studio
Dostęp	Przeglądarka internetowa	Aplikacja desktopowa
Obsługa wielu systemów	✅ Tak	🔶 Ograniczona
SQL Console	✅ Tak	✅ Tak
Zarządzanie użytkownikami	✅ Tak	✅ Tak
Monitoring systemu	✅ Nowoczesny, responsywny	✅ Klasyczny
Obsługa XS Advanced	✅ Tak	❌ Nie
Instalacja aplikacji/modeli danych	🔶 Ograniczona	✅ Tak (Modeler)
Zalecane użycie	Nowe instalacje, krajobrazy	Utrzymanie istniejących systemów, development

Typowe scenariusze administracyjne

Tworzenie kopii zapasowej (Cockpit)

1. Otwórz Cockpit → Wybierz bazę danych

2. Przejdź do kafelka „Backup”

3. Kliknij „Create Backup” → wybierz typ: full, differential, incremental

4. Uruchom → potwierdź sukces operacji

Restart instancji (Studio)

1. Zaloguj się do systemu jako SYSTEM lub admin

2. W zakładce „System” kliknij prawym → „Stop System”

3. Po chwili → „Start System”

4. Zweryfikuj status usług w zakładce „Landscape”

Dodanie użytkownika (SQL)

sql
CREATE USER admin IDENTIFIED BY "SecurePassword123";
GRANT MONITORING, BACKUP ADMIN TO admin;

Zarządzanie bazami tenantowymi (Cockpit)

Możliwości:

• Tworzenie nowego tenanta:

  sql
  CREATE DATABASE TENANT1 SYSTEM USER PASSWORD "TenantPass";
  

• Start/Stop konkretnego tenanta:

  sql
  ALTER SYSTEM START DATABASE TENANT1;
  ALTER SYSTEM STOP DATABASE TENANT1;
  

• Zarządzanie zasobami: pamięć, CPU (w zakładce "Resource Allocation")

Praktyczne wskazówki i dobre praktyki

• Używaj dedykowanych użytkowników technicznych z ograniczonymi uprawnieniami (np. tylko BACKUP OPERATOR)

• Testuj zmiany konfiguracyjne najpierw w systemach nieprodukcyjnych

• Zaplanuj regularne backupy i sprawdzaj logi ich wykonania

• Monitoruj alerty i analizuj historyczne dane wydajnościowe

• Nie edytuj plików .ini ręcznie – zawsze używaj Cockpita lub Studio

Podsumowanie

SAP HANA Cockpit i SAP HANA Studio to dwa komplementarne narzędzia do zarządzania bazą danych HANA. Cockpit zapewnia nowoczesne, centralne zarządzanie i monitoring, natomiast Studio pozostaje przydatne przy pracy lokalnej i modelowaniu danych.

✅ Cockpit – dla administratorów i DevOps
✅ Studio – dla developerów i klasycznej administracji

EA 12 factor app - fundament dla nowoczesnych aplikacji chmurowych czy przestarzały hype?

 W poprzednim wpisie „EA: 12 Factor Agents — Nowe podejście, które może zmienić Twoje myślenie o AI” zaproponowałem przeniesienie idei 12 Factor App na grunt architektury agentowej. Czas wrócić do źródeł i przyjrzeć się oryginalnemu manifestowi 12factor.net, który — mimo że powstał ponad dekadę temu — wciąż stanowi solidny fundament dla budowania nowoczesnych aplikacji chmurowych, mikrousług i systemów agentowych.

Dlaczego warto znać 12 Factor App?

Zasady 12 Factor App to nie przepis na framework czy technologię, ale zestaw praktyk projektowych, które pomagają budować aplikacje:

• przenośne (cloud-native),

• skalowalne poziomo,

• łatwe do wdrażania, monitorowania i rozwijania.

W świecie, w którym infrastruktura staje się zautomatyzowana, a aplikacje coraz bardziej rozproszone, te zasady okazują się nie tyle dobrowolnymi rekomendacjami, co warunkiem „przeżycia” w produkcji.

12 czynników — w skrócie i z komentarzem architekta

Przyjrzyjmy się krótko każdemu z 12 czynników, z perspektywy osoby projektującej systemy rozproszone, często hybrydowe, integrujące się z agentami, API, systemami kolejkowymi i narzędziami DevOps.

1. Codebase — jedna baza kodu na aplikację

Każdy serwis powinien mieć jedno źródło prawdy (repozytorium Git). W przypadku systemów agentowych może to oznaczać, że agent to również jednostka wdrożeniowa (np. kontener), a nie biblioteka współdzielona przez inne serwisy.

2. Dependencies — jawne zarządzanie zależnościami

Brak polegania na globalnym środowisku (jak systemowe paczki). W świecie micro-agents oznacza to np. unikanie ukrytych zależności między agentami a platformą hostującą.

3. Config — konfiguracja przez zmienne środowiskowe

Oddzielenie kodu od konfiguracji to baza dla portowalności i automatyzacji — zarówno w CI/CD, jak i w orkiestracji (Kubernetes, Nomad).

4. Backing services — traktuj zewnętrzne zasoby jak attachable

Usługi takie jak bazy danych, kolejki, pamięci cache są zależnościami, nie integralną częścią aplikacji. Ułatwia to testowanie, replikację, skalowanie.

5. Build, release, run — rozdzielenie etapów cyklu życia aplikacji

Oddzielenie builda (np. Docker image), release'u (konfiguracja + build) i uruchomienia (run-time). Kluczowe przy wersjonowaniu agentów i rollbackach.

6. Processes — bezstanowe procesy

Statelessness to kręgosłup skalowalności i niezawodności. Dane sesyjne powinny trafić do Redis, a nie do pamięci agenta.

7. Port binding — self-contained aplikacje nasłuchujące na porcie

Każda aplikacja (lub agent) powinna być samodzielna i gotowa do uruchomienia w dowolnym środowisku przez proste docker run.

8. Concurrency — skalowanie przez procesy

Nie chodzi tylko o wielowątkowość, ale o świadome projektowanie poziomów równoległości (np. web, worker, cron). W systemach agentowych: osobne procesy dla agentów odpowiedzialnych za inne zadania.

9. Disposability — szybki start i czyste wyłączanie

Aplikacja (agent) powinna uruchamiać się i zamykać szybko i bezpiecznie. Przydatne w autoskalowaniu i orchestracji (K8s, ECS).

10. Dev/prod parity — minimalizacja różnic środowiskowych

Im mniejsza różnica między lokalnym docker-compose up a produkcją w chmurze, tym mniej „niespodzianek”. Infrastructure as Code to tu podstawa.

11. Logs — traktuj logi jako strumień zdarzeń

Nie zapisuj logów do pliku — logi mają iść na stdout/stderr, by mogły być przechwycone przez ELK, Loki, czy inny system monitorujący.

12. Admin processes — pomocnicze zadania jako jednorazowe procesy

Migracje bazy, inspekcja danych czy czyszczenie cache — wszystko jako osobne, uruchamialne procesy. Idealne do CRON-jobów lub zadań DevOps.

12 Factor App vs. 12 Factor Agents

W podejściu agentowym mówimy o architekturze zorientowanej na samodzielne, autonomiczne komponenty komunikujące się ze sobą. W tym świetle:

• Agent może być procesem zgodnym z 12FA.

• Platforma dla agentów powinna wspierać lifecycle wg 12FA (deployment, logi, konfiguracja).

• Rozproszenie i niezależność agentów staje się naturalnym rozszerzeniem idei „self-contained apps”.

W praktyce — 12 Factor App to doskonały fundament, na którym możemy budować 12 Factor Agents.

Kiedy 12 Factor App się nie sprawdzi?

Oczywiście, jak każde podejście, 12FA ma swoje ograniczenia:

• Trudno je zastosować do monolitów z dużym stanem wewnętrznym (ERP, legacy).

• Nie nadaje się do aplikacji wymagających silnego stateful compute (np. stream processing bez zewnętrznego stanu).

• Wymaga kultury DevOps i automatyzacji — bez tego wiele założeń się nie obroni.

Podsumowanie

Zasady 12 Factor App pozostają aktualne, zwłaszcza jako podstawa dla nowoczesnych, autonomicznych komponentów — w tym agentów. W połączeniu z architekturą agentową stanowią przepis na systemy:

• elastyczne i odporne na zmiany,

• łatwe do wdrażania i skalowania,

• zgodne z filozofią „as a Service”.

Jeśli jeszcze nie stosujesz 12FA — warto zacząć chociażby od rozdzielenia konfiguracji, logów i budowania obrazów aplikacyjnych. Małe kroki, wielki zysk.

Czy Twój system jest zgodny z 12 Factor App? A może agenci w Twojej organizacji mogliby na tym podejściu skorzystać? Daj znać w komentarzach lub na LinkedInie — chętnie podyskutuję.

EA CNCF – ekosystem, który napędza współczesny cloud-native

 W ciągu ostatnich kilku lat pojęcie cloud-native przestało być modnym hasłem, a stało się standardem w budowie nowoczesnych systemów. Ale za sukcesem wielu technologii, które dzisiaj uważamy za podstawowe — jak Kubernetes, Prometheus czy Envoy — stoi jedna organizacja: Cloud Native Computing Foundation (CNCF). W tym artykule przyjrzymy się, czym jest CNCF, jaka jest jej historia, kto za nią stoi i jak wygląda proces adopcji projektów do tego ekosystemu.

Czym jest CNCF?

Cloud Native Computing Foundation (CNCF) to fundacja typu non-profit, która powstała w 2015 roku jako część Linux Foundation. Jej celem jest rozwój, standaryzacja i promocja technologii cloud-native — takich, które są zbudowane z myślą o chmurze, konteneryzacji, skalowalności i niezawodności.

CNCF definiuje „cloud-native” jako podejście do budowania systemów odpornych, skalowalnych i zarządzalnych, wykorzystując kontenery, architektury mikroserwisowe, deklaratywne API oraz automatyzację.

Krótka historia CNCF

Fundacja została założona w lipcu 2015 roku — dokładnie wtedy, gdy Google przekazał projekt Kubernetes do open source i oddał go pod skrzydła CNCF. To był kamień milowy. Kubernetes stał się pierwszym i sztandarowym projektem fundacji.

Od tego czasu CNCF stała się jednym z największych i najbardziej wpływowych organizatorów open source w sektorze infrastruktury IT:

• 2015 – Google przekazuje Kubernetes

• 2016 – dołącza Prometheus jako drugi projekt

• 2017-2019 – boom popularności i adopcji narzędzi typu Envoy, Fluentd, Helm, gRPC

• 2020+ – CNCF zarządza setkami projektów i organizuje globalne wydarzenia (np. KubeCon)

Kto uczestniczy w CNCF?

CNCF to nie tylko fundacja – to przede wszystkim społeczność: firmy, kontrybutorzy open source, dostawcy chmury, integratorzy i niezależni deweloperzy. Fundacja ma obecnie:

• Ponad 1700 członków organizacyjnych – w tym Amazon, Google, Microsoft, Red Hat, VMware, Huawei, Alibaba

• Ponad 130 projektów open source

• Tysiące kontrybutorów z całego świata

• Ogromną społeczność skupioną wokół wydarzeń takich jak KubeCon + CloudNativeCon

Również polskie firmy i inżynierowie uczestniczą w rozwoju projektów CNCF, co czyni ten ekosystem prawdziwie globalnym.

Cykl życia projektów w CNCF

CNCF nie przyjmuje dowolnych projektów ani nie traktuje ich wszystkich jednakowo. Każdy projekt przechodzi przez trzy etapy w swoim „życiu” w fundacji:

1. Sandbox

To etap inkubacji – projekty trafiają tu, gdy:

• Są we wczesnej fazie rozwoju

• Chcą zbudować społeczność

• Chcą pokazać potencjał w zakresie cloud-native

Przykład: Dapr, Crossplane, Keptn zaczynały w Sandbox.

2. Incubating

Projekt trafia tu, gdy:

• Udowodnił swoje zastosowanie w praktyce

• Ma aktywną społeczność

• Ma formalne procedury rozwoju i zarządzania

CNCF pomaga wówczas w stabilizacji, dokumentacji, bezpieczeństwie i adopcji przez firmy.

3. Graduated

To status „pełnoprawnego obywatela CNCF”. Wymagania:

• Dowiedzione wdrożenia produkcyjne w wielu organizacjach

• Zrównoważony rozwój i governance

• Spełnienie rygorystycznych wymagań co do bezpieczeństwa i dokumentacji

Przykłady: Kubernetes, Prometheus, Envoy, etcd, containerd

Co daje projektowi dołączenie do CNCF?

• Wiarygodność i zaufanie – dla klientów i deweloperów

• Wsparcie społeczności i fundacji – w obszarach takich jak bezpieczeństwo, testy, CI/CD

• Ekspozycję – m.in. na wydarzeniach CNCF, w raportach i na mapie landscape

• Integrację z innymi projektami – naturalna kompatybilność z Kubernetes i innymi toolami z ekosystemu

CNCF Landscape – mapa (nie)do ogarnięcia

CNCF prowadzi Cloud Native Landscape – interaktywną mapę ekosystemu cloud-native. Znajdziemy tam setki narzędzi pogrupowanych m.in. według kategorii:

• Orkiestracja i zarządzanie

• Obserwowalność i analiza

• Networking

• Storage

• Continuous Delivery

To świetne źródło inspiracji, ale też przestroga – ekosystem CNCF jest ogromny i ciągle rośnie.

🔗 https://landscape.cncf.io

Podsumowanie

CNCF to dziś serce open source'owego świata cloud-native. Jeśli budujesz rozwiązania oparte na Kubernetes, Prometheus, Linkerd, gRPC lub setkach innych technologii – korzystasz z efektów pracy tej fundacji i jej społeczności.

Ale CNCF to nie tylko narzędzia – to także kultura otwartości, transparentności i inżynierskiej doskonałości.

Warto śledzić jej rozwój, bo to, co dzisiaj jest w sandbox, jutro może być fundamentem Twojej infrastruktury.

EA - Wektorowe bazy danych - wstęp

 W erze rosnącej popularności modeli językowych, rekomendacji, wyszukiwania semantycznego i rozpoznawania obrazów coraz częściej słyszymy o bazach danych wektorowych. Choć ich koncepcja istnieje od lat, to właśnie rozwój sztucznej inteligencji dał im nowe życie. W tym artykule pokażę Ci, czym są, do czego służą i jak się z nimi pracuje w praktyce.

Czym są wektorowe bazy danych?

Bazy danych wektorowe służą do przechowywania i wyszukiwania danych w postaci wektorów osadzonych (embeddings). W odróżnieniu od klasycznych baz SQL czy NoSQL, gdzie szukamy po kluczach, tekstach czy relacjach, tutaj wyszukujemy po podobieństwie matematycznym między punktami w przestrzeni wielowymiarowej.

Do czego to służy?

Bazy wektorowe są fundamentem takich zastosowań jak:

• Wyszukiwanie semantyczne (np. „znajdź podobne dokumenty”)

• Rekomendacje (np. „użytkownicy podobni do Ciebie kupili…”)

• Chatboty RAG (Retrieval-Augmented Generation) – pobieranie kontekstu z bazy wiedzy dla modelu LLM

• Analiza obrazów, dźwięku, filmów – porównywanie treści na poziomie cech ukrytych

• Wykrywanie anomalii – poprzez odległość od normalnych przypadków

Jak to działa?

1. Osadzanie danych (embedding):

   • Każdy dokument, obraz czy rekord przechodzi przez model AI (np. BERT, CLIP, OpenAI), który przekształca go w wektor liczb rzeczywistych (np. 768-wymiarowy).

   • Ten wektor reprezentuje znaczenie treści, a nie jej dokładne słowa.

2. Przechowywanie:

   • Wektor trafia do bazy danych wektorowych razem z identyfikatorem i metadanymi (np. kategoria, źródło, użytkownik).

   • Baza indeksuje te dane pod kątem szybkiego wyszukiwania.

3. Wyszukiwanie (query):

   • Nowy wektor zapytania (np. pytanie od użytkownika) porównywany jest z istniejącymi wektorami.

   • Używa się metryk podobieństwa jak:

   • Cosine similarity mierzy kąt między wektorami i ignoruje ich długość — im bliżej 1, tym bardziej podobne.

   • Dot product to iloczyn skalarny dwóch wektorów, który rośnie wraz z ich zgodnością kierunkową i wielkością.

   • Euclidean distance to fizyczna odległość między punktami w przestrzeni — im mniejsza, tym większe podobieństwo.

4. Zwracane są najbardziej podobne rekordy – a niekoniecznie identyczne słowa.

Jakie narzędzia są dostępne?

Najpopularniejsze silniki baz wektorowych:

Narzędzie	Cechy
Pinecone	SaaS, skalowalny, integracja z OpenAI
Weaviate	Open-source + REST/GraphQL API
Qdrant	Wydajny silnik z Rust, JSON API
FAISS	Biblioteka od Meta (do lokalnego użycia)
Milvus	Duży ekosystem, klastrowy
Chroma	Prostota, idealna do aplikacji RAG

 Jak budować model danych?

Zazwyczaj każdy rekord (np. dokument, paragraf, obraz) zawiera:

json
{
  "id": "doc-123",
  "embedding": [0.11, -0.22, ..., 0.03],
  "metadata": {
    "title": "Jak działa GPT",
    "tags": ["AI", "LLM"],
    "language": "pl"
  }
}

Przykład: Wyszukiwanie podobnych dokumentów

1. Użytkownik wpisuje zapytanie: „Co to jest tokenizacja tekstu?”

2. Zapytanie jest osadzane w wektor.

3. Silnik porównuje go z wektorami w bazie i zwraca najbardziej podobne dokumenty.

4. Backend prezentuje wyniki lub przekazuje kontekst do LLM (RAG).

Wydajność i indeksowanie

Wyszukiwanie po setkach tysięcy lub milionach rekordów wymaga specjalnych algorytmów:

• HNSW (Hierarchical Navigable Small World)
  Struktura grafu oparta na wielu warstwach, gdzie najwyższe poziomy łączą tylko najbardziej reprezentatywne punkty, a niższe warstwy szczegółowo łączą bliskie punkty. Umożliwia bardzo szybkie przechodzenie między odległymi wektorami — zbliżone do działania GPS w nawigacji drogowej.

• IVF (Inverted File Index)
  Przestrzeń wektorów dzieli się na klastry (centroidy), a każdy wektor przypisuje do najbliższego klastra. Wyszukiwanie ogranicza się tylko do kilku najbliższych klastrów, co znacząco przyspiesza czas odpowiedzi.

• PQ (Product Quantization)
  Kompresuje wektory, dzieląc je na podprzestrzenie i kodując każdą z nich jako dyskretny indeks. Dzięki temu zamiast przeszukiwać pełne wektory, algorytm porównuje ich zakodowane, uproszczone wersje — drastycznie redukując zużycie pamięci i czas obliczeń.

Silniki bazują na technikach Approximate Nearest Neighbor (ANN), by przyspieszyć wyszukiwanie kosztem dokładności (co często jest akceptowalne).

Bezpieczeństwo i wyzwania

• Zarządzanie aktualizacjami osadzeń (embedding drift)

• Przechowywanie i prywatność danych

• Integracja z bazami metadanych (SQL/NoSQL)

• Skalowanie i replikacja (dla dużych systemów produkcyjnych)

Podsumowanie

Bazy wektorowe nie zastępują klasycznych baz danych — uzupełniają je w kontekście AI i przetwarzania nieustrukturyzowanych danych. Jeśli tworzysz systemy rekomendacyjne, chatboty, aplikacje RAG lub przeszukujące duże zbiory danych – to narzędzie, które powinieneś poznać.