โลโก้เซเฟอร์เน็ต

ความฉลาดทางข้อมูลเชิงกำเนิด

ข้อมูลขนาดใหญ่

วิธีที่ Amazon เพิ่มประสิทธิภาพกระบวนการกระทบยอดทางการเงินปริมาณมากด้วย Amazon EMR เพื่อความสามารถในการปรับขนาดและประสิทธิภาพที่สูงขึ้น | อเมซอนเว็บเซอร์วิส

เผยแพร่ซ้ำโดยเพลโต
เผยแพร่ซ้ำโดยเพลโต

วันที่:

Views: 67

การกระทบยอดบัญชีเป็นขั้นตอนสำคัญเพื่อให้แน่ใจว่างบการเงินมีความครบถ้วนและถูกต้อง โดยเฉพาะบริษัทต่างๆ จะต้องกระทบยอด งบดุล บัญชีที่อาจมีการแสดงข้อมูลที่ขัดต่อข้อเท็จจริงอันเป็นสาระสำคัญหรือเป็นสาระสำคัญ นักบัญชีจะตรวจสอบแต่ละบัญชีในบัญชีแยกประเภททั่วไปและตรวจสอบว่ายอดคงเหลือที่แสดงนั้นครบถ้วนและถูกต้อง เมื่อพบความคลาดเคลื่อน นักบัญชีจะตรวจสอบและดำเนินการแก้ไขตามความเหมาะสม

ในฐานะส่วนหนึ่งขององค์กร FinTech ของ Amazon เรานำเสนอแพลตฟอร์มซอฟต์แวร์ที่ช่วยให้ทีมบัญชีภายในของ Amazon ดำเนินการกระทบยอดบัญชีได้ เพื่อเพิ่มประสิทธิภาพกระบวนการกระทบยอด ผู้ใช้เหล่านี้ต้องการการเปลี่ยนแปลงประสิทธิภาพสูงพร้อมความสามารถในการปรับขนาดตามความต้องการ รวมถึงความสามารถในการประมวลผลขนาดไฟล์ที่หลากหลายตั้งแต่ต่ำเพียงไม่กี่ MB ไปจนถึงมากกว่า 100 GB เป็นไปไม่ได้เสมอไปที่จะปรับข้อมูลลงในเครื่องเดียวหรือประมวลผลด้วยโปรแกรมเดียวภายในกรอบเวลาที่เหมาะสม การคำนวณนี้จะต้องดำเนินการเร็วพอที่จะให้บริการในทางปฏิบัติ โดยสามารถแยกตรรกะการเขียนโปรแกรมและรายละเอียดพื้นฐาน (การกระจายข้อมูล ความทนทานต่อข้อผิดพลาด และการกำหนดเวลา) ได้

เราสามารถบรรลุการคำนวณพร้อมกันเหล่านี้บนเครื่องหลายเครื่องหรือเธรดที่มีฟังก์ชันเดียวกันในกลุ่มองค์ประกอบของชุดข้อมูลได้โดยใช้โซลูชันการประมวลผลข้อมูลแบบกระจาย สิ่งนี้สนับสนุนให้เราคิดค้นบริการกระทบยอดที่ขับเคลื่อนโดยบริการของ AWS ขึ้นมาใหม่ ซึ่งรวมถึง อเมซอน EMR และ Apache Spark กรอบการประมวลผลแบบกระจายซึ่งใช้ ไพสปาร์ค- บริการนี้ช่วยให้ผู้ใช้สามารถประมวลผลไฟล์ที่มีขนาดมากกว่า 100 GB ซึ่งมีธุรกรรมมากถึง 100 ล้านรายการในเวลาน้อยกว่า 30 นาที บริการกระทบยอดได้กลายเป็นขุมพลังสำหรับการประมวลผลข้อมูล และตอนนี้ผู้ใช้สามารถดำเนินการต่างๆ ได้อย่างราบรื่น เช่น เดือย, สมัคร (เช่นการดำเนินการ Excel VLOOKUP) คณิตศาสตร์ การดำเนินงานและ ข้อมูลเพิ่มเติมโดยมอบโซลูชันที่หลากหลายและมีประสิทธิภาพสำหรับการปรับชุดข้อมูลจำนวนมหาศาล การเพิ่มประสิทธิภาพนี้เป็นข้อพิสูจน์ถึงความสามารถในการขยายขนาดและความเร็วที่ทำได้โดยการนำโซลูชันการประมวลผลข้อมูลแบบกระจายมาใช้

