Big Data file formats: ทำความรู้จัก Avro, Parquet และ ORC

Burasakorn Sabyeying
Mils’ Blog
Published in
4 min readMar 7, 2022

บทความนี้เราจะมาพูดถึง Big data file formats และอะไรคือคุณสมบัติของ file format พวกนี้ รวมถึงมาทำความรู้จักว่าเหล่าแก๊ง Apache: Avro, Parquet, และ ORC ว่าคืออะไร และแตกต่างกันยังไง

ในโลกของ Big Data ส่วนหนึ่งที่ต้องคำนึงอีกอย่างคือ การเลือก file format เพราะหากเราเลือก format ที่เหมาะสมกับการเก็บข้อมูลแล้ว จะส่งเสริมให้ performance ของระบบเราดีขึ้นด้วย

ก่อนอื่นที่เราจะมาเล่าว่า file format มีอะไรบ้าง เรามาทำความเข้าใจกันก่อนว่า อะไรคือคุณสมบัติในการเลือก file format

1. Row or Column

ข้อมูลของเรา ควร support การเป็น row-based format หรือ column-based format นะ?

สมมติว่า data เราหน้าตาแบบนี้

ตัวอย่างจาก https://en.wikipedia.org/wiki/RCFile

Row-based format

คือข้อมูลที่เวลา computer อ่านข้อมูล จะอ่านจากซ้ายไปขวา (→) ทำให้จำเป็นต้องอ่าน value ในทุกๆ column

001:10,Smith,Joe,40000;002:12,Jones,Mary,50000;003:11,Johnson,Cathy,44000;004:22,Jones,Bob,55000;

row-based เหมาะกับงานที่ write-heavy workload เพราะง่ายกับการ append row

Column-based format

แน่นอนว่าคือการที่ computer จะอ่านข้อมูลจากบนลงล่าง (↓) นั่นแปลว่าในการอ่านแบบนี้ จะอ่านเพียงแค่ column เท่าที่ใช้เท่านั้น จึง skip การอ่าน column ที่ไม่ใช้ไปเลย มันช่วยทำให้ save ค่า compute อีกด้วย

10:001,12:002,11:003,22:004;Smith:001,Jones:002,Johnson:003,Jones:004;Joe:001,Mary:002,Cathy:003,Bob:004;40000:001,50000:002,44000:003,55000:004;

column-based format จึงเหมาะกับ read-heavy workload

ลองคิดภาพตามง่ายๆ การ SELECT แค่บาง column ที่จำเป็นเท่านั้น

SELECT sum(income_amount) from table_name

กับการ SELECT มาทั้งหมด

SELECT * from table_name

ความเร็วย่อมต่างกันแน่นอน

2. Schema Evolution

data schema เรามีการเปลี่ยนแปลงไหมนะ? หากมีใครสักคนเพิ่ม column ใหม่เข้ามา หรือ rename column ย่อมสร้างผลกระทบหากเรามี script ดึงข้อมูลก้อนนี้เป็นไฟล์แน่นอน ผลคือเราต้องไปแก้ script ใหม่ให้ handle ทั้ง 2 scenarios

3. Splitability

data นั้นถูกแบ่งในการ process ได้ไหมนะ?

เพราะแน่นอนข้อมูลที่ใหญ่ก็จะมีจำนวน records เป็นหลักแสนหรือหลักล้าน การแบ่งส่วนจะช่วยให้ step ในการ process นั้นง่ายขึ้น และทำ parallel computing ได้

XML ก็ตกรอบไป เพราะ XML ต้องมี tag เปิดและปิดจึงแบ่งไม่ได้

4. Compression

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

ที่สำคัญ ข้อมูลแบบ column-based นั้นจะบีบอัดข้อมูลได้ดีกว่า row-based นั่นเพราะ value ใน column เดียวกันซึ่งมี type เดียวกันตั้งอยู่ตำแหน่งชิดกัน ทำให้การบีบอัดดีกว่า

คราวนี้เรา cover ไปถึงปัจจัยต่างๆแล้ว เรามาทำความรู้จักกับ file format ต่างๆดีกว่า

Avro

History of Avro:

Avro หรือ Apache Avro เป็น open source project ที่ถูกสร้างโดย Doug Cutting หรือ บิดาผู้สร้าง Hadoop นั่นเอง ในตอนนั้น Hadoop มีปัญหาเรื่องการ write ที่ต้อง compatible กับภาษาอื่นๆ Avro จึงเข้ามาช่วย deal กับ data format ตรงนี้ที่จะให้ support หลายๆภาษาเข้ามา process ได้

