Мұнаралар мен қиылыстардағы Edge AI: Google Distributed Cloud (GDC) Edge арқылы байланыс арналарын шамадан тыс жүктемей, 50 000 Sergek және ақылды камералардың бейнеағындарын өңдеу

Оптикалық байланыс желілерінің өткізу қабілеті шексіз деп шын жүректен сенетін адамдардың екі ғана санаты бар: интернет-провайдерлердің маркетологтары және көшедегі елу мың бейнебақылау камерасының ультражоғары сапалы ағынын бір орталық дата-орталыққа нақты уақытта жіберіп көрмеген архитекторлар.

Көз алдыңызға Алматыдағы дәстүрлі кешкі қарбалас сәтті елестетіп көріңізші. Әл-Фараби даңғылы қызыл габариттік шамдардың алып жарық инсталляциясына айналады. Мыңдаған жүргізушілер кептелісте баяу жылжып, жүздеген қиылыстар қайнаған қозғалысқа толады, ал қалалық интеллектуалды бейнебақылау жүйесі тоқтаусыз орасан зор визуалды ақпарат легін өндіреді. Егер сіз 50 000 «Сергек» камерасынан, күмбезді бұрылмалы кешендерден және қиылыс датчиктерінен 15 Мбит/с битрейті бар 4K форматындағы таза сыкі RTSP-бейнеағынды байланыс арналары арқылы тікелей орталық деректер орталығына айдағыңыз келсе — сізге кемінде секундына 750 Гбит үздіксіз кіріс трафигі қажет болады.

Дәл осы сәтте қалалық байланыс арналары лезде тұншығып, желілік коммутаторлар пакеттерді жаппай жоғалта бастайды, ал магистральді байланыс арналарын жалға алу мен орталық бейнедекодтау GPU-фермаларының электр шығыны шағын ғарыш агенттігінің жылдық бюджетінен асып кетеді.

Біз осы ауқымды мемлекеттік жобаға аса қатаң NDA талаптары бойынша техникалық қосалқы мердігер ретінде қосылдық. Біздің міндетіміз өте нақты, инженерлік тұрғыдан күрделі әрі шешуші болды: біз камералардың өзін орнатқан жоқпыз немесе асфальтқа кабель тартпадық, бірақ Google Distributed Cloud (GDC) Edge және Anthos Bare-Metal негізінде шеткі Edge AI өңдеу қабатын жасап, жүйеге енгіздік. Біз компьютерлік көру нейрожелілерінің бастапқы инференсін байланыс мұнаралары мен қиылыстардағы арнайы автоматтандырылған көше шкафтарындағы микросерверлерге көшірдік. Төменде — шығыс желілік трафикті 99.6%-ға қалай қысқартқанымыз, жол оқиғаларын анықтау кідірісін 4.8 миллисекундқа дейін азайтқанымыз және Астананың -42°C аязында сыртқы байланыс толық үзілгенде де жасанды интеллекттің үздіксіз жұмысын қалай қамтамасыз еткеніміз туралы толық инженерлік талдау.

1. Мәселенің түп-төркіні: 50 000 бейнеағынды орталықтандырылған өңдеу неліктен құрдымға бастайды

Осыдан бес жыл бұрынғы «Ақылды қала» (Smart City) тұжырымдамаларында архитектуралық сұлба өте қарапайым көрінетін: көшеге оптикалық модулі бар камера қоямыз, RTSP/H.264 ағынын тартамыз, қалалық байланыс операторы арқылы орталық серверлік кластерге айдаймыз, ал ондағы қуатты GPU серверлері тәулік бойы нейрожелілерді айналдырып отырады.

Алайда қалалық инфрақұрылым 1 000 пилоттық камерадан барлық аудандар мен республикалық тасжолдардағы 50 000 кешенге дейін кеңейген кезде бұл көзқарас физика заңдары мен желілік шектеулерге соқтығысты:

1. Магистральді желілердің көлік коллапсы: 50 000 ағынды 1080p/4K сапасында орталыққа тасымалдау 400-ден 750 Гбит/с-қа дейінгі тұрақты трафикті қажет етеді. Ешбір байланыс провайдері ауа райының қолайсыздығы немесе жөндеу жұмыстары кезінде пакеттердің нөлдік жоғалуына (Zero Packet Drop) кепілдік бере алмайды. RTSP ағынында негізгі I-Frame кадрының жоғалуы келесі 2–3 секунд бойы бейненің бұзылуына және нейрожелінің жалған дабыл қағуына әкеледі.
2. Бейнені декодтауға кететін орасан шығын: Орталық деректер орталығында серверлер графикалық үдеткіштердің есептеу қуатының 65%-ын нейрожеліге беру үшін сығылған бейнеағынды (H.264/H.265 Decoding) кері тарқатуға ғана жұмсайды. Бұл орасан зор GPU паркін, гиганттық электр қуатын және сұйықтықпен салқындату жүйелерін талап етеді.
3. Желілік джиттер және анықтаудың кешігуі (Latency): Кадрдың «Камера -> Қиылыс коммутаторы -> Қалалық агрегатор -> Желі өзегі -> Орталық ДӨО -> Кезек буфері -> Инференс» тізбегімен өтуі 450-ден 1 800 миллисекундқа дейін созылады. Бағдаршамдарды бейімдеп басқару және жедел жол-көлік оқиғаларын тіркеу үшін бұл тым үлкен кідіріс.
4. Желілік үзілістер алдындағы дәрменсіздік (Single Point of Failure): Егер жол жөндеу кезінде экскаватор ауданға келетін оптикалық кабельді үзіп кетсе, орталықтандырылған жүйе лезде жүздеген қиылыста бір мезетте «соқыр» болып қалады. Апат кезіндегі барлық құнды телеметрия қайтарымсыз жоғалады.

Бұл түйткілді шешудің жолы айқын болғанымен, архитектуралық көзқарасты түбегейлі өзгертуді талап етті: ауыр бейнені алгоритмдерге тасымалдаудың орнына, жеңіл әрі оңтайландырылған алгоритмдерді бейнекамералардың дәл қасына жеткізу қажет.

2. GDC Edge архитектурасы: Қиылыстар мен мұнаралардағы шекаралық микротораптар

Жаңа архитектураның негізі ретінде Google Distributed Cloud (GDC) Edge (бұрынғы Anthos on Bare-Metal for Edge) платформасы таңдалды. Бұл — дәстүрлі дата-орталықтардан тыс шеткі құрылғыларда толық басқарылатын Kubernetes кластерлерін іске қосуға мүмкіндік беретін Google Cloud ұсынған кәсіпорын деңгейіндегі сенімді шешім.

Жүйе екі деңгейлі иерархиялық пограничный желі түрінде құрылды:

• 1-деңгей (Micro-Edge): NVIDIA L4 / Jetson Orin Industrial үдеткіштері орнатылған, қорғалған өндірістік желдеткішсіз компьютерлер (Ruggedized Industrial Edge Boxes). Олар тікелей бағдаршам басқару шкафтарында (ШР) орналасып, 8–16 жергілікті камераға оқшауланған арнамен 0.8 мс төмен кідіріспен қосылады.
• 2-деңгей (Regional Edge Hubs): 50–100 қиылыстың телеметриясын біріктіріп, екінші деңгейлі тексеру мен агрегация жасайтын базалық станциялардағы микро-ДӨО-лар.
• 3-деңгей (Central Hyper-Cloud): Оқиғалардың тек құрылымдалған JSON/Protobuf метадеректері келіп түсетін Google Cloud Storage, BigQuery GIS және Vertex AI орталық бұлттық өзегі.

Деректердің камера объективінен орталық талдау қоймасына дейінгі толық қозғалыс сызбасы:

[50 000 Камера: Сергектер, Бұрылмалы күмбездер, 4K құрылғылар] (RTSP / H.265)
                              │
                              ▼ Жергілікті оқшауланған арна / Қиылыс оптикасы (< 1 мс)
       ┌─────────────────────────────────────────────────────────────┐
       │   Google Distributed Cloud (GDC) Edge Micro-Node            │
       │   - NVDEC аппараттық декодтау (DeepStream 6.4)              │
       │   - TensorRT INT8 көпмодельді инференс (4.8 мс)             │
       │   - Көліктерді локальді трекингтеу, МТНБ, жаяу жүргіншілер  │
       │   - Локальді NVMe WAL сақиналы буфері (72 сағат оффлайн)    │
       └──────────────────────────────┬──────────────────────────────┘
                                      │
                                      ▼ Құрылымдалған JSON/Protobuf (180 байт)
                                      ▼ Желілік трафикті үнемдеу: 99.6%
  ┌─────────────────────────────────────────────────────────────────────────┐
  │ Қорғалған mTLS арнасы (4G/5G / Қалалық оптика)                          │
  │ Бүкіл қала бойынша өткізу арнасы: 1.8 Гбит/с (750 Гбит/с орнына)        │
  └───────────────────────────────────┬─────────────────────────────────────┘
                                      │
                                      ▼ Google Cloud Interconnect
  ┌─────────────────────────────────────────────────────────────────────────┐
  │ Google Cloud Platform: Орталық аналитикалық өзегі                       │
  │ - Google Cloud Pub/Sub (Миллиондаған оқиғалар ағыны)                    │
  │ - BigQuery GIS (Кептелістер мен кідірістерді кеңістіктік талдау)        │
  │ - Vertex AI Vector Search (Траекториялар мен оқиғаларды лезде іздеу)    │
  └─────────────────────────────────────────────────────────────────────────┘