ในโพสต์นี้ เราจะอธิบายวิธีที่เราผสานรวม Amazon EMR เพื่อสร้างระบบที่มีความพร้อมใช้งานสูงและปรับขนาดได้ ซึ่งช่วยให้เราสามารถรันกระบวนการกระทบยอดทางการเงินปริมาณมากได้

สถาปัตยกรรมก่อนการโยกย้าย

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมก่อนหน้านี้ของเรา

บริการดั้งเดิมของเราถูกสร้างขึ้นด้วย บริการ Amazon Elastic Container (Amazon ECS) บน AWS ฟาร์เกต- เราประมวลผลข้อมูลตามลำดับโดยใช้ Python อย่างไรก็ตาม เนื่องจากขาดความสามารถในการประมวลผลแบบขนาน เราจึงต้องเพิ่มขนาดคลัสเตอร์ในแนวตั้งบ่อยครั้งเพื่อรองรับชุดข้อมูลที่ใหญ่ขึ้น สำหรับบริบท ข้อมูล 5 GB พร้อมการดำเนินการ 50 รายการใช้เวลาประมาณ 3 ชั่วโมงในการประมวลผล บริการนี้ได้รับการกำหนดค่าให้ปรับขนาดในแนวนอนเป็นอินสแตนซ์ ECS ห้าอินสแตนซ์ที่สำรวจข้อความ บริการ Amazon Simple Queue (Amazon SQS) ซึ่งส่งคำขอการเปลี่ยนแปลง แต่ละอินสแตนซ์ได้รับการกำหนดค่าด้วย 4 vCPU และหน่วยความจำ 30 GB เพื่อให้สามารถปรับขนาดแนวนอนได้ อย่างไรก็ตาม เราไม่สามารถขยายขีดความสามารถด้านประสิทธิภาพได้เนื่องจากกระบวนการเกิดขึ้นตามลำดับ โดยเลือกกลุ่มข้อมูลจาก บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) สำหรับการประมวลผล ตัวอย่างเช่น การดำเนินการ VLOOKUP ที่จะรวมไฟล์สองไฟล์เข้าด้วยกัน จำเป็นต้องอ่านทั้งสองไฟล์ในหน่วยความจำทีละก้อนเพื่อให้ได้เอาต์พุต สิ่งนี้กลายเป็นอุปสรรคสำหรับผู้ใช้เนื่องจากต้องรอเป็นเวลานานในการประมวลผลชุดข้อมูลของตน

ในฐานะส่วนหนึ่งของการปรับสถาปัตยกรรมใหม่และการปรับปรุงให้ทันสมัย ​​เราต้องการบรรลุสิ่งต่อไปนี้:

  • ความพร้อมใช้งานสูง – คลัสเตอร์การประมวลผลข้อมูลควรจะมีความพร้อมใช้งานสูง โดยให้ความพร้อมใช้งาน 9 วินาที (99.9%)
  • ทางเข้า – บริการควรรองรับ 1,500 รันต่อวัน
  • ความแอบแฝง – ควรจะสามารถประมวลผลข้อมูล 100 GB ได้ภายใน 30 นาที
  • ความแตกต่าง – คลัสเตอร์ควรสามารถรองรับเวิร์กโหลดได้หลากหลาย โดยมีไฟล์ตั้งแต่ไม่กี่ MB ไปจนถึงหลายร้อย GB
  • การค้นหาพร้อมกัน – การใช้งานต้องการความสามารถในการรองรับการทำงานพร้อมกันอย่างน้อย 10 องศา
  • ความน่าเชื่อถือของงานและความสม่ำเสมอของข้อมูล – งานจำเป็นต้องดำเนินการอย่างน่าเชื่อถือและสม่ำเสมอเพื่อหลีกเลี่ยงการละเมิดข้อตกลงระดับการให้บริการ (SLA)
  • คุ้มค่าและปรับขนาดได้ – ต้องสามารถปรับขนาดได้ตามปริมาณงาน ทำให้คุ้มค่า
  • ความปลอดภัยและการปฏิบัติตามข้อกำหนด – เมื่อคำนึงถึงความละเอียดอ่อนของข้อมูล จะต้องสนับสนุนการควบคุมการเข้าถึงอย่างละเอียดและการใช้งานด้านความปลอดภัยที่เหมาะสม
  • การตรวจสอบ – โซลูชันจะต้องมีการตรวจสอบคลัสเตอร์และงานตั้งแต่ต้นทางถึงปลายทาง

