התאמה בין החשבונות היא צעד חשוב להבטחת השלמות והדיוק של הדוחות הכספיים. באופן ספציפי, חברות חייבות להתפייס מאזן חשבונות שעלולים להכיל הצגות מוטעות משמעותיות או מהותיות. רואי חשבון עוברים על כל חשבון בפנקס החשבונות ומוודאים שהיתרה הרשומה מלאה ומדויקת. כאשר מתגלים אי התאמות, רואי החשבון בודקים ונוקטים בפעולות מתקנות מתאימות.

כחלק מארגון ה-FinTech של אמזון, אנו מציעים פלטפורמת תוכנה המעצימה את צוותי הנהלת החשבונות הפנימיים באמזון לבצע התאמות חשבונות. כדי לייעל את תהליך ההתאמה, משתמשים אלה דורשים טרנספורמציה של ביצועים גבוהים עם יכולת קנה מידה לפי דרישה, כמו גם יכולת לעבד גדלי קבצים משתנים הנעים בין כמה MBs בודדים ליותר מ-100 GB. לא תמיד ניתן להתאים נתונים למכונה בודדת או לעבד אותם בתוכנית אחת בודדת במסגרת זמן סבירה. חישוב זה צריך להיעשות מהר מספיק כדי לספק שירותים מעשיים שבהם ניתן להפריד את היגיון התכנות והפרטים הבסיסיים (הפצת נתונים, סובלנות תקלות ותזמון).

אנו יכולים להשיג חישובים בו-זמניים אלה על מספר מכונות או חוטים של אותה פונקציה על פני קבוצות של אלמנטים של מערך נתונים על ידי שימוש בפתרונות עיבוד נתונים מבוזרים. זה עודד אותנו להמציא מחדש את שירות הפיוס שלנו המופעל על ידי שירותי AWS, כולל אמזון EMR ו אפאצ 'י ספארק מסגרת עיבוד מבוזרת, המשתמשת PySpark. שירות זה מאפשר למשתמשים לעבד קבצים מעל 100 GB המכילים עד 100 מיליון עסקאות בפחות מ-30 דקות. שירות הפיוס הפך לתחנת כוח לעיבוד נתונים, וכעת משתמשים יכולים לבצע בצורה חלקה מגוון פעולות, כגון Pivot, להצטרף (כמו פעולת VLOOKUP של Excel), אריתמטי פעולות, ו יותר, מתן פתרון רב תכליתי ויעיל להתאמה בין מערכי נתונים עצומים. שיפור זה הוא עדות למדרגיות ולמהירות שהושגו באמצעות אימוץ פתרונות עיבוד נתונים מבוזרים.

בפוסט זה, אנו מסבירים כיצד שילבנו את Amazon EMR כדי לבנות מערכת זמינה וניתנת להרחבה שאפשרה לנו להפעיל תהליך התאמה פיננסי בנפח גבוה.

אדריכלות לפני הגירה

התרשים הבא ממחיש את הארכיטקטורה הקודמת שלנו.

השירות הוותיק שלנו נבנה עם שירות מיכלים אלסטי של אמזון (אמזון ECS) ב- AWS פרגייט. עיבדנו את הנתונים ברצף באמצעות Python. עם זאת, בשל היעדר יכולת עיבוד מקבילית, נאלצנו לעתים קרובות להגדיל את גודל האשכול אנכית כדי לתמוך במערכי נתונים גדולים יותר. לצורך ההקשר, עיבוד של 5 GB של נתונים עם 50 פעולות לקח בערך 3 שעות. שירות זה הוגדר לקנה מידה אופקי לחמישה מופעי ECS שמהם נשאלו הודעות שירות תורים פשוט של אמזון (Amazon SQS), שהזינה את בקשות השינוי. כל מופע הוגדר עם 4 מעבדי vCPU ו-30 GB של זיכרון כדי לאפשר קנה מידה אופקי. עם זאת, לא יכולנו להרחיב את קיבולת הביצועים שלו מכיוון שהתהליך התרחש ברצף, תוך בחירת נתחי נתונים מ שירות אחסון פשוט של אמזון (Amazon S3) לעיבוד. לדוגמה, פעולת VLOOKUP שבה יש לחבר שני קבצים דרשה קריאת שני הקבצים בזיכרון חלק אחר נתח כדי לקבל את הפלט. זה הפך למכשול עבור משתמשים מכיוון שהם נאלצו לחכות פרקי זמן ארוכים כדי לעבד את מערכי הנתונים שלהם.

כחלק מהארכיטקטורה והמודרניזציה מחדש שלנו, רצינו להשיג את הדברים הבאים:

• זמינות גבוהה - אשכולות עיבוד הנתונים צריכים להיות זמינים ביותר, ולספק שלוש 9 של זמינות (99.9%)
• התפוקה - השירות אמור להתמודד עם 1,500 ריצות ביום
• חֶבִיוֹן - הוא אמור להיות מסוגל לעבד 100 GB של נתונים בתוך 30 דקות
• ההטרוגניות - האשכול אמור להיות מסוגל לתמוך במגוון רחב של עומסי עבודה, עם קבצים הנעים בין כמה MBs למאות GBs
• מקיפות שאילתות – היישום דורש את היכולת לתמוך במינימום 10 דרגות של במקביל
• אמינות משרות ועקביות נתונים - משרות צריכות לפעול באופן אמין ועקבי כדי להימנע מהפרת הסכמי רמת שירות (SLAs)
• חסכוני וניתן להרחבה - זה חייב להיות ניתן להרחבה בהתבסס על עומס העבודה, מה שהופך אותו לחסכוני
• אבטחה ותאימות – בהתחשב ברגישות הנתונים, עליו לתמוך בקרת גישה דקדקנית וביישומי אבטחה מתאימים
• ניטור – הפתרון חייב להציע ניטור מקצה לקצה של האשכולות והמשרות

למה אמזון EMR

Amazon EMR הוא פתרון הביג דאטה בענן המוביל בתעשייה לעיבוד נתונים בקנה מידה פטה-בייט, ניתוח אינטראקטיבי ולמידת מכונה (ML) תוך שימוש במסגרות קוד פתוח כגון אפאצ 'י ספארק, כוורת אפאצ'י, ו פרסטו. עם מסגרות אלה ופרויקטים קשורים בקוד פתוח, אתה יכול לעבד נתונים למטרות ניתוח ועומסי עבודה של BI. Amazon EMR מאפשר לך להפוך ולהעביר כמויות גדולות של נתונים פנימה והחוצה ממאגרי נתונים ומסדי נתונים אחרים של AWS, כגון Amazon S3 ו אמזון דינמו.

יתרון בולט של אמזון EMR טמון בשימוש היעיל שלו בעיבוד מקביל עם PySpark, המסמן שיפור משמעותי לעומת קוד Python רציף מסורתי. גישה חדשנית זו מייעלת את הפריסה והקנה מידה של אשכולות Apache Spark, ומאפשרת הקבלה יעילה על מערכי נתונים גדולים. תשתית המחשוב המבוזרת לא רק משפרת את הביצועים, אלא גם מאפשרת עיבוד של כמויות עצומות של נתונים במהירויות חסרות תקדים. מצויד בספריות, PySpark מאפשר פעולות כמו Excel מסגרות נתונים, וההפשטה ברמה גבוהה יותר של DataFrames מפשטת מניפולציות מסובכות של נתונים, ומפחיתה את מורכבות הקוד. בשילוב עם הקצאת אשכול אוטומטית, הקצאת משאבים דינמית ואינטגרציה עם שירותי AWS אחרים, אמזון EMR מתגלה כפתרון רב-תכליתי המתאים לעומסי עבודה מגוונים, החל מעיבוד אצווה ועד ML. סבילות התקלות המובנית ב-PySpark ו- Amazon EMR מקדמת חוסן, גם במקרה של כשלים בצמתים, מה שהופך אותו לבחירה ניתנת להרחבה, חסכונית ועם ביצועים גבוהים לעיבוד נתונים מקביל ב-AWS.

Amazon EMR מרחיבה את היכולות שלה מעבר ליסודות, ומציעה מגוון אפשרויות פריסה כדי לתת מענה לצרכים מגוונים. בין אם זה אמזון EMR ב-EC2, אמזון EMR ב-EKS, Amazon EMR ללא שרת, או אמזון EMR ב-AWS Outposts, אתה יכול להתאים את הגישה שלך לדרישות ספציפיות. למי שמחפש סביבה ללא שרת לעבודות Spark, שילוב דבק AWS היא גם אפשרות ריאלית. בנוסף לתמיכה במסגרות שונות של קוד פתוח, כולל Spark, Amazon EMR מספקת גמישות בבחירת מצבי פריסה, ענן מחשוב אלסטי של אמזון (Amazon EC2) סוגי מופעים, מנגנוני קנה מידה וטכניקות אופטימיזציה רבות לחסכון בעלויות.

אמזון EMR עומדת ככוח דינמי בענן, ומספקת יכולות ללא תחרות לארגונים המחפשים פתרונות ביג דאטה חזקים. האינטגרציה החלקה שלו, התכונות החזקות ויכולת ההסתגלות הופכים אותו לכלי הכרחי לניווט במורכבות של ניתוח נתונים ו-ML ב-AWS.

אדריכלות שעוצבה מחדש

התרשים הבא ממחיש את הארכיטקטורה המחודשת שלנו.