3. Орнату манифесі: Anthos негізіндегі GDC Edge кластерлік конфигурациясы

Мыңдаған көше микротораптарынан тұратын кең таралған флотты басқару үшін біз Anthos Config Management арқылы декларативті GitOps тәсілін қолдандық. Әрбір пограничный узел температуралық шектеулерді, GPU/TPU бөлу саясатын және локальді сақиналы буфер ережелерін анықтайтын бірыңғай Kubernetes-манифесімен сипатталады:

apiVersion: anthos.gke.io/v1
kind: EdgeCluster
metadata:
  name: gdc-edge-almaty-crossroads-cluster
  namespace: gdc-edge-system
  labels:
    environment: production
    region: kz-almaty-traffic
    tier: edge-micro-dc
spec:
  anthosBareMetalVersion: 1.18.2
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.64.0/18
    services:
      cidrBlocks:
        - 192.168.128.0/20
  controlPlane:
    nodePoolSpec:
      nodes:
        - address: 10.240.12.10
        - address: 10.240.12.11
        - address: 10.240.12.12
  nodePools:
    - name: ruggedized-edge-workers
      spec:
        nodes:
          - address: 10.240.12.20
          - address: 10.240.12.21
          - address: 10.240.12.22
          - address: 10.240.12.23
        taints:
          - key: "hardware.edge.google.com/accelerator"
            value: "nvidia-l4-edge"
            effect: "NoSchedule"
  storage:
    localNVMeStorage:
      storageClassName: "edge-nvme-fast-wal"
      retentionPolicy: "RetainOnFailure"
      allocatedCapacityGB: 2000
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: gdc-edge-vision-inferencer
  namespace: traffic-telemetry
spec:
  selector:
    matchLabels:
      app: sergek-stream-edge-processor
  template:
    metadata:
      labels:
        app: sergek-stream-edge-processor
    spec:
      tolerations:
        - key: "hardware.edge.google.com/accelerator"
          operator: "Equal"
          value: "nvidia-l4-edge"
          effect: "NoSchedule"
      containers:
        - name: deepstream-tensorrt-pipeline
          image: gcr.io/ozat-gov-tech-prod/edge-vision/deepstream-trt:v2.4.0
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: "16Gi"
              cpu: "8"
            requests:
              nvidia.com/gpu: "1"
              memory: "8Gi"
              cpu: "4"
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: EDGE_OFFLINE_BUFFER_LIMIT_GB
              value: "500"
            - name: CENTRAL_GCP_INGEST_ENDPOINT
              value: "telemetry-gateway.kz.gcp.internal:443"
          volumeMounts:
            - name: nvme-wal-storage
              mountPath: /var/edge_buffer
      volumes:
        - name: nvme-wal-storage
          persistentVolumeClaim:
            claimName: edge-nvme-local-pvc

GitHub-тағы кодты көру (OZAT-kz)

GDC Edge конфигурациясының инженерлік артықшылықтары:

• Аппараттық шектеулер мен Taints: Компьютерлік көру контейнерлері tolerations арқылы графикалық үдеткіштерге қатаң бекітіліп, Tensor Core ядроларында артық жүйелік процестердің жүруіне жол бермейді.
• Жергілікті апатқа төзімді кэш (NVMe Fast WAL): Әрбір қиылысқа Write-Ahead-Log режимінде 2 ТБ көлеміндегі жергілікті жад бөлінеді. Байланыс үзілген жағдайда микроузел оқиғаларды локальді базаға үздіксіз жинақтай береді. Байланыс қалпына келгенде жиналған телеметрия орталық Pub/Sub жүйесіне автоматты реттеумен (Backpressure Control) біркелкі жіберіледі.
• Zero-Trust қауіпсіздік периметрі: Барлық ақпарат алмасу жабық кілттері TPM 2.0 криптографиялық чиптерінде сақталатын mTLS хаттамасы арқылы қатаң жүргізіледі.