Feature & characteristics:

  • Avro เก็บข้อมูลเป็นแบบ row-based
  • Avro ประกอบด้วย 2 ส่วน คือ schema ที่อยู่ในรูป JSON และ data ที่อยู่ในรูป binary
  • Avro จึงรองรับ Schema Evolution เนื่องจากนางพก schema ไปกับตัวเองตลอด ส่งผลให้ program ไม่ต้องลำบากในการ handle schema changes
  • Avro สามารถ processed ได้จากหลายภาษา เช่น C, C++, C#, Java, Python และ Ruby
  • รองรับเรื่องการ compress และ splittable อย่างที่เราเล่าไปด้านบน
  • Avro support Kafka, Druid (real-time database)

ตัวอย่าง schema

{
"type" : "record",
"name" : "student",
"doc" : "Schema generated by Kite",
"fields" : [ {
"name" : "name",
"type" : "string",
"doc" : "Full name"
}, {
"name" : "id",
"type" : "long",
"doc" : "First two digits infer class year"
}
}

Parquet

History of Parquet:

Parquet หรือ Apache Parquet ถูกคิดค้นโดย Twitter และ Cloudera ซึ่ง Parquet เนี้ยเป็นตัว improved version ของ Trevni ซึ่งเป็น columnar format ที่ Doug Cutting เป็นคนสร้าง !

Parquet ถูก released ครั้งแรกในปี 2013 และภายในปี 2015 Apache Parquet ก็กลายมาเป็น Apache Software Foundation (ASF) อันดับต้นๆ

Feature & characteristics:

  • Parquet เป็น column-based format
  • พอเป็น column-based ก็ทำให้เหมาะกับงาน read-heavy workload นั่นคือ query ได้เร็วมาก
  • รองรับเรื่อง data compress และ efficient encoding scheme
  • Parquet support Impala, Spark
  • ยัง support พวก complex data type และ nested data structure

ORC

History of ORC:

ORC หรือ Apache ORC ย่อมาจาก Optimized Row Columnar

ถูกสร้างโดย Hortonworks ในปี 2013 และถูก design มาเพื่อแก้ไขปัญหาเรื่อง Hive limitation

ORC นั้นถูกสร้างด้วยแรงบันดาลใจจาก RCFile ที่ถูกพัฒนาโดย Facebook แต่ให้การ reduce size ที่ดีกว่าถึง 75% ทีเดียว

มีความคล้ายกับ Parquet มากๆ เพราะเป็น columnar storage file ที่อยู่ใน Hadoop ecosystem เช่นกัน

Feature & characteristics:

  • ORC เป็น row-columnar format (= เป็น columnar เหมือนกับ Parquet)
  • ทำให้เหมาะกับ read-heavy workload
  • ORC support Hive, Pig, Presto (ORC เป็น default storage ของ Hive)
  • ORC เพิ่มความเร็วของการ read ขึ้นไปอีกด้วย Stripes ซึ่ง stripe ประกอบไปด้วย Index data, Row data, Stripe footer หากพูดง่ายๆคือ stripe เก็บ build-in index, ค่า aggregate min, max, sum value ทำให้เกิดการทำ row-skipping ได้และอ่านได้รวดเร็วมาก
cr. https://docs.cloudera.com/cdp-private-cloud-base/7.1.6/hive-performance-tuning/topics/hive_maximize_storage_resources_using_orc.html

แล้วใช้ตัวไหนดีล่ะ ?

ย้อนกลับไปปัจจัย 4 อย่างที่เราเล่ามาด้านบน เราต้องตอบให้ได้ว่า dataset มี use case แบบไหน เพื่อหาว่า file format ไหนตอบโจทย์เรามากที่สุด

ในมุม read หรือ write, Avro นั้นอาจจะเหมาะกับเคสที่ต้องอ่านทั้ง whole row และ write-heavy workload มากกว่า ในขณะที่ Parquet เหมาะกับงาน analytical query มากกว่า เพราะความสามารถใน read-heavy workload

หากเราเทียบระหว่าง row-based หรือ column-based, เมื่อเป็น row-based สามารถหา Avro ได้เลย แต่ถ้ามาฝั่ง column-based ปุ๊บ เราต้อง compare ระหว่าง Parquet และ ORC ที่มีความใกล้เคียงกันมาก หลายคนจึงมักเปรียบเทียบด้วย technology ที่คนนิยมใช้ Parquet เหมาะกับ Apache Spark ในขณะที่ ORC นั้นเหมาะกับงานฝั่ง Hive และ Avro เหมาะกับ Kafka มากกว่า

ref.

--

--

Burasakorn Sabyeying
Mils’ Blog

Data engineer at CJ Express. Women Techmakers Ambassador. GDG Cloud Bangkok team. Moved to Mesodiar.com