הפתרון פועל תחת חוזה API, שבו לקוחות יכולים להגיש תצורות טרנספורמציה, להגדיר את מערך הפעולות לצד מיקום הנתונים של S3 לעיבוד. הבקשה מועברת בתור דרך Amazon SQS, ואז מופנית לאמזון EMR באמצעות פונקציית Lambda. תהליך זה מתחיל ביצירת שלב EMR של אמזון ליישום מסגרת Spark על אשכול EMR ​​ייעודי. למרות שאמזון EMR מתאימה למספר בלתי מוגבל של צעדים לאורך חייו של אשכול ארוך טווח, רק 256 שלבים יכולים לפעול או בהמתנה בו זמנית. להקבלה אופטימלית, מקביליות הצעדים מוגדרת ל-10, מה שמאפשר ל-10 שלבים לפעול במקביל. במקרה של כשלים בבקשות, ה-Amazon SQS תור של אותיות מתות (DLQ) שומרת על האירוע. Spark מעבד את הבקשה, ומתרגם פעולות דמויות Excel לקוד PySpark לתוכנית שאילתות יעילה. Resilient DataFrames מאחסנים קלט, פלט ונתוני ביניים בזיכרון, מייעלים את מהירות העיבוד, מפחיתים את עלות ה-I/O של הדיסק, משפרים את ביצועי עומס העבודה ומספקים את הפלט הסופי למיקום Amazon S3 שצוין.

אנו מגדירים את ה-SLA שלנו בשני ממדים: חביון ותפוקה. השהייה מוגדרת כמשך הזמן שלוקח לביצוע עבודה אחת מול גודל מערך נתונים דטרמיניסטי ומספר הפעולות שבוצעו במערך הנתונים. תפוקה מוגדרת כמספר המרבי של עבודות בו-זמנית שהשירות יכול לבצע מבלי להפר את SLA ההשהיה של עבודה אחת. SLA המדרגיות הכוללת של השירות תלויה באיזון של קנה מידה אופקי של משאבי מחשוב אלסטיים וקנה מידה אנכי של שרתים בודדים.

מכיוון שהיינו צריכים להריץ 1,500 תהליכים ביום עם חביון מינימלי וביצועים גבוהים, אנו בוחרים לשלב את Amazon EMR במצב פריסת EC2 עם קנה מידה מנוהל המאפשר תמיכה בעיבוד גדלי קבצים משתנים.

תצורת אשכול EMR ​​מספקת אפשרויות רבות ושונות:

• סוגי צומת EMR – צמתים ראשיים, ליבה או משימה
• אפשרויות רכישה למשל – מופעים לפי דרישה, מופעים שמורים או מופעים נקודתיים
• אפשרויות תצורה – צי מופעי EMR או קבוצת מופעים אחידה
• אפשרויות קנה מידה - קנה מידה אוטומטי או קנה מידה מנוהל של Amazon EMR

בהתבסס על עומס העבודה המשתנה שלנו, הגדרנו צי מופעי EMR (לשיטות מומלצות, ראה אמינות). החלטנו גם להשתמש בקנה מידה מנוהל של Amazon EMR כדי לשנות את קנה המידה של הליבה והמשימות (לתרחישי קנה מידה, עיין ב תרחישי הקצאת צמתים). לבסוף, בחרנו באופטימיזציה לזיכרון AWS Graviton מקרים, המספקים עד עלות נמוכה יותר ב-30% ועד 15% ביצועים משופרים לעומסי עבודה של Spark.

הקוד הבא מספק תמונת מצב של תצורת האשכול שלנו:

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

ביצוע

עם ההגירה שלנו לאמזון EMR, הצלחנו להשיג ביצועי מערכת המסוגלים לטפל במגוון מערכי נתונים, החל מ-273 B ועד ל-88.5 GB עם p99 של 491 שניות (כ-8 דקות).

האיור הבא ממחיש את מגוון גדלי הקבצים המעובדים.

האיור הבא מציג את זמן האחזור שלנו.

כדי להשוות מול עיבוד רציף, לקחנו שני מערכי נתונים המכילים 53 מיליון רשומות והרצנו פעולת VLOOKUP זה מול זה, יחד עם 49 פעולות אחרות דמויות Excel. עיבוד זה נמשך 26 דקות בשירות החדש, לעומת 5 ימים לעיבוד בשירות מדור קודם. שיפור זה גדול כמעט פי 300 בהשוואה לארכיטקטורה הקודמת מבחינת ביצועים.

שיקולים

זכור את הדברים הבאים כאשר אתה שוקל פתרון זה:

