Am going through the docs to run a service/instance and want to do some POC

The administrator for capitalone.com has disabled the ability to receive items from outside their domain. If those you're attempting to share with would like more information, they should contact their domain administrator directly.

oh, okay thanks @User

<!here> We created a new meetup group for Apache Pinot. https://www.meetup.com/apache-pinot/ Please sign up and share with your network.

As well as our official twitter account : https://twitter.com/ApachePinot

The twitter account is suspended and just unlocked, however all the followers are cleared. So please re-follow this account for news and updates.

I would like to configure Pinot locally /Azure. The documentation available doesn't provide necessary steps. It would be helpful if some one can guide us on the same we are planning to use Pinot in our existing project and would like to test all the use cases

Are you running kubernetes on Azure?

You can have multiple

independent

tables each of which consumes from a topic each

<!here>: hey everyone! experimenting with Pinot. anyone have a quick definition for the difference between dimensions fields and metrics fields? it looks like metric fields are almost always `INT`s and the

STRING

columns are almost always dimension fields. could someone explain the difference, or link me to a doc? thanks!

metrics and dimensions can be of any data type

i found this: https://support.google.com/datastudio/answer/6402048?hl=en but i’m not sure if it’s applicable to Pinot

metrics mostly are of INT, LONG, DOUBLE, (BYTES in special cases like tdigest/HLL)

@User: thanks! i think i understand that, i just don’t understand how the choice of metric vs. dimension affects storage or query capabilities

Metrics are mainly for aggregation purpose, and cannot be type STRING

Dimensions are mainly for slice and dice (in filter clause and group by clause)

Dimensions are usually not of type BYTES

thanks, @User!

looking at the sample baseball stats schema,

yearID

is a dimension

Dimensions can be both single-valued or multi-valued, while metrics can only be single-valued

ah, ok

so if it needs to be aggregated, go with metrics. otherwise, dimension

Internally, we use the same way to compress the data, so with the same config, they will have the same performance and storage

You are correct, for example,

memberId

should be a dimension, while

revenue

or

price

which are used for aggregation should be metrics

i think that makes sense…

yearID

is an

INT

dimension because we’d want to slice and dice (filter/group by), but it would be silly to aggregate the year field

do you need any metrics at all? i.e., can you have a dimension-only table?

yes, you can have dimension-only table but you can only run count(*) on that table

For certain cases, yes. For example, you only need to

COUNT

for different slice and dice

We support aggregation on dimensions, but some optimizations will differentiate dimensions and metrics

E.g. pre-aggregation will only happen on metrics if configured