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

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

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

เอกสารนี้แสดงวิธีที่นักพัฒนาแอปสามารถเปลี่ยนสัญญาณจาก "Mobility services" ("Last Mile Fleet Solution" (LMFS) หรือ "On-demand Rides and Deliveries Solution" (ODRD) ของ Google Maps Platform ให้เป็นเหตุการณ์ที่กำหนดเองที่นำไปใช้ได้จริง นอกจากนี้ เรายังครอบคลุมแนวคิดหลักและการตัดสินใจด้านการออกแบบของ การอ้างอิงเหตุการณ์ของกลุ่มยานพาหนะ โซลูชัน ที่มีอยู่ใน 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%
  • การเรียงลำดับ : เหตุการณ์อาจไม่จำเป็นต้องเข้าถึงระบบตามลำดับที่สร้างขึ้น โดยเฉพาะอย่างยิ่งสำหรับกรณีการใช้งานที่เกี่ยวข้องกับการสื่อสารผ่านเครือข่ายมือถือ ซึ่งทำให้เกิดความล่าช้าและเส้นทางการกำหนดเส้นทางที่ซับซ้อน คุณต้องทราบความแตกต่างระหว่าง "เวลาของเหตุการณ์" (เวลาที่เกิดเหตุการณ์จริง) กับ "เวลาประมวลผล" (เวลาที่เหตุการณ์เข้าถึงระบบ) และจัดการเหตุการณ์ตามนั้น โดยทั่วไป คุณควรประมวลผลเหตุการณ์ตาม "เวลา เหตุการณ์"
  • การนำส่งข้อความ - อย่างน้อย 1 ครั้งเทียบกับ 1 ครั้งเท่านั้น: แพลตฟอร์มเหตุการณ์ต่างๆ มีการรองรับการนำส่งข้อความเหล่านี้แตกต่างกัน คุณต้องพิจารณากลยุทธ์การลองใหม่หรือการขจัดข้อมูลที่ซ้ำกัน ทั้งนี้ขึ้นอยู่กับกรณีการใช้งาน
  • ความสมบูรณ์ : เช่นเดียวกับการเปลี่ยนลำดับการสั่งซื้อ มีโอกาสที่ข้อความจะสูญหาย ซึ่งอาจเกิดจากการปิดแอปพลิเคชันและอุปกรณ์เนื่องจาก แบตเตอรี่ของอุปกรณ์หมด โทรศัพท์ได้รับความเสียหายโดยไม่ตั้งใจ การเชื่อมต่อขาดหายขณะอยู่ในอุโมงค์ หรือได้รับข้อความ แต่ได้รับนอกช่วงเวลาที่ยอมรับได้ ความไม่สมบูรณ์จะส่งผลต่อผลลัพธ์ของคุณอย่างไร

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

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

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

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

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