流和文件格式中的数据组件表示为封装 消息，包括：
创新互联专注于贺州企业网站建设,成都响应式网站建设,商城建设。贺州网站建设公司,为贺州等地区提供建站服务。全流程定制设计，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
所述metadata_size包括flatbuffer加填充的大小。所述 Message flatbuffer包括版本号，特定消息（作为flatbuffer联合），和消息体的大小：
table Message {
version: org.apache.arrow.flatbuf.MetadataVersion;
header: MessageHeader;
bodyLength: long;
}目前，我们支持4种类型的消息：
我们提供用于RecordBatch的流格式。它被作为封装消息的序列呈现，每个消息遵循上述格式。该模式首先在流中，对于以后的所有RecordBatch都是相同的。如果模式中的任何字段都是字典编码的，则一个或多个 DictionaryBatch消息将跟随模式。
...
...
当流读取器实现读取流时，在每个消息之后，它可以读取接下来的4个字节以知道以下消息元数据的大小。读取消息flatbuffer后，您可以读取消息体。
流写入器可以通过写入0长度作为int32或简单地关闭流接口来发送流终端（EOS）信号。
我们以与流格式非常相似的格式定义支持随机访问的“文件格式”。该文件以魔术字符串ARROW1 （加上填充）开始和结束。文件中的内容与流格式相同。在文件末尾，我们编写一个页脚，包括文件中每个数据块的偏移量和大小，以便随机访问是可以实现的。有关文件页脚的精确细节，请参阅 format / File.fbs。
示意， 我们有：
所述RecordBatch元数据包含一个深度优先（先序）扁平化设置字段的元数据和物理内存缓冲区（Message.fbs 中的一些注释已经缩短/移除）：
table RecordBatch {
length: long;
nodes: [FieldNode];
buffers: [Buffer];
}
struct FieldNode {
length: long;
null_count: long;
}
struct Buffer {
/// The shared memory page id where this buffer is located. Currently this is
/// not used
page: int;
/// The relative offset into the shared memory page where the bytes for this
/// buffer starts
offset: long;
/// The absolute length (in bytes) of the memory buffer. The memory is found
/// from offset (inclusive) to offset + length (non-inclusive).
length: long;
} 在文件的上下文中，不使用page，Buffer偏移量用作消息正文开头的参考帧。因此，在通用IPC设置中，这些偏移量可能是一个或多个共享内存区域中的任何位置，在文件格式中偏移量从0开始。
RecordBatch的位置以及元数据块的大小以及缓冲区的大小存储在文件页脚中：
struct Block {
offset: long;
metaDataLength: int;
bodyLength: long;
}一些关于这个的注释
字典Batch尚未实现，但它们在元数据中提供。目前，文件中显示的DICTIONARY细分片段不会出现在任何文件实现中。
Tensor消息类型提供一种方式来编写使用Arrow的共享内存工具的固定大小的值（如一个NumPy的ndarray）的多维数组。尽管我们在C ++中提供了一个参考实现，但通常不需要实现这种数据格式的Arrow实现。
当编写独立封装的Tensor消息时，我们使用上述格式，但另外将起始偏移（如果写入共享内存区域）对齐为8的倍数：
