בחר שירות Kinesis להזרמת נתונים.
→עיבוד בשליטת צרכן בתת-שנייה → Kinesis Data Streams. אספקה מנוהלת במלואה ל-S3/Redshift/OpenSearch עם המרת פורמט אופציונלית → Kinesis Data Firehose.
למה: KDS שומר רשומות (24 שעות–365 ימים) ותומך בצרכנים מרובים. ל-Firehose אין יכולת שידור חוזר; הוא מחליף שידור חוזר באספקה ללא פעולות תפעוליות.
מקור↗
זרם נתונים חווה שגיאות ProvisionedThroughputExceeded בשיא העומס.
→Reshard. כל shard תומך בקלט של 1 MB/s או 1,000 רשומות/שנייה, ופלט של 2 MB/s. השתמש במפתחות חלוקה אחידים; הפעל Enhanced Fan-Out עבור >2 MB/s לצרכן.
למה: מפתחות חלוקה חמים מרכזים תנועה ב-shard אחד. מפתחות אקראיים או מבוססי hash מפזרים את העומס.
מקור↗
עומס העבודה בזרימה נצפה כקופצני ובלתי צפוי; resharding ידני מהווה כאב תפעולי.
→Kinesis Data Streams במצב קיבולת לפי דרישה. מתאים את קנה המידה אוטומטית עד 200 MB/s כברירת מחדל; תשלום לפי נפח נתונים.
מקור↗
מספר צרכנים הקוראים מאותו זרם חווים את מגבלת הקריאה של 2 MB/s/shard.
→Enhanced Fan-Out. כל צרכן מקבל 2 MB/s/shard ייעודיים באמצעות SubscribeToShard מבוסס push ב-HTTP/2.
מקור↗
מקסם את תפוקת הקלט מצד היישום המפיק.
→Kinesis Producer Library (KPL) עם אגרגציה + איסוף. מקבץ רשומות משתמש מרובות לרשומת Kinesis אחת עד 1 MB; מפחית עלויות PUT.
למה: PutRecord של רשומה יחידה מוגבל בקצב ויקר ב-50 אלף אירועים/שנייה. KPL מבצע אגרגציה בצד הלקוח.
מקור↗
הנחת JSON clickstream ל-S3 כקובץ Parquet, מחולק לפי זמן אירוע.
→Firehose עם המרת פורמט רשומה (JSON → Parquet) באמצעות Glue Data Catalog table + חלוקה דינמית לפי חותמת זמן אירוע.
למה: Parquet + חלוקה מפחיתים באופן דרמטי את עלויות סריקת Athena. חלוקה דינמית מונעת שלב ETL נפרד.
מקור↗
חלק מהרשומות נכשלות בטרנספורמציה או באספקה של Firehose; יש צורך ללכוד אותן לצורך שידור חוזר.
→הגדר גיבוי S3 עם `AllData` או `FailedDataOnly`. רשומות שנכשלו נוחתות בקידומת המוגדרת עם מטא נתונים של שגיאות.
מקור↗
ודא שאין אובדן נתונים ב-MSK אם AZ של ברוקר כושל.
→גורם שכפול ≥ 3 על פני 3 AZs ו-`min.insync.replicas=2` עם `acks=all` של המפיק. הפעל Multi-AZ דרך KRaft ללא ZooKeeper או מיקום ברוקרים ב-3 AZs.
מקור↗
הזרם מ-MSK ל-S3, OpenSearch או RDS מבלי לנהל אשכול Kafka Connect.
→MSK Connect עם מחבר מנוהל (Confluent S3 Sink, Debezium עבור CDC). מתאים אוטומטית את קנה המידה של ה-workers לפי WCU.
מקור↗
נושא מאחסן את הגרסה האחרונה של רשומה לכל מפתח; ניתן לזרוק גרסאות ישנות.
→הגדר את מדיניות הניקוי של הנושא (`cleanup.policy=compact`). Kafka שומר את הערך העדכני ביותר לכל מפתח; רשומות ישנות יותר עם אותו מפתח מתאימות לדחיסה.
מקור↗
העברה שבועית חוזרת של 10 TB מ-NFS מקומי ל-S3 על גבי Direct Connect.
→AWS DataSync עם סוכן מקומי + משימה מתוזמנת. מאמת את שלמות הנתונים, תומך בהעברות מצטברות ומקביליות.
למה: DataSync מהיר יותר מ-aws-cli sync ומטפל באופן מובנה בהגבלת רוחב פס, ניסיונות חוזרים ואימות.
מקור↗
משיכת נתונים מ-SaaS APIs (Salesforce, ServiceNow, Zendesk) ל-S3 בלוח זמנים.
→AWS AppFlow. מחברים מנוהלים, OAuth מטופל, מתוזמן או מופעל על ידי אירועים, כותב Parquet ל-S3.
מקור↗
שכפול שינויים מתמשכים מ-SQL Server מקומי ל-Aurora MySQL עם זמן השבתה מינימלי.
→AWS DMS עם משימת full-load + CDC. השתמש ב-Schema Conversion Tool (SCT) להמרת סכימה/קוד הטרוגניים לפני DMS.
מקור↗
מופע שכפול של DMS כושל — השכפול מופסק.
→הפעל Multi-AZ במופע השכפול. מופע המתנה סינכרוני ב-AZ אחר; כשל אוטומטי.
מקור↗
צורך באנליטיקה כמעט בזמן אמת על נתוני Aurora OLTP ללא צינור ETL.
→אינטגרציית Aurora zero-ETL ל-Redshift. שכפול רציף של נתוני Aurora ל-Redshift; שאילתות רואות נתונים חדשים תוך שניות.
למה: מבטל צינורות DMS / Glue / CDC מותאמים אישית עבור מקרה השימוש OLTP-to-warehouse.
מקור↗
העברת 100 TB של ארכיון היסטורי משרת מקומי ל-S3; רוחב הפס מוגבל.
→AWS Snowball Edge Storage Optimized. התקן פיזי נשלח לאתר; העתקת נתונים; החזרה במשלוח.
מקור↗
JSON המקור מכיל מערכים מקוננים; ניתוח יחסי בהמשך דורש שורות שטוחות.
→טרנספורמציית Glue PySpark `Relationalize` (או `explode()` ב-DataFrame) משטחת מערכים מקוננים לשורות/טבלאות נפרדות.
מקור↗
Glue Crawler מסיק טיפוסים דו-משמעיים (`choice<int,string>`) מנתוני CSV מבולגנים.
→הפעל טרנספורמציית `ResolveChoice` — המר לטיפוס ספציפי או הטל ל-struct. או תקן במקור על ידי אכיפת סכימה.
מקור↗
משימת Glue ETL רצה לפי שעה על נתוני S3 הולכים וגדלים; יש צורך לעבד רק קבצים חדשים.
→הפעל Glue job bookmarks. Glue עוקב אחר קבצים/חלוקות מעובדות ומדלג עליהם בהפעלות חוזרות.
למה: מונע עיבוד מחדש של כל הנתונים. נדרש עבור צינורות ETL מצטברים.
מקור↗
משימת Glue Spark נכשלת עם OutOfMemoryError על הדרייבר במהלך אגרגציות גדולות.
→עבור ל-G.2X או G.4X workers (יותר זיכרון דרייבר) או הפעל `--enable-glue-datacatalog` push-down predicates כדי להפחית נתונים מעורבבים.
מקור↗
הפעל Spark Structured Streaming רציף מול מקור Kinesis עם תשתית מנוהלת.
→משימת Glue streaming ETL. Spark Structured Streaming מתחת למכסה המנוע; שמירת נקודות בדיקה ל-S3.
מקור↗
אנליסט עסקי צריך לנקות ולבצע טרנספורמציה לנתונים ללא כתיבת קוד.
→AWS Glue DataBrew. טרנספורמציות מבוססות מתכונים ויזואליים (250+), פרופילים, lineage. פלט ל-S3, Redshift, RDS.
מקור↗
הפעל משימת Glue ETL רק לאחר ש-Crawler מעדכן בהצלחה את Glue Data Catalog.
→Glue Workflow עם טריגרים מותנים. הצלחת Crawler ← הפעל משימת ETL. כשלון ← דלג / התרעה.
מקור↗
Crawler מסיק את כל עמודות ה-CSV כ-`string` — יש צורך בטיפוסי תאריך ומספר.
→הוסף מסווג Glue מותאם אישית (תבנית Grok או רמז עמודה) לפני הסריקה. לחלופין, כתוב מראש שורת כותרת עם טיפוסים מפורשים.
מקור↗
מפיקים/צרכנים מרובים ב-Kafka זקוקים לאבולוציית סכימה מבלי לשבור אחד את השני.
→AWS Glue Schema Registry עם כללי תאימות (BACKWARD/FORWARD/FULL). מפיקים רושמים סכימה; צרכנים מאחזרים + מאמתים.
מקור↗
בחר בין EMR ל-Glue עבור Spark ETL.
→Spark מותאם אישית רץ לאורך זמן עם כוונון עמוק, מספר framework-ים (Hive, Presto, Flink) ← EMR. ETL ללא שרת בתשלום לפי משימה עם אינטגרציה ל-Glue Data Catalog ← Glue. Spark קופצני/בלתי צפוי ← EMR Serverless.
מקור↗
משימות Spark/Hive לסירוגין; רוצה אפס פעולות אשכול וללא מחשוב סרק.
→EMR Serverless. מאגרי קיבולת מאותחלים מראש להפעלות עם לטנסי נמוכה; מותאם קנה מידה לכל משימה; תשלום לפי vCPU-hour.
מקור↗
ערבב on-demand core + spot task nodes עבור EMR ממוטב עלויות.
→Instance Fleets עם קיבולת יעד לכל סוג. Core fleet ב-on-demand ליציבות HDFS; task fleet ב-Spot עם סוגי מופעים מגוונים.
מקור↗
תקנן על Kubernetes; רוצה שמשימות EMR Spark ישתפו אשכול עם עומסי עבודה אחרים.
→EMR on EKS. Spark רץ כ-pods על אשכול EKS קיים; שיתוף תשתית ותפקידי IAM דרך IRSA.
מקור↗
סטרימינג stateful עם אגרגציות מבוססות חלונות וסמנטיקה של "בדיוק פעם אחת".
→Kinesis Data Analytics for Apache Flink. סביבת ריצה מנוהלת של Flink; נקודות בדיקה ל-S3; מותאם קנה מידה אוטומטית.
מקור↗
טרנספורמציה קלה לכל רשומה בזרם Kinesis (<1 ms לכל אחת).
→Lambda עם Event Source Mapping על KDS. כוונן `BatchSize`, `MaximumBatchingWindowInSeconds`, ו-`ParallelizationFactor`.
למה: Lambda זול יותר מ-KCL/Glue Streaming עבור עבודה קטנה לכל רשומה.
מקור↗
שלב Step Functions נכשל לעיתים עקב throttling חולף; נסה שוב ולאחר מכן התרעה.
→הוסף בלוק `Retry` עם `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. בנוסף `Catch` למצב התרעה.
מקור↗
עבד 500,000 קבצי JSON במקביל דרך טרנספורמציית Lambda.
→Step Functions distributed Map state עם `MaxConcurrency` ו-ItemReader מ-S3. פיזור על פני אלפי הפעלות Lambda מקבילות.
מקור↗
DAG מורכב עם תלויות בין שירותים (Glue + Redshift COPY + Lambda + דוא"ל) ודרישות lineage.
→Amazon MWAA (Managed Workflows for Apache Airflow). אופרטורים מקוריים של Airflow לשירותי AWS; סנכרון DAG מונחה Git.
מקור↗
צורך ב-rollback של שינויים ב-DAG אם פריסה גורמת לכשלים.
→אחסן DAGs בדלי S3 עם גרסאות + סנכרון באמצעות S3 versioning. או שמור repo של DAG ב-Git עם סביבה לכל branch + סנכרון S3 דרך CI.
מקור↗