Versions Compared

Old Version 27

changes.mady.by.user Hoon Park

Saved on

compared with

New Version Current

changes.mady.by.user Hoon Park

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Current State: [UNDER DISCUSSION]

Discussion Thread: [...] https://lists.apache.org/thread.html/6f638139bb77019a649ec7034783a650e1f558ef75acc1dda991d573@%3Cdev.zeppelin.apache.org%3E

JIRA: ZEPPELIN-2019


2. Motivation

Apache Zeppelin provides valuable features for table manipulations such as built-in visualizations, pivoting and CSV download. However, these features are limited from the table size perspective. Currently, they are executed on the browser side and the table size is limited (configurable and 1000 rows by default). Thus moving these computations from in-browser to backend will be a starting point for handling large data and improving pivoting, filtering, full CSV download, pagination, and other functionalities.

 Furthermore, the tables across interpreter processes currently can’t be shared. For example, table from JDBC interpreter wouldn’t be accessible from SparkSQL or Python interpreters. So the idea here is to extend existing Zeppelin ResourcePool to resource pool to share Table resources across interpreters. It would allow also to have one central Table menu to access and view table information of registered Table resources.

Thus the critical question is “How Zeppelin can support large data handling and share across interpreters?”
Here are already resolved issues and they can be clues to solving the problem. 

...

Based on above work, this proposal aims to build a mechanism for handling table resource in backend and design API for ResourcePool. This will bring Zeppelin to 

  • register the table result as a shared resource

  • list all available (registered) tables

  • preview tables including its meta information (e.g columns, types, ..)

  • download registered tables as CSV, and other formats.

  • pivoting / filtering in backend to transforming larger data

  • cross join tables in different interpreters (e.g Spark interpreter uses a table result generated from JDBC interpreter)

 

For more future work tasks, please refer the 7. Potential Future Work section

...

  1. A newly created table result can be registered as a Resource in an interpreter.

  2. Since every resource registered in a resource pool in an interpreter can be searched via DisbitrubedResourcePool and supports remote method invocation, other interpreters can use it.

  3. Let’s say JDBCInterpreter created a table result and keep it (JDBCTableData) into its resource pool.

  4. Then, SparkInterpreter can fetch rows, columns via remote method invocation. if Zeppelin registers the distributed resource pool as Spark Data Source, SparkInterpreter can use all table resources in Zeppelin smoothly.
    (e.g Querying the table in SparkSQL as like a normal table)

...

Here are is a more detailed view to explain how one interpreter can handle its TableData implementation with the resource pool.

...

4. Public Interfaces

4.1. Interfaces for TableData related classes

TableData interface defines methods to handle a table resource. Each interpreter can implement its own TableData. The reason why we can’t make the global TableData class for all interpreters is that each interpreter uses a different storage and a different mechanism to export/import data.

...

Each interpreter can implement its own TableData class. For example,

  • SparkInterpreter can have SparkTableData which

    • points RDD to get the table result

    • filter and pivot can be written by using Spark RDD APIs

  • JDBCInterpreter can have JDBCTableData which

    • keeps query to reproduce the table result

    • filter and pivot can be written using a query that has additional where and group by statements groupby statements.

Some interpreters (e.g ShellInterpreter) might not be connected with external storage. In this case, those interpreters can use the InterpreterResultTableData class.

4.2. Example Implementation: ZeppelinResourcePool as Spark Data Source

(image copied from from https://databricks.com/blog/2015/01/09/spark-sql-data-sources-api-unified-data-access-for-the-spark-platform.html)

 

Spark supports pluggable data sources. We can use make Zeppelin’s DistributedResourcePool a spark data source using Spark DataSource API. Please refer these articles for more information.

 

4.2.1. BaseRelation Implementation

...


4.3. ResourceRegistry Class

ResourceRegistry class manages a list of available resources (e.g. tables). Thus it should provide the following functionalities:

...

4.4. ResourcePoolRestAPI Class

ResourcePoolRestAPI class provides APIs to access resources to end-users. Thus it should provide the following functionalities:

...

5.1. How can a user decide to create TableData instance for sharing the resource?

  • For interpreters which use SQL

    • provide an interpreter option: create TableData whenever executing a paragraph

    • or provide new interpreter magic for it: %spark.sql_share, %jdbc.mysql_share, …

    • or automatically put all table results into the resource pool if they are not heavy (e.g keeping query only, or just reference for RDD)

    • If interpreter supports runtime interpreterparameters, we can use this syntax: %jdbc(share=true) to specify whether share the  table result or not

  • For interpreters which use programming language (e.g python)

    • provide API like z.put()

      Code Block
      languagescala
      linenumberstrue
      // infer instance type and convert it to predefined the `TableData` subclass such as `SparkDataFrameTableData`
z.put (“myTable01”, myDataFrame01)

// or force user to put the `TableData` subclass
val myTableData01 = new SparkRDDTableData(myRdd01)
z.put(“myTable01”, myTableData01)

       

  • For interpreters which use DSL (e.g ElasticsearchInterpreter)

    • provide an interpreter option: create TableData whenever executing a paragraph

    • or provide new interpreter magic for it: %elasticserach_share

    • or automatically put all table results into the resource pool if they are not heavy

...

  • For interpreters which use SQL

    • Keep the query to reproduce table result later

    • Or create a view in the storage using the requested query

  • For interpreters which use programming language

    • Keep reference/info to RDD, Data Frame, or other variables in REPL

  • For interpreters which use DSL (e.g ElasticsearchInterpreter)

    • TBD

5.3. What should the table name be?

  • If a note has a title can be part of the table name. For example, (e.g Note Title + Paragraph Id + Result Index)

  • when using API like z.put(resourceName, …), use the passed resource name

...

The issues we discussed above can be implemented in this sequence.the following order of priority

  • ZEPPELIN-TBD: Adding pivot, filter methods to TableData

  • ZEPPELIN-TBD: ResourceRegistry

  • ZEPPELIN-TBD: Rest API for resource pool

  • ZEPPELIN-TBD: UI for Table page

  • ZEPPELIN-TBD: Apply pivot, filter methods for built-in visualizations

  • ZEPPELIN-TBD: SparkTableData, SparkSQLTableData, JDBCTableData, etc.

  • ZEPPELINZEPPELN-2029: ACL for ResourcePool

  • ZEPPELIN-2022: Zeppelin resource pool as a Spark DataSourceData Source

7. Potential Future Work

  • Watch / Unwatch: for automatic paragraph updating for Streaming Data Representation.

  • ZEPPELIN-1494: Bind JDBC result to a dataset on the Zeppelin context

  • Ability to construct table result from the resource pool in language interpreters (e.g python)

    • Let’s assume that we can build a pandas data frame using TableData

      Code Block
      languagepy
      linenumberstrue
      # in python interpreter

t = z.get("tableResourceName") # will return object that has `hasNext` and `next`
p = new PandasTableData(t)

# use p.pandasInstance …
    ZEPPELIN-1494: Bind JDBC result to a dataset on the Zeppelin context