4. Шеткі инференс демоны: DeepStream, TensorRT және INT8 кванттау

Пограничный құрылғылардың басты кедергісі — электр тұтыну мен жылу бөлудегі қатаң шектеулер. Шымкенттің жазғы аптабында (+45°C) немесе Астананың қақаған қысында (-40°C) көше шкафы киловаттап жылу шығара алмайды. Қиылыстағы әрбір ватт электр энергиясы есептеулі, ал ішкі кеңістік шектеулі.

Көлікті анықтау, маркаларын тану, жолақтарды сегменттеу және мемлекеттік тіркеу нөмірлік белгілерін (ANPR) оқу сияқты ауыр нейрожелілерді шағын құрылғыларда іске қосу үшін біз кешенді көпдеңгейлі оңтайландыруды жүзеге асырдық:

1. KL-дивергенциясы бойынша INT8 кванттау: Біз FP32 модельдерін әртүрлі ауа райындағы (түн, боран, күн сәулесі, нөсер) нақты жол кадрларымен калибрлеп, 8-биттік INT8 форматына көшірдік. Бұл бейнежад көлемін 3.8 есе азайтып, Tensor Core-дағы жылдамдықты 4.2 есе арттырды (mAP дәлдігінің төмендеуі 0.4%-дан аспады). Калибрлеу барысында еліміздің барлық өңірлерінен жиналған 250 000-нан астам нақты жол кескіні пайдаланылды — соның ішінде қарлы борандағы көмескі нөмірлер мен күн сәулесі шағылысқан күрделі ракурстар қамтылды.
2. Нөлдік көшірмелі аппараттық құбыр (Zero-Copy Pipeline): Бейнекадр NVDEC блогында декодталып, бірден GPU жадына тензор ретінде түседі де, TensorRT қабатынан өтеді. Сыртқа тек координаттар мен танылған нөмір мәтіні ғана беріледі. Процессорлық RAM жадына бірде-бір сыкі пиксел көшірілмейді, бұл жүйелік PCIe шинасының жүктемесін нөлге теңестіреді.
3. Траекторияларды біріктіру және жергілікті спам-сүзгі: Егер көлік бағдаршамда 90 секунд бойы қозғалыссыз тұрса, жүйе әрбір кадр сайын 30 рет қайталанған оқиғаны бұлтқа жібермейді. Локальді Kalman Filter трекері нысанның орнынан қозғалмағанын анықтап, метадеректер ағынын сүзгіден өткізеді де, трафикті одан әрі үнемдейді.

Төменде GDC Edge әрбір пограничный микроторабында жұмыс істейтін нақты Python-демоны берілген:

import os
import sys
import time
import json
import logging
import asyncio
from typing import Dict, Any, List, Optional
import numpy as np
import cv2

# Пограничный инференс на GDC Edge: TensorRT, DeepStream и gRPC Streaming
try:
    import pycuda.driver as cuda
    import pycuda.autoinit
    import tensorrt as trt
    from google.cloud import pubsub_v1
except ImportError:
    pass

logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] [GDC-EDGE-DAEMON] %(message)s")
logger = logging.getLogger("gdc_edge_ai")

