Skip to main content

Command Palette

Search for a command to run...

Exploring Serialization Methods

A Deep Dive into Facebook's Use of FlatBuffers and Beyond

Published
•5 min read•View as Markdown
Exploring Serialization Methods
W

constant failure

Serialization is the process of converting data structures or objects into a format that can be easily stored or transmitted and later reconstructed. In the world of mobile and big data applications, efficient serialization is crucial for performance, especially when dealing with large amounts of data. Two popular serialization methods are JSON and FlatBuffers. In this blog, we'll explore these methods, delve into a case study of Facebook's transition to using FlatBuffers for their Android application, and discuss various features of serialization formats.

JSON vs. FlatBuffers

JSON: A widely-used lightweight data-interchange format that is easy to read and write for humans and easy to parse and generate for machines. However, JSON parsing can be slow, especially for large data sets, and can lead to significant memory overhead.

FlatBuffers: An open-source project from Google, FlatBuffers is an evolution of protocol buffers. It includes object metadata, allowing direct access to individual subcomponents of the data without having to deserialize the entire object upfront. This results in faster read times and reduced memory overhead.

Features of Serialization Formats

Serialization formats come with a variety of features that cater to different needs. Let's explore some of these features:

Expressiveness

  • Hierarchically Nested or Flat Tables: While formats like ROOT, Parquet, Avro, JSON, and XML support hierarchical tables, CSV, SQLite, Numpy, and high-performance HDF5 are more suited for flat tables. Conversion from hierarchical to flat table can result in data loss.
  • Schema: Formats like ROOT, Parquet, and Avro are strongly typed, whereas JSON, BSON, and MessagePack are dynamic.
  • Schema Evolution: ROOT, ProtoBuf, Thrift, and Avro support rules to automatically translate data schemas into container objects, while formats like Objectivity and Java serialization do not.
  • Language Specificity: While ProtoBuf, Thrift, Avro, Parquet, Cap'n Proto, OAMap, and SQL schemas are language agnostic, ROOT is specialized for C++, Pickle for Python, and Kryo for Java.

Performance

  • Data Representation: Columnar representation, as seen in ROOT (one level deep), Parquet, ORC, and OAMap, improves efficiency when accessing subsets of attributes, whereas formats like JSON, ProtoBuf, Thrift, Avro, and Google FlatBuffers are rowwise.
  • Compression: Formats like ROOT, ProtoBuf, Thrift, Avro, Parquet, and HDF5 support built-in compression, while JSON and CSV do not.
  • Robustness: ROOT, HDF5, Avro, and Parquet are robust against bit errors, whereas JSON and CSV are not.
  • Serialized/Runtime Unity: Apache Arrow, used in Spark and Pandas, ensures that the byte-representation of serialized data is the same as that of runtime objects.

Accessibility

  • Readability: While formats like FITS, ASDF, and XML support human readability, ROOT and BSON are binary.
  • Immutability: Most file formats are immutable.
  • Partial-write Recovery: ROOT, CSV, JSONLines, Avro, and OAMap support reading data that has been partially written, whereas Parquet and HDF5 do not.
  • Parallelism: ROOT, Blosc, and HDF5 support parallel reading, while Avro and JSON do not. However, no specific formats are highlighted for parallel writing.
  • Streamability: JSONLines, CSV, and Avro are streamable, while ROOT and Parquet are not.
  • Random Accessibility: ROOT, Arrow, and OAMap support random access, whereas ProtoBuf, Thrift, Avro, JSON, CSV, XML, and Parquet do not.
  • Database-style Indexing: Parquet supports database-style indexing, while ROOT, Avro, and JSON do not.

Community

  • RPC Protocol: Formats like JSON, ProtoBuf, Thrift, Avro, Cap'n Proto, and MessagePack are designed for RPC, whereas ROOT, HDF5, Parquet, and Google Flatbuffers are more for archival files.
  • Specifications: Formats like FITS, ProtoBuf, Thrift, Avro, Parquet, Arrow, and HDF5 have detailed specifications, while ROOT does not.
  • Independent Implementations: ROOT has seven independent implementations, contrasting the attitude in HEP against "reinventing the wheel".

Facebook's Journey with FlatBuffers

On Facebook's Android app, users keep up with their family and friends through status updates and photos. The backend stores the data that makes up the social graph of these connections. However, it's not feasible to download the entire graph on mobile clients. Instead, a local tree structure of a node and some of its connections is downloaded.

Previously, Facebook considered storing this tree structure in JSON. However, this would require parsing the JSON and transforming it into a Java object before the UI could use it. They found several issues with using JSON:

  • Parsing Speed: Parsing a typical 20 KB JSON stream took 35 ms, exceeding the UI frame refresh interval of 16.6 ms.
  • Parser Initialization: Initializing a JSON parser could take between 100 ms to 200 ms, slowing down the app's start time.
  • Garbage Collection: Parsing JSON led to the creation of many small objects, placing pressure on Java's garbage collector.

To address these challenges, Facebook explored alternate formats and discovered FlatBuffers. With FlatBuffers, data can be accessed directly without deserializing the entire object, reducing latency and improving performance. Additionally, FlatBuffers are immutable by design, but Facebook developed a method to track mutations side by side with the original FlatBuffer, allowing for efficient updates.

Furthermore, Facebook introduced the concept of "Flat Models," where FlatBuffers are used not only for storage but also for networking and as the in-memory format in the app. This approach eliminates data transformation from server response to UI display, simplifying the architecture and improving performance.

Results of Adopting FlatBuffers

After transitioning most of Facebook's Android app to use FlatBuffers, they observed significant performance improvements:

  • Story load time from disk cache reduced from 35 ms to 4 ms per story.
  • Transient memory allocations reduced by 75%.
  • Cold start time improved by 10-15%.
  • Storage size reduced by 15%.

Conclusion

The choice of serialization method can have profound impacts on app performance. By adopting FlatBuffers, Facebook was able to enhance the user experience, allowing users to spend more time engaging with content. The case of Facebook underscores the importance of selecting the right tools and methodologies for specific challenges in software development. Moreover, understanding the various features and capabilities of serialization formats can guide developers in making informed decisions tailored to their specific needs.

Source:

More from this blog

[ossca] 모델 리소스 추가

1. 시작하기 먼저 Hugging Face Transformers GitHub에서 해당 이슈를 읽어보세요. 다양한 모델의 문서를 관련 리소스를 모아서 개선하자는 내용이 있습니다. 저희 채널은 물론이고, 해당 이슈에 댓글을 달아 작업하고 싶은 모델을 신청하세요. 아래에 상위 21개 모델의 주요 특징, 게재 연도, 도메인, 기관, 링크를 정리해뒀습니다. 모델주요 특징게재 연도도메인기관링크 BART사전 훈련 목표(pre-training ...

Aug 1, 20234 min read
[ossca] 모델 리소스 추가

mint

19 posts

I don't know.