หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

ปาร์เก้

พื้นที่เก็บข้อมูลนี้มีข้อกำหนดสำหรับคำจำกัดความ Apache Parquet และ Apache Thrift เพื่ออ่านและเขียนข้อมูลเมตา Parquet

Apache Parquet เป็นรูปแบบไฟล์ข้อมูลแบบโอเพ่นซอร์สที่เน้นคอลัมน์ ซึ่งออกแบบมาเพื่อการจัดเก็บและเรียกค้นข้อมูลที่มีประสิทธิภาพ โดยให้รูปแบบการบีบอัดและการเข้ารหัสประสิทธิภาพสูงเพื่อจัดการข้อมูลที่ซับซ้อนจำนวนมาก และได้รับการสนับสนุนในภาษาการเขียนโปรแกรมและเครื่องมือวิเคราะห์มากมาย

แรงจูงใจ

เราสร้าง Parquet เพื่อสร้างข้อได้เปรียบของการแสดงข้อมูลแบบเรียงเป็นแนวที่บีบอัดและมีประสิทธิภาพสำหรับโครงการใดๆ ในระบบนิเวศ Hadoop

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

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

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

โมดูล

โครงการ parquet-format ประกอบด้วยข้อกำหนดรูปแบบและคำจำกัดความ Thrift ของข้อมูลเมตาที่จำเป็นในการอ่านไฟล์ Parquet อย่างถูกต้อง

โปรเจ็กต์ parquet-java มีโมดูลย่อยหลายโมดูล ซึ่งใช้คอมโพเนนต์หลักของการอ่านและการเขียนสตรีมข้อมูลเชิงคอลัมน์ที่ซ้อนกัน แมปแกนนี้ลงในรูปแบบ parquet และจัดเตรียมรูปแบบอินพุต/เอาท์พุต Hadoop ตัวโหลด Pig และอื่นๆ ยูทิลิตี้ที่ใช้ Java สำหรับการโต้ตอบกับ Parquet

โครงการ parquet-compatibility ประกอบด้วยการทดสอบความเข้ากันได้ที่สามารถใช้เพื่อตรวจสอบว่าการใช้งานในภาษาต่างๆ สามารถอ่านและเขียนไฟล์ของกันและกันได้

อาคาร

ทรัพยากร Java สามารถสร้างขึ้นได้โดยใช้ mvn package เวอร์ชันเสถียรปัจจุบันควรพร้อมใช้งานจาก Maven Central เสมอ

ทรัพยากรความประหยัด C ++ สามารถสร้างขึ้นได้ผ่าน make

Thrift สามารถสร้างโค้ดเป็นภาษาอื่นๆ ที่สนับสนุน Thrift ได้

อภิธานศัพท์

  • บล็อก (บล็อก HDFS): นี่หมายถึงบล็อกใน HDFS และความหมายไม่เปลี่ยนแปลงสำหรับการอธิบายรูปแบบไฟล์นี้ รูปแบบไฟล์ได้รับการออกแบบให้ทำงานได้ดีบน HDFS

  • ไฟล์: ไฟล์ HDFS ที่ต้องรวมข้อมูลเมตาของไฟล์ ไม่จำเป็นต้องมีข้อมูลจริง

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

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

  • หน้า: ส่วนคอลัมน์จะถูกแบ่งออกเป็นหน้าต่างๆ เพจถือเป็นหน่วยที่แบ่งแยกไม่ได้ตามแนวคิด (ในแง่ของการบีบอัดและการเข้ารหัส) อาจมีประเภทเพจได้หลายประเภทซึ่งซ้อนทับกันในคอลัมน์เดียว

ในเชิงลำดับชั้น ไฟล์จะประกอบด้วยกลุ่มแถวตั้งแต่หนึ่งกลุ่มขึ้นไป กลุ่มแถวประกอบด้วยหนึ่งส่วนคอลัมน์ต่อคอลัมน์ ส่วนคอลัมน์ประกอบด้วยหนึ่งหน้าขึ้นไป

หน่วยความขนาน

  • MapReduce - กลุ่มไฟล์/แถว
  • IO - ส่วนของคอลัมน์
  • การเข้ารหัส/การบีบอัด - หน้า

รูปแบบไฟล์