• אשכולות בגודל נכון - למרות שאמזון EMR ניתן לשינוי גודל, חשוב להתאים את הגודל הנכון של האשכולות. גודל נכון מפחית אשכול איטי, אם הוא קטן, או עלויות גבוהות יותר, אם האשכול גדול מדי. כדי לצפות בעיות אלו, אתה יכול לחשב את מספר וסוג הצמתים שיידרשו לעומסי העבודה.
• צעדים מקבילים – הפעלת שלבים במקביל מאפשרת לך להפעיל עומסי עבודה מתקדמים יותר, להגדיל את ניצול משאבי האשכולות ולצמצם את משך הזמן הנדרש להשלמת עומס העבודה שלך. ניתן להגדיר את מספר השלבים המותרים לרוץ בו-זמנית וניתן להגדיר אותו בעת השקת אשכול ובכל זמן לאחר הפעלת האשכול. עליך לשקול ולבצע אופטימיזציה של השימוש במעבד/זיכרון לכל עבודה כאשר מספר משימות פועלות באשכול משותף אחד.
• אשכולות EMR חולפים מבוססי עבודה - אם ישים, מומלץ להשתמש באשכול EMR ​​חולף מבוסס עבודה, המספק בידוד מעולה, המוודא שכל משימה פועלת בתוך הסביבה הייעודית שלה. גישה זו מייעלת את ניצול המשאבים, מסייעת במניעת הפרעות בין עבודות ומשפרת את הביצועים והאמינות הכוללים. האופי החולף מאפשר שינוי קנה מידה יעיל, ומספק פתרון חזק ומבודד לצרכי עיבוד נתונים מגוונים.
• EMR ללא שרת - EMR Serverless היא הבחירה האידיאלית אם אתה מעדיף לא לטפל בניהול ובתפעול של אשכולות. זה מאפשר לך להריץ יישומים ללא מאמץ באמצעות מסגרות קוד פתוח הזמינות בתוך EMR Serverless, ומציעה חוויה פשוטה ונטולת טרחה.
• אמזון בעברית EMR ב- EKS - אמזון EMR ב-EKS מציע יתרונות ברורים, כגון זמני הפעלה מהירים יותר ומדרגיות משופרת בפתרון אתגרי קיבולת המחשוב - מה שמועיל במיוחד עבור משתמשי Graviton ו-Spot Instance. הכללת מגוון רחב יותר של סוגי מחשוב משפרת את יעילות העלות, ומאפשרת הקצאת משאבים מותאמת. יתר על כן, תמיכת Multi-AZ מספקת זמינות מוגברת. תכונות משכנעות אלו מספקות פתרון חזק לניהול עומסי עבודה ב-Big Data עם ביצועים משופרים, אופטימיזציה של עלויות ואמינות על פני תרחישי מחשוב שונים.

סיכום

בפוסט זה, הסברנו כיצד אמזון עשתה אופטימיזציה לתהליך ההתאמה הפיננסית שלה בנפח גבוה עם Amazon EMR לצורך מדרגיות וביצועים גבוהים יותר. אם יש לך אפליקציה מונוליטית שתלויה בקנה מידה אנכי כדי לעבד בקשות נוספות או מערכי נתונים, העברתו למסגרת עיבוד מבוזרת כמו Apache Spark ובחירה בשירות מנוהל כגון Amazon EMR למחשוב עשויה לעזור להפחית את זמן הריצה כדי להפחית את האספקה ​​שלך SLA, וגם עשוי לעזור להפחית את העלות הכוללת של בעלות (TCO).

כאשר אנו מאמצים את Amazon EMR עבור מקרה השימוש הספציפי הזה, אנו ממליצים לך לבחון אפשרויות נוספות במסע חדשנות הנתונים שלך. שקול להעריך את AWS Glue, יחד עם אפשרויות פריסה דינמיות אחרות של Amazon EMR כגון EMR Serverless או Amazon EMR ב-EKS, כדי לגלות את שירות AWS הטוב ביותר המותאם למקרה השימוש הייחודי שלך. העתיד של מסע חדשנות הנתונים טומן בחובו אפשרויות והתקדמות מלהיבות שיש לחקור עוד יותר.

על הכותבים

ג'ישאן חטרפאל הוא מהנדס פיתוח תוכנה האב באמזון, שם הוא מפתח מוצרי פינטק המבוססים על ארכיטקטורות נטולות שרתים של מחשוב ענן, האחראיות על בקרות ה-IT הכלליות, הדיווח הפיננסי והבקרות של חברות על ממשל, סיכונים ותאימות.

שקטי מישרה הוא אדריכל פתרונות ראשי ב-AWS, שם הוא עוזר ללקוחות לחדש את ארכיטקטורת הנתונים שלהם ולהגדיר את אסטרטגיית הנתונים מקצה לקצה שלהם, כולל אבטחת נתונים, נגישות, ממשל ועוד. הוא גם מחבר הספר פשט את ניתוח הנתונים הגדולים עם Amazon EMR. מחוץ לעבודה, סקטי נהנית ללמוד טכנולוגיות חדשות, לצפות בסרטים ולבקר במקומות עם המשפחה.

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/