Paylanmış MCMC Konveyerlərinin Arxitekturası: Go gRPC, pgvector və Next.js Server-Sent Events

Yerli mühitdə R və ya Python ilə işləyən yüksək optimallaşdırılmış statistik skriptdən istehsalat (production) səviyyəli, paylanmış veb arxitekturasına keçid tətbiqi məlumat elmində (data science) ən kritik mühəndislik maneələrindən biridir. Markov Zənciri Monte Karlo (MCMC) alqoritmləri, məsələn, Hamiltonian Monte Karlo (HMC) və ya adaptiv Metropolis-Hastings, təbiəti etibarilə ardıcıl, hesablama baxımından çox ağır və davamlı yaddaş ayrılmasına (memory allocation) ciddi şəkildə ehtiyac duyan proseslərdir. Məlumat elmi komandaları bu modelləri standart Python (məsələn, FastAPI və ya Flask) və ya R (məsələn, Plumber) mühitlərindən istifadə edərək monolit REST API-ləri kimi yerləşdirməyə cəhd etdikdə, arxitektura qaçılmaz olaraq paralel sorğuların (concurrent load) təzyiqi altında çökür. Bu icra mühitlərinin sinxron təbiəti icra axınlarını (threads) bloklayır, nəticədə böyük həcmdə yaddaş sərfiyyatına, kəsilən bağlantılara və gecikmənin (latency) fəlakətli dərəcədə pisləşməsinə səbəb olur.

2026-cı il etibarilə, ehtimal modellərinin yerləşdirilməsi üçün sənaye standartı tamamilə bir-birindən asılı olmayan (decoupled) və başlıqsız (headless) arxitekturanı tələb edir. Biz ağır riyazi nüvələri şəbəkə daşınması təbəqəsindən ayırmalıyıq. Müasir paradiqma statistik alqoritmləri yüksək asinxronluğa malik Go mikroxidmətlərində kapsullaşdırmağı, yaradılan posterior nümunələrini optimallaşdırılmış gRPC kanalları vasitəsilə yayımlamağı, vəziyyət vektorlarını pgvector istifadə edərək PostgreSQL-də yaddaşa yazmağı və konvergensiya metriklərini Next.js App Router ön üzündə (frontend) Server-Sent Events (SSE) vasitəsilə qəbul etməyi nəzərdə tutur. Bu hesabat həmin sistemin qurulmasına aparan tam mühəndislik yolunu təfərrüatı ilə izah edir.

Paylanmış MCMC Mühərriki: Go-da Asinxronluq

Mürəkkəb bir posterior paylanmanı dəqiq qiymətləndirmək üçün geniş səpələnmiş başlanğıc nöqtələrindən başlayan $M$ sayda paralel Markov zəncirini icra etmək standart təcrübədir. Ənənəvi böyük məlumat (big data) mühitlərində, bu zəncirləri məlumat seqmentləri (shards) üzrə paylamaq üçün adətən PySpark kimi çərçivələrdən istifadə olunur. Lakin PySpark-ın JVM əlavə yükü, paylanmış fayl sistemlərinin (HDFS) gecikməsi və qlobal model sinxronizasiyası ilə birləşdikdə, ötürücülük qabiliyyətini kəskin şəkildə məhdudlaşdırır. Testlər göstərir ki, çoxölçülü loqistik reqressiyalar üçün PySpark konfiqurasiyaları saniyədə təxminən 18.7 Effektiv Nümunə Ölçüsü (ESS/s) həddində tıxanır.

Nümunə toplama orkestrasiyasının Go-da yenidən yazılması bu məhdudiyyətləri aradan qaldırır. Go-nun yüngül "goroutine"-ləri və kilidsiz (lock-free) kanalları, əməliyyat sistemi səviyyəli axınlara (OS-level threads) xas olan ağır kontekst dəyişməsi (context-switching) cəzası olmadan tək bir çoxnüvəli maşında minlərlə müstəqil Markov zəncirinin icrasına imkan verir.

