Docs
Search…
Schema Inference
What is schema inference?
When working with anything big-data, you almost certainly have had to define a schema for the type of data that the target system should expect to receive.
We have always thought that this is super annoying.
Every time your events or data payload changes, you must remember to go into some platform and update the schema, repair tables, test the whole thing and 🤞.
When Batch collects events, rather than requiring you to define a schema for the event, Batch will automatically infer the schema from the event structure. Batch will also automatically evolve the schema as your events evolve.
We call this schema inference.
What is the schema used for?
Short answer
The schema is used for generating a parquet structure and a Hive metastore table definition.
Long answer
When Batch collects your events, it stores them in two locations - our search platform and in S3.
Each storage location is used for different purposes:
- 1.Search platform is used for facilitating fast but potentially incomplete searches via our dashboard or API. It is stored in JSON format and does not contain your full data set.
- 2.S3 is used for facilitating replays and extended searches. It is stored as batched parquet and contains your full data set.
In order to facilitate replays, Batch translates your Lucene search query to an SQL query that matches our generated parquet and Hive table schema. This query is then executed via AWS Athena (Presto) which searches through all of the parquet data.
Storing your data in parquet and S3, enables us to have near-infinite storage that can be programmatically queried and retrieved.
What does a schema look like?
Given the following JSON event:
1
{
2
"object1": {
3
"foo": "bar",
4
"bar": 123,
5
"baz": true
6
},
7
"object2": [
8
1,
9
2,
10
3
11
],
12
"object3": [
13
"foo",
14
"bar"
15
],
16
"object4": [
17
{
18
"nested_obj_1": {
19
"foo": "bar"
20
}
21
},
22
{
23
"nested_obj_2": {
24
"foo": "baz"
25
}
26
}
27
]
28
}
Copied!
Batch will generate the following schema:
1
{
2
"Fields": [
3
{
4
"Tag": "name=payload, repetitiontype=OPTIONAL",
5
"Fields": [
6
{
7
"Tag": "name=object1, repetitiontype=OPTIONAL",
8
"Fields": [
9
{
10
"Tag": "name=foo, type=UTF8, repetitiontype=OPTIONAL"
11
},
12
{
13
"Tag": "name=bar, type=DOUBLE, repetitiontype=OPTIONAL"
14
},
15
{
16
"Tag": "name=baz, type=BOOLEAN, repetitiontype=OPTIONAL"
17
}
18
]
19
},
20
{
21
"Tag": "name=object2, type=LIST, repetitiontype=OPTIONAL",
22
"Fields": [
23
{
24
"Tag": "name=element, type=DOUBLE, repetitiontype=OPTIONAL"
25
}
26
]
27
},
28
{
29
"Tag": "name=object3, type=LIST, repetitiontype=OPTIONAL",
30
"Fields": [
31
{
32
"Tag": "name=element, type=UTF8, repetitiontype=OPTIONAL"
33
}
34
]
35
},
36
{
37
"Tag": "name=object4, type=LIST, repetitiontype=OPTIONAL",
38
"Fields": [
39
{
40
"Tag": "name=element, repetitiontype=OPTIONAL",
41
"Fields": [
42
{
43
"Tag": "name=nested_obj_1, repetitiontype=OPTIONAL",
44
"Fields": [
45
{
46
"Tag": "name=foo, type=UTF8, repetitiontype=OPTIONAL"
47
}
48
]
49
}
50
]
51
}
52
]
53
}
54
]
55
}
56
]
57
}
Copied!
While the inferred schema is not easy to read, it is intended to be used programmatically.
You can view a user-friendly version of the current schema and all past schemas from the collection's page. The user-friendly schema output will look like this:
1
[
2
{
3
"name":"object1",
4
"type":"object",
5
"fields":[
6
{
7
"name":"foo",
8
"type":"string"
9
},
10
{
11
"name":"bar",
12
"type":"double"
13
},
14
{
15
"name":"baz",
16
"type":"boolean"
17
}
18
]
19
},
20
{
21
"name":"object2",
22
"type":"array",
23
"fields":[
24
"double"
25
]
26
},
27
{
28
"name":"object3",
29
"type":"array",
30
"fields":[
31
"string"
32
]
33
},
34
{
35
"name":"object4",
36
"type":"array",
37
"fields":[
38
{
39
"name":"nested_obj_1",
40
"type":"object",
41
"fields":[
42
{
43
"name":"foo",
44
"type":"string"
45
}
46
]
47
}
48
]
49
}
50
]
Copied!
Schema inference rules
- 1.Do not change types for existing keys
- 1.You can always add new keys or omit keys from your events but you cannot replace existing keys - this will cause a schema conflict. For example, if your event had a key called
foothat was aString, do not send another event which hasfooas anInteger.
- 2.Field names that use non-alphanumeric characters will be transformed to the format
_UTFHEXCODE_when stored in parquet- 1.We need to do this as Hive does not support non-alphanumeric characters for column names.
- 3.Field names that use uppercase characters will be automatically updated to lowercase when stored in parquet.
- 1.We need to do this as Hive columns are case-insensitive.
Best practices
Follow these best practices to ensure that your data lookups and replays remain fast and easy to work with.
- 1.Use a common event envelope
- 1.By doing this, you will prevent possible future key and type collisions.
- 2.Use
snake_casefor JSON keys- 1.When generating the schema, every key is defined as a "column" in the schema with an associated type and while parquet is case-sensitive, Hive is not. This means that while having
fieldandFIELDat the same nest-level is OK in parquet, it is NOT okay in Hive - it will cause duplicate column errors. Due to this, Batch will automatically convert ALL keys to lowercase when storing in parquet for you but to avoid any strange behavior, we advise to try to present the data in an already good format.
- 3.Use alphanumeric characters for keys
- 1.Similar to the Hive issue with case-insensitivity, Hive is not able to deal with any non-alphanumeric characters for columns. Batch will automatically convert any non-supported characters to the equivalent unicode hex code - but again, it is best to present a data set which won't require any such behind-the-scenes transformations.
Last modified 6mo ago