สร้างกิจกรรมแบบเกือบเรียลไทม์ด้วย Fleet Engine และโซลูชันอ้างอิงเหตุการณ์ของ Fleet

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

  • ตรวจสอบประสิทธิภาพของกลุ่มยานพาหนะและระบุปัญหาที่อาจเกิดขึ้นตั้งแต่เนิ่นๆ
  • ปรับปรุงการบริการลูกค้าด้วยการระบุเวลาที่คาดว่าจะนำส่ง (ETA) และข้อมูลการติดตามที่ถูกต้อง
  • ลดค่าใช้จ่ายโดยการระบุและแก้ไขความไม่มีประสิทธิภาพ
  • ปรับปรุงความปลอดภัยด้วยการตรวจสอบพฤติกรรมคนขับและระบุอันตรายที่อาจเกิดขึ้น
  • เพิ่มประสิทธิภาพเส้นทางและตารางเวลาของคนขับเพื่อปรับปรุงประสิทธิภาพ
  • ปฏิบัติตามกฎระเบียบด้วยการติดตามตำแหน่งยานพาหนะและชั่วโมงการทำงาน

เอกสารนี้แสดงวิธีที่นักพัฒนาแอปสามารถเปลี่ยนสัญญาณจาก "บริการ การเดินทาง" ของ Google Maps Platform ("Last Mile Fleet Solution" (LMFS) หรือ "On-demand Rides and Deliveries Solution" (ODRD) ให้เป็นเหตุการณ์ที่กำหนดเองที่นำไปใช้ได้จริง นอกจากนี้ เรายังครอบคลุมแนวคิดหลักและการตัดสินใจด้านการออกแบบของการอ้างอิงเหตุการณ์ของกลุ่มยานพาหนะ โซลูชัน ที่มีอยู่ใน GitHub ด้วย

เอกสารนี้เกี่ยวข้องกับ

เมื่ออ่านเอกสารนี้จนจบ คุณควรมีความเข้าใจพื้นฐานเกี่ยวกับองค์ประกอบสำคัญและข้อควรพิจารณาของระบบการสตรีม รวมถึงบล็อกการสร้างจาก Google Maps Platform และ Google Cloud ที่ประกอบกันเป็นโซลูชันอ้างอิงเหตุการณ์ของกองยานพาหนะ

ภาพรวมโซลูชันอ้างอิงเหตุการณ์ของกลุ่มยานพาหนะ

Fleet Events Reference Solution เป็นโซลูชันโอเพนซอร์สที่ช่วยให้ลูกค้าและพาร์ทเนอร์ด้านการเดินทางสร้างเหตุการณ์สําคัญบนคอมโพเนนต์ของ Fleet Engine และ Google Cloud ได้ ปัจจุบันโซลูชันอ้างอิงรองรับลูกค้าที่ใช้ Last Mile Fleet Solution โดยจะรองรับการเดินทางและการนำส่งตามความต้องการในเร็วๆ นี้

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

  • การเปลี่ยนแปลงเวลาถึงโดยประมาณของงาน
  • การเปลี่ยนแปลงเวลาถึงโดยประมาณแบบสัมพัทธ์สำหรับการมาถึงของงาน
  • เวลาที่เหลือจนกว่าจะถึงงาน
  • ระยะทางที่เหลือจนกว่าจะถึงงาน
  • การเปลี่ยนสถานะ TaskOutcome

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

องค์ประกอบที่ใช้สร้างสรรค์เชิงตรรกะ

แผนภาพ : แผนภาพต่อไปนี้แสดงองค์ประกอบระดับสูงที่ประกอบกันเป็นโซลูชันอ้างอิงสำหรับเหตุการณ์ของกลุ่มยานพาหนะ

ภาพรวมของเหตุการณ์ในกลุ่มและบล็อกการสร้างเชิงตรรกะ

โซลูชันอ้างอิงประกอบด้วยคอมโพเนนต์ต่อไปนี้

  • แหล่งที่มาของเหตุการณ์: แหล่งที่มาของสตรีมเหตุการณ์เดิม ทั้ง "Last Mile Fleet Solution" หรือ "On-demand Rides and Deliveries Solution" มีการผสานรวมกับ Cloud Logging ซึ่งช่วยเปลี่ยนบันทึกการเรียก RPC ของ Fleet Engine ให้เป็นสตรีมเหตุการณ์ที่พร้อมใช้งานสำหรับนักพัฒนาแอป ซึ่งเป็นแหล่งข้อมูลหลักที่ใช้
  • การประมวลผล: ระบบจะแปลงบันทึกการเรียกใช้ RPC ดิบเป็นเหตุการณ์การเปลี่ยนแปลงสถานะ ภายในบล็อกนี้ ซึ่งจะคำนวณสตรีมของเหตุการณ์บันทึก หากต้องการตรวจหาการเปลี่ยนแปลงดังกล่าว คอมโพเนนต์นี้ต้องมีที่เก็บสถานะเพื่อให้สามารถเปรียบเทียบเหตุการณ์ใหม่ที่เข้ามากับเหตุการณ์ก่อนหน้าเพื่อตรวจหาการเปลี่ยนแปลงได้ เหตุการณ์อาจไม่ได้ รวมข้อมูลที่น่าสนใจทั้งหมดเสมอไป ในกรณีดังกล่าว บล็อกนี้อาจ ทำให้มีการเรียกค้นไปยังแบ็กเอนด์ตามที่จำเป็น
    • ที่เก็บสถานะ: เฟรมเวิร์กการประมวลผลบางอย่างจะให้ข้อมูลกลาง ที่คงอยู่ด้วยตัวเอง แต่หากไม่ได้ใช้ คุณควรใช้บริการความคงทนของข้อมูลประเภท K-V เพื่อจัดเก็บสถานะด้วยตนเอง เนื่องจากสถานะเหล่านี้ควรไม่ซ้ำกันสำหรับรถยนต์และประเภทเหตุการณ์
  • Sink (เหตุการณ์ที่กำหนดเอง): การเปลี่ยนแปลงสถานะที่ตรวจพบควรพร้อมใช้งานสำหรับ แอปพลิเคชันหรือบริการใดก็ตามที่ได้รับประโยชน์จากสถานะดังกล่าว จึงเป็นตัวเลือกที่เหมาะสมในการเผยแพร่เหตุการณ์ที่กำหนดเองนี้ไปยังระบบการนำส่งเหตุการณ์เพื่อการใช้งานขั้นปลาย
  • บริการปลายทาง: โค้ดที่ใช้เหตุการณ์ที่สร้างขึ้นและดำเนินการ เฉพาะสำหรับกรณีการใช้งานของคุณ

การเลือกบริการ

เมื่อพูดถึงการใช้โซลูชันอ้างอิงสำหรับ "Last Mile Fleet Solution" หรือ "On-demand Rides and Deliveries Solution" (จะพร้อมใช้งานในช่วงปลายไตรมาสที่ 3 ปี 2023) การเลือกเทคโนโลยีสำหรับ "แหล่งที่มา" และ "ปลายทาง" จะเป็นไปอย่างตรงไปตรงมา ในทางกลับกัน "การประมวลผล" มีตัวเลือกที่หลากหลาย โซลูชันอ้างอิงได้เลือกบริการต่อไปนี้ของ Google

แผนภาพ : แผนภาพต่อไปนี้แสดงบริการของ Google Cloud ที่ใช้ในการติดตั้งใช้งาน โซลูชันอ้างอิง

บล็อกการสร้างโซลูชันอ้างอิงสำหรับเหตุการณ์ของกลุ่มยานพาหนะ

เลย์เอาต์โปรเจ็กต์ Cloud

เราขอแนะนำให้คุณใช้การติดตั้งใช้งานแบบหลายโปรเจ็กต์เป็นค่าเริ่มต้น เพื่อให้สามารถแยกการใช้งาน Google Maps Platform และ Google Cloud ออกจากกันได้อย่างชัดเจน และเชื่อมโยงกับการจัดการการเรียกเก็บเงินที่คุณเลือก

แหล่งที่มาของเหตุการณ์

"Last Mile Fleet Solution" และ "On-demand Rides and Deliveries Solution" จะเขียนเพย์โหลดคำขอและการตอบกลับของ API ไปยัง Cloud Logging Cloud Logging จะส่งบันทึกไปยังบริการที่คุณเลือกอย่างน้อย 1 รายการ การกำหนดเส้นทางไปยัง Cloud Pub/Sub เป็นตัวเลือกที่เหมาะสมที่สุด ในที่นี้ และช่วยให้คุณแปลงบันทึกเป็นสตรีมเหตุการณ์ได้โดยไม่ต้องเขียนโค้ด

อ่างล้างจาน

ใน Google Cloud Cloud Pub/Sub เป็นระบบการนำส่งข้อความแบบเรียลไทม์ที่เลือกใช้ เช่นเดียวกับวิธีที่ระบบส่ง เหตุการณ์จากแหล่งที่มาไปยัง Pub/Sub ระบบจะ เผยแพร่เหตุการณ์ที่กำหนดเองไปยัง Pub/Sub เพื่อการใช้งานดาวน์สตรีมด้วย

กำลังประมวลผล

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

  • Cloud Functions เป็นแพลตฟอร์มการประมวลผล สำหรับการเปิดตัวครั้งแรก (*)
    • Serverless ปรับขนาดขึ้นและลงด้วยการควบคุมการปรับขนาดเพื่อจัดการต้นทุน
    • Java เป็นภาษาโปรแกรมเนื่องจากมีไลบรารีของไคลเอ็นต์สำหรับ API ที่เกี่ยวข้องกับ Fleet Engine ซึ่งช่วยให้การติดตั้งใช้งานง่ายขึ้น
  • Cloud Firestore เป็นที่เก็บสถานะ
    • ที่เก็บคีย์-ค่าแบบไร้เซิร์ฟเวอร์
  • Cloud Pub/Sub เป็นจุดผสานรวม กับคอมโพเนนต์ต้นทางและปลายทาง
    • การผสานรวมแบบเรียลไทม์ที่เชื่อมต่อกันอย่างหลวมๆ

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

*หมายเหตุ: โซลูชันอ้างอิงนี้วางแผนที่จะเปิดตัวการติดตั้งใช้งานทางเลือกที่จะช่วยให้เป็นไปตามข้อกำหนดต่างๆ ได้

การทำให้ใช้งานได้

เราเลือกใช้ Terraform เป็นเครื่องมืออัตโนมัติเพื่อให้กระบวนการติดตั้งใช้งานโซลูชันอ้างอิงสามารถทำซ้ำ ปรับแต่ง ควบคุมซอร์สโค้ด และปลอดภัยได้ Terraform เป็นเครื่องมือ IaC (Infrastructure as Code) ที่มีการนำไปใช้อย่างแพร่หลายและมี การรองรับ Google Cloud อย่างเต็มที่

โมดูล Terraform

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

โมดูลที่รวมอยู่ในโซลูชันอ้างอิง

  • การกำหนดค่าการบันทึกของ Fleet Engine: ทำให้การกำหนดค่าที่เกี่ยวข้องกับ Cloud Logging เป็นแบบอัตโนมัติเพื่อใช้กับ Fleet Engine ในโซลูชันอ้างอิง จะใช้เพื่อกำหนดเส้นทางบันทึกที่เกี่ยวข้องกับ Fleet Engine ไปยังหัวข้อ Pub/Sub ที่ระบุ
  • การติดตั้งใช้งานฟังก์ชันระบบคลาวด์ของเหตุการณ์กลุ่ม: มีการติดตั้งใช้งานโค้ดฟังก์ชันตัวอย่าง และจัดการการตั้งค่าสิทธิ์อัตโนมัติ ที่จำเป็นสำหรับการผสานรวมข้ามโปรเจ็กต์ที่ปลอดภัย
  • การติดตั้งใช้งานโซลูชันอ้างอิงทั้งหมด: เรียกใช้ 2 โมดูลก่อนหน้าและ รวมโซลูชันทั้งหมด

ความปลอดภัย

เราใช้ IAM เพื่อใช้หลักการสิทธิ์ขั้นต่ำพร้อมกับแนวทางปฏิบัติแนะนำด้านความปลอดภัยของ Google Cloud เช่น การแอบอ้างเป็นบัญชีบริการ โปรดอ่านบทความต่อไปนี้เพื่อทำความเข้าใจข้อเสนอของ Google Cloud ที่จะช่วยให้คุณควบคุมความปลอดภัยได้มากขึ้น

การดำเนินการถัดไป

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

ภาคผนวก

รวบรวมข้อกำหนด

เราขอแนะนำให้คุณรวบรวมข้อกำหนดตั้งแต่เนิ่นๆ ในกระบวนการ

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

  • ต้องมีข้อมูลใดบ้างเพื่อให้สตรีมเหตุการณ์มีประโยชน์
    • ผลลัพธ์สามารถมาจากข้อมูลที่บันทึกหรือสร้างขึ้นใน บริการของ Google โดยเฉพาะได้ไหม หรือต้องมีการเพิ่มคุณค่าข้อมูลด้วยระบบภายนอกที่ผสานรวม หรือไม่ หากใช่ ระบบเหล่านั้นคืออะไรและมีอินเทอร์เฟซการผสานรวมใดบ้าง
    • คุณต้องการวัดเมตริกใดในฐานะธุรกิจ ถูกกำหนดไว้อย่างไร?
    • หากต้องการคํานวณเมตริกในเหตุการณ์ต่างๆ คุณจะต้องใช้การรวบรวมประเภทใด ลองวางขั้นตอนเชิงตรรกะ (เช่น เปรียบเทียบ ETA/ATA กับ SLO ในกลุ่มย่อยของกองยานพาหนะในช่วงเวลาที่มีการใช้งานสูงสุดเพื่อ คำนวณประสิทธิภาพภายใต้ข้อจำกัดด้านทรัพยากร)
  • เหตุใดคุณจึงสนใจโมเดลที่อิงตามเหตุการณ์หรือโมเดลแบบกลุ่ม คุณต้องการให้การผสานรวมนี้มีเวลาในการตอบสนองต่ำ (เวลาในการดำเนินการ) หรือเป็นการผสานรวมแบบหลวมๆ (ความคล่องตัว)
    • หากเป็นเวลาในการตอบสนองต่ำ ให้กำหนด "ต่ำ" นาที วินาที น้อยกว่า 1 วินาที และเวลาในการตอบสนอง คือเท่าใด
  • ทีมของคุณได้ลงทุนในเทคโนโลยีสแต็กและทักษะที่เกี่ยวข้องแล้วใช่ไหม หากใช่ โปรดระบุว่าคืออะไรและมีจุดเชื่อมต่อการผสานรวมใดบ้าง
    • ระบบปัจจุบันของคุณมีข้อกำหนดใดที่ทำตามไม่ได้หรืออาจ มีปัญหาในการประมวลผลเหตุการณ์ที่มาจากกลุ่มอุปกรณ์

หลักการออกแบบ

การมีกระบวนการคิดที่ควรทำตามนั้นมีประโยชน์เสมอ ซึ่งจะช่วยให้คุณตัดสินใจด้านการออกแบบได้อย่างสอดคล้องกัน โดยเฉพาะอย่างยิ่งเมื่อมีตัวเลือกมากมายให้เลือก

  • ใช้ตัวเลือกที่ง่ายกว่าเป็นค่าเริ่มต้น
  • ตั้งค่าเริ่มต้นเป็นระยะเวลาในการสร้างคุณค่าที่สั้นลง โค้ดน้อยลง เรียนรู้ได้ง่ายขึ้น
  • สำหรับเวลาในการตอบสนองและประสิทธิภาพ ให้ตั้งเป้าหมายให้ตรงตามเกณฑ์ที่คุณกำหนด ไม่ใช่การเพิ่มประสิทธิภาพสูงสุด นอกจากนี้ ให้หลีกเลี่ยงการเพิ่มประสิทธิภาพมากเกินไปเนื่องจากมักจะทำให้เกิดความซับซ้อน
  • เช่นเดียวกับค่าใช้จ่าย ควบคุมต้นทุนให้อยู่ในระดับที่เหมาะสม คุณอาจยังไม่พร้อมที่จะใช้บริการที่มีมูลค่าสูงแต่มีราคาแพงกว่า
  • ในระยะทดลอง การลดขนาดอาจมีความสำคัญไม่แพ้การเพิ่มขนาด พิจารณาแพลตฟอร์มที่ให้ความยืดหยุ่นในการเพิ่มขนาดโดยมีขีดจำกัด และลดขนาด (ควรเป็น 0) เพื่อให้คุณไม่ต้องเสียค่าใช้จ่ายเมื่อไม่ได้ดำเนินการใดๆ คุณอาจพิจารณาประสิทธิภาพสูงพร้อมโครงสร้างพื้นฐานที่พร้อมใช้งานตลอดเวลาในภายหลัง เมื่อมั่นใจว่าจำเป็นต้องใช้
  • สังเกตและวัดผลเพื่อให้คุณระบุได้ในภายหลังว่าควรปรับปรุงส่วนใดเพิ่มเติม
  • ให้บริการต่างๆ มีการเชื่อมต่อกันอย่างหลวมๆ ซึ่งจะช่วยให้คุณสลับชิ้นส่วนทีละชิ้นได้ง่ายขึ้น ในภายหลัง
  • สุดท้ายแต่ไม่ท้ายสุด ความปลอดภัยต้องเข้มงวด ในฐานะบริการที่ทำงานในสภาพแวดล้อมระบบคลาวด์สาธารณะ ระบบจึงต้องไม่มีช่องโหว่ที่ไม่ได้รักษาความปลอดภัย

แนวคิดการสตรีม

หากคุณเพิ่งเริ่มใช้การประมวลผลแบบเหตุการณ์หรือการสตรีม มีแนวคิดสำคัญ ที่ควรทราบ ซึ่งบางแนวคิดอาจแตกต่างจากการประมวลผลเป็นกลุ่มอย่างมาก

  • การปรับขนาด : การประมวลผลแบบสตรีมจะแตกต่างจากการประมวลผลแบบกลุ่มตรงที่โดยปกติแล้วคุณจะทราบปริมาณข้อมูลที่จะประมวลผล แต่ในการประมวลผลแบบสตรีมคุณจะไม่ทราบ การจราจรติดขัดในเมืองอาจทำให้เกิดเหตุการณ์จำนวนมากในทันทีจากพื้นที่หนึ่งๆ และคุณยังคงต้องประมวลผลเหตุการณ์เหล่านั้นได้
  • การแบ่งช่วง : แทนที่จะประมวลผลเหตุการณ์ทีละรายการ คุณอาจต้องการจัดกลุ่มเหตุการณ์ในช่วงไทม์ไลน์เป็น "ช่วง" เล็กๆ เพื่อใช้เป็นหน่วยสำหรับการคำนวณ มีกลยุทธ์การแบ่งช่วงเวลาต่างๆ เช่น "ช่วงเวลาคงที่ (เช่น ทุกวันตามปฏิทิน)" "ช่วงเวลาแบบเลื่อน (5 นาทีที่ผ่านมา)" "ช่วงเวลาเซสชัน (ระหว่างการเดินทางนี้)" ซึ่งคุณควรเลือกจากกลยุทธ์เหล่านี้ ยิ่งกรอบเวลานานเท่าใด การสร้างผลลัพธ์ก็จะยิ่งล่าช้ามากขึ้นเท่านั้น เลือกรุ่นและการกำหนดค่าที่เหมาะสมซึ่งตรงตามข้อกำหนดของคุณ
  • การทริกเกอร์ : มีบางกรณีที่คุณไม่มีทางเลือกอื่นนอกจากต้องมี กรอบเวลาที่ยาวนานกว่า อย่างไรก็ตาม คุณไม่ควรที่จะรอจนถึงช่วงท้ายๆ ของ กรอบเวลาเพื่อสร้างเหตุการณ์ แต่ควรปล่อยผลลัพธ์ระดับกลาง ออกมาแทน แนวคิดนี้สามารถนำไปใช้กับกรณีการใช้งานที่ มีคุณค่าในการแสดงผลลัพธ์อย่างรวดเร็วเป็นอันดับแรก แล้วจึงแก้ไขในภายหลัง ลองนึกถึงการส่งสถานะระดับกลางเมื่อการนำส่งเสร็จสมบูรณ์ 25%, 50% และ 75%
  • การเรียงลำดับ : เหตุการณ์อาจไม่ได้เข้าสู่ระบบตามลำดับที่สร้างขึ้น โดยเฉพาะอย่างยิ่งสำหรับกรณีการใช้งานที่เกี่ยวข้องกับการสื่อสารผ่านเครือข่ายมือถือ ซึ่งจะเพิ่มความล่าช้าและเส้นทางการกำหนดเส้นทางที่ซับซ้อน คุณต้องทราบความแตกต่างระหว่าง "เวลาของเหตุการณ์" (เวลาที่เกิดเหตุการณ์จริง) กับ "เวลาประมวลผล" (เวลาที่เหตุการณ์เข้าถึงระบบ) และจัดการเหตุการณ์ตามนั้น โดยทั่วไป คุณควรประมวลผลเหตุการณ์ตาม "event time"
  • การนำส่งข้อความ - อย่างน้อย 1 ครั้งเทียบกับ 1 ครั้งเท่านั้น: แพลตฟอร์มเหตุการณ์ต่างๆ มีการรองรับที่แตกต่างกัน คุณต้องพิจารณากลยุทธ์การลองใหม่หรือการขจัดข้อมูลที่ซ้ำกัน ทั้งนี้ขึ้นอยู่กับกรณีการใช้งาน
  • ความสมบูรณ์ : เช่นเดียวกับการเปลี่ยนลำดับการสั่งซื้อ มีโอกาสที่ข้อความจะสูญหาย ปัญหานี้อาจเกิดจากการปิดแอปพลิเคชันและอุปกรณ์เนื่องจาก แบตเตอรี่ของอุปกรณ์หมด โทรศัพท์ได้รับความเสียหายโดยไม่ตั้งใจ การเชื่อมต่อขาดหายขณะอยู่ในอุโมงค์ หรือข้อความที่ได้รับแต่ อยู่นอกกรอบเวลาที่ยอมรับได้ ความไม่สมบูรณ์จะส่งผลต่อผลลัพธ์ของคุณอย่างไร

โปรดทราบว่ายังมีกรณีอื่นๆ นอกเหนือจากนี้ ต่อไปนี้คือแหล่งข้อมูลที่ขอแนะนำ ซึ่งจะช่วยให้คุณเข้าใจแต่ละเรื่องได้ดียิ่งขึ้น

ผู้ร่วมให้ข้อมูล

Google เป็นผู้ดูแลเอกสารนี้ ผู้มีส่วนร่วมต่อไปนี้เป็นผู้เขียนบทความนี้

ผู้เขียนหลัก:

  • Mary Pishny | ผู้จัดการผลิตภัณฑ์ Google Maps Platform
  • Ethel Bao| วิศวกรซอฟต์แวร์ Google Maps Platform
  • Mohanad Almiski | วิศวกรซอฟต์แวร์ Google Maps Platform
  • Naoya Moritani | วิศวกรโซลูชัน Google Maps Platform