gRPC Axını və vtprotobuf Optimallaşdırmaları

Statistik mühərrik ilə veb tətbiqetmə təbəqəsi arasında şəbəkə daşınması üçün HTTP/1.1 üzərindən REST struktur olaraq qeyri-kafidir. REST JSON serializasiyasına əsaslanır ki, bu da hesablama baxımından bahalı olan sətir (string) analizini tələb edir və yaddaş təmizləyicisi (GC) üzərində əhəmiyyətli təzyiq yaradır. Əvəzində, HTTP/2 üzərindən gRPC, binar serializasiya üçün Protocol Buffers (protobuf) istifadə edərək multipleksləşdirilmiş, davamlı bağlantılar təmin edir.

gRPC istifadə etmək qərarı birbaşa aparat təminatının (hardware) istifadə metriklərindən irəli gəlir. Standart protobuf serializasiyası sürətlidir, lakin MCMC çıxışının miqyasında, bir xidmətin saniyədə on minlərlə çoxölçülü sürüşən nöqtəli (float) massiv yayımlaya bildiyi halda, yaddaşın ayrılması (memory allocation) əsas maneəyə çevrilir. vtprotobuf qoşmasının (plugin) tətbiq edilməsi daxil olan və xaric olan axınlar (ingress/egress streams) zamanı yaddaş ayırmalarını hovuzlaşdıraraq (memory pooling) və təkrarlanan struktur (struct) yaradılmasının qarşısını alaraq bu prosesi kəskin şəkildə optimallaşdırır.

Metrik	REST (JSON / HTTP/1.1)	Standart gRPC (Protobuf)	Optimallaşdırılmış gRPC (vtprotobuf + Yaddaş Hovuzu)
Serializasiya Formatı	Mətn (JSON)	Binar	Binar
Bağlantı Yükü	Yüksək (Hər Sorğu Üçün)	Aşağı (Multipleksləşdirilmiş)	Aşağı (Multipleksləşdirilmiş)
CPU İstifadəsi (Xaric olan Axın)	~3.0 Nüvə	~1.6 Nüvə	~0.7 Nüvə
Yaddaş Ayrılması	Davamlı GC təzyiqi	Orta	Minimal (Hovuzlaşdırılmış)
MCMC üçün Uyğunluğu	Zəif	Yaxşı	Mükəmməl

Aşağıda "zombi" hesablamaların yaddaş sızıntısına səbəb olmasının qarşısını almaq üçün müştəri ayrılmalarını təhlükəsiz şəkildə idarə edən və paralel zəncirləri orkestr etmək üçün kanallardan istifadə edən istehsalat səviyyəli Go gRPC xidmətinin tətbiqi verilmişdir.

package main

import (
	"context"
	"math/rand"
	"sync"

	"google.golang.org/grpc/codes"
	"google.golang.org/grpc/status"

	pb "github.com/your-org/mcmc-core/proto" // vtprotobuf generasiyasını fərz edir
)

type MCMCServer struct {
	pb.UnimplementedMCMCServiceServer
}

