วิธีดำเนินการตามกระบวนการคุณภาพข้อมูล

คุณภาพข้อมูล (DQ) ในระบบคลังข้อมูลมีความสำคัญมากขึ้นเรื่อยๆ ข้อกำหนดด้านกฎระเบียบที่เพิ่มขึ้น แต่ยังมีความซับซ้อนเพิ่มขึ้นของโซลูชันคลังข้อมูล บังคับให้บริษัทต่างๆ เร่งรัด (หรือเริ่ม) ความคิดริเริ่มด้านคุณภาพข้อมูล

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

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

• มีปัญหาด้านคุณภาพของข้อมูลที่ส่งผลกระทบอย่างรุนแรงต่อธุรกิจ
• หน่วยงานกำกับดูแลบังคับใช้มาตรฐานคุณภาพข้อมูล (เช่น BCBS 239 ในอุตสาหกรรมการเงิน)

การรักษาของ DQ นั้นคล้ายกับการทดสอบในการพัฒนาซอฟต์แวร์—หากโครงการหมดเวลาและ/หรืองบประมาณ ส่วนนี้มักจะลดลงก่อน

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

คำจำกัดความของข้อกำหนด

ก่อนอภิปรายหัวข้อ ความเข้าใจทั่วไปเกี่ยวกับคำศัพท์ที่ใช้เป็นสิ่งสำคัญ

คลังข้อมูล (DWH)

คลังข้อมูล (DWH) คือระบบที่ไม่ใช้ระบบปฏิบัติการซึ่งส่วนใหญ่ใช้สำหรับการสนับสนุนการตัดสินใจ มันรวบรวมข้อมูลของระบบปฏิบัติการ (ทั้งหมดหรือชุดย่อยที่เล็กกว่า) และให้ข้อมูลที่ปรับให้เหมาะสมสำหรับการสืบค้นสำหรับผู้ใช้ระบบ DWH คลังข้อมูลควรจัดเตรียม "ความจริงเวอร์ชันเดียว" ภายในองค์กร คลังข้อมูลมักจะสร้างจากขั้นตอน/ชั้น:

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

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

คุณภาพของข้อมูล

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

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

คุณภาพของข้อมูลเป็นหัวข้อต่อเนื่อง ต้องใช้วงจรวงจร DQ (ดูบทต่อไป) ข้อกำหนดด้านกฎระเบียบและกฎการปฏิบัติตามกฎระเบียบยังมีผลกระทบต่อคุณภาพของข้อมูลที่จำเป็น เช่น TCPA (กฎหมายคุ้มครองผู้บริโภคทางโทรศัพท์ของสหรัฐอเมริกา) หรือ GDPR ในยุโรปสำหรับปัญหาความเป็นส่วนตัว แต่ยังรวมถึงกฎเฉพาะอุตสาหกรรม เช่น Solvency II สำหรับการประกันภัยในสหภาพยุโรป BCBS 239 และอื่นๆ เพื่อการธนาคาร เป็นต้น

วงจรคุณภาพข้อมูล

เช่นเดียวกับหัวข้อคุณภาพทั้งหมด DQ เป็นกิจกรรมต่อเนื่องที่ออกแบบมาเพื่อรักษาคุณภาพที่น่าพอใจ อันเป็นผลมาจากโครงการ DQ จะต้องนำ วงจรวนรอบ ที่คล้ายกับด้านล่างมาใช้:

ขั้นตอนในลูปนี้จะอธิบายในบทต่อไป

บทบาทด้านคุณภาพข้อมูล

เพื่อนำความคิดริเริ่ม DQ ที่ประสบความสำเร็จไปใช้ บทบาทต่อไปนี้มีความจำเป็น:

• เจ้าของข้อมูล เจ้าของข้อมูลมีหน้าที่รับผิดชอบต่อคุณภาพของข้อมูล แต่ยังรวมถึงการปกป้องความเป็นส่วนตัวของข้อมูลด้วย เจ้าของข้อมูล “เป็นเจ้าของ” โดเมนข้อมูล ควบคุมการเข้าถึง และรับผิดชอบในการประกันคุณภาพของข้อมูลและดำเนินการแก้ไขข้อค้นพบ ในองค์กรขนาดใหญ่ มักพบเจ้าของข้อมูลหลายราย โดเมนข้อมูลอาจเป็นเช่น ข้อมูลการตลาด การควบคุมข้อมูล ฯลฯ หากมีเจ้าของข้อมูลมากกว่าหนึ่งรายในบริษัท ควรมีบุคคลหนึ่งคน (เจ้าของข้อมูลหรือบุคคลอื่น) ที่รับผิดชอบในกระบวนการคุณภาพข้อมูลโดยรวม เจ้าของข้อมูลควรมีอำนาจที่เข้มแข็งในการบังคับใช้คุณภาพข้อมูลและสนับสนุนกระบวนการ DQ ดังนั้นเจ้าของข้อมูลจึงมักเป็นผู้มีส่วนได้เสียอาวุโส ความเข้าใจที่ดีเกี่ยวกับโดเมนธุรกิจควบคู่ไปกับทักษะการสื่อสารที่ดีเป็นสิ่งสำคัญ
• สจ๊วตข้อมูล ผู้ดูแลข้อมูลช่วยนำคุณภาพข้อมูลไปใช้ในองค์กร สนับสนุนผู้ใช้ข้อมูลในคำถามเกี่ยวกับวิธีตีความข้อมูล/รูปแบบข้อมูล ปัญหาด้านคุณภาพข้อมูล ฯลฯ ผู้ดูแลข้อมูลมักเป็นพนักงานของเจ้าของข้อมูลหรือสามารถจัดระเบียบในศูนย์ความสามารถด้านคุณภาพข้อมูล หรือทีม DQ ผู้ดูแลข้อมูลสามารถมีพื้นฐานด้านไอทีหรือธุรกิจได้ แต่ควรทราบทั้งสองฝ่าย ทักษะการวิเคราะห์พร้อมกับความเข้าใจที่ดีเกี่ยวกับโดเมนธุรกิจที่พวกเขาสนับสนุน รวมกับทักษะในการสื่อสารที่ดี เป็นข้อกำหนดเบื้องต้นที่สำคัญสำหรับผู้ดูแลข้อมูลที่ประสบความสำเร็จ
• ผู้ใช้ข้อมูล เหล่านี้คือผู้ใช้คลังข้อมูลที่ทำงานกับข้อมูล ผู้ใช้ข้อมูลมักจะทำงานกับเลเยอร์ของ data mart และรับผิดชอบต่อผลลัพธ์การทำงานกับข้อมูล ผู้ใช้ข้อมูลต้องแน่ใจว่ามีการตรวจสอบคุณภาพข้อมูลที่เพียงพอสำหรับระดับคุณภาพที่ต้องการ ผู้ใช้ข้อมูลจำเป็นต้องมีความเข้าใจอย่างลึกซึ้งในข้อมูล โดเมนธุรกิจ และทักษะการวิเคราะห์ที่จำเป็นในการตีความข้อมูล มีเหตุผลที่จะหาคนไม่กี่คนในหมู่ผู้ใช้ข้อมูลในทุกหน่วยธุรกิจที่จะรับผิดชอบปัญหาด้านคุณภาพของข้อมูล

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

กำหนดกฎเกณฑ์

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

จะค้นหากฎ DQ ได้อย่างไร

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

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

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

แก้ไขข้อผิดพลาด

ข้อผิดพลาดที่ทราบประเภทใดที่อาจเกิดขึ้นในคลังข้อมูล

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

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

มิติข้อมูลคุณภาพ

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

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

ข้อมูลที่สร้างโดย กระบวนการโหลด คลังข้อมูลก็มีประโยชน์เช่นกัน

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

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