ไฟล์นี้และคำจำกัดความของ Thrift ควรอ่านร่วมกันเพื่อให้เข้าใจรูปแบบ 

 4-byte magic number "PAR1"
<Column 1 Chunk 1>
<Column 2 Chunk 1>
...
<Column N Chunk 1>
<Column 1 Chunk 2>
<Column 2 Chunk 2>
...
<Column N Chunk 2>
...
<Column 1 Chunk M>
<Column 2 Chunk M>
...
<Column N Chunk M>
File Metadata
4-byte length in bytes of file metadata (little endian)
4-byte magic number "PAR1"

ในตัวอย่างข้างต้น มี N คอลัมน์ในตารางนี้ โดยแบ่งออกเป็นกลุ่มแถว M ข้อมูลเมตาของไฟล์ประกอบด้วยตำแหน่งของตำแหน่งเริ่มต้นของส่วนคอลัมน์ทั้งหมด รายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่มีอยู่ในข้อมูลเมตาสามารถพบได้ในคำจำกัดความของ Thrift

ข้อมูลเมตาของไฟล์จะถูกเขียนหลังจากข้อมูลเพื่อให้สามารถเขียนผ่านครั้งเดียวได้

ผู้อ่านควรอ่านข้อมูลเมตาของไฟล์ก่อนเพื่อค้นหาส่วนคอลัมน์ทั้งหมดที่พวกเขาสนใจ จากนั้นจึงควรอ่านส่วนคอลัมน์ตามลำดับ

ข้อมูลเมตา

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

แผนภาพข้อมูลเมตา

ประเภท

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

  • บูลีน: บูลีน 1 บิต
  • INT32: ints ที่ลงนาม 32 บิต
  • INT64: ints ที่ลงนาม 64 บิต
  • INT96: ints ที่ลงนาม 96 บิต
  • FLOAT: ค่าจุดลอยตัว IEEE 32 บิต
  • สองเท่า: ค่าจุดลอยตัว IEEE 64 บิต
  • BYTE_ARRAY: อาร์เรย์ไบต์ที่ยาวตามอำเภอใจ
  • FIXED_LEN_BYTE_ARRAY: อาร์เรย์ไบต์ที่มีความยาวคงที่

ประเภทลอจิก

ประเภทลอจิคัลใช้เพื่อขยายประเภทที่ไม้ปาร์เก้สามารถใช้เพื่อจัดเก็บโดยระบุว่าควรตีความประเภทดั้งเดิมอย่างไร ซึ่งจะทำให้ชุดของประเภทดั้งเดิมเหลือน้อยที่สุดและนำการเข้ารหัสที่มีประสิทธิภาพของไม้ปาร์เก้กลับมาใช้ใหม่ ตัวอย่างเช่น สตริงจะถูกจัดเก็บด้วยประเภทดั้งเดิม BYTE_ARRAY พร้อมด้วยคำอธิบายประกอบ STRING คำอธิบายประกอบเหล่านี้จะกำหนดวิธีการถอดรหัสและตีความข้อมูลเพิ่มเติม คำอธิบายประกอบจะถูกจัดเก็บเป็นฟิลด์ LogicalType ในข้อมูลเมตาของไฟล์และได้รับการบันทึกไว้ใน LogicalTypes.md

เรียงลำดับ

