1. סקירה כללית
בעולם של תעשיות קריטיות ומפוקחות, ארגונים מתמודדים עם פרדוקס עצום: איך אפשר להטמיע AI מתקדם כדי לשפר את הייצור, כשמדיניות אבטחת הסייבר מחייבת שהנתונים לא ייחשפו אף פעם לאינטרנט הציבורי? רשתות אינטראנט והאינטרנט הציבורי מופרדים לחלוטין, ואין ביניהם שום קשר. למרות שבתעשיית הייצור המודרנית יש צורך נואש ב-AI חזוי כדי למנוע כשלים קטסטרופליים בציוד ולשפר את התפוקה, שליחת יומני טלמטריה רגישים, מתכוני סגסוגת מוגנים בפטנט או נתוני ERP ל-Cloud APIs של ענן ציבורי היא למעשה דבר שלא בא בחשבון. לכן, אם אי אפשר להעביר את הנתונים לענן, הענן צריך להגיע לנתונים.
ב-Codelab הזה נביא את הכלים המתקדמים ביותר של Google Cloud לנתונים ול-AI ישירות לסביבות מנותקות ומאובטחות מאוד באמצעות Gemma 4 ו-AlloyDB Omni.
AlloyDB Omni: הכספת האולטימטיבית לנתונים
אפשר לחשוב על AlloyDB Omni ככספת עם ביצועים גבוהים. זהו מסד נתונים בקונטיינר ברמה שמתאימה לארגונים, שאפשר להוריד ולהריץ באופן מלא ברשת האינטראנט המאובטחת שלכם.
- שילוב חלק: הוא מתחבר ישירות לחיישני הייצור (כמו VIM או מכבש כבד) ולמערכות ERP מקומיות (כמו Oracle R12).
- אחסון שמותאם ל-AI: הוא מאחסן באופן מאובטח גיליונות תהליכים סודיים ביותר באמצעות הטמעות וקטורים לחיפוש מבוסס-AI (pgvector).
- ביצועים: הוא עולה משמעותית על הביצועים של PostgreSQL הרגיל, גם בעומסי עבודה כבדים של טרנזקציות וגם בעיבוד באמצעות AI.
מומחי AI מקומיים: Gemma, TimesFM, TabFM
במקום להשתמש בממשקי API מרוחקים, אתם יכולים להוריד מודלים עם משקלים פתוחים ולהריץ אותם באופן מקורי בחומרה המקומית שלכם, בלי דליפת נתונים דרך ה-API.
- Gemma: מודל שפה גדול (LLM) עם משקלים פתוחים של Google, שפועל כמומחה למחקר ופיתוח. הוא יכול לקרוא בצורה מאובטחת יומנים היסטוריים או לנתח מתכונים מורכבים של סגסוגות שרשומות כפטנט כדי לחזות מאפיינים מכניים.
- TimesFM (The Numerical Forecaster): מודלים גדולים של שפה (LLM) לפעמים "הוזים" מספרים, ולכן מכונות כבדות דורשות מודל בסיס ייעודי של סדרות זמנים. מודל TimesFM חוזה במדויק אופקים מספריים לטווח ארוך (עד 16,000 נקודות על הגרף), קורא יומני רטט וטמפרטורה כדי לחזות עקומות מדויקות של כשלים בציוד – באופן אופליין לחלוטין.
- TabFM (The Tabular Reasoner): בעוד שמודלי LLM מטפלים בטקסט ו-TimesFM מטפל במגמות מספריות, TabFM מתמחה בהסקת מסקנות על סמך נתונים בטבלאות מובנות. אפשר להריץ אותו באופן מאובטח בארגון כדי לבצע ניתוחים מורכבים ולענות על שאלות ישירות מנתוני ERP או CRM צפופים עם כמה עמודות, בלי צורך לכתוב שאילתות SQL join מורכבות.
תרחיש לדוגמה
תחזוקה חזויה במכבש חישול של 1,500 טון:
זמן השבתה לא מתוכנן של המכונות הענקיות האלה עוצר את הייצור, וגורם לבזבוז עצום של זמן וחומרים קריטיים. לעומת זאת, בתחזוקה מתוזמנת, לעיתים קרובות מחליפים חלקים יקרים מוקדם מדי, וזה בזבוז של תקציב. אנחנו צריכים לעבור מתחזוקה תגובתית לתחזוקה חזויה בלי לפגוע ב-air gap.
מה תלמדו
ב-Codelab הזה:
- תשתמשו ב-AlloyDB Omni כדי לתעד באופן מאובטח נתונים מחיישני רטט וטמפרטורה באופן מקומי. אתם יכולים להוסיף עוד פרמטרים כדי להפוך את הנתונים למציאותיים ושימושיים יותר.
- תלמדו איך להשתמש ב-Gemma כדי לנתח את המגמות בהשוואה ליומני כשלים היסטוריים.
- תבנו מערכת שחוזה תקלות ומפעילה באופן אוטומטי הזמנות עבודה מדומות לניהול נכסים ב-ERP שלכם.
אנחנו משתמשים ב-Docker כדי להקצות גם את ה-LLM המקומי וגם את AlloyDB Omni. היופי בגישה הזו הוא הפשטות שלה: AlloyDB Omni יכול לנהל באופן אוטומטי את תהליך ה-ML-Agent הפנימי שלו.
דרישות
- היכרות בסיסית עם SQL.
- מכונה וירטואלית רגילה של Linux (למשל, Ubuntu 22.04) או מכונה מקומית (macOS או Windows) שמותקן בה Docker.
2. הפעלת ה-LLM המקומי (Gemma 4)
נשתמש ב-Ollama כדי לארח את Gemma באופן מקומי. יוצרים קובץ Docker כדי להגדיר את מכונת Ollama:
- במחשב המקומי, מריצים את הפקודות הבאות בטרמינל, אחת אחרי השנייה:
mkdir -p gemma4-ollama && cd gemma4-ollama
cat << 'EOF' > Dockerfile
FROM ollama/ollama:latest
ENV OLLAMA_HOST=0.0.0.0:8080
ENV OLLAMA_MODELS=/root/.ollama
ENV MODEL=gemma4:e2b
RUN ollama serve & sleep 5 && ollama pull $MODEL
ENTRYPOINT ["ollama", "serve"]
EOF
- יוצרים ומריצים את הקונטיינר ברשת המארחת:
docker build -t gemma4-local .
docker run --network host -d -p 8080:8080 --name gemma4-ollama-instance gemma4-local
- כדי לבדוק את זה, אפשר להשתמש בפקודה:
curl -X POST http://localhost:8080/api/generate -d '{
"model": "gemma4:e2b",
"prompt": "Hello! Explain Gemma 4 in a few sentences."
}'
3. התקנה והפעלה של AlloyDB Omni
בשלב הבא, מפעילים את מאגר מסד הנתונים של AlloyDB Omni, גם ברשת המארחת:
docker run -d \
--name my-omni \
--network host \
-e POSTGRES_PASSWORD=omni \
gcr.io/alloydb-omni/alloydbomni:18
אם לא נמצאה קובץ אימג' של AlloyDB Omni מפרויקט בענן שלכם ב-Google Cloud, נסו לבצע אימות על ידי הרצת הפקודה לפני הרצת הפקודה docker run שלמעלה:
gcloud auth login
אחרי שהאימות מסתיים, מנסים להריץ שוב את הפקודה docker run.
4. הפעלת סוכן ה-ML הפנימי
כברירת מחדל, תכונות השילוב של למידת המכונה ב-AlloyDB Omni מושבתות. צריך לשנות את הקובץ postgresql.conf בתוך הקונטיינר כדי להפעיל את התהליך הפנימי של ML-Agent ואת מנוע השאילתות של ה-AI.
מריצים את הפקודה הבאה כדי להוסיף את הדגלים הנדרשים:
docker exec -it my-omni sh -c "cat << EOF >> /var/lib/postgresql/data/postgresql.conf
omni_enable_ml_agent_process = 'on'
google_ml_integration.enable_model_support = 'on'
google_ml_integration.enable_ai_query_engine = 'on'
EOF"
מפעילים מחדש את הקונטיינר כדי להחיל את השינויים:
docker restart my-omni
כדי להתחיל לבדוק שאילתות, אפשר להפעיל את psql באמצעות הפקודה:
docker exec -it my-omni psql -U postgres
5. ניתוב ה-AI ל-LLM המקומי
אחרי שמתחברים למסד הנתונים באמצעות psql (docker exec -it my-omni psql -U postgres), אפשר לרשום את המודל המקומי שלא מחובר לרשת. במקום לשלוח קריאה לאינטרנט, צריך לנתב את model_request_url לשרת Ollama המקומי שפועל ביציאה 8080.
מריצים את הצהרות ה-SQL הבאות משורת הפקודה של psql במסוף:
CREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;
CALL google_ml.create_model(
model_id => 'gemma4:e2b',
model_request_url => 'http://localhost:8080/api/generate',
model_provider => 'custom',
model_type => 'generic'
);
עכשיו אפשר להפעיל חיזויים בצורה מאובטחת מתוך SQL:
SELECT google_ml.predict_row(
'gemma4:e2b',
'{"model": "gemma4:e2b", "prompt": "Why is the sky blue?", "stream": false}'
)->'response';
פלט:
עכשיו, אחרי שבדקנו את זה על מקרה בדיקה כללי, בואו נכניס לתמונה את הנתונים של תרחיש השימוש שלנו.
6. יצירת סכימה והטמעת נתונים
עכשיו נרחיב את תרחיש השימוש שלנו וניצור את הסכימה ואת הנתונים שנדרשים להדגמה.
מריצים את הצהרות ה-SQL הבאות משורת הפקודה של psql במסוף:
-- ==============================================================================
-- 1. Setup the Schema for the 1500T Forging Press
-- ==============================================================================
CREATE TABLE IF NOT EXISTS forging_press_logs (
log_id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT NOW(),
cycle_id VARCHAR(50) NOT NULL,
hyd_pressure_bar NUMERIC(5,2),
oil_temp_c NUMERIC(5,2),
vib_z_rms NUMERIC(5,2)
);
-- Clean up any existing data if running multiple times
TRUNCATE TABLE forging_press_logs;
-- ==============================================================================
-- 2. Generate 1,000 Records of Simulated Data
-- ==============================================================================
-- 99% of data is 'Normal'
INSERT INTO forging_press_logs (cycle_id, hyd_pressure_bar, oil_temp_c, vib_z_rms)
SELECT
'C-' || LPAD(i::text, 5, '0'),
280.0 + (random() * 10 - 5), -- Pressure around 280
42.0 + (random() * 5), -- Temp around 42-47
1.8 + (random() * 0.5) -- Vib Z around 1.8-2.3
FROM generate_series(1, 990) AS i;
-- 1% of data is 'Anomalous' (Hydraulic pressure drop & vibration spike)
INSERT INTO forging_press_logs (cycle_id, hyd_pressure_bar, oil_temp_c, vib_z_rms)
SELECT
'C-' || LPAD((990 + i)::text, 5, '0'),
250.0 + (random() * 5), -- Pressure dropping
55.0 + (random() * 5), -- Temp rising
5.0 + (random() * 1.5) -- High vibration
FROM generate_series(1, 10) AS i;
-- ==============================================================================
-- 3. Run the AI Prediction via AlloyDB Omni
-- ==============================================================================
-- Ensure the model is registered (assuming 'gemma4:e2b' is running locally on port 8080)
CREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;
DO $$
BEGIN
CALL google_ml.create_model(
model_id => 'gemma4:e2b',
model_request_url => 'http://localhost:8080/api/generate',
model_provider => 'custom',
model_type => 'generic'
);
EXCEPTION WHEN OTHERS THEN
-- Ignore error if model already exists
END $$;
-- Query the most recent 5 potentially anomalous records and ask Gemma for an analysis
SELECT
cycle_id,
hyd_pressure_bar,
vib_z_rms,
google_ml.predict_row(
model_id => 'gemma4:e2b',
request_body => json_build_object(
'model', 'gemma4:e2b',
'stream', false,
'prompt', 'You are an industrial engineer. Analyze this sensor data from a 1500T forging press: Pressure=' || hyd_pressure_bar || ' bar, Vibration=' || vib_z_rms || ' mm/s. Normal pressure is ~280 bar and normal vibration is ~2.0 mm/s. Does this indicate a hydraulic failure? Answer in one short sentence.'
)
)->>'response' AS ai_analysis
FROM
forging_press_logs
WHERE
hyd_pressure_bar < 260 OR vib_z_rms > 4.5
ORDER BY
timestamp DESC
LIMIT 5;
אם נריץ את ההצהרות שלמעלה אחת אחרי השנייה, נקבל את התוצאה הבאה:
עכשיו, כשהנתונים מוכנים, אפשר לעבור לבניית מרכז הבקרה של התחזוקה החזויה.
7. יצירת מרכז בקרה לשידור חי
כדי להמחיש את הארכיטקטורה הזו, אפשר לחבר אותה בקלות למרכז בקרה של Python Flask, שהוא אפליקציית אינטרנט.
במקום להריץ שאילתות SQL באופן ידני, קצה עורפי קל של Flask מעביר את נתוני הטלמטריה של החיישנים בזמן אמת למרכז בקרה ב-HTML. במהלך הפעילות הרגילה, מרכז הבקרה פשוט משרטט את הגרפים.
אבל כשה-backend מזהה חריגה (למשל, ירידה בלחץ), קוד Python מפעיל באופן מיידי את הפונקציה google_ml.predict_row() בתוך AlloyDB. AlloyDB מעביר בצורה חלקה את ההקשר למודל Gemma המקומי, ותובנות אבחון ה-AI מופיעות במרכז הבקרה בזמן אמת.
💡 טיפ ל-Codelab: כדי לצאת מהקונטיינר של מסד הנתונים ולחזור לשורת הפקודה של המארח, מקלידים \q ולוחצים על Enter (או פותחים כרטיסייה חדשה של הטרמינל). לאחר מכן, מריצים את הפקודות של אפליקציית Flask שבהמשך.
לשם כך:
- עוברים לסביבת הפיתוח או לעורך הקוד ופותחים את הטרמינל.
- מריצים את הפקודה הבאה:
pip install flask psycopg2-binary
- משכפלים את מאגר הקוד בספריית הפרויקט באמצעות הפקודה הבאה במסוף Cloud Shell:
git clone https://github.com/AbiramiSukumaran/gemma4-alloydb-omni-demo
- עוברים לתיקיית הפרויקט:
cd gemma4-alloydb-omni-demo
- מריצים את האפליקציה:
python3 app.py
פותחים את דפדפן האינטרנט או לוחצים על הקישור לאפליקציה שפועלת במארח המקומי.
מה מוצג במרכז השליטה של הסטרימינג בשידור חי
אפליקציית Flask פועלת כמרכז בקרה למעקב בזמן אמת אחרי מכבש החישול של 1,500 טון, וממחישה איך מערכת עם air gap, שהיא אופליין לחלוטין, מטפלת בתחזוקה חזויה:
- זרם טלמטריה רציף: מרכז הבקרה מציג תרשימים של יומני רטט (מ"מ/שנייה) ולחץ הידראולי (בר) בזמן אמת, ומתעדכן באופן דינמי כדי לדמות פעולות פעילות ברצפת הייצור.
- חריגות במסד הנתונים בזמן אמת: כשחיישן יורד מתחת לסף (למשל, הלחץ יורד מתחת ל-260 בר), הקצה העורפי של Python מסמן את האירוע ומיד מפעיל את הפונקציה
google_ml.predict_row()בתוך AlloyDB Omni. - אבחון מקומי באמצעות AI: AlloyDB Omni מעביר את ההקשר בזמן אמת למודל Gemma 4 המקומי. Gemma פועל כמומחה תעשייתי מקומי, מנתח את נתוני הטלמטריה ומדפיס התראה על בעיה בתגים (למשל, "אזהרה: ירידה בלחץ ורעידות חזקות מצביעות על כשל פוטנציאלי באטם ההידראולי") ישירות במרכז הבקרה.
- אפס זליגת נתונים: כל החישובים, מסדי הנתונים, התרשימים וההסקה של ה-AI מתבצעים באופן מקומי במארח, בלי צורך בחיבור לאינטרנט.
8. הדרך לסביבת הייצור
כדי להרחיב את הארכיטקטורה הזו מאב טיפוס מקומי לפריסה ברצפת ייצור בלי לפגוע באבטחה של ה-air gap, אתם יכולים לבחור מבין שני מסלולי התקנה סטנדרטיים מקומיים:
מכונות וירטואליות בסביבת ייצור ו-Bare-Metal (ללא קונטיינרים):
בסביבות שבהן לא מומלץ להשתמש בקונטיינרים, או שבהן מדיניות האבטחה דורשת שילוב עמוק עם מערכת ההפעלה המארחת, אפשר לפרוס באמצעות חבילת ה-RPM הרשמית של AlloyDB Omni. בעזרת כלי הניהול של AlloyDB Omni Red Hat RPM, הפריסה הזו מספקת ביצועים עם זמן אחזור קצר, תאימות ל-SELinux וזמינות גבוהה (HA) אוטומטית ישירות למכונות הווירטואליות המקומיות של RHEL או Rocky Linux, באופן אופליין לחלוטין.
Kubernetes בסביבת ייצור וזמינות גבוהה (HA):
אם התשתית של המפעל שלכם משתמשת בתזמור מקומי, אתם יכולים לפרוס את AlloyDB Omni ב-Kubernetes . בעזרת AlloyDB Omni Kubernetes Operator הרשמי, אתם יכולים לפרוס באופן הצהרתי אשכול מסד נתונים חזק עם רפליקות גיבוי סינכרוניות, גיבויים מקומיים אוטומטיים ונקודות קצה ייעודיות לקריאה בלבד.
9. מעולה!
בתעשיות כמו ייצור ביטחוני ותעשיות עם air gap, הבחירה היא כבר לא בין אבטחה מחמירה לבין חדשנות טכנולוגית. כשפורסים מסדי נתונים בקונטיינרים, מודלים ייעודיים של שרתי proxy ו-AI עם משקלים פתוחים בחומרה ריבונית, אפשר להפוך את רצפת הייצור למרכז חכם וצופה פני עתיד, תוך שמירה על החפיר הדיגיטלי שלכם.