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

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

ประเด็นสำคัญ

• EDW สมัยใหม่รองรับงานด้านระบบธุรกิจอัจฉริยะ การรายงานทางการเงิน และเวิร์กโหลดด้านแมชชีนเลิร์นนิง จากแหล่งเก็บข้อมูลแบบรวมศูนย์เพียงแห่งเดียวที่มีการกำกับดูแล และเป็นข้อมูลเชิงโครงสร้างที่พร้อมสำหรับการวิเคราะห์

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

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

คลังข้อมูลระดับองค์กรคืออะไร

คลังข้อมูลระดับองค์กร (EDW) คือแหล่งเก็บข้อมูลรวมศูนย์ที่สนับสนุนระบบธุรกิจอัจฉริยะ การรายงานทางการเงิน และที่สำคัญยิ่งขึ้นคือ คลังข้อมูลฟีเจอร์และชุดข้อมูลฝึกฝนสำหรับแมชชีนเลิร์นนิง

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

คลังข้อมูลระดับองค์กรทำงานอย่างไร

ในภาพรวม EDW จะรวบรวมข้อมูลจากทั่วทั้งธุรกิจ ทำข้อมูลให้เป็นมาตรฐาน และทำให้สามารถนำไปใช้งานได้ การดำเนินการดังกล่าวมักจะแบ่งออกเป็นสามขั้นตอน

วิธีการทำงานของคลังข้อมูลระดับองค์กรมีดังนี้

นำเข้า

ข้อมูลจะส่งจากระบบต้นทาง เช่น แพลตฟอร์มการชำระเงิน, ระบบบริหารความสัมพันธ์ลูกค้า (CRM), ระบบวางแผนทรัพยากรองค์กร (ERP) และฐานข้อมูลผลิตภัณฑ์ เข้ามายังชั้นข้อมูลเดียว ณ จุดนี้ ข้อมูลยังคงเป็นข้อมูลดิบอยู่: สคีมาอาจแตกต่างกัน เวลาบันทึกอาจขัดแย้งกัน และค่าที่ขาดหายไปอาจไม่สอดคล้องกัน

โมเดล

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

แนวทางการสร้างโมเดลที่พบบ่อย 2 รูปแบบมีดังนี้

• สคีมาแบบ Star: ตารางข้อเท็จจริงส่วนกลาง (เช่น ตารางคำสั่งซื้อ) ที่เชื่อมต่อกับตารางมิติ (ลูกค้า ผลิตภัณฑ์ วันที่) สคีมานี้เรียบง่าย ส่งคำขอรวดเร็ว และใช้อย่างแพร่หลายสำหรับการรายงาน

• สคีมาแบบ Snowflake: เวอร์ชันของสคีมาแบบ Star เวอร์ชันที่ปรับให้เป็นมาตรฐานมากขึ้น โดยจะมีการแบ่งมิติข้อมูลออกเป็นตารางที่เกี่ยวข้องขนาดเล็กลง ซึ่งช่วยลดความซ้ำซ้อน แต่อาจทำให้การส่งคำขอทำได้ยากขึ้น

ให้บริการ

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

คลังข้อมูลระดับองค์กรสมัยใหม่ทำงานบนสถาปัตยกรรมแบบใด

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

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

EDW ที่ได้รับการออกแบบมาอย่างดียังมีคุณสมบัติร่วมกันบางประการดังนี้

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

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

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

สิ่งใดที่ทำให้คลังข้อมูลระดับองค์กรมีความน่าเชื่อถือ

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

วิธีที่การกำกับดูแลและการควบคุมความปลอดภัยทำให้คลังข้อมูลระดับองค์กรพร้อมใช้งานสำหรับองค์กรมีดังนี้

• การควบคุมการเข้าถึงตามบทบาท (RBAC): สิทธิ์การเข้าถึงจะกำหนดตามบทบาท ซึ่งช่วยให้ผู้ใช้งานเห็นเฉพาะข้อมูลที่จำเป็นสำหรับตนเองเท่านั้น

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

• การบันทึกตรวจสอบ: ทุกการสืบค้นข้อมูลสามารถติดตามได้ ซึ่งมีความสำคัญต่อการปฏิบัติตามข้อกำหนด (เช่น Service Organization Control 2 หรือ PCI DSS ขึ้นอยู่กับประเภทข้อมูลของคุณ) เมื่อมีการโต้แย้งเกี่ยวกับตัวชี้วัด บันทึกตรวจสอบจะช่วยให้คุณสามารถติดตามได้อย่างแม่นยำว่ารายงานนั้นสร้างขึ้นจากเวอร์ชันใดของข้อมูล

• ลำดับชั้นข้อมูล: ข้อกำหนดสามารถติดตามตัวชี้วัดใดๆ กลับไปยังแหล่งที่มาได้ ซึ่งช่วยให้การแก้ไขข้อบกพร่องมีประสิทธิภาพมากขึ้น

• การกำหนดนิยามตัวชี้วัดให้สอดคล้องกัน: ชั้นความหมายที่ใช้ร่วมกันจะช่วยป้องกันไม่ให้ทีมต่างๆ คำนวณตัวชี้วัดเดียวกันด้วยวิธีที่แตกต่างกัน

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

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

สิ่งที่ควรให้ความสำคัญมีดังนี้

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

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

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

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

• ให้ความสำคัญกับจุดเริ่มต้นที่ส่งผลกระทบสูง: ระบุเวิร์กโฟลว์การรายงานที่มีมูลค่าทางธุรกิจสูงสุดและมีข้อมูลต้นทางที่สะอาดที่สุด รวมถึงสร้างเวิร์กโฟลว์เหล่านั้นก่อน

การเคลื่อนย้ายข้อมูลส่งผลดีหรือผลเสียต่อคลังข้อมูลระดับองค์กรอย่างไร

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

จุดที่มักเกิดความล้มเหลวได้แก่:

• การเปลี่ยนแปลง API ที่ทำให้การผสานการทำงานเสียหายโดยไม่ทันตั้งตัว

• ข้อมูลประจำตัวที่หมดอายุและการอัปเดตการตรวจสอบสิทธิ์

• ขีดจำกัดอัตราที่ไม่คาดคิดในช่วงที่มีการใช้งานสูงสุด

• ไปป์ไลน์ที่ล้มเหลวโดยไม่มีการแจ้งเตือนผู้เกี่ยวข้อง

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

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

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

วิธีการมีดังนี้

• ปลายทางที่รองรับ: Snowflake, Amazon Redshift, Databricks และอื่นๆ อีกมากมาย

• สถานะความพร้อมด้านความปลอดภัย: Stripe Data Pipeline ไม่จำเป็นต้องใช้บริการ ETL จากบุคคลที่สาม ซึ่งช่วยลดความเสี่ยงต่อข้อมูลที่รวมถึงธุรกรรมทางการเงินและข้อมูลลูกค้า

• ภาระในการบำรุงรักษา: ไม่มีตัวเชื่อมต่อแบบกำหนดเองให้ต้องสร้างหรือบำรุงรักษา เมื่อ API ของ Stripe เปลี่ยนแปลง ไปป์ไลน์จะปรับเปลี่ยนในฝั่ง Stripe ไม่ใช่ฝั่งของคุณ