หัวหน้าสถาปนิกข้อมูล AWS
ลูกค้าของเราซึ่งเป็นผู้ให้บริการด้านไอทีชั้นนำระดับโลก ต้องการรับสมัคร Lead AWS Data Architect ประจำสำนักงานของลูกค้าใน ลอนดอน สหราชอาณาจักร
นี่เป็นตำแหน่งงานแบบผสมผสาน คุณสามารถทำงานจากระยะไกลในสหราชอาณาจักร และเข้าทำงานที่สำนักงานในลอนดอน 2 วันต่อสัปดาห์
นี่คือสัญญาจ้างชั่วคราวระยะเวลา 6 เดือน ขึ้นไป เริ่มงานได้ทันที
อัตราค่าบริการรายวัน: อัตราตามกลไกตลาด
ในฐานะสถาปนิกด้านข้อมูลเชิงปฏิบัติการของ AWS คุณจะออกแบบ สร้าง และปรับปรุงแพลตฟอร์มข้อมูลการชำระเงินของเราอย่างต่อเนื่อง โดยการนำเหตุการณ์ ISO 20022 เข้าสู่เลคเฮาส์บน AWS คุณจะรับประกันการกำกับดูแลข้อมูล การตรวจสอบ และการเพิ่มประสิทธิภาพต้นทุนที่ดีที่สุด ในขณะที่ดูแลผลิตภัณฑ์ข้อมูลแบบครบวงจรในด้าน CX, การชำระเงิน และ CPO ซึ่งรวมถึงการจัดการรายการงานค้างของผลิตภัณฑ์ ข้อตกลงระดับบริการ (SLA) และสัญญาข้อมูล ตลอดจนการจัดทำคู่มือการปฏิบัติงาน การกำหนด SLO และการจัดทำรายงานต้นทุนและคุณภาพรายไตรมาส
หน้าที่ความรับผิดชอบหลัก
- ผลิตภัณฑ์ข้อมูล (ที่จะเกิดขึ้น): คลังข้อมูลการดำเนินงานช่องทาง (เลเยอร์ประสิทธิภาพสูงประมาณ 30 วัน) และคลังข้อมูลวิเคราะห์ช่องทาง (7 ปีขึ้นไป) เปิดเผย API สถานะและรายงานต่างๆ พร้อม SLA ที่ชัดเจน
- สถาปัตยกรรมแพลตฟอร์ม: S3/Glue/Athena/Iceberg Lakehouse, Redshift สำหรับ BI/การดำเนินงาน, QuickSight สำหรับแดชบอร์ด PO/การดำเนินงาน, Lambda/Step Functions สำหรับการจัดการกระบวนการสตรีมข้อมูล
- การสตรีมและการนำเข้าข้อมูล: Kafka (K4/K5/Confluent) และ AWS MSK/Kinesis; ตัวเชื่อมต่อ/CDC ไปยัง DW/Lake การแบ่งพาร์ติชัน การเก็บรักษา การเล่นซ้ำ การทำงานซ้ำ EventBridge สำหรับการกำหนดเส้นทางเหตุการณ์แบบเนทีฟของ AWS
- สัญญาเหตุการณ์: Avro/Protobuf, Schema Registry, กฎความเข้ากันได้, กลยุทธ์การกำหนดเวอร์ชัน
- จากสภาพปัจจุบันสู่สภาพที่ต้องการ: API สำหรับจัดการสินค้าคงคลัง/ไฟล์/ฟีด SWIFT และระบบจัดเก็บข้อมูล (Aurora Postgres, Kafka) กำหนดขั้นตอนการย้ายข้อมูลและคู่มือการเปลี่ยนระบบ
- การกำกับดูแลและคุณภาพ: การเป็นเจ้าของข้อมูลในฐานะผลิตภัณฑ์ ที่มาของข้อมูล การควบคุมการเข้าถึง กฎเกณฑ์ด้านคุณภาพ การเก็บรักษาข้อมูล
- การตรวจสอบและบริหารจัดการทางการเงิน (FinOps): Grafana/Prometheus/CloudWatch สำหรับวัด TPS, อัตราความสำเร็จ, ความล่าช้า, ค่าใช้จ่ายต่อ 1 ล้านเหตุการณ์ คู่มือการปฏิบัติงาน + การแจ้งเตือนที่นำไปสู่การดำเนินการได้
- ขนาดและความยืดหยุ่น: รองรับการชำระเงินหลายสิบล้านรายการต่อวัน รูปแบบการใช้งานหลายโซน/ภูมิภาค และ RPO/RTO ที่ใช้งานได้จริง
- ความปลอดภัย: การจำแนกประเภทข้อมูล การเข้ารหัส KMS การสร้างโทเค็นเมื่อจำเป็น การจัดการสิทธิ์การเข้าถึงแบบจำกัด (Least-privilege IAM) การตรวจสอบที่ไม่สามารถเปลี่ยนแปลงได้
- การสร้างระบบด้วยตนเอง: Python/Scala/SQL; Spark/Glue; Step Functions/Lambda; IaC (Terraform); CI/CD (GitLab/Jenkins); การทดสอบอัตโนมัติ
ข้อกำหนดสำคัญ
ทักษะที่จำเป็น:
- การสตรีมมิ่งและ EDA: Kafka (Confluent) และ AWS MSK/Kinesis; Kinesis Firehose; การจัดลำดับ การเล่นซ้ำ ความหมายแบบ exactly-at-least-once; EventBridge สำหรับการกำหนดเส้นทางและการกรองเหตุการณ์
- การจัดการ Schema: Avro/Protobuf + Schema Registry (ความเข้ากันได้ กลยุทธ์เกี่ยวกับหัวข้อ การพัฒนา)
- ชุดเครื่องมือจัดการข้อมูลของ AWS: S3/Glue/Athena, Redshift, Step Functions, Lambda; ไปป์ไลน์การสตรีมข้อมูล Kinesis & S3→Glue; Glue Streaming; รูปแบบ DLQ
- การชำระเงินและ ISO 20022: PAIN/PACS/CAMT, การสร้างแบบจำลองวงจรชีวิต, การปรับปรุงแก้ไข, ความรู้เกี่ยวกับ SWIFT/ช่องทางไฟล์
- การกำกับดูแล: แนวคิดการจัดการข้อมูลขนาดใหญ่, การเป็นเจ้าของ, ข้อตกลงระดับบริการด้านคุณภาพ, การเข้าถึง, การเก็บรักษา, ที่มาของข้อมูล
- การตรวจสอบและบริหารจัดการด้านการเงิน: สร้างแดชบอร์ด การแจ้งเตือน ตัวชี้วัดต้นทุน และแก้ไขปัญหาปริมาณงานต่ำในระดับขนาดใหญ่
- การส่งมอบงาน: โค้ดสำหรับใช้งานจริง, การวิเคราะห์ประสิทธิภาพ, การตรวจสอบโค้ด, การทดสอบอัตโนมัติ, การออกแบบที่ปลอดภัยตั้งแต่เริ่มต้น
หลักการพื้นฐานด้านสถาปัตยกรรมข้อมูล (สิ่งที่ต้องมี):
- การสร้างแบบจำลองข้อมูลเชิงตรรกะ: แผนภาพความสัมพันธ์ระหว่างเอนทิตี, การทำให้เป็นรูปแบบมาตรฐาน (1NF ผ่าน Boyce-Codd/BCNF), ข้อดีข้อเสียของการลดรูปแบบมาตรฐาน; การพึ่งพาเชิงฟังก์ชันและความผิดปกติ
- การสร้างแบบจำลองข้อมูลเชิงกายภาพ: การออกแบบตาราง กลยุทธ์การแบ่งพาร์ติชัน ดัชนี รูปแบบการจัดเก็บข้อมูลสำหรับ OLTP เทียบกับการวิเคราะห์ข้อมูล
- การทำให้เป็นรูปแบบมาตรฐานและการออกแบบ: ทำให้เป็นรูปแบบมาตรฐาน 3NF/BCNF สำหรับ OLTP; เข้าใจว่าเมื่อใดควรทำให้เป็นรูปแบบที่ไม่ปกติสำหรับคำสั่งค้นหา; Data Vault, สคีมาแบบดาว (star schema)
- CQRS: การแยกการอ่าน/เขียน; การบันทึกเหตุการณ์; การสร้างใหม่ เมื่อใดที่ CQRS มีความเหมาะสม และเมื่อใดที่เกินความจำเป็น
- สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (Event-Driven Architecture - EDA): การออกแบบที่เน้นเหตุการณ์เป็นหลัก; ขอบเขตแบบรวมกลุ่ม; รูปแบบการเผยแพร่/ย่อย; การจัดการกระบวนการ; การทำงานซ้ำได้โดยไม่เกิดผลซ้ำซ้อน; การส่งมอบอย่างน้อยหนึ่งครั้ง
- บริบทที่จำกัดและการสร้างแบบจำลองโดเมน: ชั้นป้องกันการทุจริต, เคอร์เนลที่ใช้ร่วมกัน, ภาษาที่เผยแพร่, ภาษาที่ใช้ได้ทั่วไป
- เอนทิตี, วัตถุคุณค่า และแหล่งเก็บข้อมูล: เอกลักษณ์ของเอนทิตีในโดเมน; ความไม่เปลี่ยนแปลง; การสร้างนามธรรมของแหล่งเก็บข้อมูลเหนือการคงอยู่ถาวร; บันทึกตามเวลา/เวอร์ชัน
- เหตุการณ์และสัญญาของโดเมน: การกำหนดเวอร์ชันของสคีมา (Avro/Protobuf); ความเข้ากันได้แบบย้อนหลัง/ไปข้างหน้า; การเล่นซ้ำเหตุการณ์; การแมปเหตุการณ์โดเมนไปยังหัวข้อ Kafka และตาราง Aurora
ทักษะที่พึงประสงค์:
- การปรับแต่ง QuickSight/Tableau และ Redshift; ksqlDB/Flink; กลไกภายในของ Aurora Postgres
- ข้อจำกัดของ Edge/API (Apigee/API‑GW), รูปแบบ mTLS/webhook
เนื่องจากมีผู้สมัครจำนวนมาก เราจึงไม่สามารถตอบกลับทุกคนได้
หากคุณไม่ได้รับการติดต่อกลับจากเราภายใน 7 วันหลังจากส่งใบสมัคร โปรดถือว่าคุณไม่ได้รับการคัดเลือกในครั้งนี้
โปรดติดตามเว็บไซต์ของเรา ที่ https://projectrecruit.com/jobs/ เพื่อดูตำแหน่งงานว่างในอนาคต