// StreamPosterior paralel zəncirləri icra edir və nümunələri koordinatora axınla ötürür.
func (s *MCMCServer) StreamPosterior(
	req *pb.SamplingRequest,
	stream pb.MCMCService_StreamPosteriorServer,
) error {
	var wg sync.WaitGroup

	// Şəbəkədəki əks-təzyiq zamanı goroutine-lərin bloklanmasının qarşısını almaq
	// üçün buferləşdirilmiş kanal.
	sampleChan:= make(chan *pb.Sample, 5000)
	errorChan:= make(chan error, req.NumChains)

	// Müştəri bağlantını kəsdikdə goroutine sızıntılarının qarşısını almaq üçün
	// kontekst idarəetməsi.
	ctx, cancel:= context.WithCancel(stream.Context())
	defer cancel()

	// Paralel Markov zəncirlərini başlat.
	for i:= int32(0); i < req.NumChains; i++ {
		wg.Add(1)

		go func(chainID int32) {
			defer wg.Done()

			// Dövr daxilində yaddaş ayırmalarını minimuma endirmək üçün vəziyyət
			// massivini əvvəlcədən ayır.
			state:= make([]float64, req.Dimensions)

			for step:= int32(0); step < req.Iterations; step++ {
				select {
				case <-ctx.Done():
					return // Müştəri ayrıldı; zənciri təhlükəsiz şəkildə sonlandır.
				default:
					// Metropolis-Hastings təklif addımını simulyasiya et.
					for d:= int32(0); d < req.Dimensions; d++ {
						state[d] += rand.NormFloat64() * 0.1
					}

					sampleChan <- &pb.Sample{
						ChainId:   chainID,
						Iteration: step,
						State:     append([]float64(nil), state...),
					}
				}
			}
		}(i)
	}

	// WaitGroup tamamlandıqdan sonra asinxron olaraq kanalı bağla.
	go func() {
		wg.Wait()
		close(sampleChan)
	}()

	// Axın istehlakı dövrü.
	for {
		select {
		case err:= <-errorChan:
			return status.Errorf(codes.Internal, "zəncirin icrası xəta verdi: %v", err)

		case sample, ok:= <-sampleChan:
			if !ok {
				return nil // Axın uğurla tamamlandı.
			}

			if err:= stream.Send(sample); err != nil {
				return err // Şəbəkə xətası.
			}
		}
	}
}

Çoxdilli MCMC Konveyerinin Dockerləşdirilməsi

Bu arxitekturanı yerləşdirmək üçün Go binar faylı konteynerləşdirilməlidir. Köhnə R və ya C++ statistik kitabxanalarını (məsələn, RStan və ya xüsusi Hamiltonian tətbiqləri) cgo vasitəsilə inteqrasiya edərkən, Docker qurulma prosesi son istehsalat obrazının (image) yüngül və təhlükəsiz qalmasını təmin etmək üçün çoxmərhələli (multi-stage) bir yanaşma tələb edir.

İlk mərhələ lazımi C++ alətlərini və R başlıqlarını ehtiva edən ağır kompayler obrazından istifadə edir. Yaradılan statik əlaqələndirilmiş (statically linked) Go binar faylı daha sonra minimal Alpine Linux obrazına ötürülür. Bu, konteynerin həcmini bir neçə giqabaytdan 50 meqabaytın altına endirir, yerləşdirmə vaxtlarını kəskin şəkildə sürətləndirir və hücum səthini (attack surface) azaldır.

# Mərhələ 1: Qurulma mühiti
FROM golang:1.22-bullseye AS builder

# cgo əlaqələndirmələri üçün C++ alətlərini və R kitabxanalarını quraşdır.
RUN apt-get update && apt-get install -y \
        build-essential \
        r-base-core \
        r-cran-rcpp \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY go.mod go.sum./
RUN go mod download

COPY..

# Statik əlaqələndirilmiş binar faylı qur.
RUN CGO_ENABLED=1 GOOS=linux go build \
        -a -installsuffix cgo \
        -ldflags '-extldflags "-static"' \
        -o mcmc_engine.

# Mərhələ 2: Minimal istehsalat obrazı
FROM alpine:3.19

RUN apk --no-cache add ca-certificates

WORKDIR /root/
COPY --from=builder /app/mcmc_engine.

EXPOSE 50051
CMD ["./mcmc_engine"]

Dinamik Konvergensiya Diaqnostikası ($\hat{R}$)