ทำไมต้อง Amazon EMR

Amazon EMR เป็นโซลูชัน Big Data บนคลาวด์ชั้นนำของอุตสาหกรรมสำหรับการประมวลผลข้อมูลระดับเพตะไบต์ การวิเคราะห์เชิงโต้ตอบ และการเรียนรู้ของเครื่อง (ML) โดยใช้เฟรมเวิร์กโอเพ่นซอร์ส เช่น Apache Spark, อาปาเช่ไฮฟ์และ โอมเพี้ยง- ด้วยเฟรมเวิร์กเหล่านี้และโปรเจ็กต์โอเพ่นซอร์สที่เกี่ยวข้อง คุณสามารถประมวลผลข้อมูลเพื่อวัตถุประสงค์ในการวิเคราะห์และปริมาณงาน BI ได้ Amazon EMR ช่วยให้คุณสามารถแปลงและย้ายข้อมูลจำนวนมากเข้าและออกจากที่เก็บข้อมูลและฐานข้อมูล AWS อื่นๆ เช่น Amazon S3 และ อเมซอน ไดนาโมดีบี.

ข้อได้เปรียบที่โดดเด่นของ Amazon EMR อยู่ที่การใช้การประมวลผลแบบขนานกับ PySpark อย่างมีประสิทธิภาพ ซึ่งถือเป็นการปรับปรุงที่สำคัญเหนือโค้ด Python ตามลำดับแบบดั้งเดิม แนวทางที่เป็นนวัตกรรมนี้เพิ่มความคล่องตัวในการปรับใช้และปรับขนาดคลัสเตอร์ Apache Spark ช่วยให้สามารถใช้งานแบบขนานบนชุดข้อมูลขนาดใหญ่ได้อย่างมีประสิทธิภาพ โครงสร้างพื้นฐานการประมวลผลแบบกระจายไม่เพียงเพิ่มประสิทธิภาพการทำงาน แต่ยังช่วยให้สามารถประมวลผลข้อมูลจำนวนมหาศาลด้วยความเร็วที่ไม่เคยมีมาก่อน PySpark มาพร้อมกับไลบรารี ช่วยให้การทำงานเหมือนกับ Excel ง่ายขึ้น ดาต้าเฟรมและนามธรรมระดับสูงกว่าของ DataFrames ช่วยลดความยุ่งยากในการจัดการข้อมูลที่ซับซ้อน ลดความซับซ้อนของโค้ด เมื่อรวมกับการจัดเตรียมคลัสเตอร์อัตโนมัติ การจัดสรรทรัพยากรแบบไดนามิก และการผสานรวมกับบริการของ AWS อื่นๆ Amazon EMR พิสูจน์แล้วว่าเป็นโซลูชันอเนกประสงค์ที่เหมาะสำหรับปริมาณงานที่หลากหลาย ตั้งแต่การประมวลผลเป็นชุดไปจนถึง ML ความทนทานต่อข้อผิดพลาดโดยธรรมชาติใน PySpark และ Amazon EMR ส่งเสริมความแข็งแกร่ง แม้ในกรณีที่โหนดล้มเหลว ทำให้เป็นตัวเลือกที่ปรับขนาดได้ คุ้มค่า และมีประสิทธิภาพสูงสำหรับการประมวลผลข้อมูลแบบขนานบน AWS

