ฉันคิดว่าความแตกต่างหลักที่ฉันสามารถอธิบายได้เกี่ยวข้องกับรูปแบบเชิงบันทึกและเชิงคอลัมน์ รูปแบบที่เน้นการบันทึกเป็นสิ่งที่เราทุกคนคุ้นเคย - ไฟล์ข้อความรูปแบบตัวคั่นเช่น CSV, TSV AVRO เย็นกว่าเล็กน้อยเนื่องจากสามารถเปลี่ยนสคีมาเมื่อเวลาผ่านไปเช่นการเพิ่มหรือลบคอลัมน์ออกจากบันทึก เทคนิคอื่น ๆ ของรูปแบบต่างๆ (โดยเฉพาะอย่างยิ่งรวมถึงการบีบอัด) เกี่ยวข้องกับการแบ่งรูปแบบหรือไม่นั่นคือคุณสามารถอ่านบล็อกของระเบียนจากที่ใดก็ได้ในชุดข้อมูลและยังรู้ว่าเป็นสคีมาหรือไม่ แต่นี่คือรายละเอียดเพิ่มเติมเกี่ยวกับรูปแบบเสาเช่นไม้ปาร์เก้
ไม้ปาร์เก้และรูปแบบเสาอื่น ๆ จัดการกับสถานการณ์ทั่วไปของ Hadoop ได้อย่างมีประสิทธิภาพ เป็นเรื่องปกติที่จะมีตาราง (ชุดข้อมูล) ที่มีคอลัมน์มากกว่าที่คุณคาดหวังในฐานข้อมูลเชิงสัมพันธ์ที่ออกแบบมาอย่างดี - ร้อยหรือสองร้อยคอลัมน์ไม่ใช่เรื่องแปลก เป็นเช่นนี้เพราะเรามักจะใช้เป็นสถานที่ Hadoop ไปdenormalizeข้อมูลจากรูปแบบเชิงสัมพันธ์ - ใช่คุณจะได้รับจำนวนมากของค่าซ้ำและหลายตารางทั้งหมดบี้เป็นหนึ่งเดียว แต่จะง่ายกว่ามากในการสืบค้นเนื่องจากการรวมทั้งหมดได้รับการดำเนินการ มีข้อดีอื่น ๆ เช่นการรักษาข้อมูลสถานะในเวลา ดังนั้นจึงเป็นเรื่องปกติที่จะมีคอลัมน์ในตาราง
สมมติว่ามีคอลัมน์ 132 คอลัมน์และบางคอลัมน์เป็นช่องข้อความยาวมากแต่ละคอลัมน์จะเรียงตามอีกคอลัมน์หนึ่งและอาจใช้ถึง 10K ต่อระเบียน
แม้ว่าการสืบค้นตารางเหล่านี้จะทำได้ง่ายด้วยจุดยืนของ SQL แต่ก็เป็นเรื่องปกติที่คุณจะต้องได้รับระเบียนบางช่วงโดยอิงจากคอลัมน์ร้อยคอลัมน์เหล่านั้นเพียงไม่กี่คอลัมน์ ตัวอย่างเช่นคุณอาจต้องการบันทึกทั้งหมดในเดือนกุมภาพันธ์และมีนาคมสำหรับลูกค้าที่มียอดขาย> $ 500
ในการดำเนินการนี้ในรูปแบบแถวแบบสอบถามจะต้องสแกนทุกระเบียนของชุดข้อมูล อ่านแถวแรกแยกวิเคราะห์ระเบียนลงในช่อง (คอลัมน์) และรับวันที่และคอลัมน์การขายรวมไว้ในผลลัพธ์ของคุณหากเป็นไปตามเงื่อนไข ทำซ้ำ หากคุณมีประวัติ 10 ปี (120 เดือน) คุณกำลังอ่านทุกๆบันทึกเพื่อหา 2 เดือนนั้น แน่นอนว่านี่เป็นโอกาสที่ดีในการใช้พาร์ติชันแบบปีและเดือน แต่ถึงอย่างนั้นคุณกำลังอ่านและแยกวิเคราะห์ 10K ของแต่ละระเบียน / แถวในช่วงสองเดือนนั้นเพียงเพื่อดูว่ายอดขายของลูกค้าอยู่ที่> $ 500 หรือไม่
ในรูปแบบคอลัมน์แต่ละคอลัมน์ (ฟิลด์) ของเรกคอร์ดจะถูกเก็บไว้กับคนอื่น ๆ โดยกระจายไปทั่วบล็อกต่างๆบนดิสก์ - คอลัมน์สำหรับปีรวมกันคอลัมน์สำหรับเดือนด้วยกันคอลัมน์สำหรับคู่มือพนักงานของลูกค้า (หรืออื่น ๆ ข้อความยาว) และอื่น ๆ ทั้งหมดที่สร้างระเบียนเหล่านั้นมีขนาดใหญ่มากในตำแหน่งแยกต่างหากบนดิสก์และแน่นอนว่าคอลัมน์สำหรับการขายด้วยกัน ห่าวันที่และเดือนเป็นตัวเลขและยอดขายก็เช่นกัน - มันเป็นเพียงไม่กี่ไบต์ จะดีหรือไม่ถ้าเราต้องอ่านข้อมูลเพียงไม่กี่ไบต์สำหรับแต่ละระเบียนเพื่อพิจารณาว่าระเบียนใดตรงกับข้อความค้นหาของเรา ที่เก็บเสาเพื่อช่วยเหลือ!
แม้ว่าจะไม่มีพาร์ติชันก็ตามการสแกนช่องเล็ก ๆ ที่จำเป็นเพื่อตอบสนองการสืบค้นของเรานั้นรวดเร็วมากโดยทั้งหมดเรียงตามลำดับบันทึกและมีขนาดเท่ากันทั้งหมดดังนั้นดิสก์จึงพยายามตรวจสอบข้อมูลน้อยกว่ามากสำหรับบันทึกที่รวมอยู่ ไม่จำเป็นต้องอ่านคู่มือพนักงานและช่องข้อความยาวอื่น ๆ เพียงแค่เพิกเฉย ดังนั้นโดยการจัดกลุ่มคอลัมน์ซึ่งกันและกันแทนที่จะเป็นแถวคุณจะสามารถสแกนข้อมูลน้อยลงได้เกือบตลอดเวลา ชนะ!
แต่เดี๋ยวก่อนมันจะดีขึ้น หากแบบสอบถามของคุณต้องการเพียงเพื่อทราบค่าเหล่านั้นและอีกสองสามคอลัมน์ (สมมติว่า 10 จาก 132 คอลัมน์) และไม่สนใจคอลัมน์คู่มือพนักงานนั้นเมื่อเลือกระเบียนที่ถูกต้องเพื่อส่งคืนแล้วตอนนี้จะต้องไปเท่านั้น กลับไปที่คอลัมน์ 10 คอลัมน์ที่จำเป็นในการแสดงผลลัพธ์โดยไม่สนใจอีก 122 คอลัมน์จาก 132 ในชุดข้อมูลของเรา อีกครั้งเราข้ามการอ่านมาก
(หมายเหตุ: ด้วยเหตุนี้รูปแบบคอลัมน์จึงเป็นตัวเลือกที่น่าเบื่อเมื่อทำการแปลงแบบตรงตัวอย่างเช่นหากคุณรวมตารางทั้งสองตารางเป็นชุดผลลัพธ์ขนาดใหญ่ (ger) ชุดเดียวที่คุณบันทึกเป็นตารางใหม่แหล่งที่มา กำลังจะได้รับการสแกนอย่างสมบูรณ์ดังนั้นประสิทธิภาพในการอ่านจึงไม่ได้รับประโยชน์มากนักและเนื่องจากรูปแบบคอลัมน์จำเป็นต้องจำข้อมูลเพิ่มเติมเกี่ยวกับตำแหน่งที่อยู่จึงใช้หน่วยความจำมากกว่ารูปแบบแถวที่คล้ายกัน)
อีกหนึ่งประโยชน์ของคอลัมน์: ข้อมูลกระจายไปทั่ว ในการรับระเบียนเดียวคุณสามารถมีคนงาน 132 คนแต่ละคนอ่าน (และเขียน) ข้อมูลจาก / ถึง 132 ที่ต่างกันใน 132 บล็อกข้อมูล ใช่สำหรับการขนาน!
และตอนนี้สำหรับ clincher: อัลกอริธึมการบีบอัดจะทำงานได้ดีขึ้นมากเมื่อสามารถค้นหารูปแบบการทำซ้ำได้ คุณสามารถบีบอัดAABBBBBBCCCCCCCCCCCCCCCCเป็น2A6B16Cแต่ABCABCBCBCBCCCCCCCCCCCCCCจะไม่ได้รับความเป็นขนาดเล็ก (ดีจริงในกรณีนี้มันจะ แต่เชื่อฉัน :-)) ดังนั้นอีกครั้งการอ่านน้อยลง และการเขียนด้วย.
ดังนั้นเราจึงอ่านข้อมูลน้อยลงเพื่อตอบคำถามทั่วไปการอ่านและเขียนแบบขนานอาจเร็วกว่าและการบีบอัดมีแนวโน้มที่จะทำงานได้ดีขึ้นมาก
คอลัมน์นั้นยอดเยี่ยมเมื่อด้านอินพุตของคุณมีขนาดใหญ่และเอาต์พุตของคุณเป็นเซ็ตย่อยที่ถูกกรอง: จากใหญ่ไปน้อยนั้นยอดเยี่ยม ไม่เป็นประโยชน์เมื่ออินพุตและเอาต์พุตใกล้เคียงกัน
แต่ในกรณีของเรา Impala ใช้คำค้นหา Hive เก่าของเราซึ่งทำงานใน 5, 10, 20 หรือ 30 นาทีและเสร็จสิ้นในเวลาไม่กี่วินาทีหรือหนึ่งนาที
หวังว่านี่จะช่วยตอบคำถามของคุณได้อย่างน้อยที่สุด!