เทคนิคการตรวจสอบข้อมูลยอดนิยมสำหรับ Analytics และเหตุผลที่คุณต้องการ

หมายเหตุบรรณาธิการ: บทความนี้เผยแพร่ครั้งแรกในบล็อก Iteratively เมื่อวันที่ 14 ธันวาคม 2020

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

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

เทคนิคการตรวจสอบข้อมูลเชิงรับและเชิงรุก: แก้ไขปัญหาข้อมูลก่อนที่จะกลายเป็นปัญหา

“การป้องกันเพียงหนึ่งออนซ์ก็คุ้มค่ากับการรักษาหนึ่งปอนด์” เป็นคำพูดโบราณที่เป็นจริงในเกือบทุกสถานการณ์ รวมถึงเทคนิคการตรวจสอบข้อมูลสำหรับการวิเคราะห์ อีกวิธีหนึ่งในการพูดก็คือ เป็นฝ่ายรุกดีกว่าตั้งรับ

วัตถุประสงค์ของการตรวจสอบข้อมูลคือการระบุว่าข้อมูลใดอาจไม่ถูกต้อง ไม่สอดคล้อง ไม่สมบูรณ์ หรือแม้แต่ขาดหายไป

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

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

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

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

เทคนิคการตรวจสอบข้อมูลเชิงโต้ตอบอาจดูเหมือนการแปลงข้อมูลของคุณในคลังสินค้าด้วยเครื่องมืออย่าง dbt หรือ Dataform

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

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

• ข้อมูลเป็นกีฬาประเภททีม มันไม่ได้ขึ้นอยู่กับแผนกใดแผนกหนึ่งหรือบุคคลเดียวเพื่อให้แน่ใจว่าข้อมูลของคุณสะอาด ทุกคนต้องทำงานร่วมกันเพื่อให้แน่ใจว่าข้อมูลมีคุณภาพสูงและแก้ปัญหาก่อนที่จะเกิดขึ้น
• การตรวจสอบข้อมูลควรเป็นส่วนหนึ่งของ Software Development Life Cycle (SDLC) เมื่อคุณผสานรวมเข้ากับ SDLC ของคุณและควบคู่ไปกับการพัฒนาทดสอบที่มีอยู่และกระบวนการ QA อัตโนมัติของคุณ (แทนที่จะเพิ่มเป็นความคิดในภายหลัง) คุณจะประหยัดเวลาด้วยการป้องกันปัญหาข้อมูลแทนที่จะแก้ปัญหาในภายหลัง
• การตรวจสอบข้อมูลเชิงรุกสามารถรวมเข้ากับเครื่องมือที่มีอยู่ของคุณและไปป์ไลน์ CI/CD นี่เป็นเรื่องง่ายสำหรับทีมพัฒนาของคุณ เพราะพวกเขาลงทุนไปกับระบบทดสอบอัตโนมัติแล้ว และตอนนี้สามารถขยายได้อย่างรวดเร็วเพื่อเพิ่มความครอบคลุมสำหรับการวิเคราะห์เช่นกัน
• การทดสอบการตรวจสอบข้อมูลเชิงรุกเป็นหนึ่งในวิธีที่ดีที่สุดที่ทีมที่เคลื่อนไหวเร็วจะสามารถทำงานได้อย่างมีประสิทธิภาพ ช่วยให้มั่นใจได้ว่าสามารถวนซ้ำได้อย่างรวดเร็วและหลีกเลี่ยงการล่องลอยของข้อมูลและปัญหาดาวน์สตรีมอื่นๆ
• การตรวจสอบข้อมูลเชิงรุกช่วยให้คุณมั่นใจในการเปลี่ยนแปลงและอัปเดตรหัสของคุณตามต้องการ ในขณะที่ลดจำนวนข้อบกพร่องที่คุณจะต้องแก้ไขในภายหลัง กระบวนการเชิงรุกนี้ช่วยให้แน่ใจว่าคุณและทีมของคุณกำลังเปลี่ยนรหัสที่เกี่ยวข้องโดยตรงกับข้อมูลที่คุณเกี่ยวข้องเท่านั้น

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