Amazon EMR ขยายขีดความสามารถนอกเหนือจากพื้นฐาน โดยเสนอตัวเลือกการปรับใช้ที่หลากหลายเพื่อตอบสนองความต้องการที่หลากหลาย ไม่ว่าจะเป็น Amazon EMR บน EC2, Amazon EMR บน EKS, Amazon EMR ไร้เซิร์ฟเวอร์,หรือ Amazon EMR บน AWS Outpostsคุณสามารถปรับแต่งแนวทางของคุณให้ตรงตามความต้องการเฉพาะได้ สำหรับผู้ที่กำลังมองหาสภาพแวดล้อมแบบไร้เซิร์ฟเวอร์สำหรับงาน Spark การบูรณาการ AWS กาว ก็เป็นทางเลือกหนึ่งเช่นกัน นอกเหนือจากการรองรับเฟรมเวิร์กโอเพ่นซอร์สที่หลากหลาย รวมถึง Spark แล้ว Amazon EMR ยังให้ความยืดหยุ่นในการเลือกโหมดการใช้งาน อเมซอน อีลาสติก คอมพิวท์ คลาวด์ ประเภทอินสแตนซ์ (Amazon EC2) กลไกการปรับขนาด และเทคนิคการเพิ่มประสิทธิภาพเพื่อประหยัดต้นทุนมากมาย

Amazon EMR ถือเป็นพลังแบบไดนามิกในระบบคลาวด์ โดยมอบความสามารถที่ไม่มีใครเทียบได้สำหรับองค์กรที่กำลังมองหาโซลูชัน Big Data ที่แข็งแกร่ง การผสานรวมที่ราบรื่น คุณสมบัติอันทรงพลัง และความสามารถในการปรับเปลี่ยนทำให้เป็นเครื่องมือที่ขาดไม่ได้ในการนำทางความซับซ้อนของการวิเคราะห์ข้อมูลและ ML บน AWS

สถาปัตยกรรมที่ออกแบบใหม่

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมที่ออกแบบใหม่ของเรา

โซลูชันทำงานภายใต้สัญญา API ซึ่งลูกค้าสามารถส่งการกำหนดค่าการแปลง โดยกำหนดชุดการดำเนินการควบคู่ไปกับตำแหน่งชุดข้อมูล S3 สำหรับการประมวลผล คำขอจะจัดคิวผ่าน Amazon SQS จากนั้นส่งไปยัง Amazon EMR ผ่านฟังก์ชัน Lambda กระบวนการนี้เริ่มต้นการสร้างขั้นตอน Amazon EMR สำหรับการนำเฟรมเวิร์ก Spark ไปใช้งานบนคลัสเตอร์ EMR เฉพาะ แม้ว่า Amazon EMR จะรองรับจำนวนขั้นตอนไม่จำกัดตลอดอายุการใช้งานของคลัสเตอร์ที่รันระยะยาว แต่มีเพียง 256 ขั้นตอนเท่านั้นที่สามารถรันหรือรอดำเนินการพร้อมกันได้ เพื่อการขนานที่เหมาะสมที่สุด ขั้นตอนการทำงานพร้อมกันจะถูกตั้งค่าไว้ที่ 10 ทำให้สามารถทำงานพร้อมกันได้ 10 ขั้นตอน ในกรณีที่คำขอล้มเหลว Amazon SQS คิวจดหมายตาย (DLQ) คงกิจกรรมไว้ Spark ประมวลผลคำขอ โดยแปลการดำเนินการที่คล้ายกับ Excel ให้เป็นโค้ด PySpark เพื่อแผนการสืบค้นที่มีประสิทธิภาพ DataFrames ที่ยืดหยุ่นจะจัดเก็บอินพุต เอาท์พุต และข้อมูลระดับกลางในหน่วยความจำ เพิ่มประสิทธิภาพความเร็วการประมวลผล ลดต้นทุน I/O ของดิสก์ เพิ่มประสิทธิภาพเวิร์กโหลด และส่งมอบเอาต์พุตสุดท้ายไปยังตำแหน่ง Amazon S3 ที่ระบุ