Avtomatlaşdırılmış MCMC yerləşdirilməsində ən böyük risk prosesin vaxtından əvvəl dayandırılmasıdır. Zəncirləri hədəf stasionar paylanmaya çatmazdan əvvəl dayandırmaq güclü qərəzli (biased) parametr qiymətləndirmələri ilə nəticələnir, zəncirləri sonsuzadək işlətmək isə hesablama resurslarını israf edir və infrastruktur xərclərini artırır. Stasionarlığı müəyyən etmək üçün sənaye standartı mexanizmi Gelman-Rubin potensial miqyasın kiçilməsi faktorudur, yəni $\hat{R}$.

$\hat{R}$-in riyazi əsası çoxsaylı müstəqil zəncirlər arasındakı dispersiyanı ($B$) həmin fərdi zəncirlərin daxilindəki dispersiya ($W$) ilə müqayisə etməyə əsaslanır. Əgər zəncirlər eyni posterior fəzasına konvergensiya edibsə (yaxınlaşıbsa), zəncirlərarası dispersiya və zəncirdaxili dispersiya demək olar ki, eyni olmalıdır.

Fərz edək ki, $m$ zəncirlərin sayı, $n$ isə hər zəncir üçün iterasiyaların sayıdır. Zəncirlərarası dispersiya belə müəyyən edilir:

Zəncirdaxili dispersiya belə müəyyən edilir:

Birləşdirilmiş marjinal dispersiya qiymətləndirməsi çəkili orta dəyər kimi hesablanır:

Sonra potensial miqyasın kiçilməsi faktoru aşağıdakı kimi alınır:

İstehsalat mühitində bu diaqnostika geriyə dönük hesablana bilməz. O, daxil olan gRPC axını üzərində dinamik olaraq hesablanmalıdır. Axın irəlilədikcə, həm $B$, həm də $W$ üçün kvadratların davamlı cəmi yenilənir. $\hat{R} \to 1$ olduqda (sənaye konsensusu bütün ölçülər üzrə $\hat{R} \leq 1.05$ kimi ciddi bir həddi diktə edir), orkestrator zəncirlərin qarışdığını əminliklə iddia edə bilər və gRPC axınını sonlandırmaq və goroutine-ləri azad etmək üçün erkən çıxış siqnalını (early exit signal) işə sala bilər.

PostgreSQL 16 və pgvector ilə Çoxölçülü Vəziyyətin Saxlanması

Davamlı posterior vəziyyət axınını saxlamaq çətindir. Tipik bir icra prosesi 4 zəncir üzrə 10,000 iterasiya yarada bilər və hər bir vəziyyət yüzlərlə ölçüdən ibarət olur. Tarixən bu məlumatlar düzəldilərək HDFS-ə və ya obyekt yaddaşına (blob storage) yazılırdı. Lakin pgvector genişlənməsi (v0.8+) ilə birləşdirilmiş PostgreSQL 16, ehtimal paylanmalarını (probabilistic distributions) necə saxladığımızı və təhlil etdiyimizi kökündən dəyişdirir.

MCMC vəziyyət vektorlarını VECTOR tiplərindən istifadə edərək yerli olaraq saxlamaqla biz mürəkkəb analitikaları birbaşa verilənlər bazasının daxilində yerinə yetirə bilərik. Məsələn, posterior nümunələrə k-ən yaxın qonşu (k-NN) sorğularını tətbiq etmək, məlumat alimlərinə çoxmodlu paylanmaları sürətlə aşkar etməyə və ya zaman keçdikcə zəncirlərin trayektoriyasının necə klasterləşdiyini təhlil etməyə imkan verir.

Milyonlarla nümunə üzrə yüksək sürətli sorğuları dəstəkləmək üçün vektorlara Hierarchical Navigable Small World (HNSW) indeksi tətbiq edilir.

