Apache Pinot Daily Email Digest (2020-06-23)

[Pinot Slack Email Digest <sn...@apache.org>]

<h3><u>#general</u></h3><br><strong>@tmmwangioo3: </strong>Hi all, is there a way to rename a column name in Pinot? Avro provides a way to alias a field and I was wondering if that is translated to Pinot column names(dimension columns) in some way at both write and read time.<br><strong>@tmmwangioo3: </strong>```// Sample avro schema with an aliased field
record Foo {
  string @aliases(["old_bar"]) bar;

  // Other fields
}```<br><h3><u>#troubleshooting</u></h3><br><strong>@elon.azoulay: </strong>We noticed that the kubernetes chart for the server has a readiness probe. The server goes into a crash loop because it cannot receive traffic: localhost:8097/health - doesn't even work when running curl on the pod. When the readiness probe is removed the server starts up and the curl works.<br><strong>@elon.azoulay: </strong>Is the readiness probe necessary? I was able to reproduce this behavior 2x<br><strong>@elon.azoulay: </strong>(in staging of course :slightly_smiling_face: )<br><strong>@g.kishore: </strong>What is this with latest version?<br><strong>@g.kishore: </strong>@laxman also faced the same issue<br><strong>@elon.azoulay: </strong>With 0.3.0<br><strong>@elon.azoulay: </strong>We will be upgrading in a few days<br><strong>@g.kishore: </strong>Hmm 0.3.0 worked fine<br><strong>@elon.azoulay: </strong>It works fine without the readiness probe<br><strong>@elon.azoulay: </strong>Strange, if readiness probe is enabled even local traffic is not permitted, i.e. curl localhost:8097/health fails<br><strong>@fx19880617: </strong>hmm, so this endpoint is not working even if you execute `curl localhost:8097/health` inside a pinot server container?<br><strong>@elon.azoulay: </strong>Yep, but when I remove the readiness probe (and keep the liveness probe) it works<br><strong>@elon.azoulay: </strong>i.e. curl from `kubectl exec -it pinot-server bash` works without readiness probe only<br><strong>@fx19880617: </strong>hmmm<br><strong>@fx19880617: </strong>let me also check<br><h3><u>#presto-pinot-streaming</u></h3><br><strong>@elon.azoulay: </strong>@jackie.jxt, qq - should I pass in the QueryScheduler, ResourceManager, etc. from the ServerInstance? Was implementing a modified QueryExecutor to run the query, and something like the CombineOperator but it emits a DataTable to the response stream every n rows.<br><strong>@jackie.jxt: </strong>@elon.azoulay I think you should directly use QueryExecutor on the gRPC server side<br><strong>@jackie.jxt: </strong>The current QueryScheduler cannot handle streaming result<br><strong>@elon.azoulay: </strong>Yep, so I was going to extend the interface<br><strong>@jackie.jxt: </strong>And I think gRPC can provide load balancing<br><strong>@elon.azoulay: </strong>Sounds good, thanks!<br><strong>@elon.azoulay: </strong>So I'm doing something very similar to the query executor, just not returning anything, instead it's emitting to the output stream<br><strong>@jackie.jxt: </strong>If we find that gRPC is not good enough, we can extend QueryScheduler then<br><strong>@jackie.jxt: </strong>I think the QueryExecutor should return a stub where you can keep fetching data blocks<br><strong>@jackie.jxt: </strong>Or pass in a callback maybe?<br><strong>@elon.azoulay: </strong>It can already do that on the client side. I'll get this together and push it, thanks!<br>