เรากำหนด SLA ของเราเป็นสองมิติ: เวลาแฝงและปริมาณงาน เวลาแฝงหมายถึงระยะเวลาที่ใช้ในการทำงานหนึ่งงานเทียบกับขนาดชุดข้อมูลที่กำหนดและจำนวนการดำเนินการที่ทำบนชุดข้อมูล ปริมาณงานหมายถึงจำนวนสูงสุดของงานพร้อมกันที่บริการสามารถทำได้โดยไม่ละเมิด SLA เวลาแฝงของงานหนึ่งงาน SLA ความสามารถในการปรับขนาดโดยรวมของบริการขึ้นอยู่กับความสมดุลของขนาดแนวนอนของทรัพยากรการประมวลผลที่ยืดหยุ่นและขนาดแนวตั้งของเซิร์ฟเวอร์แต่ละเครื่อง

เนื่องจากเราต้องรัน 1,500 กระบวนการต่อวันโดยมีเวลาแฝงน้อยที่สุดและมีประสิทธิภาพสูง เราจึงเลือกที่จะรวม Amazon EMR ในโหมดการปรับใช้ EC2 พร้อมเปิดใช้งานการปรับขนาดที่ได้รับการจัดการเพื่อรองรับการประมวลผลขนาดไฟล์ตัวแปร

การกำหนดค่าคลัสเตอร์ EMR มีตัวเลือกต่างๆ มากมาย:

  • ประเภทโหนด EMR – โหนดหลัก คอร์ หรืองาน
  • ตัวเลือกการซื้ออินสแตนซ์ – อินสแตนซ์ตามความต้องการ อินสแตนซ์แบบเหมาจ่าย หรืออินสแตนซ์สปอต
  • ตัวเลือกการกำหนดค่า – ฟลีตอินสแตนซ์ EMR หรือกลุ่มอินสแตนซ์แบบเดียวกัน
  • ตัวเลือกการปรับขนาด - ปรับขนาดอัตโนมัติ หรือการปรับขนาดที่มีการจัดการของ Amazon EMR