İndeks Parametri	Dəyər	MCMC Posterior Məlumatları Üçün Nəticələri
İndeks Tipi	hnsw	Dinamik axınlar üçün IVFFlat-dan üstündür; əvvəlcədən təlim mərhələsi tələb etmir.
Məsafə Metrikası	vector_l2_ops	Evklid məsafəsi posterior daxilindəki parametr vəziyyətləri arasındakı fəza məsafəsini dəqiq təmsil edir.
m	16	İndeksin qurulması zamanı hər bir element üçün yaradılan ikitərəfli əlaqələrin maksimum sayını idarə edir. 16 yadda tutma dərəcəsini (recall) daxiletmə sürəti ilə tarazlaşdırır.
ef_construction	64	Qrafın qurulması zamanı dinamik namizəd siyahısının ölçüsünü müəyyən edir. Daha yüksək dəyərlər daha yavaş daxiletmə bahasına sorğunun dəqiqliyini yaxşılaşdırır.

Tələb olunan verilənlər bazası sxemi yüksək səviyyədə normallaşdırılmış SQL strukturu vasitəsilə icra edilir ki, bu da işin (job) metadatası üçün tranzaksiya bütövlüyünü təmin etməklə yanaşı nümunələr üçün vektor axtarış imkanları verir:

-- Çoxölçülü dəstək üçün pgvector genişlənməsini aktivləşdir.
CREATE EXTENSION IF NOT EXISTS vector;

-- MCMC icraları üçün ciddi relasiyalı bütövlüyü təmin edən metadata cədvəli.
CREATE TABLE mcmc_jobs (
    job_id      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    model_name  VARCHAR(255) NOT NULL,
    dimensions  INT          NOT NULL,
    status      VARCHAR(50)  DEFAULT 'RUNNING',
    created_at  TIMESTAMPTZ  DEFAULT NOW()
);

-- Fərdi posterior vektorları saxlayan zaman seriyası cədvəli.
CREATE TABLE posterior_samples (
    sample_id       BIGSERIAL PRIMARY KEY,
    job_id          UUID REFERENCES mcmc_jobs(job_id) ON DELETE CASCADE,
    chain_id        INT NOT NULL,
    iteration       INT NOT NULL,
    state_vector    VECTOR(256), -- Təbii olaraq 2000 ölçüyə qədər dəstəkləyir.
    log_likelihood  FLOAT,
    created_at      TIMESTAMPTZ DEFAULT NOW()
);

-- L2 məsafə məntiqindən istifadə edərək HNSW indeksini qur.
CREATE INDEX idx_posterior_hnsw
    ON posterior_samples
    USING hnsw (state_vector vector_l2_ops)
    WITH (m = 16, ef_construction = 64);

RSC Sərhədini Aşmaq: Next.js Server-Sent Events

Sonuncu arxitektura komponenti real vaxt konvergensiya məlumatlarının vizuallaşdırma üçün müştərinin brauzerinə çatdırılmasını əhatə edir. REST son nöqtəsini dövri olaraq yoxlamaq (polling) olduqca səmərəsizdir və WebSockets tam dupleks əlaqə təklif etsə də, bağlantı vəziyyətinin idarə edilməsi, təhlükəsizlik divarından (firewall) keçid və yük tarazlayıcı (load balancer) konfiqurasiyası baxımından ciddi infrastruktur mürəkkəbliyi yaradır.

Əvəzində, Server-Sent Events (SSE) mükəmməl birtərəfli ötürmə mühiti təmin edir. Next.js 15 App Router-dən istifadə edərək, yerli veb ReadableStream API vasitəsilə SSE son nöqtəsi (endpoint) qururuq. Bu texnika Next.js-ə standart HTTP keep-alive bağlantısı üzərindən məlumat parçalarını (chunks) serverdən müştəriyə tədricən ötürməyə imkan verir.

Bundan əlavə, bunu Route Handler vasitəsilə idarə etmək məlumat axınının React Server Component (RSC) izləmə sərhədlərinə (trace boundaries) hörmət etməsini təmin edir və hidrasiya uyğunsuzluqlarını (hydration mismatches) yüngülləşdirir. TraceKit kimi müasir müşahidə (observability) alətləri bütün bu konveyeri izləyə bilər və arxa üz (backend) Go gRPC icrasından tutmuş Next.js API təbəqəsinə və oradan da müştəri tərəfi hidrasiya prosesinə qədər iz davamlılığını qoruya bilər.

