Differences between CSV and JSON

According to the Internet Engineering Task Force (IETF) RFC 4180, Each line [in a CSV file] should contain the same number of fields throughout the file.

However, in practice, if each record in a CSV file or stream contains, in the same column, a field that identifies the record type, then records might be heterogeneous: different column layouts in each record. Applications that interpret the records, such as analytics platforms, can use that field to detect the record type, and then apply a corresponding column layout definition. (How an application detects the record type and applies a column layout definition depends on the application.)

More precisely, a JSON object is an unordered set of name/value pairs; the order of name/value pairs is not significant.

Name/value pairs are also known as key-value (KV) pairs.

The following example shows a header followed by two data records:

tran,count
A,5
B,10

In this context, field names are also known as labels.

The following example shows two JSON objects separated by a newline character. This format is known as JSON Lines:

{"tran": "A", "count": 5}
{"tran": "B", "optfld": "X", "count": 10}

Some z/OS®-based log record types contain nested structures, such as repeating sections. If you want to preserve such structures in a common data exchange format, JSON is a better fit than CSV.

For example, in the following JSON object, the value of the steps field is an array; each element of the array is an object. This is a simplified example to illustrate nesting, not actual log data.

{
  "job": "A",
  "rc": 8,
  "steps": [
    {"name": "A1", "rc": 0},
    {"name": "A2", "rc": 0},
    {"name": "A3", "rc": 8}
  ]
}

CSV needs external metadata to identify data types, so some analytics platforms might need more configuration to ingest CSV than JSON.

If you forward logs to an analytics platform that needs to distinguish between strings and numbers, JSON already does this.

Regardless of whether you use CSV or JSON, you might need to configure the analytics platform to recognize the format of date values, such as event time stamps.

Each value is accompanied by a field name (also known as a key).

Disadvantage: if you forward logs to an analytics platform with a licensing model that is based on the volume of data ingested, and that calculation includes keys, then you might pay more to ingest keys than values.

Advantage: reduced risk of data corruption due to incorrect field mapping, such as changes to record formats over time. Each value in each record is explicitly paired with the correct key.