[ 
https://issues.apache.org/jira/browse/FLINK-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255663#comment-17255663
 ] 

Sebastian Liu commented on FLINK-20416:
---------------------------------------

Hi [~lirui], thx a lot for your comments. I have started a discussion in our 
Flink dev mailing group, and replied & resolved some comments from design doc. 

For the wrapper of a delegate catalog, I thought that this approach might help 
our developers use the cache with minimizing changes to the existing catalog 
implementation. Certainly, providing a generic cache util would give us more 
flexible, even for scenarios other than catalog. But Guava's loadingCache 
already does a pretty good job. Or what do you think the cache utility of 
catalog should be and how to use in the current catalog api?  Looking forward 
for your suggestion or comments~

> Need a cached catalog for batch SQL job
> ---------------------------------------
>
>                 Key: FLINK-20416
>                 URL: https://issues.apache.org/jira/browse/FLINK-20416
>             Project: Flink
>          Issue Type: Improvement
>          Components: Connectors / Common, Connectors / Hive, Table SQL / API, 
> Table SQL / Planner
>            Reporter: Sebastian Liu
>            Priority: Major
>              Labels: pull-request-available
>
> For OLAP scenarios, There are usually some analytical queries which running 
> time is relatively short. These queries are also sensitive to latency. In the 
> current Blink sql processing, parse/validate/optimize stages are all need 
> meta data from catalog API. But each request to the catalog requires re-run 
> of the underlying meta query. 
>  
> We may need a cached catalog which can cache the table schema and statistic 
> info to avoid unnecessary repeated meta requests. 
> I have submitted a related PR for adding a genetic cached catalog, which can 
> delegate other implementations of {{AbstractCatalog. }}
> {{[https://github.com/apache/flink/pull/14260]}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to