// app/api/mcmc-stream/route.ts
import { NextRequest } from "next/server";
import { createGrpcClient, createDbPool } from "@/lib/infrastructure";
import { calculateRHat } from "@/lib/statistics";

// Dinamik icranı məcbur et; axının statik keşlənməsinin qarşısını al.
export const dynamic = "force-dynamic";

export async function GET(req: NextRequest) {
  const encoder = new TextEncoder();
  const jobId = req.nextUrl.searchParams.get("jobId");

  const stream = new ReadableStream({
    async start(controller) {
      const grpcClient = createGrpcClient();
      const db = createDbPool();
      const stateBuffer = [];

      try {
        const streamCall = grpcClient.streamPosterior({
          numChains: 4,
          dimensions: 256,
          iterations: 10000,
        });

        for await (const sample of streamCall) {
          // Vektoru asinxron olaraq PostgreSQL pgvector-a yaz.
          await db.query(
            `INSERT INTO posterior_samples (job_id, chain_id, iteration, state_vector)
             VALUES ($1, $2, $3, $4)`,
            [jobId, sample.chainId, sample.iteration, `[${sample.state.join(",")}]`]
);

          stateBuffer.push(sample);

          // Dövri olaraq Gelman-Rubin konvergensiya diaqnostikasını hesabla.
          if (stateBuffer.length % 100 === 0) {
            const rHat = calculateRHat(stateBuffer);

            const data = JSON.stringify({
              chain: sample.chainId,
              iteration: sample.iteration,
              primary_dimension: sample.state[0], // İzləmə qrafiki üçün çıxarılan xüsusiyyət.
              rHat,
            });

            controller.enqueue(encoder.encode(`data: ${data}\n\n`));

            // Stasionarlıq hədlərinə əsaslanaraq dayandırma qaydasını tətbiq et.
            if (rHat < 1.05 && sample.iteration > 2000) {
              controller.enqueue(
                encoder.encode(`event: convergence\ndata: {"status": "converged"}\n\n`)
);

              await db.query(
                `UPDATE mcmc_jobs SET status = 'COMPLETED' WHERE job_id = $1`,
                [jobId]
);

              break; // gRPC axınını zərifliklə bağla.
            }
          }
        }
      } catch (error) {
        console.error("SSE axını xətası:", error);
        controller.enqueue(
          encoder.encode(`event: error\ndata: {"message": "Nəticəçıxarma uğursuz oldu"}\n\n`)
);
      } finally {
        controller.close();
      }
    },
  });

  // Standart SSE başlıqlarını brauzerə qaytar.
  return new Response(stream, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache, no-transform",
      Connection: "keep-alive",
    },
  });
}

Müştəri tərəfi arxitekturası ardınca məlumatlar daxil olduqca dinamik, bloklamayan iz qrafiklərini render etmək üçün EventSource və React Suspense-dən istifadə edir. Bu, məlumat aliminə bütün məlumat bazasının brauzer yaddaşına yüklənməsini tələb etmədən zəncir qarışmasını və stasionarlığını dərhal vizual olaraq təsdiqləməyə imkan verir.

Yekunlaşdırsaq, müasir ehtimal konveyerinin mühəndisliyi ciddi sistem ayrılması (decoupling) məşğələsidir. Go-nun aşağı gecikməli asinxronluğunu, gRPC-nin binar səmərəliliyini, PostgreSQL pgvector-un qabaqcıl çoxölçülü indeksləşdirilməsini və Next.js Server-Sent Events-in qüsursuz axın imkanlarını birləşdirərək, qabaqcıl statistik modelləri ən ciddi istehsalat mühitlərinə yerləşdirməyə qadir olan davamlı bir arxitektura qururuq.