จากปริมาณงานที่แปรผันของเรา เราได้กำหนดค่าฟลีตอินสแตนซ์ EMR (สำหรับแนวทางปฏิบัติที่ดีที่สุด โปรดดู ความเชื่อถือได้- นอกจากนี้เรายังตัดสินใจใช้การปรับขนาดที่มีการจัดการของ Amazon EMR เพื่อปรับขนาดแกนหลักและโหนดงาน (สำหรับสถานการณ์การปรับขนาด โปรดดูที่ สถานการณ์การจัดสรรโหนด- สุดท้าย เราเลือกเพิ่มประสิทธิภาพหน่วยความจำ AWS กราวิตอน กรณีซึ่งมีให้มากถึง ต้นทุนลดลง 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

ประสิทธิภาพ

ด้วยการโยกย้ายไปยัง Amazon EMR เราจึงสามารถบรรลุประสิทธิภาพของระบบที่สามารถจัดการชุดข้อมูลที่หลากหลายได้ ตั้งแต่ต่ำเพียง 273 B ไปจนถึงสูงถึง 88.5 GB พร้อมด้วย p99 491 วินาที (ประมาณ 8 นาที)

รูปภาพต่อไปนี้แสดงขนาดไฟล์ต่างๆ ที่ได้รับการประมวลผล

รูปต่อไปนี้แสดงเวลาแฝงของเรา

เพื่อเปรียบเทียบกับการประมวลผลตามลำดับ เราใช้ชุดข้อมูลสองชุดที่มีบันทึก 53 ล้านรายการ และเรียกใช้การดำเนินการ VLOOKUP เปรียบเทียบกัน พร้อมด้วยการดำเนินการที่คล้ายกับ Excel อื่นๆ อีก 49 รายการ การดำเนินการนี้ใช้เวลา 26 นาทีในการประมวลผลในบริการใหม่ เทียบกับ 5 วันในการประมวลผลในบริการเดิม การปรับปรุงนี้ดีกว่าสถาปัตยกรรมรุ่นก่อนเกือบ 300 เท่าในแง่ของประสิทธิภาพ

สิ่งที่ควรพิจารณา

โปรดคำนึงถึงสิ่งต่อไปนี้เมื่อพิจารณาวิธีแก้ปัญหานี้:

  • คลัสเตอร์ที่มีขนาดเหมาะสม – แม้ว่า Amazon EMR จะสามารถปรับขนาดได้ แต่สิ่งสำคัญคือต้องปรับขนาดคลัสเตอร์ให้ถูกต้อง การกำหนดขนาดที่เหมาะสมจะช่วยลดคลัสเตอร์ที่ช้า หากมีขนาดเล็กเกินไป หรือมีค่าใช้จ่ายสูงกว่า หากคลัสเตอร์มีขนาดใหญ่เกินไป เพื่อคาดการณ์ปัญหาเหล่านี้ คุณสามารถคำนวณจำนวนและประเภทของโหนดที่จำเป็นสำหรับปริมาณงานได้
  • ขั้นตอนขนาน – การรันขั้นตอนแบบขนานช่วยให้คุณสามารถรันปริมาณงานขั้นสูง เพิ่มการใช้ทรัพยากรคลัสเตอร์ และลดระยะเวลาที่ใช้ในการดำเนินการปริมาณงานของคุณให้เสร็จสมบูรณ์ จำนวนขั้นตอนที่อนุญาตให้รันในครั้งเดียวสามารถกำหนดค่าได้ และสามารถตั้งค่าได้เมื่อคลัสเตอร์ถูกเปิดใช้งาน และเมื่อใดก็ได้หลังจากที่คลัสเตอร์เริ่มทำงาน คุณต้องพิจารณาและปรับการใช้งาน CPU/หน่วยความจำต่องานให้เหมาะสม เมื่อมีการรันงานหลายงานในคลัสเตอร์ที่ใช้ร่วมกันเพียงคลัสเตอร์เดียว
  • คลัสเตอร์ EMR ชั่วคราวตามงาน – หากเป็นไปได้ ขอแนะนำให้ใช้คลัสเตอร์ EMR ชั่วคราวตามงาน ซึ่งให้การแยกที่เหนือกว่า โดยตรวจสอบว่าแต่ละงานทำงานภายในสภาพแวดล้อมเฉพาะของตน แนวทางนี้เพิ่มประสิทธิภาพการใช้ทรัพยากร ช่วยป้องกันการแทรกแซงระหว่างงาน และเพิ่มประสิทธิภาพและความน่าเชื่อถือโดยรวม ลักษณะชั่วคราวช่วยให้สามารถปรับขนาดได้อย่างมีประสิทธิภาพ โดยมอบโซลูชันที่แข็งแกร่งและแยกเดี่ยวสำหรับความต้องการในการประมวลผลข้อมูลที่หลากหลาย
  • EMR ไร้เซิร์ฟเวอร์ – EMR Serverless เป็นตัวเลือกที่เหมาะสมที่สุด หากคุณไม่ต้องการจัดการการจัดการและการทำงานของคลัสเตอร์ ช่วยให้คุณสามารถรันแอปพลิเคชันได้อย่างง่ายดายโดยใช้เฟรมเวิร์กโอเพ่นซอร์สที่มีอยู่ใน EMR Serverless มอบประสบการณ์ที่ตรงไปตรงมาและไม่ยุ่งยาก
  • อเมซอน EMR บน EKS – Amazon EMR บน EKS มีข้อได้เปรียบที่แตกต่างกัน เช่น เวลาเริ่มต้นเร็วขึ้น และความสามารถในการปรับขนาดที่ดีขึ้นในการแก้ปัญหาด้านความจุในการประมวลผล ซึ่งเป็นประโยชน์อย่างยิ่งสำหรับผู้ใช้อินสแตนซ์ Graviton และ Spot การรวมประเภทการประมวลผลที่หลากหลายขึ้นช่วยเพิ่มประสิทธิภาพด้านต้นทุน ช่วยให้สามารถจัดสรรทรัพยากรได้อย่างเหมาะสม นอกจากนี้ การสนับสนุน Multi-AZ ยังช่วยเพิ่มความพร้อมใช้งานอีกด้วย คุณลักษณะที่น่าสนใจเหล่านี้เป็นโซลูชันที่มีประสิทธิภาพสำหรับการจัดการปริมาณงาน Big Data ด้วยประสิทธิภาพที่ดีขึ้น การเพิ่มประสิทธิภาพต้นทุน และความน่าเชื่อถือในสถานการณ์การประมวลผลต่างๆ

สรุป

ในโพสต์นี้ เราได้อธิบายว่า Amazon เพิ่มประสิทธิภาพกระบวนการกระทบยอดทางการเงินปริมาณมากกับ Amazon EMR ได้อย่างไรเพื่อความสามารถในการปรับขนาดและประสิทธิภาพที่สูงขึ้น หากคุณมีแอปพลิเคชันขนาดใหญ่ที่ต้องอาศัยการปรับขนาดแนวตั้งเพื่อประมวลผลคำขอหรือชุดข้อมูลเพิ่มเติม การย้ายแอปพลิเคชันไปยังเฟรมเวิร์กการประมวลผลแบบกระจาย เช่น Apache Spark และการเลือกบริการที่ได้รับการจัดการ เช่น Amazon EMR สำหรับการประมวลผล อาจช่วยลดรันไทม์เพื่อลดการส่งมอบของคุณ SLA และยังอาจช่วยลดต้นทุนรวมในการเป็นเจ้าของ (TCO)

ขณะที่เรายอมรับ Amazon EMR สำหรับกรณีการใช้งานเฉพาะนี้ เราขอแนะนำให้คุณสำรวจความเป็นไปได้เพิ่มเติมในเส้นทางนวัตกรรมข้อมูลของคุณ พิจารณาประเมิน AWS Glue พร้อมด้วยตัวเลือกการปรับใช้ Amazon EMR แบบไดนามิกอื่นๆ เช่น EMR Serverless หรือ Amazon EMR บน EKS เพื่อค้นหาบริการ AWS ที่ดีที่สุดที่ปรับให้เหมาะกับกรณีการใช้งานเฉพาะของคุณ อนาคตของการเดินทางด้านนวัตกรรมข้อมูลถือเป็นโอกาสที่น่าตื่นเต้นและความก้าวหน้าที่ต้องสำรวจเพิ่มเติม

เกี่ยวกับผู้เขียน

จีชาน เขตะปาล เป็นวิศวกรฝ่ายพัฒนาซอฟต์แวร์อาวุโสที่ Amazon ซึ่งเขาพัฒนาผลิตภัณฑ์ฟินเทคโดยใช้สถาปัตยกรรมไร้เซิร์ฟเวอร์ของการประมวลผลบนคลาวด์ที่รับผิดชอบการควบคุมทั่วไปด้านไอทีของบริษัท การรายงานทางการเงิน และการควบคุมด้านการกำกับดูแล ความเสี่ยง และการปฏิบัติตามข้อกำหนด

ศักติ มิศรา เป็นสถาปนิกโซลูชันหลักที่ AWS ซึ่งเขาช่วยลูกค้าปรับปรุงสถาปัตยกรรมข้อมูลให้ทันสมัย ​​และกำหนดกลยุทธ์ข้อมูลแบบครบวงจร รวมถึงความปลอดภัยของข้อมูล การเข้าถึง การกำกับดูแล และอื่นๆ เขายังเป็นผู้เขียนหนังสืออีกด้วย ลดความซับซ้อนของการวิเคราะห์ข้อมูลขนาดใหญ่ด้วย Amazon EMR. นอกเวลางาน ศักติสนุกกับการเรียนรู้เทคโนโลยีใหม่ๆ ดูหนัง และเยี่ยมชมสถานที่ต่างๆ กับครอบครัว

จุด_img

ข่าวกรองล่าสุด

จุด_img

ลิขสิทธิ์ @ 2024 Plato Technologies Inc.