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

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

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

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

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

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

ภาพรวมโซลูชันข้อมูลอ้างอิงกิจกรรม Fleet

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

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

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

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

องค์ประกอบพื้นฐานเชิงตรรกะ

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

ภาพรวมของเหตุการณ์ของกลุ่มยานพาหนะและองค์ประกอบพื้นฐานเชิงตรรกะ

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

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

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

เมื่อต้องการติดตั้งใช้งานโซลูชันอ้างอิงสำหรับ "โซลูชันกลุ่มรถขนส่งสินค้าในขั้นสุดท้าย" หรือ "โซลูชันการเดินทางและการนำส่งแบบออนดีมานด์" (จะพร้อมใช้งานในช่วงปลายไตรมาสที่ 3 ปี 2023) การเลือกเทคโนโลยีสำหรับ "แหล่งที่มา" และ "พื้นที่เก็บข้อมูล" จะทําได้ง่ายๆ ในขณะที่ "การประมวลผล" มีตัวเลือกที่หลากหลาย โซลูชันการอ้างอิงได้เลือกบริการของ Google ต่อไปนี้

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

องค์ประกอบพื้นฐานในการสร้างโซลูชันข้อมูลอ้างอิงเหตุการณ์ของยานพาหนะ

เลย์เอาต์โปรเจ็กต์ที่อยู่ในระบบคลาวด์

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

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

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

อ่างล้างจาน

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

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

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

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

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

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

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

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

โมดูล Terraform

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

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

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

ความปลอดภัย

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

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

ตอนนี้คุณพร้อมเข้าถึงและสำรวจโซลูชันข้อมูลอ้างอิงเหตุการณ์ของ Fleet เพิ่มเติมแล้ว ไปที่ 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