ມັນອາດຈະເປັນການຍາກເລັກນ້ອຍທີ່ຈະພິຈາລະນາການບໍລິການທີ່ມີຢູ່ແລະທາງເລືອກສະຖາປັດຕະຍະກໍາທັງຫມົດໃນເວລາທີ່ຄິດກ່ຽວກັບແພລະຕະຟອມຂໍ້ມູນ.
ແພລະຕະຟອມຂໍ້ມູນວິສາຫະກິດມັກຈະປະກອບດ້ວຍຄັງຂໍ້ມູນ, ຮູບແບບຂໍ້ມູນ, ຂໍ້ມູນຂໍ້ມູນ, ແລະບົດລາຍງານ, ແຕ່ລະຄົນມີຈຸດປະສົງສະເພາະແລະຊຸດທັກສະທີ່ຈໍາເປັນ. ໃນທາງກົງກັນຂ້າມ, ການອອກແບບໃຫມ່ທີ່ເອີ້ນວ່າ data lakehouse ໄດ້ເກີດຂື້ນໃນໄລຍະສອງສາມປີຜ່ານມາ.
ຄວາມຄ່ອງແຄ້ວຂອງ Data lakes ແລະການຄຸ້ມຄອງຂໍ້ມູນຄັງເກັບຂໍ້ມູນແມ່ນລວມເຂົ້າກັນໃນສະຖາປັດຕະຍະກໍາການເກັບຮັກສາຂໍ້ມູນປະຕິວັດທີ່ມີຊື່ວ່າ "Data lakehouse."
ພວກເຮົາຈະກວດກາເບິ່ງຂໍ້ມູນໃນຄວາມເລິກໃນບົດຄວາມນີ້, ລວມທັງອົງປະກອບຂອງຕົນ, ລັກສະນະ, ສະຖາປັດຕະ, ແລະດ້ານອື່ນໆ.
Data Lakehouse ແມ່ນຫຍັງ?
ດັ່ງທີ່ຊື່ຫມາຍເຖິງ, data lakehouse ແມ່ນປະເພດໃຫມ່ຂອງສະຖາປັດຕະຍະກໍາຂໍ້ມູນທີ່ປະສົມປະສານກັບ Data lake ກັບຄັງຂໍ້ມູນເພື່ອແກ້ໄຂຂໍ້ບົກຜ່ອງຂອງແຕ່ລະຄົນແຍກຕ່າງຫາກ.
ໂດຍເນື້ອແທ້ແລ້ວ, ລະບົບ lakehouse ໃຊ້ການເກັບຮັກສາລາຄາບໍ່ແພງເພື່ອຮັກສາຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍໃນຮູບແບບຕົ້ນສະບັບຂອງພວກເຂົາ, ຄືກັບຂໍ້ມູນທະເລສາບ. ການເພີ່ມຊັ້ນຂໍ້ມູນເມຕາເດຕາຢູ່ເທິງສຸດຂອງຮ້ານຍັງໃຫ້ໂຄງສ້າງຂໍ້ມູນ ແລະສ້າງຄວາມເຂັ້ມແຂງໃຫ້ເຄື່ອງມືການຈັດການຂໍ້ມູນຄືກັບທີ່ພົບເຫັນຢູ່ໃນຄັງຂໍ້ມູນ.
ມັນເກັບຮັກສາປະລິມານອັນໃຫຍ່ຫຼວງຂອງຂໍ້ມູນທີ່ມີການຈັດຕັ້ງ, ເຄິ່ງໂຄງສ້າງ, ແລະບໍ່ມີໂຄງສ້າງທີ່ພວກເຂົາໄດ້ຮັບຈາກແອັບພລິເຄຊັນທຸລະກິດ, ລະບົບ, ແລະເຄື່ອງມືທີ່ແຕກຕ່າງກັນທີ່ໃຊ້ໃນທົ່ວອົງການຈັດຕັ້ງຂອງພວກເຂົາ.
ສ່ວນໃຫຍ່ຂອງເວລາ, ຂໍ້ມູນການເກັບຂໍ້ມູນໃຊ້ໂຄງສ້າງພື້ນຖານການເກັບຮັກສາທີ່ມີລາຄາຖືກທີ່ມີການໂຕ້ຕອບການຂຽນໂປຼແກຼມໂປຼແກຼມ (API) ເພື່ອເກັບຮັກສາຂໍ້ມູນໃນຮູບແບບໄຟລ໌ທົ່ວໄປ.
ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ສໍາລັບທີມງານຈໍານວນຫຼາຍທີ່ຈະເຂົ້າເຖິງຂໍ້ມູນຂອງບໍລິສັດທັງຫມົດໂດຍຜ່ານລະບົບດຽວສໍາລັບການລິເລີ່ມທີ່ຫລາກຫລາຍ, ເຊັ່ນ: ວິທະຍາສາດຂໍ້ມູນ, ການຮຽນຮູ້ເຄື່ອງຈັກ, ແລະທາງທຸລະກິດ.
ຄຸນລັກສະນະ
- ການເກັບຮັກສາລາຄາຖືກ. A lakehouse ຂໍ້ມູນຈະຕ້ອງສາມາດເກັບຮັກສາຂໍ້ມູນໃນການເກັບຮັກສາວັດຖຸລາຄາຖືກ, ເຊັ່ນ: Google Cloud ການເກັບຮັກສາ, ການເກັບຮັກສາ Azure Blob, Amazon Simple Storage Service, ຫຼືພື້ນເມືອງທີ່ໃຊ້ ORC ຫຼື Parquet.
- ຄວາມສາມາດໃນການເພີ່ມປະສິດທິພາບຂໍ້ມູນ: ການເພີ່ມປະສິດທິພາບການຈັດວາງຂໍ້ມູນ, ແຄດ, ແລະການດັດສະນີແມ່ນບາງຕົວຢ່າງຂອງວິທີການ lakehouse ຂໍ້ມູນຕ້ອງສາມາດເພີ່ມປະສິດທິພາບຂໍ້ມູນໃນຂະນະທີ່ຮັກສາຮູບແບບຕົ້ນສະບັບຂອງຂໍ້ມູນ.
- ຊັ້ນຂອງ metadata ການເຮັດທຸລະກໍາ: ຢູ່ເທິງສຸດຂອງການເກັບຮັກສາຄ່າໃຊ້ຈ່າຍຕ່ໍາທີ່ສໍາຄັນ, ນີ້ເຮັດໃຫ້ຄວາມສາມາດໃນການຈັດການຂໍ້ມູນທີ່ສໍາຄັນສໍາລັບການປະຕິບັດຄັງຂໍ້ມູນ.
- ຮອງຮັບ Declarative DataFrame API: ເຄື່ອງມື AI ສ່ວນໃຫຍ່ສາມາດໃຊ້ DataFrames ເພື່ອດຶງຂໍ້ມູນການເກັບຮັກສາວັດຖຸດິບ. ການສະຫນັບສະຫນູນສໍາລັບ Declarative DataFrame API ເພີ່ມຄວາມສາມາດໃນການປັບປຸງການນໍາສະເຫນີຂໍ້ມູນແລະໂຄງສ້າງຂອງຂໍ້ມູນແບບເຄື່ອນໄຫວເພື່ອຕອບສະຫນອງກັບວຽກງານວິທະຍາສາດຂໍ້ມູນຫຼື AI ໂດຍສະເພາະ.
- ສະຫນັບສະຫນູນການເຮັດທຸລະກໍາ ACID: ຄໍາຫຍໍ້ ACID, ເຊິ່ງຫຍໍ້ມາຈາກ atomicity, ຄວາມສອດຄ່ອງ, ໂດດດ່ຽວ, ແລະຄວາມທົນທານ, ເປັນອົງປະກອບທີ່ສໍາຄັນໃນການກໍານົດທຸລະກໍາແລະຮັບປະກັນຄວາມສອດຄ່ອງແລະຄວາມຫມັ້ນຄົງຂອງຂໍ້ມູນ. ການເຮັດທຸລະກໍາດັ່ງກ່າວໃນເມື່ອກ່ອນແມ່ນເປັນໄປໄດ້ພຽງແຕ່ໃນຄັງຂໍ້ມູນ, ແຕ່ວ່າ lakehouse ສະເຫນີທາງເລືອກທີ່ຈະນໍາໃຊ້ໃຫ້ເຂົາເຈົ້າກັບ lakes ຂໍ້ມູນ ຄືກັນ. ດ້ວຍທໍ່ຂໍ້ມູນຫຼາຍອັນລວມທັງການອ່ານແລະຂຽນຂໍ້ມູນພ້ອມກັນ, ນີ້ແກ້ໄຂບັນຫາຂອງຂໍ້ມູນທີ່ມີຄຸນນະພາບຕ່ໍາຂອງຂໍ້ມູນສຸດທ້າຍ.
ອົງປະກອບຂອງ Data Lakehouse
ສະຖາປັດຕະຍະກໍາຂອງ Data lakehouse ໄດ້ແບ່ງອອກເປັນສອງຊັ້ນຕົ້ນຕໍໃນລະດັບສູງ. ການຮັບຂໍ້ມູນຂອງຊັ້ນເກັບຮັກສາແມ່ນຖືກຄວບຄຸມໂດຍເວທີ Lakehouse (ເຊັ່ນ: ທະເລສາບຂໍ້ມູນ).
ໂດຍບໍ່ຈໍາເປັນຕ້ອງໂຫລດຂໍ້ມູນເຂົ້າໄປໃນຄັງຂໍ້ມູນຫຼືປ່ຽນເປັນຮູບແບບທີ່ເປັນເຈົ້າຂອງ, ຊັ້ນການປຸງແຕ່ງສາມາດສອບຖາມຂໍ້ມູນໃນຊັ້ນເກັບຮັກສາໄດ້ໂດຍກົງໂດຍໃຊ້ເຄື່ອງມືຕ່າງໆ.
ຈາກນັ້ນ, ແອັບ BI, ເຊັ່ນດຽວກັນກັບເຕັກໂນໂລຊີ AI ແລະ ML, ສາມາດໃຊ້ຂໍ້ມູນໄດ້. ເສດຖະສາດຂອງ Data lake ແມ່ນສະຫນອງໃຫ້ໂດຍການອອກແບບນີ້, ແຕ່ເນື່ອງຈາກວ່າເຄື່ອງຈັກປະມວນຜົນໃດໆສາມາດອ່ານຂໍ້ມູນນີ້, ທຸລະກິດມີສິດເສລີພາບໃນການເຮັດໃຫ້ຂໍ້ມູນກະກຽມສາມາດເຂົ້າເຖິງການວິເຄາະໂດຍລະບົບຕ່າງໆ. ປະສິດທິພາບຂອງໂປເຊດເຊີແລະຄ່າໃຊ້ຈ່າຍທັງສອງສາມາດໄດ້ຮັບການປັບປຸງໂດຍການນໍາໃຊ້ວິທີການນີ້ສໍາລັບການປຸງແຕ່ງແລະການວິເຄາະ.
ເນື່ອງຈາກການສະຫນັບສະຫນູນການເຮັດທຸລະກໍາຂອງຖານຂໍ້ມູນທີ່ປະຕິບັດຕາມເງື່ອນໄຂ ACID (ປະລໍາມະນູ, ຄວາມສອດຄ່ອງ, ການໂດດດ່ຽວ, ແລະຄວາມທົນທານ), ສະຖາປັດຕະຍະກໍາຍັງຊ່ວຍໃຫ້ຫຼາຍພາກສ່ວນສາມາດເຂົ້າເຖິງແລະຂຽນຂໍ້ມູນພ້ອມກັນພາຍໃນລະບົບ:
- ປະຕິມາທິ ຫມາຍເຖິງຄວາມຈິງທີ່ວ່າທຸລະກໍາເຕັມຫຼືບໍ່ມີມັນ, ປະສົບຜົນສໍາເລັດໃນຂະນະທີ່ເຮັດທຸລະກໍາ. ໃນກໍລະນີທີ່ຂະບວນການຂັດຂວາງ, ນີ້ຈະຊ່ວຍຫຼີກເວັ້ນການສູນເສຍຂໍ້ມູນຫຼືຄວາມເສຍຫາຍ.
- ຄວາມສອດຄ່ອງ ຮັບປະກັນການເຮັດທຸລະກໍາເກີດຂຶ້ນໃນລັກສະນະທີ່ຄາດເດົາໄດ້, ສອດຄ່ອງ. ມັນຮັກສາຄວາມສົມບູນຂອງຂໍ້ມູນໂດຍການຮັບປະກັນວ່າທຸກໆຂໍ້ມູນແມ່ນຖືກຕ້ອງຕາມກົດລະບຽບທີ່ກໍານົດໄວ້ກ່ອນ.
- Isolation ຮັບປະກັນວ່າ, ຈົນກ່ວາມັນສໍາເລັດ, ບໍ່ມີທຸລະກໍາສາມາດໄດ້ຮັບຜົນກະທົບຈາກການເຮັດທຸລະກໍາອື່ນໆພາຍໃນລະບົບ. ນີ້ອະນຸຍາດໃຫ້ຫຼາຍພາກສ່ວນສາມາດອ່ານແລະຂຽນຈາກລະບົບດຽວກັນພ້ອມໆກັນໂດຍບໍ່ມີການແຊກແຊງເຊິ່ງກັນແລະກັນ.
- ຄວາມທົນທານ ຮັບປະກັນວ່າການປ່ຽນແປງຂອງຂໍ້ມູນໃນລະບົບຍັງສືບຕໍ່ມີຢູ່ຫຼັງຈາກການເຮັດທຸລະກໍາສໍາເລັດ, ເຖິງແມ່ນວ່າໃນກໍລະນີລະບົບລົ້ມເຫລວ. ການປ່ຽນແປງໃດໆທີ່ເກີດຂຶ້ນມາໂດຍການເຮັດທຸລະກໍາແມ່ນໄດ້ຮັບການເກັບຮັກສາໄວ້ຕະຫຼອດໄປ.
Data Lakehouse ສະຖາປັດຕະຍະກໍາ
Databricks (ຜູ້ປະດິດສ້າງແລະຜູ້ອອກແບບແນວຄວາມຄິດ Delta Lake ຂອງພວກເຂົາ) ແລະ AWS ແມ່ນສອງຜູ້ສະຫນັບສະຫນູນຕົ້ນຕໍສໍາລັບແນວຄວາມຄິດຂອງ Data lakehouse. ດັ່ງນັ້ນພວກເຮົາຈະອີງໃສ່ຄວາມຮູ້ແລະຄວາມເຂົ້າໃຈຂອງພວກເຂົາເພື່ອອະທິບາຍຮູບແບບສະຖາປັດຕະຍະກໍາຂອງ lakehouses.
ລະບົບ lakehouse ຂໍ້ມູນປົກກະຕິຈະມີຫ້າຊັ້ນ:
- ຊັ້ນການກິນ
- ຊັ້ນເກັບຮັກສາ
- ຊັ້ນຂໍ້ມູນເມຕາ
- ຊັ້ນ API
- ຊັ້ນການບໍລິໂພກ
ຊັ້ນການກິນ
ຊັ້ນທໍາອິດຂອງລະບົບແມ່ນຮັບຜິດຊອບໃນການເກັບກໍາຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆແລະສົ່ງມັນໄປຫາຊັ້ນເກັບຮັກສາ. ຊັ້ນຂໍ້ມູນສາມາດນໍາໃຊ້ຫຼາຍໂປໂຕຄອນເພື່ອເຊື່ອມຕໍ່ກັບແຫຼ່ງພາຍໃນແລະພາຍນອກຈໍານວນຫລາຍ, ລວມທັງການລວມເອົາຄວາມສາມາດໃນການປຸງແຕ່ງຂໍ້ມູນ batch ແລະ streaming, ເຊັ່ນ:
- ຖານຂໍ້ມູນ NoSQL,
- ການແບ່ງປັນໄຟລ໌
- ຄໍາຮ້ອງສະຫມັກ CRM,
- ເວບໄຊທ໌,
- ເຊັນເຊີ IoT,
- ສື່ມວນຊົນສັງຄົມ,
- ຊອບແວເປັນບໍລິການ (SaaS) ຄໍາຮ້ອງສະຫມັກ, ແລະ
- ລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ, ແລະອື່ນໆ.
ໃນຈຸດນີ້, ອົງປະກອບເຊັ່ນ Apache Kafka ສໍາລັບການຖ່າຍທອດຂໍ້ມູນແລະ Amazon Data Migration Service (Amazon DMS) ສໍາລັບການນໍາເຂົ້າຂໍ້ມູນຈາກຖານຂໍ້ມູນ RDBMSs ແລະ NoSQL ສາມາດຖືກນໍາໃຊ້.
ຊັ້ນເກັບຮັກສາ
ສະຖາປັດຕະຍະກໍາ lakehouse ແມ່ນຫມາຍຄວາມວ່າເພື່ອໃຫ້ສາມາດເກັບຮັກສາຂໍ້ມູນປະເພດຕ່າງໆເປັນວັດຖຸໃນຮ້ານຂາຍວັດຖຸທີ່ມີລາຄາຖືກ, ເຊັ່ນ AWS S3. ການນໍາໃຊ້ຮູບແບບໄຟລ໌ເປີດ, ຫຼັງຈາກນັ້ນເຄື່ອງມືລູກຄ້າສາມາດອ່ານລາຍການເຫຼົ່ານີ້ໂດຍກົງຈາກຮ້ານ.
ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ສໍາລັບ APIs ຫຼາຍແລະອົງປະກອບຊັ້ນການບໍລິໂພກໃນການເຂົ້າເຖິງແລະນໍາໃຊ້ຂໍ້ມູນດຽວກັນ. ຊັ້ນ metadata ເກັບຮັກສາ schemas ສໍາລັບຊຸດຂໍ້ມູນທີ່ມີໂຄງສ້າງແລະເຄິ່ງໂຄງສ້າງເພື່ອໃຫ້ອົງປະກອບສາມາດນໍາໃຊ້ພວກມັນກັບຂໍ້ມູນໃນຂະນະທີ່ພວກເຂົາອ່ານມັນ.
ສໍາລັບຕົວຢ່າງ, ແພລະຕະຟອມ Hadoop Distributed File System (HDFS) ສາມາດຖືກນໍາໃຊ້ເພື່ອສ້າງການບໍລິການເກັບຮັກສາຟັງທີ່ແບ່ງປັນຄອມພິວເຕີ້ແລະການເກັບຮັກສາຢູ່ໃນສະຖານທີ່. Lakehouse ແມ່ນ ເໝາະ ສົມທີ່ສຸດ ສຳ ລັບການບໍລິການເຫຼົ່ານີ້.
ຊັ້ນຂໍ້ມູນເມຕາ
ຊັ້ນຂໍ້ມູນ metadata ແມ່ນອົງປະກອບພື້ນຖານຂອງ lakehouse ຂໍ້ມູນທີ່ຈໍາແນກການອອກແບບນີ້. ມັນເປັນລາຍການດຽວທີ່ສະເຫນີ metadata (ຂໍ້ມູນກ່ຽວກັບຊິ້ນຂໍ້ມູນອື່ນໆ) ສໍາລັບລາຍການທັງຫມົດທີ່ເກັບໄວ້ໃນທະເລສາບແລະອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດຈ້າງຄວາມສາມາດໃນການບໍລິຫານເຊັ່ນ:
- ສະບັບທີ່ສອດຄ່ອງຂອງຖານຂໍ້ມູນແມ່ນເຫັນໄດ້ໂດຍການເຮັດທຸລະກໍາພ້ອມໆກັນຍ້ອນການເຮັດທຸລະກໍາ ACID;
- caching ເພື່ອບັນທຶກໄຟລ໌ເກັບຮັກສາວັດຖຸຟັງ;
- ເພີ່ມດັດສະນີໂຄງສ້າງຂໍ້ມູນໂດຍໃຊ້ indexing ເພື່ອເລັ່ງການປະມວນຜົນແບບສອບຖາມ;
- ການນໍາໃຊ້ສູນສໍາເນົາ cloning ເພື່ອຊ້ໍາວັດຖຸຂໍ້ມູນ; ແລະ
- ເພື່ອເກັບຮັກສາຂໍ້ມູນບາງຮຸ່ນ, ແລະອື່ນໆ, ໃຫ້ໃຊ້ການດັດແກ້ຂໍ້ມູນ.
ນອກຈາກນັ້ນ, ຊັ້ນຂໍ້ມູນ metadata ຊ່ວຍໃຫ້ການປະຕິບັດການຈັດການ schema, ການນໍາໃຊ້ DW schema topologies ເຊັ່ນ star/snowflake schemas, ແລະການສະຫນອງການຄຸ້ມຄອງຂໍ້ມູນແລະຄວາມສາມາດໃນການກວດສອບໂດຍກົງໃນຂໍ້ມູນ, ປັບປຸງຄວາມສົມບູນຂອງທໍ່ຂໍ້ມູນທັງຫມົດ.
ຄຸນສົມບັດສໍາລັບການວິວັດທະນາການ schema ແລະການບັງຄັບໃຊ້ແມ່ນລວມຢູ່ໃນການຄຸ້ມຄອງ schema. ໂດຍການປະຕິເສດການຂຽນໃດໆທີ່ບໍ່ກົງກັບ schema ຂອງຕາຕະລາງ, ການບັງຄັບໃຊ້ schema ຊ່ວຍໃຫ້ຜູ້ໃຊ້ສາມາດຮັກສາຄວາມສົມບູນຂອງຂໍ້ມູນແລະຄຸນນະພາບ.
Schema evolution ອະນຸຍາດໃຫ້ schema ປະຈຸບັນຂອງຕາຕະລາງຖືກດັດແປງເພື່ອຮອງຮັບຂໍ້ມູນການປ່ຽນແປງ. ເນື່ອງຈາກການໂຕ້ຕອບການບໍລິຫານດຽວຢູ່ເທິງຂອງຂໍ້ມູນທະເລສາບ, ຍັງມີຄວາມສາມາດໃນການຄວບຄຸມແລະການກວດສອບ.
ຊັ້ນ API
ຊັ້ນທີ່ສໍາຄັນອີກປະການຫນຶ່ງຂອງສະຖາປັດຕະປະຈຸບັນ, ເຈົ້າພາບ APIs ຈໍານວນຫນຶ່ງທີ່ຜູ້ໃຊ້ສຸດທ້າຍທັງຫມົດສາມາດນໍາໃຊ້ເພື່ອປະຕິບັດວຽກໄວຂຶ້ນແລະໄດ້ຮັບສະຖິຕິທີ່ຊັບຊ້ອນຫຼາຍ.
ການນໍາໃຊ້ metadata APIs ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການລະບຸແລະເຂົ້າເຖິງລາຍການຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ໃຫ້.
ໃນແງ່ຂອງຫ້ອງສະຫມຸດການຮຽນຮູ້ເຄື່ອງຈັກ, ບາງສ່ວນຂອງພວກເຂົາເຊັ່ນ TensorFlow ແລະ Spark MLlib, ສາມາດອ່ານຮູບແບບໄຟລ໌ເປີດເຊັ່ນ Parquet ແລະເຂົ້າເຖິງຊັ້ນ metadata ໂດຍກົງ.
ໃນເວລາດຽວກັນ, DataFrame APIs ສະເຫນີໂອກາດຫຼາຍກວ່າເກົ່າສໍາລັບການເພີ່ມປະສິດທິພາບ, ເຮັດໃຫ້ນັກຂຽນໂປລແກລມສາມາດຈັດລະບຽບແລະປ່ຽນແປງຂໍ້ມູນທີ່ກະແຈກກະຈາຍ.
ຊັ້ນການບໍລິໂພກ
Power BI, Tableau, ແລະເຄື່ອງມື ແລະແອັບອື່ນໆຖືກໂຮດພາຍໃຕ້ຊັ້ນການບໍລິໂພກ. ດ້ວຍການອອກແບບ lakehouse, metadata ທັງຫມົດແລະຂໍ້ມູນທັງຫມົດທີ່ເກັບໄວ້ໃນທະເລສາບແມ່ນສາມາດເຂົ້າເຖິງແອັບຯລູກຄ້າໄດ້.
lakehouse ສາມາດຖືກນໍາໃຊ້ໂດຍຜູ້ໃຊ້ທັງຫມົດພາຍໃນບໍລິສັດເພື່ອປະຕິບັດທຸກປະເພດ ການດໍາເນີນງານການວິເຄາະ, ລວມທັງການສ້າງ dashboards ທາງທຸລະກິດແລະການດໍາເນີນການສອບຖາມ SQL ແລະວຽກງານການຮຽນຮູ້ເຄື່ອງຈັກ.
ຂໍ້ໄດ້ປຽບຂອງ Data Lakehouse
ອົງການຈັດຕັ້ງສາມາດສ້າງ lakehouse ຂໍ້ມູນເພື່ອປະສົມປະສານແພລະຕະຟອມຂໍ້ມູນໃນປະຈຸບັນຂອງພວກເຂົາແລະເພີ່ມປະສິດທິພາບຂະບວນການຈັດການຂໍ້ມູນທັງຫມົດຂອງພວກເຂົາ. ໂດຍ dismantling ສິ່ງກີດຂວາງ silo ເຊື່ອມຕໍ່ແຫຼ່ງຕ່າງໆ, lakehouse ຂໍ້ມູນສາມາດທົດແທນຄວາມຕ້ອງການສໍາລັບການແກ້ໄຂບັນຫາທີ່ແຕກຕ່າງກັນ.
ເມື່ອປຽບທຽບກັບແຫຼ່ງຂໍ້ມູນທີ່ຄັດສັນມາ, ການປະສົມປະສານນີ້ຜະລິດຂັ້ນຕອນການສິ້ນສຸດທີ່ມີປະສິດທິຜົນຫຼາຍຂຶ້ນ. ນີ້ມີຄວາມໄດ້ປຽບຫຼາຍ:
- ບໍລິຫານໜ້ອຍລົງ: ແທນທີ່ຈະສະກັດຂໍ້ມູນຈາກຂໍ້ມູນວັດຖຸດິບແລະການກະກຽມມັນສໍາລັບການນໍາໃຊ້ພາຍໃນຄັງຂໍ້ມູນ, lakehouse ຂໍ້ມູນອະນຸຍາດໃຫ້ແຫຼ່ງຂໍ້ມູນໃດໆທີ່ເຊື່ອມຕໍ່ກັບມັນເພື່ອໃຫ້ຂໍ້ມູນຂອງເຂົາເຈົ້າມີແລະຈັດລະບຽບສໍາລັບການນໍາໃຊ້.
- ການເພີ່ມປະສິດທິພາບຄ່າໃຊ້ຈ່າຍເພີ່ມຂຶ້ນ: Data lakehouses ຖືກສ້າງຂຶ້ນໂດຍໃຊ້ໂຄງສ້າງພື້ນຖານໃນຍຸກປະຈຸບັນທີ່ແບ່ງການຄິດໄລ່ແລະການເກັບຮັກສາ, ເຮັດໃຫ້ມັນງ່າຍດາຍທີ່ຈະຂະຫຍາຍການເກັບຮັກສາໂດຍບໍ່ມີການເພີ່ມພະລັງງານຄອມພິວເຕີ. ພຽງແຕ່ການນໍາໃຊ້ການເກັບຮັກສາຂໍ້ມູນລາຄາຖືກສົ່ງຜົນໃຫ້ສາມາດຂະຫຍາຍໄດ້ທີ່ປະຫຍັດຄ່າໃຊ້ຈ່າຍ.
- ການຄຸ້ມຄອງຂໍ້ມູນທີ່ດີກວ່າ: Data lakehouses ກໍ່ສ້າງດ້ວຍສະຖາປັດຕະຍະກໍາເປີດມາດຕະຖານ, ອະນຸຍາດໃຫ້ຄວບຄຸມຄວາມປອດໄພ, metrics, ການເຂົ້າເຖິງໂດຍອີງໃສ່ພາລະບົດບາດ, ແລະອົງປະກອບການຄຸ້ມຄອງທີ່ສໍາຄັນອື່ນໆ. ໂດຍການເຊື່ອມໂຍງຊັບພະຍາກອນແລະແຫຼ່ງຂໍ້ມູນ, ພວກມັນເຮັດໃຫ້ງ່າຍດາຍແລະປັບປຸງການປົກຄອງ.
- ມາດຕະຖານທີ່ງ່າຍດາຍ: ເນື່ອງຈາກການເຊື່ອມຕໍ່ໄດ້ຖືກຈໍາກັດສູງໃນຊຸມປີ 1980, ໃນເວລາທີ່ສາງຂໍ້ມູນໄດ້ຖືກພັດທະນາຄັ້ງທໍາອິດ, ມາດຕະຖານ schema ທ້ອງຖິ່ນໄດ້ຖືກພັດທະນາເລື້ອຍໆພາຍໃນທຸລະກິດ, ເຖິງແມ່ນວ່າພະແນກຕ່າງໆ. Data lakehouses ນໍາໃຊ້ຄວາມຈິງທີ່ວ່າຂໍ້ມູນຫຼາຍປະເພດໃນປັດຈຸບັນມີມາດຕະຖານເປີດສໍາລັບ schema ໂດຍການກິນແຫຼ່ງຂໍ້ມູນຈໍານວນຫລາຍດ້ວຍ schema ເອກະພາບທີ່ທັບຊ້ອນກັນເພື່ອປັບປຸງຂັ້ນຕອນ.
ຂໍ້ເສຍຂອງ Data Lakehouse
ເຖິງວ່າຈະມີທັງຫມົດ hoopla ທີ່ຢູ່ອ້ອມຮອບ lakehouses ຂໍ້ມູນ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮັກສາຢູ່ໃນໃຈວ່າແນວຄວາມຄິດຍັງໃຫມ່ຫຼາຍ. ໃຫ້ແນ່ໃຈວ່າຈະຊັ່ງນໍ້າຫນັກຂໍ້ເສຍກ່ອນທີ່ຈະປະຕິບັດຢ່າງເຕັມສ່ວນກັບການອອກແບບໃຫມ່ນີ້.
- ໂຄງສ້າງ monolithic: ການອອກແບບລວມທັງໝົດຂອງ lakehouse ສະເຫນີຂໍ້ໄດ້ປຽບຫຼາຍຢ່າງ, ແຕ່ມັນກໍ່ເຮັດໃຫ້ເກີດບັນຫາບາງຢ່າງ. ສະຖາປັດຕະຍະກໍາ Monolithic ມັກຈະເຮັດໃຫ້ການບໍລິການທີ່ບໍ່ດີສໍາລັບຜູ້ໃຊ້ທັງຫມົດແລະສາມາດມີຄວາມເຄັ່ງຄັດແລະຍາກທີ່ຈະຮັກສາ. ໂດຍປົກກະຕິ, ສະຖາປະນິກແລະນັກອອກແບບມັກສະຖາປັດຕະຍະກໍາແບບໂມດູນທີ່ພວກເຂົາສາມາດປັບແຕ່ງສໍາລັບກໍລະນີການນໍາໃຊ້ຕ່າງໆ.
- ເທັກໂນໂລຍີຍັງບໍ່ທັນມີເທື່ອ: ເປົ້າໝາຍສຸດທ້າຍປະກອບມີການຮຽນຮູ້ເຄື່ອງຈັກ ແລະປັນຍາປະດິດຈຳນວນຫຼວງຫຼາຍ. ກ່ອນທີ່ lakehouses ສາມາດປະຕິບັດໄດ້ຕາມທີ່ຄາດໄວ້, ເຕັກໂນໂລຢີເຫຼົ່ານີ້ຕ້ອງພັດທະນາຕື່ມອີກ.
- ບໍ່ແມ່ນຄວາມກ້າວຫນ້າທີ່ສໍາຄັນຕໍ່ໂຄງສ້າງທີ່ມີຢູ່: ຍັງມີຄວາມສົງໄສຫຼາຍກ່ຽວກັບວ່າເຮືອນ lakehouses ຈະມີຄຸນຄ່າຫຼາຍກວ່າເທົ່າໃດ. ຜູ້ຂັດຂວາງບາງຄົນຂັດແຍ້ງວ່າການອອກແບບສາງທະເລສາບທີ່ຈັບຄູ່ກັບອຸປະກອນອັດຕະໂນມັດທີ່ເຫມາະສົມສາມາດບັນລຸປະສິດທິພາບທີ່ສົມທຽບໄດ້.
ສິ່ງທ້າທາຍຂອງ Data Lakehouse
ມັນອາດຈະເປັນການຍາກທີ່ຈະຮັບຮອງເອົາເຕັກນິກການ lakehouse ຂໍ້ມູນ. ເນື່ອງຈາກຄວາມຊັບຊ້ອນຂອງສ່ວນປະກອບຂອງມັນ, ມັນບໍ່ຖືກຕ້ອງທີ່ຈະເບິ່ງຫ້ອງນ້ໍາຂໍ້ມູນເປັນໂຄງສ້າງທີ່ເຫມາະສົມທີ່ສົມບູນແບບຫຼື "ເວທີດຽວສໍາລັບທຸກສິ່ງທຸກຢ່າງ," ສໍາລັບຫນຶ່ງ.
ນອກຈາກນັ້ນ, ເນື່ອງຈາກການເພີ່ມຂຶ້ນຂອງການຮັບຮອງເອົາຂໍ້ມູນທະເລສາບ, ທຸລະກິດຈະຕ້ອງຍ້າຍຄັງຂໍ້ມູນໃນປະຈຸບັນຂອງພວກເຂົາໄປຫາພວກເຂົາ, ອີງໃສ່ພຽງແຕ່ຄໍາສັນຍາຂອງຄວາມສໍາເລັດທີ່ບໍ່ມີຜົນປະໂຫຍດທາງດ້ານເສດຖະກິດທີ່ສະແດງໃຫ້ເຫັນ.
ຖ້າມີບັນຫາການຊັກຊ້າ ຫຼືການຢຸດເຮັດວຽກຕະຫຼອດຂະບວນການໂອນຍ້າຍ, ນີ້ອາດຈະເຮັດໃຫ້ລາຄາແພງ, ໃຊ້ເວລາຫຼາຍ, ແລະບາງທີອາດບໍ່ປອດໄພ.
ຜູ້ໃຊ້ທຸລະກິດຕ້ອງຍອມຮັບເອົາເຕັກໂນໂລຢີທີ່ມີຄວາມຊໍານິຊໍານານສູງ, ອີງຕາມຜູ້ຂາຍສະເພາະໃດຫນຶ່ງທີ່ສະແດງການແກ້ໄຂຕະຫຼາດຢ່າງຈະແຈ້ງຫຼື implicitly ເປັນ lakehouses ຂໍ້ມູນ. ເຫຼົ່ານີ້ອາດຈະບໍ່ສະເຫມີເຮັດວຽກກັບເຄື່ອງມືອື່ນໆທີ່ເຊື່ອມຕໍ່ກັບ lake ຂໍ້ມູນຢູ່ໃນສູນກາງຂອງລະບົບ, ເພີ່ມບັນຫາ.
ນອກຈາກນັ້ນ, ມັນອາດຈະເປັນການຍາກທີ່ຈະສະຫນອງການວິເຄາະ 24/7 ໃນຂະນະທີ່ດໍາເນີນວຽກງານທີ່ສໍາຄັນຂອງທຸລະກິດ, ເຊິ່ງຮຽກຮ້ອງໃຫ້ມີໂຄງສ້າງພື້ນຖານທີ່ມີຄ່າໃຊ້ຈ່າຍທີ່ມີປະສິດທິພາບ.
ສະຫຼຸບ
ສູນຂໍ້ມູນຊະນິດໃໝ່ທີ່ສຸດໃນຊຸມປີທີ່ຜ່ານມາແມ່ນສູນຂໍ້ມູນ. ມັນປະສົມປະສານຫຼາຍຂົງເຂດ, ເຊັ່ນ: ເຕັກໂນໂລຊີຂໍ້ມູນຂ່າວສານ, ຊອບແວ open-source, ຄອມພິວເຕີ້ຟັງ, ແລະໂປໂຕຄອນການເກັບຮັກສາທີ່ແຈກຢາຍ.
ມັນຊ່ວຍໃຫ້ທຸລະກິດສາມາດເກັບຂໍ້ມູນທຸກປະເພດຈາກສະຖານທີ່ໃດກໍ່ຕາມ, ເຮັດໃຫ້ການຄຸ້ມຄອງແລະການວິເຄາະງ່າຍຂຶ້ນ. Data Lakehouse ແມ່ນແນວຄວາມຄິດທີ່ ໜ້າ ສົນໃຈຫຼາຍ.
ບໍລິສັດໃດກໍ່ຕາມຈະມີການແຂ່ງຂັນຢ່າງຫຼວງຫຼາຍຖ້າມັນມີການເຂົ້າເຖິງແພລະຕະຟອມຂໍ້ມູນທັງຫມົດໃນຫນຶ່ງທີ່ໄວແລະມີປະສິດທິພາບເທົ່າກັບຄັງຂໍ້ມູນໃນຂະນະທີ່ຍັງມີຄວາມຍືດຫຍຸ່ນເທົ່າກັບການເກັບຂໍ້ມູນ.
ແນວຄວາມຄິດຍັງພັດທະນາແລະຍັງຂ້ອນຂ້າງໃຫມ່. ດັ່ງນັ້ນ, ມັນອາດຈະໃຊ້ເວລາບາງເວລາເພື່ອກໍານົດວ່າບາງສິ່ງບາງຢ່າງສາມາດແຜ່ລາມໄດ້ຫຼືບໍ່.
ພວກເຮົາທຸກຄົນຄວນຈະຢາກຮູ້ຢາກເຫັນກ່ຽວກັບທິດທາງທີ່ສະຖາປັດຕະຍະກໍາ Lakehouse ກໍາລັງມຸ່ງຫນ້າໄປ.
ອອກຈາກ Reply ເປັນ