Parquet เก็บสถิติต่ำสุด/สูงสุดได้หลายระดับ (เช่น ส่วนของคอลัมน์ ดัชนีคอลัมน์ และหน้าข้อมูล) การเปรียบเทียบค่าประเภทเป็นไปตามกฎต่อไปนี้:

  1. ตรรกะแต่ละประเภทมีลำดับการเปรียบเทียบที่ระบุ หากคอลัมน์มีคำอธิบายประกอบด้วยประเภทลอจิคัลที่ไม่รู้จัก สถิติอาจไม่สามารถนำมาใช้ในการตัดข้อมูลได้ ลำดับการจัดเรียงสำหรับประเภทลอจิคัลได้รับการบันทึกไว้ในหน้า LogicalTypes.md

  2. สำหรับประเภทดั้งเดิม จะใช้กฎต่อไปนี้:

    • BOOLEAN - เท็จ จริง

    • INT32, INT64 - การเปรียบเทียบแบบลงนาม

    • FLOAT, DOUBLE - การเปรียบเทียบแบบลงนามพร้อมการจัดการ NaN และศูนย์แบบพิเศษ รายละเอียดได้รับการบันทึกไว้ในคำจำกัดความของ Thrift ในสหภาพ ColumnOrder มีการสรุปไว้ที่นี่ แต่คำจำกัดความของ Thrift ถือว่าเชื่อถือได้:

      • ไม่ควรเขียน NaN ลงในฟิลด์สถิติขั้นต่ำหรือสูงสุด
      • หากค่าสูงสุดที่คำนวณได้เป็นศูนย์ (ไม่ว่าจะเป็นค่าลบหรือบวก) ควรเขียน +0.0 ลงในฟิลด์สถิติสูงสุด
      • หากค่าต่ำสุดที่คำนวณได้เป็นศูนย์ (ไม่ว่าจะเป็นค่าลบหรือบวก) ควรเขียน -0.0 ลงในฟิลด์สถิติขั้นต่ำ

      เพื่อความเข้ากันได้แบบย้อนหลังเมื่ออ่านไฟล์:

      • หากค่า min เป็น NaN ก็ควรละเว้น
      • หากค่าสูงสุดคือ NaN ก็ควรละเว้น
      • ถ้าค่าต่ำสุดคือ +0 กลุ่มแถวอาจมีค่า -0 เช่นกัน
      • หากค่าสูงสุดคือ -0 กลุ่มแถวอาจมีค่า +0 เช่นกัน
      • เมื่อค้นหาค่า NaN ควรละเว้นค่าต่ำสุดและสูงสุด

    • BYTE_ARRAY และ FIXED_LEN_BYTE_ARRAY - การเปรียบเทียบแบบไบต์ที่ไม่ได้ลงนามแบบพจนานุกรม

การเข้ารหัสแบบซ้อน

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

รองรับการเข้ารหัสสองระดับสำหรับ BIT_PACKED และ RLE ตอนนี้ใช้ RLE เท่านั้นเนื่องจากแทนที่ BIT_PACKED

ค่าว่าง

Nullity ถูกเข้ารหัสในระดับคำจำกัดความ (ซึ่งเข้ารหัสความยาวรัน) ค่า NULL จะไม่ถูกเข้ารหัสในข้อมูล ตัวอย่างเช่น ในสคีมาที่ไม่ซ้อนกัน คอลัมน์ที่มี 1,000 NULL จะถูกเข้ารหัสด้วยการเข้ารหัสความยาวรัน (0, 1,000 ครั้ง) สำหรับระดับคำจำกัดความและไม่มีอะไรอื่นอีก

หน้าข้อมูล

สำหรับหน้าข้อมูล ข้อมูลทั้ง 3 ส่วนจะถูกเข้ารหัสกลับไปด้านหลัง โดยอยู่หลังส่วนหัวของหน้า ไม่อนุญาตให้มีช่องว่างภายในในหน้าข้อมูล เพื่อให้เรามี:

  1. ข้อมูลระดับการทำซ้ำ
  2. ข้อมูลระดับคำจำกัดความ
  3. ค่าที่เข้ารหัส

ค่า uncompressed_page_size ที่ระบุในส่วนหัวเป็นค่าของทั้ง 3 ชิ้นรวมกัน

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

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

การเข้ารหัสที่รองรับมีอธิบายไว้ใน Encodings.md

ตัวแปลงสัญญาณการบีบอัดที่รองรับมีอธิบายไว้ใน Compression.md

ชิ้นคอลัมน์

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

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

นอกจากนี้ ไฟล์ยังสามารถมีดัชนีคอลัมน์เสริมเพื่อให้ผู้อ่านข้ามหน้าได้อย่างมีประสิทธิภาพมากขึ้น ดู PageIndex.md สำหรับรายละเอียดและเหตุผลเบื้องหลังการเพิ่มสิ่งเหล่านี้ลงในรูปแบบ

การตรวจสอบ

เพจทุกประเภทสามารถตรวจสอบผลรวมแยกกันได้ ซึ่งช่วยให้สามารถปิดใช้งานเช็คซัมในระดับไฟล์ HDFS เพื่อรองรับการค้นหาแถวเดียวได้ดียิ่งขึ้น เช็คซัมคำนวณโดยใช้อัลกอริธึม CRC32 มาตรฐาน - ที่ใช้ใน เช่น GZip - บนการแสดงไบนารีแบบอนุกรมของเพจ (ไม่รวมส่วนหัวของหน้า)