มาดำน้ำกันเถอะ

วิธีการตรวจสอบข้อมูล

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

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

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

เทคนิคการตรวจสอบข้อมูลในเครื่องลูกข่าย

คุณสามารถใช้เครื่องมือเช่น Amplitude Data เพื่อใช้ประโยชน์จากความปลอดภัยของประเภท การทดสอบหน่วย และ linting (การวิเคราะห์โค้ดแบบคงที่) สำหรับการตรวจสอบความถูกต้องของข้อมูลฝั่งไคลเอ็นต์

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

• ความปลอดภัยของประเภท คือเมื่อคอมไพเลอร์ตรวจสอบความถูกต้องของประเภทข้อมูลและคำแนะนำการใช้งานที่ต้นทาง ป้องกันข้อผิดพลาดดาวน์สตรีมเนื่องจากการพิมพ์ผิดหรือตัวแปรที่ไม่คาดคิด
• การทดสอบหน่วย คือเมื่อคุณทดสอบการเลือกรหัสเฉพาะในการแยก น่าเสียดายที่ทีมส่วนใหญ่ไม่ได้รวมการวิเคราะห์ไว้ในการทดสอบหน่วยเมื่อต้องตรวจสอบความถูกต้องของการวิเคราะห์
• การทดสอบ A/B คือการที่คุณทดสอบโฟลว์การวิเคราะห์ของคุณกับชุดข้อมูลสีทอง (เวอร์ชันของการวิเคราะห์ที่คุณรู้ว่าสมบูรณ์แบบ) หรือสำเนาข้อมูลการผลิตของคุณ สิ่งนี้ช่วยให้คุณทราบได้ว่าการเปลี่ยนแปลงที่คุณทำนั้นดีและปรับปรุงสถานการณ์ที่เป็นอยู่หรือไม่

เทคนิคการตรวจสอบข้อมูลในไปป์ไลน์

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

วิธีการตรวจสอบข้อมูลในไปป์ไลน์อาจมีลักษณะดังนี้:

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

เทคนิคการตรวจสอบข้อมูลในคลังสินค้า

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

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

ฟังก์ชันทั้งหมดของเครื่องมือนี้ขึ้นอยู่กับเทคนิคการตรวจสอบข้อมูลหลักบางส่วนในเลเยอร์นี้:

• การจัดทำ แผน เพื่อให้แน่ใจว่าข้อมูล CRUD และการแปลงเป็นไปตามข้อกำหนดที่ตั้งไว้
• การทดสอบความปลอดภัย เพื่อให้แน่ใจว่าข้อมูลเป็นไปตามข้อกำหนดด้านความปลอดภัย เช่น GDPR
• การทดสอบความสัมพันธ์ ในเครื่องมือต่างๆ เช่น dbt เพื่อให้แน่ใจว่าฟิลด์ในโมเดลหนึ่งแมปกับฟิลด์ในตารางที่กำหนด (หรือที่รู้จักในชื่อ Referential Integrity)
• การทดสอบความสดและการกระจาย (ตามที่เรากล่าวถึงในส่วนไปป์ไลน์)
• การ ตรวจสอบช่วงและประเภท ที่ยืนยันว่าข้อมูลที่ส่งจากลูกค้าอยู่ในช่วงหรือรูปแบบที่คาดไว้ของคลังสินค้า

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

เหตุใดจึงถึงเวลาที่จะยอมรับเทคนิคการตรวจสอบข้อมูลที่ดีขึ้น

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

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

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

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

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

ลงทุนในการตรวจสอบวิเคราะห์เชิงรุกเพื่อรับเงินปันผลจากข้อมูล

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

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