คลังข้อมูล - สถาปัตยกรรม
ในบทนี้เราจะพูดถึงกรอบการวิเคราะห์ธุรกิจสำหรับการออกแบบคลังข้อมูลและสถาปัตยกรรมของคลังข้อมูล
กรอบการวิเคราะห์ธุรกิจ
นักวิเคราะห์ธุรกิจได้รับข้อมูลจากคลังข้อมูลเพื่อวัดประสิทธิภาพและทำการปรับเปลี่ยนที่สำคัญเพื่อให้ได้รับชัยชนะเหนือผู้ถือธุรกิจรายอื่นในตลาด การมีคลังข้อมูลมีข้อดีดังต่อไปนี้ -
เนื่องจากคลังข้อมูลสามารถรวบรวมข้อมูลได้อย่างรวดเร็วและมีประสิทธิภาพจึงสามารถเพิ่มประสิทธิผลทางธุรกิจได้
คลังข้อมูลช่วยให้เรามีมุมมองที่สอดคล้องกันของลูกค้าและสินค้าดังนั้นจึงช่วยให้เราจัดการความสัมพันธ์กับลูกค้าได้
คลังข้อมูลยังช่วยลดค่าใช้จ่ายโดยการติดตามแนวโน้มรูปแบบในระยะเวลาอันยาวนานอย่างสม่ำเสมอและเชื่อถือได้
ในการออกแบบคลังข้อมูลที่มีประสิทธิผลและประสิทธิผลเราจำเป็นต้องเข้าใจและวิเคราะห์ความต้องการทางธุรกิจและสร้างก business analysis framework. แต่ละคนมีมุมมองที่แตกต่างกันเกี่ยวกับการออกแบบคลังข้อมูล มุมมองเหล่านี้มีดังนี้ -
The top-down view - มุมมองนี้ช่วยให้สามารถเลือกข้อมูลที่เกี่ยวข้องที่จำเป็นสำหรับคลังข้อมูลได้
The data source view - มุมมองนี้นำเสนอข้อมูลที่ถูกบันทึกจัดเก็บและจัดการโดยระบบปฏิบัติการ
The data warehouse view- มุมมองนี้รวมถึงตารางข้อเท็จจริงและตารางมิติข้อมูล แสดงถึงข้อมูลที่จัดเก็บภายในคลังข้อมูล
The business query view - เป็นการดูข้อมูลจากมุมมองของผู้ใช้ปลายทาง
สถาปัตยกรรมคลังข้อมูลสามชั้น
โดยทั่วไปคลังข้อมูลจะใช้สถาปัตยกรรมสามชั้น ต่อไปนี้เป็นสามระดับของสถาปัตยกรรมคลังข้อมูล
Bottom Tier- ชั้นล่างสุดของสถาปัตยกรรมคือเซิร์ฟเวอร์ฐานข้อมูลคลังข้อมูล เป็นระบบฐานข้อมูลเชิงสัมพันธ์ เราใช้เครื่องมือส่วนหลังและยูทิลิตี้เพื่อป้อนข้อมูลไปยังชั้นล่างสุด เครื่องมือและยูทิลิตี้แบ็คเอนด์เหล่านี้ทำหน้าที่แยก, ล้าง, โหลดและรีเฟรช
Middle Tier - ในระดับกลางเรามี OLAP Server ที่สามารถใช้งานได้ด้วยวิธีใดวิธีหนึ่งดังต่อไปนี้
โดย Relational OLAP (ROLAP) ซึ่งเป็นระบบการจัดการฐานข้อมูลเชิงสัมพันธ์แบบขยาย ROLAP แมปการดำเนินการกับข้อมูลหลายมิติกับการดำเนินการเชิงสัมพันธ์มาตรฐาน
โดยแบบจำลอง OLAP (MOLAP) หลายมิติซึ่งใช้ข้อมูลและการดำเนินการหลายมิติโดยตรง
Top-Tier- ระดับนี้เป็นเลเยอร์ไคลเอนต์ส่วนหน้า ชั้นนี้มีเครื่องมือสืบค้นและเครื่องมือการรายงานเครื่องมือวิเคราะห์และเครื่องมือขุดข้อมูล
แผนภาพต่อไปนี้แสดงถึงสถาปัตยกรรมสามชั้นของคลังข้อมูล -
![](https://post.nghiatu.com/assets/tutorial/dwh/images/dwh_architecture.jpg)
แบบจำลองคลังข้อมูล
จากมุมมองของสถาปัตยกรรมคลังข้อมูลเรามีโมเดลคลังข้อมูลดังต่อไปนี้ -
- คลังสินค้าเสมือน
- ข้อมูลมาร์ท
- คลังสินค้าขององค์กร
คลังสินค้าเสมือน
มุมมองของคลังข้อมูลการดำเนินงานเรียกว่าคลังสินค้าเสมือน การสร้างคลังสินค้าเสมือนเป็นเรื่องง่าย การสร้างคลังสินค้าเสมือนจำเป็นต้องใช้ความจุส่วนเกินบนเซิร์ฟเวอร์ฐานข้อมูลปฏิบัติการ
ข้อมูลมาร์ท
ดาต้ามาร์ทมีข้อมูลทั้งองค์กรชุดย่อย ข้อมูลชุดย่อยนี้มีค่าสำหรับกลุ่มเฉพาะขององค์กร
กล่าวอีกนัยหนึ่งเราสามารถอ้างได้ว่า data marts มีข้อมูลเฉพาะสำหรับกลุ่มใดกลุ่มหนึ่ง ตัวอย่างเช่นข้อมูลการตลาดอาจมีข้อมูลที่เกี่ยวข้องกับสินค้าลูกค้าและการขาย มาร์ทข้อมูลถูก จำกัด เฉพาะเรื่อง
ข้อควรจำเกี่ยวกับ data marts -
เซิร์ฟเวอร์ที่ใช้ Window หรือ Unix / Linux ใช้เพื่อใช้งาน data marts มีการใช้งานบนเซิร์ฟเวอร์ต้นทุนต่ำ
รอบการใช้งานดาต้ามาร์ทถูกวัดในช่วงเวลาสั้น ๆ เช่นเป็นสัปดาห์แทนที่จะเป็นเดือนหรือปี
วงจรชีวิตของดาต้ามาร์ทอาจมีความซับซ้อนในระยะยาวหากการวางแผนและการออกแบบไม่ครอบคลุมทั้งองค์กร
มาร์ทข้อมูลมีขนาดเล็ก
มาร์ทข้อมูลได้รับการปรับแต่งตามแผนก
แหล่งที่มาของดาต้ามาร์ทคือคลังข้อมูลที่มีโครงสร้างแบบแผนก
ดาต้ามาร์ทมีความยืดหยุ่น
คลังสินค้าขององค์กร
คลังสินค้าขององค์กรรวบรวมข้อมูลทั้งหมดและหัวข้อที่ครอบคลุมทั้งองค์กร
ให้การรวมข้อมูลทั้งองค์กรแก่เรา
ข้อมูลถูกรวมจากระบบปฏิบัติการและผู้ให้บริการข้อมูลภายนอก
ข้อมูลนี้อาจแตกต่างกันไปตั้งแต่ไม่กี่กิกะไบต์ไปจนถึงหลายร้อยกิกะไบต์เทราไบต์หรือมากกว่านั้น
ตัวจัดการการโหลด
ส่วนประกอบนี้ดำเนินการที่จำเป็นในการแยกและโหลดกระบวนการ
ขนาดและความซับซ้อนของตัวจัดการโหลดจะแตกต่างกันไประหว่างโซลูชันเฉพาะจากคลังข้อมูลหนึ่งไปยังคลังข้อมูลอื่น
สถาปัตยกรรม Load Manager
ตัวจัดการโหลดทำหน้าที่ดังต่อไปนี้ -
ดึงข้อมูลจากระบบต้นทาง
โหลดข้อมูลที่แยกแล้วลงในที่เก็บข้อมูลชั่วคราวอย่างรวดเร็ว
ทำการแปลงอย่างง่ายให้เป็นโครงสร้างที่คล้ายกับโครงสร้างในคลังข้อมูล
![](https://post.nghiatu.com/assets/tutorial/dwh/images/load_manager.jpg)
ดึงข้อมูลจากแหล่งที่มา
ข้อมูลถูกดึงมาจากฐานข้อมูลการปฏิบัติงานหรือผู้ให้บริการข้อมูลภายนอก เกตเวย์คือโปรแกรมแอพพลิเคชั่นที่ใช้ในการดึงข้อมูล ได้รับการสนับสนุนโดย DBMS พื้นฐานและอนุญาตให้โปรแกรมไคลเอ็นต์สร้าง SQL เพื่อดำเนินการที่เซิร์ฟเวอร์ Open Database Connection (ODBC), Java Database Connection (JDBC) เป็นตัวอย่างของเกตเวย์
โหลดเร็ว
เพื่อลดหน้าต่างการโหลดทั้งหมดให้เหลือน้อยที่สุดจำเป็นต้องโหลดข้อมูลลงในคลังสินค้าโดยเร็วที่สุด
การแปลงมีผลต่อความเร็วของการประมวลผลข้อมูล
การโหลดข้อมูลลงในฐานข้อมูลเชิงสัมพันธ์จะมีประสิทธิภาพมากกว่าก่อนที่จะใช้การแปลงและการตรวจสอบ
เทคโนโลยีเกตเวย์พิสูจน์ได้ว่าไม่เหมาะสมเนื่องจากมักจะไม่มีประสิทธิภาพเมื่อมีข้อมูลจำนวนมากเข้ามาเกี่ยวข้อง
การเปลี่ยนแปลงอย่างง่าย
ในขณะที่โหลดอาจจำเป็นต้องทำการแปลงร่างอย่างง่าย หลังจากเสร็จสิ้นแล้วเราก็พร้อมที่จะทำการตรวจสอบที่ซับซ้อน สมมติว่าเรากำลังโหลดธุรกรรมการขาย EPOS เราจำเป็นต้องทำการตรวจสอบต่อไปนี้:
- ตัดคอลัมน์ทั้งหมดที่ไม่จำเป็นภายในคลังสินค้าออก
- แปลงค่าทั้งหมดเป็นชนิดข้อมูลที่ต้องการ
ผู้จัดการคลังสินค้า
ผู้จัดการคลังสินค้ามีหน้าที่รับผิดชอบในกระบวนการจัดการคลังสินค้า ประกอบด้วยซอฟต์แวร์ระบบของ บริษัท อื่นโปรแกรม C และเชลล์สคริปต์
ขนาดและความซับซ้อนของผู้จัดการคลังสินค้าแตกต่างกันไประหว่างโซลูชันเฉพาะ
สถาปัตยกรรมผู้จัดการคลังสินค้า
ผู้จัดการคลังสินค้ามีดังต่อไปนี้ -
- กระบวนการควบคุม
- กระบวนงานที่เก็บไว้หรือ C กับ SQL
- เครื่องมือสำรอง / กู้คืน
- สคริปต์ SQL
![](https://post.nghiatu.com/assets/tutorial/dwh/images/warehouse_manager.jpg)
การดำเนินการโดยผู้จัดการคลังสินค้า
ผู้จัดการคลังสินค้าจะวิเคราะห์ข้อมูลเพื่อทำการตรวจสอบความสอดคล้องและการอ้างอิงความสมบูรณ์
สร้างดัชนีมุมมองทางธุรกิจมุมมองพาร์ติชันเทียบกับข้อมูลพื้นฐาน
สร้างการรวมใหม่และอัปเดตการรวมที่มีอยู่ สร้างการปรับมาตรฐาน
แปลงและรวมแหล่งข้อมูลลงในคลังข้อมูลที่เผยแพร่
สำรองข้อมูลในคลังข้อมูล
เก็บข้อมูลที่หมดอายุการใช้งาน
Note - ผู้จัดการคลังสินค้ายังวิเคราะห์โปรไฟล์การสืบค้นเพื่อกำหนดดัชนีและการรวมที่เหมาะสม
ตัวจัดการแบบสอบถาม
ตัวจัดการคิวรีมีหน้าที่กำหนดคิวรีไปยังตารางที่เหมาะสม
การกำหนดคิวรีไปยังตารางที่เหมาะสมจะทำให้ความเร็วในการสืบค้นและการสร้างการตอบกลับเพิ่มขึ้นได้
ตัวจัดการคิวรีมีหน้าที่จัดกำหนดการการดำเนินการของแบบสอบถามที่ผู้ใช้วางไว้
สถาปัตยกรรม Query Manager
ภาพหน้าจอต่อไปนี้แสดงสถาปัตยกรรมของตัวจัดการแบบสอบถาม ซึ่งรวมถึงสิ่งต่อไปนี้:
- การเปลี่ยนเส้นทางแบบสอบถามผ่านเครื่องมือ C หรือ RDBMS
- ขั้นตอนการจัดเก็บ
- เครื่องมือจัดการแบบสอบถาม
- การตั้งเวลาการสืบค้นผ่านเครื่องมือ C หรือ RDBMS
- การตั้งเวลาการสืบค้นผ่านซอฟต์แวร์ของบุคคลที่สาม
![](https://post.nghiatu.com/assets/tutorial/dwh/images/query_manager.jpg)
รายละเอียดข้อมูล
ข้อมูลโดยละเอียดจะไม่ถูกเก็บไว้ทางออนไลน์ แต่จะรวมไว้ในระดับรายละเอียดถัดไปจากนั้นจะเก็บถาวรลงในเทป ส่วนข้อมูลโดยละเอียดของคลังข้อมูลจะเก็บข้อมูลโดยละเอียดไว้ในสคีมา starflake ข้อมูลโดยละเอียดถูกโหลดลงในคลังข้อมูลเพื่อเสริมข้อมูลที่รวบรวม
แผนภาพต่อไปนี้แสดงภาพที่แสดงถึงตำแหน่งที่จัดเก็บข้อมูลโดยละเอียดและใช้อย่างไร
![](https://post.nghiatu.com/assets/tutorial/dwh/images/detailed_information.jpg)
Note - หากข้อมูลโดยละเอียดถูกเก็บไว้แบบออฟไลน์เพื่อลดพื้นที่จัดเก็บดิสก์เราควรตรวจสอบให้แน่ใจว่าข้อมูลได้ถูกแยกล้างและเปลี่ยนเป็นสคีมา starflake ก่อนที่จะถูกเก็บ
ข้อมูลสรุป
ข้อมูลสรุปเป็นส่วนหนึ่งของคลังข้อมูลที่เก็บการรวมที่กำหนดไว้ล่วงหน้า การรวมเหล่านี้สร้างขึ้นโดยผู้จัดการคลังสินค้า ข้อมูลสรุปต้องถือว่าเป็นข้อมูลชั่วคราว มันเปลี่ยนไปทุกที่เพื่อตอบสนองต่อการเปลี่ยนแปลงโปรไฟล์การสืบค้น
ประเด็นที่ควรทราบเกี่ยวกับข้อมูลสรุปมีดังนี้ -
ข้อมูลสรุปช่วยเพิ่มความเร็วในการทำงานของคำค้นหาทั่วไป
เป็นการเพิ่มต้นทุนการดำเนินงาน
ต้องมีการอัปเดตทุกครั้งที่มีการโหลดข้อมูลใหม่ลงในคลังข้อมูล
อาจไม่ได้รับการสำรองข้อมูลเนื่องจากสามารถสร้างขึ้นใหม่จากข้อมูลโดยละเอียด