ภายในคลังข้อมูลที่ซับซ้อน คุณอาจจบลงด้วยกฎ DQ จำนวนมาก (บางครั้งนับพัน) กระบวนการในการดำเนินการตามกฎคุณภาพข้อมูลควรมีความรัดกุมและรวดเร็วเพียงพอที่จะจัดการกับสิ่งนี้

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

• คอลัมน์ที่กำหนดเป็นบังคับมีค่า NULL
• ค่าฟิลด์คีย์หลักจะไม่ซ้ำกันในตาราง
• ไม่มีคีย์ต่างประเทศอยู่ในตารางที่เปิดใช้งานการตรวจสอบความสมบูรณ์เชิงสัมพันธ์

อย่างไรก็ตาม พึงระลึกไว้เสมอว่าคลังข้อมูลมีการเปลี่ยนแปลงอยู่ตลอดเวลา และข้อกำหนดข้อมูลของเขตข้อมูลและตารางอาจเปลี่ยนแปลงเมื่อเวลาผ่านไป

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

ประเภทของกฎคุณภาพข้อมูล

กฎคุณภาพข้อมูลสามารถจำแนกได้ตามประเภทของการทดสอบ

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

วิธีการหาปริมาณปัญหาคุณภาพข้อมูล

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

ชิ้นส่วนต่อไปนี้หายไป:

• วิธีการหาจำนวน/นับข้อผิดพลาดที่ตรวจพบ คุณอาจนับ “จำนวนแถว” แต่คุณอาจใช้มาตราส่วนการเงิน (เช่น การเปิดเผย) โปรดทราบว่ามูลค่าทางการเงินอาจมีสัญญาณต่างกัน ดังนั้นคุณจะต้องตรวจสอบวิธีสรุปค่าเหล่านี้อย่างมีความหมาย คุณอาจลองใช้ทั้งหน่วยวัดปริมาณ (จำนวนแถวและการสรุป) สำหรับกฎคุณภาพข้อมูล
• ประชากร. จำนวนหน่วยที่ตรวจสอบโดยกฎคุณภาพข้อมูลคือเท่าใด “ห้าแถวข้อมูลในห้า” มีคุณภาพแตกต่างจาก “ห้าใน 5 ล้าน” ประชากรควรวัดโดยใช้ปริมาณเดียวกันกับข้อผิดพลาด เป็นเรื่องปกติที่จะแสดงผลลัพธ์ของกฎคุณภาพข้อมูลเป็นเปอร์เซ็นต์ ประชากรต้องไม่เหมือนกับจำนวนแถวในตาราง หากกฎ DQ ตรวจสอบเฉพาะชุดย่อยของข้อมูล (เช่น เฉพาะสัญญาที่สิ้นสุดในตารางสัญญา) ควรใช้ตัวกรองเดียวกันเพื่อวัดจำนวนประชากร
• คำจำกัดความของผลลัพธ์ แม้ว่าการตรวจสอบคุณภาพข้อมูลจะพบปัญหา แต่ก็ไม่จำเป็นต้องทำให้เกิดข้อผิดพลาดเสมอไป สำหรับคุณภาพของข้อมูล ระบบสัญญาณไฟจราจร (แดง เหลือง เขียว) ที่ใช้ค่าเกณฑ์ในการให้คะแนนสิ่งที่ค้นพบนั้นมีประโยชน์มาก ตัวอย่างเช่น สีเขียว: 0-2% สีเหลือง: 2-5% สีแดง: สูงกว่า 5% โปรดทราบว่าหากหน่วยข้อมูลผู้ใช้ใช้กฎเดียวกัน อาจมีเกณฑ์ที่แตกต่างกันมากสำหรับกฎที่กำหนด หน่วยธุรกิจการตลาดอาจไม่คำนึงถึงการสูญเสียคำสั่งซื้อบางส่วน ในขณะที่หน่วยบัญชีอาจสนใจแม้กระทั่งเซ็นต์ ควรกำหนดเกณฑ์เป็นเปอร์เซ็นต์หรือตัวเลขที่แน่นอนได้
• รวบรวมแถวข้อผิดพลาดตัวอย่าง จะช่วยได้หากกฎคุณภาพข้อมูลแสดงตัวอย่างข้อผิดพลาดที่ตรวจพบ โดยปกติ คีย์ (ธุรกิจ!) และค่าข้อมูลที่ตรวจสอบแล้วเพียงพอที่จะช่วยตรวจสอบข้อผิดพลาด เป็นความคิดที่ดีที่จะจำกัดจำนวนแถวข้อผิดพลาดที่เขียนไว้สำหรับกฎคุณภาพข้อมูล
• บางครั้ง คุณอาจพบ “ข้อผิดพลาดที่ทราบ” ในข้อมูลที่จะไม่ได้รับการแก้ไข แต่จะพบได้โดยการตรวจสอบคุณภาพข้อมูลที่มีประโยชน์ ในกรณีเหล่านี้ ขอแนะนำให้ใช้ รายการที่อนุญาตพิเศษ (คีย์ของระเบียนที่ควรข้ามโดยการตรวจสอบคุณภาพข้อมูล)

