ຫນຶ່ງໃນທັກສະທີ່ສໍາຄັນຂອງຜູ້ຊ່ຽວຊານດ້ານຂໍ້ມູນທີ່ປະສົບຜົນສໍາເລັດແມ່ນການຈັດການຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່, ຮັບປະກັນຄຸນນະພາບຂອງຂໍ້ມູນແລະຄວາມຫນ້າເຊື່ອຖື. ຂໍ້ມູນແມ່ນສ່ວນກາງແລະພື້ນຖານຂອງລະບົບຂໍ້ມູນໃດໆ, ແລະໃດກໍ່ຕາມທັກສະທີ່ດີທີ່ທ່ານມີໃນດ້ານອື່ນໆຂອງການຄ້າຂອງພວກເຮົາ, ນີ້ແມ່ນສິ່ງທີ່ທ່ານບໍ່ສາມາດເບິ່ງຂ້າມໄດ້. ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຄົ້ນຫາເຕັກນິກທີ່ເຂັ້ມແຂງສໍາລັບການປະຕິບັດການກວດສອບ QA ກ່ຽວກັບຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ໂດຍໃຊ້ຫ້ອງສະຫມຸດ Deequ ແລະວິທີການສະຖິຕິ. ໂດຍການລວມເອົາວິທີການທີ່ຂ້ອຍອະທິບາຍຂ້າງລຸ່ມນີ້, ທ່ານຈະສາມາດຮັກສາຄວາມສົມບູນຂອງຂໍ້ມູນ, ປັບປຸງການປະຕິບັດການຄຸ້ມຄອງຂໍ້ມູນຂອງທ່ານ, ແລະປ້ອງກັນບັນຫາທີ່ອາດຈະເກີດຂື້ນໃນຄໍາຮ້ອງສະຫມັກລຸ່ມ. ກວດສອບ QA ໂດຍໃຊ້ Deequ Library ເປັນຫຍັງ Deequ? ການຮັບປະກັນຄຸນນະພາບຂອງຂໍ້ມູນໃນລະດັບແມ່ນເປັນວຽກງານທີ່ຫນ້າຢ້ານກົວ, ໂດຍສະເພາະໃນເວລາທີ່ຈັດການກັບຫຼາຍຕື້ແຖວທີ່ເກັບໄວ້ໃນລະບົບໄຟລ໌ທີ່ແຈກຢາຍຫຼືຄັງຂໍ້ມູນ. ຫ້ອງສະໝຸດ Deequ ແມ່ນການສ້າງຂໍ້ມູນຂໍ້ມູນແບບເປີດແຫຼ່ງ ແລະໂຄງຮ່າງ QA ທີ່ສ້າງຂຶ້ນໃນ Spark ເຊິ່ງເປັນເຄື່ອງມືທີ່ທັນສະໄໝ ແລະຫຼາກຫຼາຍທີ່ຖືກອອກແບບມາເພື່ອແກ້ໄຂບັນຫານີ້. ສິ່ງທີ່ກໍານົດມັນນອກເຫນືອຈາກເຄື່ອງມືທີ່ຄ້າຍຄືກັນແມ່ນຄວາມສາມາດໃນການປະສົມປະສານກັບ Spark ຢ່າງບໍ່ຢຸດຢັ້ງ, ນໍາໃຊ້ພະລັງງານການປຸງແຕ່ງທີ່ແຈກຢາຍສໍາລັບການຈັດການຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ຢ່າງມີປະສິດທິພາບ. ເມື່ອທ່ານລອງມັນ, ທ່ານຈະເຫັນວ່າຄວາມຍືດຫຍຸ່ນຂອງມັນຊ່ວຍໃຫ້ທ່ານກໍານົດກົດລະບຽບການກວດສອບທີ່ຊັບຊ້ອນທີ່ເຫມາະສົມກັບຄວາມຕ້ອງການສະເພາະຂອງທ່ານ, ຮັບປະກັນການຄຸ້ມຄອງທີ່ສົມບູນແບບ. ນອກຈາກນັ້ນ, Deequ ມີລັກສະນະການວັດແທກທີ່ກວ້າງຂວາງແລະຄວາມສາມາດໃນການກວດຫາຄວາມຜິດປົກກະຕິທີ່ຈະຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດແລະແກ້ໄຂບັນຫາຄຸນນະພາບຂອງຂໍ້ມູນໄດ້ຢ່າງຈິງຈັງ. ສໍາລັບຜູ້ຊ່ຽວຊານດ້ານຂໍ້ມູນທີ່ເຮັດວຽກກັບຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ແລະແບບເຄື່ອນໄຫວ, Deequ ແມ່ນການແກ້ໄຂດ້ວຍມີດສະວິດ. ໃຫ້ເບິ່ງວ່າພວກເຮົາສາມາດນໍາໃຊ້ມັນໄດ້ແນວໃດ. ການຕັ້ງຄ່າ Deequ ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການຕັ້ງຫ້ອງສະຫມຸດ Deequ ແລະກໍລະນີການນໍາໃຊ້ກ່ຽວກັບການຂໍ້ມູນຂ່າວສານແມ່ນສາມາດເຂົ້າເຖິງ . ສໍາລັບຄວາມງ່າຍດາຍ, ໃນຕົວຢ່າງນີ້, ພວກເຮົາພຽງແຕ່ສ້າງບັນທຶກຂອງຫຼິ້ນຈໍານວນຫນ້ອຍຫນຶ່ງ: ທີ່ນີ້ val rdd = spark.sparkContext.parallelize(Seq( Item(1, "Thingy A", "awesome thing.", "high", 0), Item(2, "Thingy B", "available at http://thingb.com", null, 0), Item(3, null, null, "low", 5), Item(4, "Thingy D", "checkout https://thingd.ca", "low", 10), Item(5, "Thingy E", null, "high", 12))) val data = spark.createDataFrame(rdd) ການກໍານົດສົມມຸດຕິຖານຂໍ້ມູນ ຄໍາຮ້ອງສະຫມັກຂໍ້ມູນສ່ວນໃຫຍ່ມາພ້ອມກັບການສົມມຸດຕິຖານ implicit ກ່ຽວກັບຄຸນລັກສະນະຂໍ້ມູນ, ເຊັ່ນ: ຄ່າທີ່ບໍ່ແມ່ນ NULL ແລະຄວາມເປັນເອກະລັກ. ດ້ວຍ Deequ, ການສົມມຸດຕິຖານເຫຼົ່ານີ້ກາຍເປັນທີ່ຊັດເຈນໂດຍຜ່ານການທົດສອບຫນ່ວຍ. ນີ້ແມ່ນການກວດທົ່ວໄປບາງອັນ: ໃຫ້ແນ່ໃຈວ່າຊຸດຂໍ້ມູນມີຈໍານວນແຖວສະເພາະ. ຈຳນວນແຖວ: ກວດເບິ່ງວ່າຄຸນລັກສະນະເຊັ່ນ id ແລະຊື່ຜະລິດຕະພັນບໍ່ເຄີຍເປັນ NULL. ຄວາມສົມບູນຂອງຄຸນລັກສະນະ: ຮັບປະກັນວ່າຄຸນລັກສະນະສະເພາະ, ເຊັ່ນ: id, ເປັນເອກະລັກ. Attribute Uniqueness: ກວດສອບວ່າຄຸນລັກສະນະຕ່າງໆເຊັ່ນ: ບູລິມະສິດ ແລະ numViews ຢູ່ໃນຂອບເຂດທີ່ຄາດໄວ້. ຊ່ວງມູນຄ່າ: ກວດສອບວ່າຄໍາອະທິບາຍມີ URLs ເມື່ອຄາດຫວັງ. ການຈັບຄູ່ຮູບແບບ: ໃຫ້ແນ່ໃຈວ່າຄ່າສະເລ່ຍຂອງຄຸນລັກສະນະຕົວເລກກົງກັບເງື່ອນໄຂສະເພາະ. ຄຸນສົມບັດທາງສະຖິຕິ: ນີ້ແມ່ນວິທີທີ່ທ່ານສາມາດປະຕິບັດການກວດສອບເຫຼົ່ານີ້ໂດຍໃຊ້ Deequ: import com.amazon.deequ.VerificationSuite import com.amazon.deequ.checks.{Check, CheckLevel, CheckStatus} val verificationResult = VerificationSuite() .onData(data) .addCheck( Check(CheckLevel.Error, "unit testing my data") .hasSize(_ == 5) // we expect 5 rows .isComplete("id") // should never be NULL .isUnique("id") // should not contain duplicates .isComplete("productName") // should never be NULL // should only contain the values "high" and "low" .isContainedIn("priority", Array("high", "low")) .isNonNegative("numViews") // should not contain negative values // at least half of the descriptions should contain a url .containsURL("description", _ >= 0.5) // half of the items should have less than 10 views .hasApproxQuantile("numViews", 0.5, _ <= 10)) .run() ການຕີຄວາມຜົນໄດ້ຮັບ ຫຼັງຈາກດໍາເນີນການກວດສອບເຫຼົ່ານີ້, Deequ ແປໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນຊຸດຂອງວຽກ Spark, ເຊິ່ງມັນດໍາເນີນການເພື່ອຄິດໄລ່ metrics ໃນຂໍ້ມູນ. ຫຼັງຈາກນັ້ນ, ມັນເອີ້ນຟັງຊັນການຢືນຢັນຂອງທ່ານ (ຕົວຢ່າງ, _ == 5 ສໍາລັບການກວດສອບຂະຫນາດ) ຢູ່ໃນຕົວຊີ້ບອກເຫຼົ່ານີ້ເພື່ອເບິ່ງວ່າຂໍ້ຈໍາກັດຍຶດຫມັ້ນຢູ່ໃນຂໍ້ມູນ. ພວກເຮົາສາມາດກວດສອບວັດຖຸ "ການກວດສອບຜົນໄດ້ຮັບ" ເພື່ອເບິ່ງວ່າການທົດສອບພົບຄວາມຜິດພາດ: import com.amazon.deequ.constraints.ConstraintStatus if (verificationResult.status == CheckStatus.Success) { println("The data passed the test, everything is fine!") } else { println("We found errors in the data:\n") val resultsForAllConstraints = verificationResult.checkResults .flatMap { case (_, checkResult) => checkResult.constraintResults } resultsForAllConstraints .filter { _.status != ConstraintStatus.Success } .foreach { result => println(s"${result.constraint}: ${result.message.get}") } } ຖ້າພວກເຮົາດໍາເນີນການຕົວຢ່າງ, ພວກເຮົາໄດ້ຮັບຜົນໄດ້ຮັບຕໍ່ໄປນີ້: We found errors in the data: CompletenessConstraint(Completeness(productName)): Value: 0.8 does not meet the requirement! PatternConstraint(containsURL(description)): Value: 0.4 does not meet the requirement! ການທົດສອບພົບວ່າສົມມຸດຕິຖານຂອງພວກເຮົາຖືກລະເມີດ! ພຽງແຕ່ 4 ອອກຈາກ 5 (80%) ຂອງຄຸນຄ່າຂອງຄຸນສົມບັດຊື່ຜະລິດຕະພັນແມ່ນບໍ່ແມ່ນ null, ແລະມີພຽງແຕ່ 2 ໃນ 5 (ເຊັ່ນ: 40%) ຂອງຄຸນລັກສະນະຄໍາອະທິບາຍມີ URL. ໂຊກດີ, ພວກເຮົາໄດ້ດໍາເນີນການທົດສອບແລະພົບເຫັນຄວາມຜິດພາດ; ບາງຄົນຄວນແກ້ໄຂຂໍ້ມູນທັນທີ! QA ກວດສອບດ້ວຍວິທີການສະຖິຕິ ໃນຂະນະທີ່ Deequ ສະເຫນີກອບທີ່ເຂັ້ມແຂງສໍາລັບການກວດສອບຂໍ້ມູນ, ການລວມເອົາວິທີການສະຖິຕິສາມາດປັບປຸງການກວດສອບ QA ຂອງທ່ານຕື່ມອີກ, ໂດຍສະເພາະຖ້າທ່ານຈັດການກັບຕົວຊີ້ບອກລວມຂອງຊຸດຂໍ້ມູນ. ໃຫ້ເບິ່ງວິທີທີ່ທ່ານສາມາດຈ້າງວິທີການສະຖິຕິເພື່ອຕິດຕາມແລະຮັບປະກັນຄຸນນະພາບຂໍ້ມູນ. ບັນທຶກການຕິດຕາມການນັບ ພິຈາລະນາສະຖານະການທຸລະກິດທີ່ຂະບວນການ ETL (Extract, Transform, Load) ຜະລິດບັນທຶກ N ໃນວຽກທີ່ກໍານົດປະຈໍາວັນ. ທີມງານສະຫນັບສະຫນູນອາດຈະຕ້ອງຕັ້ງຄ່າການກວດສອບ QA ເພື່ອຍົກສູງການແຈ້ງເຕືອນຖ້າມີຄວາມແຕກຕ່າງຢ່າງຫຼວງຫຼາຍໃນຈໍານວນບັນທຶກ. ຕົວຢ່າງເຊັ່ນ, ຖ້າຂະບວນການປົກກະຕິສ້າງລະຫວ່າງ 9,500 ຫາ 10,500 ບັນທຶກປະຈໍາວັນໃນໄລຍະສອງເດືອນ, ການເພີ່ມຂຶ້ນຫຼືຫຼຸດລົງຢ່າງຫຼວງຫຼາຍສາມາດຊີ້ໃຫ້ເຫັນບັນຫາກັບຂໍ້ມູນພື້ນຖານ. ພວກເຮົາສາມາດໃຊ້ວິທີທາງສະຖິຕິເພື່ອກໍານົດຂອບເຂດນີ້ກ່ຽວກັບຂະບວນການໃດທີ່ຄວນເຕືອນໃຫ້ທີມງານສະຫນັບສະຫນູນ. ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງການຕິດຕາມການນັບບັນທຶກໃນໄລຍະສອງເດືອນ: ເພື່ອວິເຄາະນີ້, ພວກເຮົາສາມາດປ່ຽນຂໍ້ມູນການນັບບັນທຶກເພື່ອສັງເກດການປ່ຽນແປງປະຈໍາວັນ. ໂດຍທົ່ວໄປແລ້ວການປ່ຽນແປງເຫຼົ່ານີ້ຈະເຄື່ອນທີ່ປະມານສູນ, ດັ່ງທີ່ສະແດງຢູ່ໃນຕາຕະລາງຕໍ່ໄປນີ້: ເມື່ອພວກເຮົາເປັນຕົວແທນອັດຕາການປ່ຽນແປງນີ້ດ້ວຍການແຈກຢາຍປົກກະຕິ, ມັນປະກອບເປັນເສັ້ນໂຄ້ງ, ສະແດງໃຫ້ເຫັນວ່າຂໍ້ມູນຖືກແຈກຢາຍຕາມປົກກະຕິ. ການປ່ຽນແປງທີ່ຄາດໄວ້ແມ່ນປະມານ 0%, ມີຄ່າບ່ຽງເບນມາດຕະຖານ 2.63%. ການວິເຄາະນີ້ຊີ້ໃຫ້ເຫັນວ່າການນັບບັນທຶກໂດຍປົກກະຕິແມ່ນຢູ່ໃນລະດັບ -5.26% ຫາ +5.25% ທີ່ມີຄວາມຫມັ້ນໃຈ 90%. ອີງຕາມການນີ້, ທ່ານສາມາດສ້າງກົດລະບຽບເພື່ອປຸກເຕືອນຖ້າຫາກວ່າຈໍານວນບັນທຶກ deviates ເກີນຂອບເຂດນີ້, ຮັບປະກັນການແຊກແຊງທັນເວລາ. ຄຸນສົມບັດການຕິດຕາມການຄຸ້ມຄອງ e ໝາຍເຖິງອັດຕາສ່ວນຂອງຄ່າທີ່ບໍ່ແມ່ນ NULL ຕໍ່ກັບຈຳນວນບັນທຶກທັງໝົດສຳລັບການຖ່າຍຮູບຊຸດຂໍ້ມູນ. ຕົວຢ່າງ, ຖ້າ 8 ໃນ 100 ບັນທຶກມີມູນຄ່າ NULL ສໍາລັບຄຸນລັກສະນະສະເພາະ, ການຄຸ້ມຄອງສໍາລັບຄຸນລັກສະນະນັ້ນແມ່ນ 92%. Attribute coverag ຂໍໃຫ້ທົບທວນຄືນກໍລະນີທຸລະກິດອື່ນທີ່ມີຂະບວນການ ETL ສ້າງຕາຕະລາງຜະລິດຕະພັນປະຈໍາວັນ. ພວກເຮົາຕ້ອງການຕິດຕາມກວດກາການຄຸ້ມຄອງຂອງຄຸນລັກສະນະຄໍາອະທິບາຍຜະລິດຕະພັນ. ຖ້າການຄຸ້ມຄອງຫຼຸດລົງຕໍ່າກວ່າເກນທີ່ແນ່ນອນ, ຄວນເຕືອນໃຫ້ທີມງານຊ່ວຍເຫຼືອ. ຂ້າງລຸ່ມນີ້ແມ່ນການສະແດງພາບຂອງການຄຸ້ມຄອງຄຸນລັກສະນະສໍາລັບການອະທິບາຍຜະລິດຕະພັນໃນໄລຍະສອງເດືອນ: ໂດຍການວິເຄາະຄວາມແຕກຕ່າງຢ່າງແທ້ຈິງໃນແຕ່ລະມື້ໃນການຄຸ້ມຄອງ, ພວກເຮົາສັງເກດເຫັນວ່າການປ່ຽນແປງປະມານສູນ: ການເປັນຕົວແທນຂອງຂໍ້ມູນນີ້ເປັນການແຈກຢາຍແບບປົກກະຕິສະແດງໃຫ້ເຫັນວ່າມັນຖືກແຈກຢາຍໂດຍປົກກະຕິໂດຍການປ່ຽນແປງທີ່ຄາດວ່າຈະປະມານ 0% ແລະຄ່າບ່ຽງເບນມາດຕະຖານ 2.45%. ດັ່ງທີ່ພວກເຮົາເຫັນ, ສໍາລັບຊຸດຂໍ້ມູນນີ້, ການຄຸ້ມຄອງຄຸນລັກສະນະລາຍລະອຽດຂອງຜະລິດຕະພັນແມ່ນປົກກະຕິຕັ້ງແຕ່ -4.9% ຫາ +4.9% ດ້ວຍຄວາມຫມັ້ນໃຈ 90%. ອີງໃສ່ຕົວຊີ້ວັດນີ້, ພວກເຮົາສາມາດກໍານົດກົດລະບຽບເພື່ອປຸກເຕືອນຖ້າຫາກວ່າການຄຸ້ມຄອງ deviates ເກີນຂອບເຂດນີ້. QA ກວດສອບດ້ວຍສູດການຄິດໄລ່ຊຸດເວລາ ຖ້າທ່ານເຮັດວຽກກັບຊຸດຂໍ້ມູນທີ່ສະແດງໃຫ້ເຫັນການປ່ຽນແປງທີ່ສໍາຄັນເນື່ອງຈາກປັດໃຈເຊັ່ນ: ລະດູການຫຼືແນວໂນ້ມ, ວິທີການສະຖິຕິແບບດັ້ງເດີມອາດຈະເຮັດໃຫ້ເກີດການແຈ້ງເຕືອນທີ່ບໍ່ຖືກຕ້ອງ. ສູດການຄິດໄລ່ຊຸດເວລາສະເຫນີວິທີການທີ່ຫລອມໂລຫະຫຼາຍຂຶ້ນ, ປັບປຸງຄວາມຖືກຕ້ອງແລະຄວາມຫນ້າເຊື່ອຖືຂອງການກວດສອບ QA ຂອງທ່ານ. ເພື່ອຜະລິດການແຈ້ງເຕືອນທີ່ສົມເຫດສົມຜົນຫຼາຍ, ທ່ານສາມາດນໍາໃຊ້ໄດ້ ຫຼື . ອະດີດແມ່ນດີພໍສໍາລັບຊຸດຂໍ້ມູນທີ່ມີແນວໂນ້ມ, ແຕ່ອັນສຸດທ້າຍໃຫ້ພວກເຮົາຈັດການກັບຊຸດຂໍ້ມູນທີ່ມີທັງແນວໂນ້ມແລະລະດູການ. ວິທີການນີ້ໃຊ້ອົງປະກອບສໍາລັບລະດັບ, ທ່າອ່ຽງ, ແລະລະດູການ, ເຊິ່ງອະນຸຍາດໃຫ້ມັນປັບຕົວກັບການປ່ຽນແປງໃນໄລຍະເວລາ. Autoregressive Integrated Moving Average (ARIMA) ວິທີການ Holt-Winters ໃຫ້ເບິ່ງແບບຈໍາລອງການຂາຍປະຈໍາວັນທີ່ສະແດງທັງແນວໂນ້ມແລະຮູບແບບຕາມລະດູການໂດຍໃຊ້ Holt-Winters: import pandas as pd from statsmodels.tsa.holtwinters import ExponentialSmoothing # Load and preprocess the dataset data = pd.read_csv('sales_data.csv', index_col='date', parse_dates=True) data = data.asfreq('D').fillna(method='ffill') # Fit the Holt-Winters model model = ExponentialSmoothing(data, trend='add', seasonal='add', seasonal_periods=365) fit = model.fit() # Forecast and detect anomalies forecast = fit.fittedvalues residuals = data - forecast threshold = 3 * residuals.std() anomalies = residuals[abs(residuals) > threshold] print("Anomalies detected:") print(anomalies) ການນໍາໃຊ້ວິທີການນີ້, ທ່ານສາມາດກວດພົບຄວາມບິດເບືອນທີ່ສໍາຄັນທີ່ອາດຈະຊີ້ບອກເຖິງບັນຫາຄຸນນະພາບຂອງຂໍ້ມູນ, ສະຫນອງວິທີການທີ່ລະອຽດອ່ອນກວ່າໃນການກວດສອບ QA. ຂ້ອຍຫວັງວ່າບົດຄວາມນີ້ຈະຊ່ວຍໃຫ້ທ່ານປະຕິບັດການກວດສອບ QA ໄດ້ຢ່າງມີປະສິດທິພາບສໍາລັບຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ຂອງເຈົ້າ. ໂດຍການນໍາໃຊ້ຫ້ອງສະຫມຸດ Deequ ແລະການລວມເອົາວິທີການສະຖິຕິແລະສູດການຄິດໄລ່ໄລຍະເວລາ, ທ່ານສາມາດຮັບປະກັນຄວາມສົມບູນຂອງຂໍ້ມູນແລະຄວາມຫນ້າເຊື່ອຖື, ໃນທີ່ສຸດການເພີ່ມປະສິດທິພາບການຄຸ້ມຄອງຂໍ້ມູນຂອງທ່ານ. ການປະຕິບັດເຕັກນິກທີ່ອະທິບາຍໄວ້ຂ້າງເທິງຈະຊ່ວຍໃຫ້ທ່ານປ້ອງກັນບັນຫາທີ່ອາດເກີດຂື້ນໃນແອັບພລິເຄຊັນລຸ່ມນ້ໍາແລະປັບປຸງຄຸນນະພາບໂດຍລວມຂອງຂະບວນການເຮັດວຽກຂໍ້ມູນຂອງທ່ານ.