การกู้คืนข้อผิดพลาด

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

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

การแยกข้อมูลเมตาและข้อมูลคอลัมน์

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

การกำหนดค่า

  • ขนาดกลุ่มแถว: กลุ่มแถวที่ใหญ่ขึ้นจะทำให้มีคอลัมน์ขนาดใหญ่ขึ้น ซึ่งทำให้สามารถทำ IO ตามลำดับที่ใหญ่ขึ้นได้ กลุ่มขนาดใหญ่ยังต้องการบัฟเฟอร์เพิ่มเติมในเส้นทางการเขียน (หรือการเขียนสองรอบ) เราขอแนะนำกลุ่มแถวขนาดใหญ่ (512MB - 1GB) เนื่องจากอาจจำเป็นต้องอ่านทั้งกลุ่มแถว เราจึงต้องการให้พอดีกับบล็อก HDFS เดียว ดังนั้นควรตั้งค่าขนาดบล็อก HDFS ให้ใหญ่ขึ้นด้วย การตั้งค่าการอ่านที่ปรับให้เหมาะสมที่สุดคือ: กลุ่มแถว 1GB, ขนาดบล็อก HDFS 1GB, บล็อก HDFS 1 บล็อกต่อไฟล์ HDFS
  • ขนาดหน้าข้อมูล: ควรถือว่าหน้าข้อมูลไม่สามารถแบ่งแยกได้ ดังนั้นหน้าข้อมูลที่เล็กลงจึงสามารถอ่านรายละเอียดได้มากขึ้น (เช่น การค้นหาแถวเดียว) ขนาดหน้าที่ใหญ่ขึ้นจะมีค่าใช้จ่ายด้านพื้นที่น้อยลง (ส่วนหัวของหน้าน้อยลง) และอาจมีค่าใช้จ่ายในการแยกวิเคราะห์น้อยลง (ส่วนหัวในการประมวลผล) หมายเหตุ: สำหรับการสแกนตามลำดับ ไม่จำเป็นต้องอ่านทีละหน้า นี่ไม่ใช่ส่วน IO เราขอแนะนำ 8KB สำหรับขนาดหน้า

ความสามารถในการขยาย

มีหลายที่ในรูปแบบสำหรับส่วนขยายที่เข้ากันได้:

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

ส่วนขยายโปรโตคอลไบนารี

Parquet Thrift IDL ขอสงวน field-id 32767 ของโครงสร้าง Thrift ทุกอันสำหรับส่วนขยาย ประเภท (Thrift) ของฟิลด์นี้จะเป็น binary เสมอ

การทดสอบ

การทดสอบ apache/parquet มีชุดของไฟล์ Parquet เพื่อการทดสอบ

มีส่วนร่วม

แสดงความคิดเห็นเกี่ยวกับปัญหาและ/หรือติดต่อรายชื่อผู้รับจดหมายของ parquet-dev พร้อมคำถามและแนวคิดของคุณ การเปลี่ยนแปลงข้อกำหนดรูปแบบหลักนี้จะมีการเสนอและอภิปรายในเชิงลึกในรายชื่อผู้รับจดหมาย คุณอาจสนใจที่จะมีส่วนร่วมในโปรเจ็กต์ย่อย Parquet-Java ซึ่งมีการใช้งานฝั่ง Java และ API ทั้งหมด ดูส่วน "วิธีการมีส่วนร่วม" ของโครงการ Parquet-Java

หลักจรรยาบรรณ

เราและชุมชนนักพัฒนา Parquet ยึดมั่นในจรรยาบรรณตามที่อธิบายโดย Twitter OSS: https://github.com/twitter/code-of-conduct/blob/master/code-of-conduct.md

ใบอนุญาต

ลิขสิทธิ์ 2013 Twitter, Cloudera และผู้มีส่วนร่วมอื่นๆ

ได้รับอนุญาตภายใต้ใบอนุญาต Apache เวอร์ชัน 2.0: http://www.apache.org/licenses/LICENSE-2.0

ขยาย
ข้อมูลเพิ่มเติม
แอปที่เกี่ยวข้อง
แนะนำสำหรับคุณ
ข้อมูลที่เกี่ยวข้อง ทั้งหมด