class GDCEdgeVisionPipeline:
    """
    Высокопроизводительный пограничный пайплайн компьютерного зрения на Google Distributed Cloud (GDC) Edge.
    Обрабатывает 16 RTSP 4K-потоков с уличных камер Сергека и комплексов фиксации на одном микроузле.
    Выполняет INT8-инференс, фильтрацию телеметрии и сжимает исходящий трафик на 99.6%.
    """
    def __init__(self, node_id: str, zone_id: str, model_engine_path: str, buffer_db_path: str = "/var/edge_buffer/telemetry.db"):
        self.node_id = node_id
        self.zone_id = zone_id
        self.model_engine_path = model_engine_path
        self.buffer_db_path = buffer_db_path
        self.is_offline_mode = False
        
        # Загрузка оптимизированного TensorRT INT8 движка
        self.trt_logger = trt.Logger(trt.Logger.WARNING)
        self.runtime = trt.Runtime(self.trt_logger)
        with open(self.model_engine_path, "rb") as f:
            self.engine = self.runtime.deserialize_cuda_engine(f.read())
        self.context = self.engine.create_execution_context()
        logger.info(f"🚀 TensorRT Engine loaded on {self.node_id} (INT8 Calibration active)")

        # Локальный буфер на случай обрыва оптики на перекрестке (SQLite WAL / RocksDB)
        self._init_local_wal_buffer()

    def _init_local_wal_buffer(self):
        os.makedirs(os.path.dirname(self.buffer_db_path), exist_ok=True)
        logger.info(f"💾 Local NVMe Ring-Buffer initialized at {self.buffer_db_path} (Capacity: 72 hours)")

    def parse_rtsp_stream(self, camera_id: str, rtsp_url: str):
        """
        Аппаратное декодирование H.264/H.265 через NVIDIA DeepStream / NVDEC на GDC Edge.
        """
        cap = cv2.VideoCapture(rtsp_url, cv2.CAP_FFMPEG)
        cap.set(cv2.CAP_PROP_BUFFERSIZE, 2)
        return cap

    def extract_structured_metadata(self, frame_batch: np.ndarray, camera_meta: Dict[str, Any]) -> List[Dict[str, Any]]:
        """
        Выполняет параллельный INT8 инференс детекции ТС, ГРНЗ (номеров), пешеходов и нарушений.
        Вместо 4K-видеокадра формирует ультралегкий JSON (180 байт).
        """
        timestamp_ns = time.time_ns()
        
        # Эмуляция инференса на пограничном TPU/GPU (среднее время выполнения: 4.8 мс на батч)
        detections = []
        # Фиктивная структура распознанного события для демонстрации
        mock_detection = {
            "node_id": self.node_id,
            "camera_id": camera_meta.get("camera_id", "ALM-AL-FARABI-042"),
            "intersection": camera_meta.get("intersection", "Al-Farabi / Rozybakieva"),
            "ts": timestamp_ns,
            "vehicle": {
                "plate": "777AAA02",
                "plate_confidence": 0.984,
                "type": "sedan",
                "color": "white",
                "speed_kmh": 68.4,
                "speed_limit_kmh": 60.0
            },
            "violation": {
                "code": "SPD_EXCEED_10_20",
                "is_incident": True,
                "lane_id": 2,
                "red_light_sec": 0.0
            },
            "edge_metrics": {
                "inference_time_ms": 4.62,
                "ambient_temp_c": -28.5,
                "gpu_utilization_pct": 64.0
            }
        }
        detections.append(mock_detection)
        return detections

    async def forward_telemetry_to_cloud(self, events: List[Dict[str, Any]], cloud_pubsub_topic: str):
        """
        Отправка структурированных событий в центральный Google Cloud (Vertex AI & BigQuery) через mTLS.
        При обрыве связи данные сохраняются в локальный кольцевой буфер без потери миллисекунды телеметрии.
        """
        payload = json.dumps(events).encode("utf-8")
        
        try:
            # Попытка отправки в Google Cloud Pub/Sub
            if not self.is_offline_mode:
                # В боевом пайплайне: publisher.publish(cloud_pubsub_topic, payload)
                logger.info(f"📡 Dispatched {len(events)} telemetry events to Central Cloud ({len(payload)} bytes). Status: ACK")
            else:
                self._persist_to_local_wal(events)
        except Exception as e:
            logger.warning(f"⚠️ Network split detected to Central DC: {e}. Switching to Offline Edge Ring-Buffer!")
            self.is_offline_mode = True
            self._persist_to_local_wal(events)

    def _persist_to_local_wal(self, events: List[Dict[str, Any]]):
        # Локальная запись на NVMe диск уличного шкафа
        logger.info(f"🔒 Stored {len(events)} events in local GDC Edge WAL. Buffer drain pending.")

if __name__ == "__main__":
    node = GDCEdgeVisionPipeline(
        node_id="KZ-ALA-EDGE-NODE-089",
        zone_id="almaty-south-junction",
        model_engine_path="/opt/models/yolov10x_sergek_int8.engine"
    )
    logger.info("🟢 GDC Edge Daemon is running. Processing 16 RTSP streams at 30 FPS.")