ข้อมูลเมตาอื่นๆ

ข้อมูลเมตามีความสำคัญในการกำหนดเส้นทาง "วิเคราะห์" และตรวจสอบขั้นตอนของการควบคุมคุณภาพข้อมูล

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

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

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

การวัดคุณภาพข้อมูล

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

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

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

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

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

วิเคราะห์

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

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

การดำเนินการต่อไปนี้เป็นไปได้:

• ปัญหาร้ายแรง: ปัญหาต้องได้รับการแก้ไขและโหลดข้อมูลซ้ำ
• ปัญหาเป็นที่ยอมรับ: พยายามแก้ไขสำหรับการโหลดข้อมูลในอนาคต และจัดการกับปัญหาภายในคลังข้อมูลหรือการรายงาน
• กฎ DQ ที่มี ข้อบกพร่อง: แก้ไขกฎ DQ ที่มีปัญหา

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

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

แดชบอร์ดคุณภาพข้อมูล ควรประกอบด้วย:

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

แดชบอร์ดยังควรแสดงสถานะปัจจุบันของกระบวนการโหลดคลังข้อมูลล่าสุด ให้ผู้ใช้ได้เห็นมุมมอง 360 องศาของกระบวนการโหลดคลังข้อมูล

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

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

โดยส่วนตัวแล้ว ฉันคิดว่าการคำนวณมูลค่าโดยรวมของคุณภาพข้อมูลสำหรับโดเมนข้อมูลที่กำหนดนั้นค่อนข้างซับซ้อนและมีแนวโน้มที่จะเป็นแบบคาบาลิสติก แต่อย่างน้อย คุณสามารถแสดงจำนวนกฎโดยรวมที่จัดกลุ่มตามผลลัพธ์สำหรับโดเมนข้อมูล (เช่น “กฎ 100 DQ ด้วยผลลัพธ์สีเขียว 90% สีเหลือง 5% และสีแดง 5%”)

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

ปรับปรุงกระบวนการ

เนื่องจากกระบวนการคลังข้อมูลมักเปลี่ยนแปลง กลไกคุณภาพข้อมูลจึงจำเป็นต้องบำรุงรักษาด้วย

เจ้าของข้อมูลควรดูแลประเด็นต่อไปนี้เสมอ:

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

การตรวจสอบกระบวนการคุณภาพข้อมูล

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

สิ่งที่ควรค่าแก่การดูคือ:

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

บทสรุป

หลายประเด็นต่อไปนี้มีความสำคัญในโครงการประเภทใด

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

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

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

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

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

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