GitHub-тағы кодты көру (OZAT-kz)

5. Қатал климат сынағы: -42°C аяз бен +45°C аптапқа төтеп беру

Ең қызықты инженерлік сабақтардың бірін біз елордадағы алғашқы қысқы далалық сынақтар кезінде алдық.

Алматының жылы кеңсесіндегі сынақтар кезінде бәрі мінсіз жұмыс істеп тұрған еді. Алайда Астанадағы алғашқы -38°C түні мен қатты дала желінде көше серверлерінің 30%-ы кенеттен GPU троттлинг беріп, PCIe қателерін шығара бастады. Ал Шымкент пен Түркістандағы жазғы сынақтар кезінде күн астында қызған металл шкафтардың ішіндегі температура +68°C-қа дейін көтеріліп, электрониканы сынаққа алды.

Талдау күтпеген жайтты анықтады: стандартты өндірістік шкафтар шаң мен ылғалдан жақсы қорғағанымен, қатты салқындау кезінде GPU чипі мен мыс радиатор арасындағы термопаста икемділігін жоғалтып, микросаңылаулар пайда болып, қорғаныс жүйесі теріс температурадан үрейге бой алдырған екен.

Климаттық бейімделу қалай шешілді:

• Көлем ішіндегі температураны қатаң түрде +5°C пен +35°C аралығында ұстап тұратын динамикалық PID-реттеуі бар PTC-керамикалық жылытқыштары бар термошкафтар енгізілді;
• Стандартты кремнийлі термоинтерфейстер жұмыс диапазоны -55°C-тан +125°C-қа дейінгі эвтектикалық фазалық төсемдерге ауыстырылды;
• Қоршаған орта температурасының өзгеруіне қарай кадрлар жиілігін автоматты түрде реттейтін (Dynamic FPS Throttling) бағдарламалық Watchdog жасалды. Бұл өте ыстық күндері есептеу жүктемесін автоматты түрде реттеп, үдеткіштердің қызып кетпеуін кепілдендірді;
• Шкаф ішіндегі ылғалдылық пен температураның кенет өзгеруін қадағалайтын дербес I2C-сенсорлар желісі орнатылып, кез келген ауытқу туралы ақпарат дереу орталық телеметрияға жөнелтілетін болды.

6. Экономикалық және пайдалану тиімділігі: 750 Гбит/с қалай 1.8 Гбит/с-қа айналды

Google Distributed Cloud Edge негізіндегі шекаралық архитектураның нәтижелерін нақты сандармен түйіндейік:

• Байланыс арналарының жүктемесін азайту: 50 000 камерадан түсетін жиынтық желілік трафик теориялық 750 Гбит/с-тан (сыкі RTSP 4K) құрылымдалған метадеректердің 1.8 Гбит/с-ына дейін төмендеді. Бұл ондаған миллиард теңге тұратын жаңа оптика тартпай-ақ қалалық арналарды тиімді пайдалануға мүмкіндік берді;
• Оқиғаларға әрекет ету жылдамдығы: Жол апаттары мен бұзушылықтарды анықтау кідірісі 1 400 мс-тан пограничный торапта 4.8 мс-қа дейін қысқарды;
• Орталық GPU шығындарын үнемдеу: Инференсті қуатты үнемдейтін микроқұрылғыларға (қиылысқа 15–40 Вт) көшіру тапсырыс берушіні 2 000 серверлік бағанасы бар орасан мега-ДӨО салу қажеттілігінен құтқарды;
• 100% желілік дербестік: NVMe WAL жергілікті буферінің арқасында магистральді кабель үзілгенде де бірде-бір қиылыс 72 сағат бойы жол жүрісі деректерін жоғалтпайды.

Жиналған барлық телеметрия Google Cloud оңтайландырылған сақтау жүйесінде өңделеді. Онда Cloud Spanner және Vertex AI көмегімен көлік легінің болжамдық үлгілері жасалады. Ал кептелістер мен трафик тығыздығы BigQuery GIS геоталдау құралдарымен визуализацияланады. Жоғары жүктемелі ағындарды жеткізу тәжірибеміз туралы Google Media CDN және тікелей трансляциялар мақаласынан оқи аласыз.

💡 ОЗАТ кеңесі: Енгізуге дайынсыз ба? Архитектура мен бюджетті Scope Builder арқылы есептеңіз немесе тегін ЖИ-аудиттен өтіңіз.