You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@carbondata.apache.org by ch...@apache.org on 2018/09/07 15:53:46 UTC
[1/4] carbondata git commit: [CARBONDATA-2915] Reformat Documentation
of CarbonData
Repository: carbondata
Updated Branches:
refs/heads/master 3894e1d05 -> 6e50c1c6f
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/streaming-guide.md
----------------------------------------------------------------------
diff --git a/docs/streaming-guide.md b/docs/streaming-guide.md
index 32d24dc..3b71662 100644
--- a/docs/streaming-guide.md
+++ b/docs/streaming-guide.md
@@ -7,7 +7,7 @@
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -17,6 +17,24 @@
# CarbonData Streaming Ingestion
+- [Streaming Table Management](#quick-example)
+ - [Create table with streaming property](#create-table-with-streaming-property)
+ - [Alter streaming property](#alter-streaming-property)
+ - [Acquire streaming lock](#acquire-streaming-lock)
+ - [Create streaming segment](#create-streaming-segment)
+ - [Change Stream segment status](#change-segment-status)
+ - [Handoff "streaming finish" segment to columnar segment](#handoff-streaming-finish-segment-to-columnar-segment)
+ - [Auto handoff streaming segment](#auto-handoff-streaming-segment)
+ - [Stream data parser](#stream-data-parser)
+ - [Close streaming table](#close-streaming-table)
+ - [Constraints](#constraint)
+- [StreamSQL](#streamsql)
+ - [Defining Streaming Table](#streaming-table)
+ - [Streaming Job Management](#streaming-job-management)
+ - [START STREAM](#start-stream)
+ - [STOP STREAM](#stop-stream)
+ - [SHOW STREAMS](#show-streams)
+
## Quick example
Download and unzip spark-2.2.0-bin-hadoop2.7.tgz, and export $SPARK_HOME
@@ -68,7 +86,7 @@ Start spark-shell in new terminal, type :paste, then copy and run the following
| col1 INT,
| col2 STRING
| )
- | STORED BY 'carbondata'
+ | STORED AS carbondata
| TBLPROPERTIES('streaming'='true')""".stripMargin)
val carbonTable = CarbonEnv.getCarbonTable(Some("default"), "carbon_table")(spark)
@@ -116,19 +134,19 @@ streaming table using following DDL.
col1 INT,
col2 STRING
)
- STORED BY 'carbondata'
+ STORED AS carbondata
TBLPROPERTIES('streaming'='true')
```
property name | default | description
---|---|---
streaming | false |Whether to enable streaming ingest feature for this table <br /> Value range: true, false
-
+
"DESC FORMATTED" command will show streaming property.
```sql
DESC FORMATTED streaming_table
```
-
+
## Alter streaming property
For an old table, use ALTER TABLE command to set the streaming property.
```sql
@@ -259,3 +277,147 @@ ALTER TABLE streaming_table COMPACT 'close_streaming'
5. if the table has dictionary columns, it will not support concurrent data loading.
6. block delete "streaming" segment while the streaming ingestion is running.
7. block drop the streaming table while the streaming ingestion is running.
+
+
+
+## StreamSQL
+
+
+
+### Streaming Table
+
+**Example**
+
+Following example shows how to start a streaming ingest job
+
+```
+ sql(
+ s"""
+ |CREATE TABLE source(
+ | id INT,
+ | name STRING,
+ | city STRING,
+ | salary FLOAT,
+ | tax DECIMAL(8,2),
+ | percent double,
+ | birthday DATE,
+ | register TIMESTAMP,
+ | updated TIMESTAMP
+ |)
+ |STORED BY carbondata
+ |TBLPROPERTIES (
+ | 'format'='csv',
+ | 'path'='$csvDataDir'
+ |)
+ """.stripMargin)
+
+ sql(
+ s"""
+ |CREATE TABLE sink(
+ | id INT,
+ | name STRING,
+ | city STRING,
+ | salary FLOAT,
+ | tax DECIMAL(8,2),
+ | percent double,
+ | birthday DATE,
+ | register TIMESTAMP,
+ | updated TIMESTAMP
+ |)
+ |STORED BY carbondata
+ |TBLPROPERTIES (
+ | 'streaming'='true'
+ |)
+ """.stripMargin)
+
+ sql(
+ """
+ |START STREAM job123 ON TABLE sink
+ |STMPROPERTIES(
+ | 'trigger'='ProcessingTime',
+ | 'interval'='1 seconds')
+ |AS
+ | SELECT *
+ | FROM source
+ | WHERE id % 2 = 1
+ """.stripMargin)
+
+ sql("STOP STREAM job123")
+
+ sql("SHOW STREAMS [ON TABLE tableName]")
+```
+
+
+
+In above example, two table is created: source and sink. The `source` table's format is `csv` and `sink` table format is `carbon`. Then a streaming job is created to stream data from source table to sink table.
+
+These two tables are normal carbon table, they can be queried independently.
+
+
+
+### Streaming Job Management
+
+As above example shown:
+
+- `START STREAM jobName ON TABLE tableName` is used to start a streaming ingest job.
+- `STOP STREAM jobName` is used to stop a streaming job by its name
+- `SHOW STREAMS [ON TABLE tableName]` is used to print streaming job information
+
+
+
+##### START STREAM
+
+When this is issued, carbon will start a structured streaming job to do the streaming ingestion. Before launching the job, system will validate:
+
+- The format of table specified in CTAS FROM clause must be one of: csv, json, text, parquet, kafka, socket. These are formats supported by spark 2.2.0 structured streaming
+
+- User should pass the options of the streaming source table in its TBLPROPERTIES when creating it. StreamSQL will pass them transparently to spark when creating the streaming job. For example:
+
+ ```SQL
+ CREATE TABLE source(
+ name STRING,
+ age INT
+ )
+ STORED BY carbondata
+ TBLPROPERTIES(
+ 'format'='socket',
+ 'host'='localhost',
+ 'port'='8888'
+ )
+ ```
+
+ will translate to
+
+ ```Scala
+ spark.readStream
+ .schema(tableSchema)
+ .format("socket")
+ .option("host", "localhost")
+ .option("port", "8888")
+ ```
+
+
+
+- The sink table should have a TBLPROPERTY `'streaming'` equal to `true`, indicating it is a streaming table.
+- In the given STMPROPERTIES, user must specify `'trigger'`, its value must be `ProcessingTime` (In future, other value will be supported). User should also specify interval value for the streaming job.
+- If the schema specifid in sink table is different from CTAS, the streaming job will fail
+
+
+
+##### STOP STREAM
+
+When this is issued, the streaming job will be stopped immediately. It will fail if the jobName specified is not exist.
+
+
+
+##### SHOW STREAMS
+
+`SHOW STREAMS ON TABLE tableName` command will print the streaming job information as following
+
+| Job name | status | Source | Sink | start time | time elapsed |
+| -------- | ------- | ------ | ---- | ------------------- | ------------ |
+| job123 | Started | device | fact | 2018-02-03 14:32:42 | 10d2h32m |
+
+`SHOW STREAMS` command will show all stream jobs in the system.
+
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/supported-data-types-in-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/supported-data-types-in-carbondata.md b/docs/supported-data-types-in-carbondata.md
index eb74a2e..fee80f6 100644
--- a/docs/supported-data-types-in-carbondata.md
+++ b/docs/supported-data-types-in-carbondata.md
@@ -36,7 +36,7 @@
* VARCHAR
**NOTE**: For string longer than 32000 characters, use `LONG_STRING_COLUMNS` in table property.
- Please refer to TBLProperties in [CreateTable](https://github.com/apache/carbondata/blob/master/docs/data-management-on-carbondata.md#create-table) for more information.
+ Please refer to TBLProperties in [CreateTable](./ddl-of-carbondata.md#create-table) for more information.
* Complex Types
* arrays: ARRAY``<data_type>``
@@ -45,4 +45,5 @@
**NOTE**: Only 2 level complex type schema is supported for now.
* Other Types
- * BOOLEAN
\ No newline at end of file
+ * BOOLEAN
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/troubleshooting.md
----------------------------------------------------------------------
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
deleted file mode 100644
index 0156121..0000000
--- a/docs/troubleshooting.md
+++ /dev/null
@@ -1,267 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to you under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Troubleshooting
-This tutorial is designed to provide troubleshooting for end users and developers
-who are building, deploying, and using CarbonData.
-
-## When loading data, gets tablestatus.lock issues:
-
- **Symptom**
-```
-17/11/11 16:48:13 ERROR LocalFileLock: main hdfs:/localhost:9000/carbon/store/default/hdfstable/tablestatus.lock (No such file or directory)
-java.io.FileNotFoundException: hdfs:/localhost:9000/carbon/store/default/hdfstable/tablestatus.lock (No such file or directory)
- at java.io.FileOutputStream.open0(Native Method)
- at java.io.FileOutputStream.open(FileOutputStream.java:270)
- at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
- at java.io.FileOutputStream.<init>(FileOutputStream.java:101)
-```
-
- **Possible Cause**
- If you use `<hdfs path>` as store path when creating carbonsession, may get the errors,because the default is LOCALLOCK.
-
- **Procedure**
- Before creating carbonsession, sets as below:
- ```
- import org.apache.carbondata.core.util.CarbonProperties
- import org.apache.carbondata.core.constants.CarbonCommonConstants
- CarbonProperties.getInstance().addProperty(CarbonCommonConstants.LOCK_TYPE, "HDFSLOCK")
- ```
-
-## Failed to load thrift libraries
-
- **Symptom**
-
- Thrift throws following exception :
-
- ```
- thrift: error while loading shared libraries:
- libthriftc.so.0: cannot open shared object file: No such file or directory
- ```
-
- **Possible Cause**
-
- The complete path to the directory containing the libraries is not configured correctly.
-
- **Procedure**
-
- Follow the Apache thrift docs at [https://thrift.apache.org/docs/install](https://thrift.apache.org/docs/install) to install thrift correctly.
-
-## Failed to launch the Spark Shell
-
- **Symptom**
-
- The shell prompts the following error :
-
- ```
- org.apache.spark.sql.CarbonContext$$anon$$apache$spark$sql$catalyst$analysis
- $OverrideCatalog$_setter_$org$apache$spark$sql$catalyst$analysis
- $OverrideCatalog$$overrides_$e
- ```
-
- **Possible Cause**
-
- The Spark Version and the selected Spark Profile do not match.
-
- **Procedure**
-
- 1. Ensure your spark version and selected profile for spark are correct.
-
- 2. Use the following command :
-
-```
-"mvn -Pspark-2.1 -Dspark.version {yourSparkVersion} clean package"
-```
-Note : Refrain from using "mvn clean package" without specifying the profile.
-
-## Failed to execute load query on cluster.
-
- **Symptom**
-
- Load query failed with the following exception:
-
- ```
- Dictionary file is locked for updation.
- ```
-
- **Possible Cause**
-
- The carbon.properties file is not identical in all the nodes of the cluster.
-
- **Procedure**
-
- Follow the steps to ensure the carbon.properties file is consistent across all the nodes:
-
- 1. Copy the carbon.properties file from the master node to all the other nodes in the cluster.
- For example, you can use ssh to copy this file to all the nodes.
-
- 2. For the changes to take effect, restart the Spark cluster.
-
-## Failed to execute insert query on cluster.
-
- **Symptom**
-
- Load query failed with the following exception:
-
- ```
- Dictionary file is locked for updation.
- ```
-
- **Possible Cause**
-
- The carbon.properties file is not identical in all the nodes of the cluster.
-
- **Procedure**
-
- Follow the steps to ensure the carbon.properties file is consistent across all the nodes:
-
- 1. Copy the carbon.properties file from the master node to all the other nodes in the cluster.
- For example, you can use scp to copy this file to all the nodes.
-
- 2. For the changes to take effect, restart the Spark cluster.
-
-## Failed to connect to hiveuser with thrift
-
- **Symptom**
-
- We get the following exception :
-
- ```
- Cannot connect to hiveuser.
- ```
-
- **Possible Cause**
-
- The external process does not have permission to access.
-
- **Procedure**
-
- Ensure that the Hiveuser in mysql must allow its access to the external processes.
-
-## Failed to read the metastore db during table creation.
-
- **Symptom**
-
- We get the following exception on trying to connect :
-
- ```
- Cannot read the metastore db
- ```
-
- **Possible Cause**
-
- The metastore db is dysfunctional.
-
- **Procedure**
-
- Remove the metastore db from the carbon.metastore in the Spark Directory.
-
-## Failed to load data on the cluster
-
- **Symptom**
-
- Data loading fails with the following exception :
-
- ```
- Data Load failure exception
- ```
-
- **Possible Cause**
-
- The following issue can cause the failure :
-
- 1. The core-site.xml, hive-site.xml, yarn-site and carbon.properties are not consistent across all nodes of the cluster.
-
- 2. Path to hdfs ddl is not configured correctly in the carbon.properties.
-
- **Procedure**
-
- Follow the steps to ensure the following configuration files are consistent across all the nodes:
-
- 1. Copy the core-site.xml, hive-site.xml, yarn-site,carbon.properties files from the master node to all the other nodes in the cluster.
- For example, you can use scp to copy this file to all the nodes.
-
- Note : Set the path to hdfs ddl in carbon.properties in the master node.
-
- 2. For the changes to take effect, restart the Spark cluster.
-
-
-
-## Failed to insert data on the cluster
-
- **Symptom**
-
- Insertion fails with the following exception :
-
- ```
- Data Load failure exception
- ```
-
- **Possible Cause**
-
- The following issue can cause the failure :
-
- 1. The core-site.xml, hive-site.xml, yarn-site and carbon.properties are not consistent across all nodes of the cluster.
-
- 2. Path to hdfs ddl is not configured correctly in the carbon.properties.
-
- **Procedure**
-
- Follow the steps to ensure the following configuration files are consistent across all the nodes:
-
- 1. Copy the core-site.xml, hive-site.xml, yarn-site,carbon.properties files from the master node to all the other nodes in the cluster.
- For example, you can use scp to copy this file to all the nodes.
-
- Note : Set the path to hdfs ddl in carbon.properties in the master node.
-
- 2. For the changes to take effect, restart the Spark cluster.
-
-## Failed to execute Concurrent Operations(Load,Insert,Update) on table by multiple workers.
-
- **Symptom**
-
- Execution fails with the following exception :
-
- ```
- Table is locked for updation.
- ```
-
- **Possible Cause**
-
- Concurrency not supported.
-
- **Procedure**
-
- Worker must wait for the query execution to complete and the table to release the lock for another query execution to succeed.
-
-## Failed to create a table with a single numeric column.
-
- **Symptom**
-
- Execution fails with the following exception :
-
- ```
- Table creation fails.
- ```
-
- **Possible Cause**
-
- Behaviour not supported.
-
- **Procedure**
-
- A single column that can be considered as dimension is mandatory for table creation.
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/usecases.md
----------------------------------------------------------------------
diff --git a/docs/usecases.md b/docs/usecases.md
new file mode 100644
index 0000000..277c455
--- /dev/null
+++ b/docs/usecases.md
@@ -0,0 +1,215 @@
+# Use Cases
+
+CarbonData is useful in various analytical work loads.Some of the most typical usecases where CarbonData is being used is documented here.
+
+CarbonData is used for but not limited to
+
+- ### Bank
+
+ - fraud detection analysis
+ - risk profile analysis
+ - As a zip table to update the daily balance of customers
+
+- ### Telecom
+
+ - Detection of signal anamolies for VIP customers for providing improved customer experience
+ - Analysis of MR,CHR records of GSM data to determine the tower load at a particular time period and rebalance the tower configuration
+ - Analysis of access sites, video, screen size, streaming bandwidth, quality to determine the network quality,routing configuration
+
+- ### Web/Internet
+
+ - Analysis of page or video being accessed,server loads, streaming quality, screen size
+
+- ### Smart City
+
+ - Vehicle tracking analysis
+ - Unusual behaviour analysis
+
+
+
+These use cases can be broadly classified into below categories:
+
+- Full scan/Detailed/Interactive queries
+- Aggregation/OLAP BI queries
+- Real time Ingestion(Streaming) and queries
+
+
+
+## Detailed Queries in the Telecom scenario
+
+### Scenario
+
+User wants to analyse all the CHR(Call History Record) and MR(Measurement Records) of the mobile subscribers in order to identify the service failures within 10 secs.Also user wants to run machine learning models on the data to fairly estimate the reasons and time of probable failures and take action ahead to meet the SLA(Service Level Agreements) of VIP customers.
+
+### Challenges
+
+- Data incoming rate might vary based on the user concentration at a particular period of time.Hence higher data load speeds are required
+- Cluster needs to be well utilised and share the cluster among various applications for better resource consumption and savings
+- Queries needs to be interactive.ie., the queries fetch small data and need to be returned in seconds
+- Data Loaded into the system every few minutes.
+
+### Solution
+
+Setup a Hadoop + Spark + CarbonData cluster managed by YARN.
+
+Proposed the following configurations for CarbonData.(These tunings were proposed before CarbonData introduced SORT_COLUMNS parameter using which the sort order and schema order could be different.)
+
+Add the frequently used columns to the left of the table definition.Add it in the increasing order of cardinality.It was suggested to keep msisdn,imsi columns in the beginning of the schema.With latest CarbonData, SORT_COLUMNS needs to be configured msisdn,imsi in the beginning.
+
+Add timestamp column to the right of the schema as it is naturally increasing.
+
+Create two separate YARN queues for Query and Data Loading.
+
+Apart from these, the following CarbonData configuration was suggested to be configured in the cluster.
+
+
+
+| Configuration for | Parameter | Value | Description |
+|------------------ | --------------------------------------- | ------ | ----------- |
+| Data Loading | carbon.graph.rowset.size | 100000 | Based on the size of each row, this determines the memory required during data loading.Higher value leads to increased memory foot print |
+| Data Loading | carbon.number.of.cores.while.loading | 12 | More cores can improve data loading speed |
+| Data Loading | carbon.sort.size | 100000 | Number of records to sort at a time.More number of records configured will lead to increased memory foot print |
+| Data Loading | table_blocksize | 256 | To efficiently schedule multiple tasks during query |
+| Data Loading | carbon.sort.intermediate.files.limit | 100 | Increased to 100 as number of cores are more.Can perform merging in backgorund.If less number of files to merge, sort threads would be idle |
+| Data Loading | carbon.use.local.dir | TRUE | yarn application directory will be usually on a single disk.YARN would be configured with multiple disks to be used as temp or to assign randomly to applications.Using the yarn temp directory will allow carbon to use multiple disks and improve IO performance |
+| Data Loading | carbon.use.multiple.temp.dir | TRUE | multiple disks to write sort files will lead to better IO and reduce the IO bottleneck |
+| Compaction | carbon.compaction.level.threshold | 6,6 | Since frequent small loads, compacting more segments will give better query results |
+| Compaction | carbon.enable.auto.load.merge | true | Since data loading is small,auto compacting keeps the number of segments less and also compaction can complete in time |
+| Compaction | carbon.number.of.cores.while.compacting | 4 | Higher number of cores can improve the compaction speed |
+| Compaction | carbon.major.compaction.size | 921600 | Sum of several loads to combine into single segment |
+
+
+
+### Results Achieved
+
+| Parameter | Results |
+| ----------------------------------------- | ---------------- |
+| Query | < 3 Sec |
+| Data Loading Speed | 40 MB/s Per Node |
+| Concurrent query performance (20 queries) | < 10 Sec |
+
+
+
+## Detailed Queries in the Smart City scenario
+
+### Scenario
+
+User wants to analyse the person/vehicle movement and behavior during a certain time period.This output data needs to be joined with a external table for Human details extraction.The query will be run with different time period as filter to identify potential behavior mismatch.
+
+### Challenges
+
+Data generated per day is very huge.Data needs to be loaded multiple times per day to accomodate the incoming data size.
+
+Data Loading done once in 6 hours.
+
+### Solution
+
+Setup a Hadoop + Spark + CarbonData cluster managed by YARN.
+
+Since data needs to be queried for a time period, it was recommended to keep the time column at the beginning of schema.
+
+Use table block size as 512MB.
+
+Use local sort mode.
+
+Apart from these, the following CarbonData configuration was suggested to be configured in the cluster.
+
+Use all columns are no-dictionary as the cardinality is high.
+
+| Configuration for | Parameter | Value | Description |
+| ------------------| --------------------------------------- | ----------------------- | ------------------|
+| Data Loading | carbon.graph.rowset.size | 100000 | Based on the size of each row, this determines the memory required during data loading.Higher value leads to increased memory foot print |
+| Data Loading | enable.unsafe.sort | TRUE | Temporary data generated during sort is huge which causes GC bottlenecks.Using unsafe reduces the pressure on GC |
+| Data Loading | enable.offheap.sort | TRUE | Temporary data generated during sort is huge which causes GC bottlenecks.Using offheap reduces the pressure on GC.offheap can be accessed through java unsafe.hence enable.unsafe.sort needs to be true |
+| Data Loading | offheap.sort.chunk.size.in.mb | 128 | Size of memory to allocate for sorting.Can increase this based on the memory available |
+| Data Loading | carbon.number.of.cores.while.loading | 12 | Higher cores can improve data loading speed |
+| Data Loading | carbon.sort.size | 100000 | Number of records to sort at a time.More number of records configured will lead to increased memory foot print |
+| Data Loading | table_blocksize | 512 | To efficiently schedule multiple tasks during query.This size depends on data scenario.If data is such that the filters would select less number of blocklets to scan, keeping higher number works well.If the number blocklets to scan is more, better to reduce the size as more tasks can be scheduled in parallel. |
+| Data Loading | carbon.sort.intermediate.files.limit | 100 | Increased to 100 as number of cores are more.Can perform merging in backgorund.If less number of files to merge, sort threads would be idle |
+| Data Loading | carbon.use.local.dir | TRUE | yarn application directory will be usually on a single disk.YARN would be configured with multiple disks to be used as temp or to assign randomly to applications.Using the yarn temp directory will allow carbon to use multiple disks and improve IO performance |
+| Data Loading | carbon.use.multiple.temp.dir | TRUE | multiple disks to write sort files will lead to better IO and reduce the IO bottleneck |
+| Data Loading | sort.inmemory.size.in.mb | 92160 | Memory allocated to do inmemory sorting.When more memory is available in the node, configuring this will retain more sort blocks in memory so that the merge sort is faster due to no/very less IO |
+| Compaction | carbon.major.compaction.size | 921600 | Sum of several loads to combine into single segment |
+| Compaction | carbon.number.of.cores.while.compacting | 12 | Higher number of cores can improve the compaction speed.Data size is huge.Compaction need to use more threads to speed up the process |
+| Compaction | carbon.enable.auto.load.merge | FALSE | Doing auto minor compaction is costly process as data size is huge.Perform manual compaction when the cluster is less loaded |
+| Query | carbon.enable.vector.reader | true | To fetch results faster, supporting spark vector processing will speed up the query |
+| Query | enable.unsafe.in.query.procressing | true | Data that needs to be scanned in huge which in turn generates more short lived Java objects.This cause pressure of GC.using unsafe and offheap will reduce the GC overhead |
+| Query | use.offheap.in.query.processing | true | Data that needs to be scanned in huge which in turn generates more short lived Java objects.This cause pressure of GC.using unsafe and offheap will reduce the GC overhead.offheap can be accessed through java unsafe.hence enable.unsafe.in.query.procressing needs to be true |
+| Query | enable.unsafe.columnpage | TRUE | Keep the column pages in offheap memory so that the memory overhead due to java object is less and also reduces GC pressure. |
+| Query | carbon.unsafe.working.memory.in.mb | 10240 | Amount of memory to use for offheap operations.Can increase this memory based on the data size |
+
+
+
+### Results Achieved
+
+| Parameter | Results |
+| -------------------------------------- | ---------------- |
+| Query (Time Period spanning 1 segment) | < 10 Sec |
+| Data Loading Speed | 45 MB/s Per Node |
+
+
+
+## OLAP/BI Queries in the web/Internet scenario
+
+### Scenario
+
+An Internet company wants to analyze the average download speed, kind of handsets used in a particular region/area,kind of Apps being used, what kind of videos are trending in a particular region to enable them to identify the appropriate resolution size of videos to speed up transfer, and perform many more analysis to serve th customers better.
+
+### Challenges
+
+Since data is being queried by a BI tool, all the queries contain group by, which means CarbonData need to return more records as limit cannot be pushed down to carbondata layer.
+
+Results have to be returned faster as the BI tool would not respond till the data is fetched, causing bad user experience.
+
+Data might be loaded less frequently(once or twice in a day), but raw data size is huge, which causes the group by queries to run slower.
+
+Concurrent queries can be more due to the BI dashboard
+
+### Goal
+
+1. Aggregation queries are faster
+2. Concurrency is high(Number of concurrent queries supported)
+
+### Solution
+
+- Use table block size as 128MB so that pruning is more effective
+- Use global sort mode so that the data to be fetched are grouped together
+- Create pre-aggregate tables for non timestamp based group by queries
+- For queries containing group by date, create timeseries based Datamap(pre-aggregate) tables so that the data is rolled up during creation and fetch is faster
+- Reduce the Spark shuffle partitions.(In our configuration on 14 node cluster, it was reduced to 35 from default of 200)
+- Enable global dictionary for columns which have less cardinalities.Aggregation can be done on encoded data, there by improving the performance
+- For columns whose cardinality is high,enable the local dictionary so that store size is less and can take dictionary benefit for scan
+
+## Handling near realtime data ingestion scenario
+
+### Scenario
+
+Need to support storing of continously arriving data and make it available immediately for query.
+
+### Challenges
+
+When the data ingestion is near real time and the data needs to be available for query immediately, usual scenario is to do data loading in micro batches.But this causes the problem of generating many small files.This poses two problems:
+
+1. Small file handling in HDFS is inefficient
+2. CarbonData will suffer in query performance as all the small files will have to be queried when filter is on non time column
+
+CarbonData will suffer in query performance as all the small files will have to be queried when filter is on non time column.
+
+Since data is continouly arriving, allocating resources for compaction might not be feasible.
+
+### Goal
+
+1. Data is available in near real time for query as it arrives
+2. CarbonData doesnt suffer from small files problem
+
+### Solution
+
+- Use Streaming tables support of CarbonData
+- Configure the carbon.streaming.segment.max.size property to higher value(default is 1GB) if a bit slower query performance is not a concern
+- Configure carbon.streaming.auto.handoff.enabled to true so that after the carbon.streaming.segment.max.size is reached, the segment is converted into format optimized for query
+- Disable auto compaction.Manually trigger the minor compaction with default 4,3 when the cluster is not busy
+- Manually trigger Major compaction based on the size of segments and the frequency with which the segments are being created
+- Enable local dictionary
+
+
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/useful-tips-on-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/useful-tips-on-carbondata.md b/docs/useful-tips-on-carbondata.md
deleted file mode 100644
index 5b543d6..0000000
--- a/docs/useful-tips-on-carbondata.md
+++ /dev/null
@@ -1,177 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to you under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Useful Tips
- This tutorial guides you to create CarbonData Tables and optimize performance.
- The following sections will elaborate on the below topics :
-
- * [Suggestions to create CarbonData Table](#suggestions-to-create-carbondata-table)
- * [Configuration for Optimizing Data Loading performance for Massive Data](#configuration-for-optimizing-data-loading-performance-for-massive-data)
- * [Optimizing Mass Data Loading](#configurations-for-optimizing-carbondata-performance)
-
-## Suggestions to Create CarbonData Table
-
- For example, the results of the analysis for table creation with dimensions ranging from 10 thousand to 10 billion rows and 100 to 300 columns have been summarized below.
- The following table describes some of the columns from the table used.
-
- - **Table Column Description**
-
-| Column Name | Data Type | Cardinality | Attribution |
-|-------------|---------------|-------------|-------------|
-| msisdn | String | 30 million | Dimension |
-| BEGIN_TIME | BigInt | 10 Thousand | Dimension |
-| HOST | String | 1 million | Dimension |
-| Dime_1 | String | 1 Thousand | Dimension |
-| counter_1 | Decimal | NA | Measure |
-| counter_2 | Numeric(20,0) | NA | Measure |
-| ... | ... | NA | Measure |
-| counter_100 | Decimal | NA | Measure |
-
-
- - **Put the frequently-used column filter in the beginning of SORT_COLUMNS**
-
- For example, MSISDN filter is used in most of the query then we must put the MSISDN as the first column in SORT_COLUMNS property.
- The create table command can be modified as suggested below :
-
- ```
- create table carbondata_table(
- msisdn String,
- BEGIN_TIME bigint,
- HOST String,
- Dime_1 String,
- counter_1, Decimal
- ...
-
- )STORED BY 'carbondata'
- TBLPROPERTIES ('SORT_COLUMNS'='msisdn, Dime_1')
- ```
-
- Now the query with MSISDN in the filter will be more efficient.
-
- - **Put the frequently-used columns in the order of low to high cardinality in SORT_COLUMNS**
-
- If the table in the specified query has multiple columns which are frequently used to filter the results, it is suggested to put
- the columns in the order of cardinality low to high in SORT_COLUMNS configuration. This ordering of frequently used columns improves the compression ratio and
- enhances the performance of queries with filter on these columns.
-
- For example, if MSISDN, HOST and Dime_1 are frequently-used columns, then the column order of table is suggested as
- Dime_1>HOST>MSISDN, because Dime_1 has the lowest cardinality.
- The create table command can be modified as suggested below :
-
- ```
- create table carbondata_table(
- msisdn String,
- BEGIN_TIME bigint,
- HOST String,
- Dime_1 String,
- counter_1, Decimal
- ...
-
- )STORED BY 'carbondata'
- TBLPROPERTIES ('SORT_COLUMNS'='Dime_1, HOST, MSISDN')
- ```
-
- - **For measure type columns with non high accuracy, replace Numeric(20,0) data type with Double data type**
-
- For columns of measure type, not requiring high accuracy, it is suggested to replace Numeric data type with Double to enhance query performance.
- The create table command can be modified as below :
-
-```
- create table carbondata_table(
- Dime_1 String,
- BEGIN_TIME bigint,
- END_TIME bigint,
- HOST String,
- MSISDN String,
- counter_1 decimal,
- counter_2 double,
- ...
- )STORED BY 'carbondata'
- TBLPROPERTIES ('SORT_COLUMNS'='Dime_1, HOST, MSISDN')
-```
- The result of performance analysis of test-case shows reduction in query execution time from 15 to 3 seconds, thereby improving performance by nearly 5 times.
-
- - **Columns of incremental character should be re-arranged at the end of dimensions**
-
- Consider the following scenario where data is loaded each day and the begin_time is incremental for each load, it is suggested to put begin_time at the end of dimensions.
- Incremental values are efficient in using min/max index. The create table command can be modified as below :
-
- ```
- create table carbondata_table(
- Dime_1 String,
- HOST String,
- MSISDN String,
- counter_1 double,
- counter_2 double,
- BEGIN_TIME bigint,
- END_TIME bigint,
- ...
- counter_100 double
- )STORED BY 'carbondata'
- TBLPROPERTIES ('SORT_COLUMNS'='Dime_1, HOST, MSISDN')
- ```
-
- **NOTE:**
- + BloomFilter can be created to enhance performance for queries with precise equal/in conditions. You can find more information about it in BloomFilter datamap [document](https://github.com/apache/carbondata/blob/master/docs/datamap/bloomfilter-datamap-guide.md).
-
-
-## Configuration for Optimizing Data Loading performance for Massive Data
-
-
- CarbonData supports large data load, in this process sorting data while loading consumes a lot of memory and disk IO and
- this can result sometimes in "Out Of Memory" exception.
- If you do not have much memory to use, then you may prefer to slow the speed of data loading instead of data load failure.
- You can configure CarbonData by tuning following properties in carbon.properties file to get a better performance.
-
-| Parameter | Default Value | Description/Tuning |
-|-----------|-------------|--------|
-|carbon.number.of.cores.while.loading|Default: 2.This value should be >= 2|Specifies the number of cores used for data processing during data loading in CarbonData. |
-|carbon.sort.size|Default: 100000. The value should be >= 100.|Threshold to write local file in sort step when loading data|
-|carbon.sort.file.write.buffer.size|Default: 50000.|DataOutputStream buffer. |
-|carbon.merge.sort.reader.thread|Default: 3 |Specifies the number of cores used for temp file merging during data loading in CarbonData.|
-|carbon.merge.sort.prefetch|Default: true | You may want set this value to false if you have not enough memory|
-
- For example, if there are 10 million records, and i have only 16 cores, 64GB memory, will be loaded to CarbonData table.
- Using the default configuration always fail in sort step. Modify carbon.properties as suggested below:
-
- ```
- carbon.merge.sort.reader.thread=1
- carbon.sort.size=5000
- carbon.sort.file.write.buffer.size=5000
- carbon.merge.sort.prefetch=false
- ```
-
-## Configurations for Optimizing CarbonData Performance
-
- Recently we did some performance POC on CarbonData for Finance and telecommunication Field. It involved detailed queries and aggregation
- scenarios. After the completion of POC, some of the configurations impacting the performance have been identified and tabulated below :
-
-| Parameter | Location | Used For | Description | Tuning |
-|----------------------------------------------|-----------------------------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| carbon.sort.intermediate.files.limit | spark/carbonlib/carbon.properties | Data loading | During the loading of data, local temp is used to sort the data. This number specifies the minimum number of intermediate files after which the merge sort has to be initiated. | Increasing the parameter to a higher value will improve the load performance. For example, when we increase the value from 20 to 100, it increases the data load performance from 35MB/S to more than 50MB/S. Higher values of this parameter consumes more memory during the load. |
-| carbon.number.of.cores.while.loading | spark/carbonlib/carbon.properties | Data loading | Specifies the number of cores used for data processing during data loading in CarbonData. | If you have more number of CPUs, then you can increase the number of CPUs, which will increase the performance. For example if we increase the value from 2 to 4 then the CSV reading performance can increase about 1 times |
-| carbon.compaction.level.threshold | spark/carbonlib/carbon.properties | Data loading and Querying | For minor compaction, specifies the number of segments to be merged in stage 1 and number of compacted segments to be merged in stage 2. | Each CarbonData load will create one segment, if every load is small in size it will generate many small file over a period of time impacting the query performance. Configuring this parameter will merge the small segment to one big segment which will sort the data and improve the performance. For Example in one telecommunication scenario, the performance improves about 2 times after minor compaction. |
-| spark.sql.shuffle.partitions | spark/conf/spark-defaults.conf | Querying | The number of task started when spark shuffle. | The value can be 1 to 2 times as much as the executor cores. In an aggregation scenario, reducing the number from 200 to 32 reduced the query time from 17 to 9 seconds. |
-| spark.executor.instances/spark.executor.cores/spark.executor.memory | spark/conf/spark-defaults.conf | Querying | The number of executors, CPU cores, and memory used for CarbonData query. | In the bank scenario, we provide the 4 CPUs cores and 15 GB for each executor which can get good performance. This 2 value does not mean more the better. It needs to be configured properly in case of limited resources. For example, In the bank scenario, it has enough CPU 32 cores each node but less memory 64 GB each node. So we cannot give more CPU but less memory. For example, when 4 cores and 12GB for each executor. It sometimes happens GC during the query which impact the query performance very much from the 3 second to more than 15 seconds. In this scenario need to increase the memory or decrease the CPU cores. |
-| carbon.detail.batch.size | spark/carbonlib/carbon.properties | Data loading | The buffer size to store records, returned from the block scan. | In limit scenario this parameter is very important. For example your query limit is 1000. But if we set this value to 3000 that means we get 3000 records from scan but spark will only take 1000 rows. So the 2000 remaining are useless. In one Finance test case after we set it to 100, in the limit 1000 scenario the performance increase about 2 times in comparison to if we set this value to 12000. |
-| carbon.use.local.dir | spark/carbonlib/carbon.properties | Data loading | Whether use YARN local directories for multi-table load disk load balance | If this is set it to true CarbonData will use YARN local directories for multi-table load disk load balance, that will improve the data load performance. |
-| carbon.use.multiple.temp.dir | spark/carbonlib/carbon.properties | Data loading | Whether to use multiple YARN local directories during table data loading for disk load balance | After enabling 'carbon.use.local.dir', if this is set to true, CarbonData will use all YARN local directories during data load for disk load balance, that will improve the data load performance. Please enable this property when you encounter disk hotspot problem during data loading. |
-| carbon.sort.temp.compressor | spark/carbonlib/carbon.properties | Data loading | Specify the name of compressor to compress the intermediate sort temporary files during sort procedure in data loading. | The optional values are 'SNAPPY','GZIP','BZIP2','LZ4','ZSTD' and empty. By default, empty means that Carbondata will not compress the sort temp files. This parameter will be useful if you encounter disk bottleneck. |
-| carbon.load.skewedDataOptimization.enabled | spark/carbonlib/carbon.properties | Data loading | Whether to enable size based block allocation strategy for data loading. | When loading, carbondata will use file size based block allocation strategy for task distribution. It will make sure that all the executors process the same size of data -- It's useful if the size of your input data files varies widely, say 1MB~1GB. |
-| carbon.load.min.size.enabled | spark/carbonlib/carbon.properties | Data loading | Whether to enable node minumun input data size allocation strategy for data loading.| When loading, carbondata will use node minumun input data size allocation strategy for task distribution. It will make sure the node load the minimum amount of data -- It's useful if the size of your input data files very small, say 1MB~256MB,Avoid generating a large number of small files. |
-
- Note: If your CarbonData instance is provided only for query, you may specify the property 'spark.speculation=true' which is in conf directory of spark.
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/integration/hive/hive-guide.md
----------------------------------------------------------------------
diff --git a/integration/hive/hive-guide.md b/integration/hive/hive-guide.md
deleted file mode 100644
index c38a539..0000000
--- a/integration/hive/hive-guide.md
+++ /dev/null
@@ -1,100 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to you under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Quick Start
-This tutorial provides a quick introduction to using current integration/hive module.
-
-## Build (In 1.2.0, hive integration only support spark2.1 and hadoop2.7.2)
-mvn -DskipTests -Pspark-2.1 -Phadoop-2.7.2 clean package
-
-## Prepare CarbonData in Spark
-* Create a sample.csv file using the following commands. The CSV file is required for loading data into CarbonData.
-
- ```
- cd carbondata
- cat > sample.csv << EOF
- id,name,scale,country,salary
- 1,yuhai,1.77,china,33000.1
- 2,runlin,1.70,china,33000.2
- EOF
- ```
-
-* copy data to HDFS
-
-```
-$HADOOP_HOME/bin/hadoop fs -put sample.csv <hdfs store path>/sample.csv
-```
-
-* Add the following params to $SPARK_CONF_DIR/conf/hive-site.xml
-```xml
-<property>
- <name>hive.metastore.pre.event.listeners</name>
- <value>org.apache.carbondata.hive.CarbonHiveMetastoreListener</value>
-</property>
-```
-* Start Spark shell by running the following command in the Spark directory
-
-```
-./bin/spark-shell --jars <carbondata assembly jar path, carbon hive jar path>
-```
-
-```
-import org.apache.spark.sql.SparkSession
-import org.apache.spark.sql.CarbonSession._
-val rootPath = "hdfs:////user/hadoop/carbon"
-val storeLocation = s"$rootPath/store"
-val warehouse = s"$rootPath/warehouse"
-val metastoredb = s"$rootPath/metastore_db"
-
-val carbon = SparkSession.builder().enableHiveSupport().config("spark.sql.warehouse.dir", warehouse).config(org.apache.carbondata.core.constants.CarbonCommonConstants.STORE_LOCATION, storeLocation).getOrCreateCarbonSession(storeLocation, metastoredb)
-
-carbon.sql("create table hive_carbon(id int, name string, scale decimal, country string, salary double) STORED BY 'carbondata'")
-carbon.sql("LOAD DATA INPATH '<hdfs store path>/sample.csv' INTO TABLE hive_carbon")
-scala>carbon.sql("SELECT * FROM hive_carbon").show()
-```
-
-## Query Data in Hive
-### Configure hive classpath
-```
-mkdir hive/auxlibs/
-cp carbondata/assembly/target/scala-2.11/carbondata_2.11*.jar hive/auxlibs/
-cp carbondata/integration/hive/target/carbondata-hive-*.jar hive/auxlibs/
-cp $SPARK_HOME/jars/spark-catalyst*.jar hive/auxlibs/
-cp $SPARK_HOME/jars/scala*.jar hive/auxlibs/
-export HIVE_AUX_JARS_PATH=hive/auxlibs/
-```
-### Fix snappy issue
-```
-copy snappy-java-xxx.jar from "./<SPARK_HOME>/jars/" to "./Library/Java/Extensions"
-export HADOOP_OPTS="-Dorg.xerial.snappy.lib.path=/Library/Java/Extensions -Dorg.xerial.snappy.lib.name=libsnappyjava.jnilib -Dorg.xerial.snappy.tempdir=/Users/apple/DEMO/tmp"
-```
-
-### Start hive client
-$HIVE_HOME/bin/hive
-
-### Query data from hive table
-
-```
-set hive.mapred.supports.subdirectories=true;
-set mapreduce.input.fileinputformat.input.dir.recursive=true;
-
-select * from hive_carbon;
-select count(*) from hive_carbon;
-select * from hive_carbon order by id;
-```
-
-
[3/4] carbondata git commit: [CARBONDATA-2915] Reformat Documentation
of CarbonData
Posted by ch...@apache.org.
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/datamap/datamap-management.md
----------------------------------------------------------------------
diff --git a/docs/datamap/datamap-management.md b/docs/datamap/datamap-management.md
index b5d1aaa..eee03a7 100644
--- a/docs/datamap/datamap-management.md
+++ b/docs/datamap/datamap-management.md
@@ -7,7 +7,7 @@
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -17,6 +17,18 @@
# CarbonData DataMap Management
+- [Overview](#overview)
+- [DataMap Management](#datamap-management)
+- [Automatic Refresh](#automatic-refresh)
+- [Manual Refresh](#manual-refresh)
+- [DataMap Catalog](#datamap-catalog)
+- [DataMap Related Commands](#datamap-related-commands)
+ - [Explain](#explain)
+ - [Show DataMap](#show-datamap)
+ - [Compaction on DataMap](#compaction-on-datamap)
+
+
+
## Overview
DataMap can be created using following DDL
@@ -36,7 +48,7 @@ Currently, there are 5 DataMap implementations in CarbonData.
| DataMap Provider | Description | DMPROPERTIES | Management |
| ---------------- | ---------------------------------------- | ---------------------------------------- | ---------------- |
| preaggregate | single table pre-aggregate table | No DMPROPERTY is required | Automatic |
-| timeseries | time dimension rollup table | event_time, xx_granularity, please refer to [Timeseries DataMap](https://github.com/apache/carbondata/blob/master/docs/datamap/timeseries-datamap-guide.md) | Automatic |
+| timeseries | time dimension rollup table | event_time, xx_granularity, please refer to [Timeseries DataMap](./timeseries-datamap-guide.md) | Automatic |
| mv | multi-table pre-aggregate table | No DMPROPERTY is required | Manual |
| lucene | lucene indexing for text column | index_columns to specifying the index columns | Automatic |
| bloomfilter | bloom filter for high cardinality column, geospatial column | index_columns to specifying the index columns | Automatic |
@@ -49,7 +61,6 @@ There are two kinds of management semantic for DataMap.
2. Manual Refresh: Create datamap with `WITH DEFERRED REBUILD` in the statement
**CAUTION:**
-Manual refresh currently only works fine for MV, it has some bugs with other types of datamap in Carbondata 1.4.1, so we block this option for them in this version.
If user create MV datamap without specifying `WITH DEFERRED REBUILD`, carbondata will give a warning and treat the datamap as deferred rebuild.
### Automatic Refresh
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/datamap/lucene-datamap-guide.md
----------------------------------------------------------------------
diff --git a/docs/datamap/lucene-datamap-guide.md b/docs/datamap/lucene-datamap-guide.md
index 06cd194..86b00e2 100644
--- a/docs/datamap/lucene-datamap-guide.md
+++ b/docs/datamap/lucene-datamap-guide.md
@@ -59,7 +59,7 @@ It will show all DataMaps created on main table.
age int,
city string,
country string)
- STORED BY 'carbondata'
+ STORED AS carbondata
```
User can create Lucene datamap using the Create DataMap DDL:
@@ -149,7 +149,7 @@ select * from datamap_test where TEXT_MATCH('name:*n*')
select * from datamap_test where TEXT_MATCH('name:*10 -name:*n*')
```
-**Note:** For lucene queries and syntax, refer to [lucene-syntax](www.lucenetutorial.com/lucene-query-syntax.html)
+**Note:** For lucene queries and syntax, refer to [lucene-syntax](http://www.lucenetutorial.com/lucene-query-syntax.html)
## Data Management with lucene datamap
Once there is lucene datamap is created on the main table, following command on the main
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/datamap/preaggregate-datamap-guide.md
----------------------------------------------------------------------
diff --git a/docs/datamap/preaggregate-datamap-guide.md b/docs/datamap/preaggregate-datamap-guide.md
index ff4c28e..3a3efc2 100644
--- a/docs/datamap/preaggregate-datamap-guide.md
+++ b/docs/datamap/preaggregate-datamap-guide.md
@@ -64,7 +64,7 @@ Start spark-shell in new terminal, type :paste, then copy and run the following
| country string,
| quantity int,
| price bigint)
- | STORED BY 'carbondata'
+ | STORED AS carbondata
""".stripMargin)
// Create pre-aggregate table on the main table
@@ -126,7 +126,7 @@ kinds of DataMap:
a. 'path' is used to specify the store location of the datamap.('path'='/location/').
b. 'partitioning' when set to false enables user to disable partitioning of the datamap.
Default value is true for this property.
-2. timeseries, for timeseries roll-up table. Please refer to [Timeseries DataMap](https://github.com/apache/carbondata/blob/master/docs/datamap/timeseries-datamap-guide.md)
+2. timeseries, for timeseries roll-up table. Please refer to [Timeseries DataMap](./timeseries-datamap-guide.md)
DataMap can be dropped using following DDL
```
@@ -162,7 +162,7 @@ It will show all DataMaps created on main table.
country string,
quantity int,
price bigint)
- STORED BY 'carbondata'
+ STORED AS carbondata
```
User can create pre-aggregate tables using the Create DataMap DDL
@@ -270,4 +270,3 @@ release, user can do as following:
3. Create the pre-aggregate table again by `CREATE DATAMAP` command
Basically, user can manually trigger the operation by re-building the datamap.
-
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/datamap/timeseries-datamap-guide.md
----------------------------------------------------------------------
diff --git a/docs/datamap/timeseries-datamap-guide.md b/docs/datamap/timeseries-datamap-guide.md
index 135188d..3f849c4 100644
--- a/docs/datamap/timeseries-datamap-guide.md
+++ b/docs/datamap/timeseries-datamap-guide.md
@@ -17,23 +17,24 @@
# CarbonData Timeseries DataMap
-* [Timeseries DataMap Introduction](#timeseries-datamap-intoduction)
-* [Compaction](#compacting-pre-aggregate-tables)
-* [Data Management](#data-management-with-pre-aggregate-tables)
+* [Timeseries DataMap Introduction](#timeseries-datamap-introduction-alpha-feature)
+* [Compaction](#compacting-timeseries-datamp)
+* [Data Management](#data-management-on-timeseries-datamap)
## Timeseries DataMap Introduction (Alpha Feature)
-Timeseries DataMap a pre-aggregate table implementation based on 'pre-aggregate' DataMap.
+Timeseries DataMap is a pre-aggregate table implementation based on 'pre-aggregate' DataMap.
Difference is that Timeseries DataMap has built-in understanding of time hierarchy and
levels: year, month, day, hour, minute, so that it supports automatic roll-up in time dimension
for query.
+**CAUTION:** Current version of CarbonData does not support roll-up.It will be implemented in future versions.
+
The data loading, querying, compaction command and its behavior is the same as preaggregate DataMap.
-Please refer to [Pre-aggregate DataMap](https://github.com/apache/carbondata/blob/master/docs/datamap/preaggregate-datamap-guide.md)
+Please refer to [Pre-aggregate DataMap](./preaggregate-datamap-guide.md)
for more information.
To use this datamap, user can create multiple timeseries datamap on the main table which has
-a *event_time* column, one datamap for one time granularity. Then Carbondata can do automatic
-roll-up for queries on the main table.
+a *event_time* column, one datamap for one time granularity.
For example, below statement effectively create multiple pre-aggregate tables on main table called
**timeseries**
@@ -88,20 +89,10 @@ DMPROPERTIES (
) AS
SELECT order_time, country, sex, sum(quantity), max(quantity), count(user_id), sum(price),
avg(price) FROM sales GROUP BY order_time, country, sex
-
-CREATE DATAMAP agg_minute
-ON TABLE sales
-USING "timeseries"
-DMPROPERTIES (
- 'event_time'='order_time',
- 'minute_granularity'='1',
-) AS
-SELECT order_time, country, sex, sum(quantity), max(quantity), count(user_id), sum(price),
- avg(price) FROM sales GROUP BY order_time, country, sex
```
For querying timeseries data, Carbondata has builtin support for following time related UDF
-to enable automatically roll-up to the desired aggregation level
+
```
timeseries(timeseries column name, 'aggregation level')
```
@@ -111,7 +102,7 @@ SELECT timeseries(order_time, 'hour'), sum(quantity) FROM sales GROUP BY timeser
```
It is **not necessary** to create pre-aggregate tables for each granularity unless required for
-query. Carbondata can roll-up the data and fetch it.
+query.
For Example: For main table **sales** , if following timeseries datamaps were created for day
level and hour level pre-aggregate
@@ -138,7 +129,7 @@ level and hour level pre-aggregate
avg(price) FROM sales GROUP BY order_time, country, sex
```
-Queries like below will be rolled-up and hit the timeseries datamaps
+Queries like below will not be rolled-up and hit the main table
```
Select timeseries(order_time, 'month'), sum(quantity) from sales group by timeseries(order_time,
'month')
@@ -155,9 +146,10 @@ the future CarbonData release.
## Compacting timeseries datamp
-Refer to Compaction section in [preaggregation datamap](https://github.com/apache/carbondata/blob/master/docs/datamap/preaggregate-datamap-guide.md).
+Refer to Compaction section in [preaggregation datamap](./preaggregate-datamap-guide.md).
Same applies to timeseries datamap.
## Data Management on timeseries datamap
-Refer to Data Management section in [preaggregation datamap](https://github.com/apache/carbondata/blob/master/docs/datamap/preaggregate-datamap-guide.md).
-Same applies to timeseries datamap.
\ No newline at end of file
+Refer to Data Management section in [preaggregation datamap](./preaggregate-datamap-guide.md).
+Same applies to timeseries datamap.
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/ddl-of-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/ddl-of-carbondata.md b/docs/ddl-of-carbondata.md
new file mode 100644
index 0000000..acaac43
--- /dev/null
+++ b/docs/ddl-of-carbondata.md
@@ -0,0 +1,957 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# CarbonData Data Definition Language
+
+CarbonData DDL statements are documented here,which includes:
+
+* [CREATE TABLE](#create-table)
+ * [Dictionary Encoding](#dictionary-encoding-configuration)
+ * [Inverted Index](#inverted-index-configuration)
+ * [Sort Columns](#sort-columns-configuration)
+ * [Sort Scope](#sort-scope-configuration)
+ * [Table Block Size](#table-block-size-configuration)
+ * [Table Compaction](#table-compaction-configuration)
+ * [Streaming](#streaming)
+ * [Local Dictionary](#local-dictionary-configuration)
+ * [Caching Column Min/Max](#caching-minmax-value-for-required-columns)
+ * [Caching Level](#caching-at-block-or-blocklet-level)
+ * [Hive/Parquet folder Structure](#support-flat-folder-same-as-hiveparquet)
+ * [Extra Long String columns](#string-longer-than-32000-characters)
+* [CREATE TABLE AS SELECT](#create-table-as-select)
+* [CREATE EXTERNAL TABLE](#create-external-table)
+ * [External Table on Transactional table location](#create-external-table-on-managed-table-data-location)
+ * [External Table on non-transactional table location](#create-external-table-on-non-transactional-table-data-location)
+* [CREATE DATABASE](#create-database)
+* [TABLE MANAGEMENT](#table-management)
+ * [SHOW TABLE](#show-table)
+ * [ALTER TABLE](#alter-table)
+ * [RENAME TABLE](#rename-table)
+ * [ADD COLUMNS](#add-columns)
+ * [DROP COLUMNS](#drop-columns)
+ * [CHANGE DATA TYPE](#change-data-type)
+ * [MERGE INDEXES](#merge-index)
+ * [SET/UNSET Local Dictionary Properties](#set-and-unset-for-local-dictionary-properties)
+ * [DROP TABLE](#drop-table)
+ * [REFRESH TABLE](#refresh-table)
+ * [COMMENTS](#table-and-column-comment)
+* [PARTITION](#partition)
+ * [STANDARD PARTITION(HIVE)](#standard-partition)
+ * [INSERT OVERWRITE PARTITION](#insert-overwrite)
+ * [CARBONDATA PARTITION](#create-hash-partition-table)
+ * [HASH PARTITION](#create-hash-partition-table)
+ * [RANGE PARTITION](#create-range-partition-table)
+ * [LIST PARTITION](#create-list-partition-table)
+ * [SHOW PARTITIONS](#show-partitions)
+ * [ADD PARTITION](#add-a-new-partition)
+ * [SPLIT PARTITION](#split-a-partition)
+ * [DROP PARTITION](#drop-a-partition)
+* [BUCKETING](#bucketing)
+
+## CREATE TABLE
+
+ This command can be used to create a CarbonData table by specifying the list of fields along with the table properties. You can also specify the location where the table needs to be stored.
+
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name[(col_name data_type , ...)]
+ STORED AS carbondata
+ [TBLPROPERTIES (property_name=property_value, ...)]
+ [LOCATION 'path']
+ ```
+ **NOTE:** CarbonData also supports "STORED AS carbondata" and "USING carbondata". Find example code at [CarbonSessionExample](https://github.com/apache/carbondata/blob/master/examples/spark2/src/main/scala/org/apache/carbondata/examples/CarbonSessionExample.scala) in the CarbonData repo.
+### Usage Guidelines
+
+**Supported properties:**
+
+| Property | Description |
+| ------------------------------------------------------------ | ------------------------------------------------------------ |
+| [DICTIONARY_INCLUDE](#dictionary-encoding-configuration) | Columns for which dictionary needs to be generated |
+| [NO_INVERTED_INDEX](#inverted-index-configuration) | Columns to exclude from inverted index generation |
+| [SORT_COLUMNS](#sort-columns-configuration) | Columns to include in sort and its order of sort |
+| [SORT_SCOPE](#sort-scope-configuration) | Sort scope of the load.Options include no sort, local sort ,batch sort and global sort |
+| [TABLE_BLOCKSIZE](#table-block-size-configuration) | Size of blocks to write onto hdfs |
+| [MAJOR_COMPACTION_SIZE](#table-compaction-configuration) | Size upto which the segments can be combined into one |
+| [AUTO_LOAD_MERGE](#table-compaction-configuration) | Whether to auto compact the segments |
+| [COMPACTION_LEVEL_THRESHOLD](#table-compaction-configuration) | Number of segments to compact into one segment |
+| [COMPACTION_PRESERVE_SEGMENTS](#table-compaction-configuration) | Number of latest segments that needs to be excluded from compaction |
+| [ALLOWED_COMPACTION_DAYS](#table-compaction-configuration) | Segments generated within the configured time limit in days will be compacted, skipping others |
+| [streaming](#streaming) | Whether the table is a streaming table |
+| [LOCAL_DICTIONARY_ENABLE](#local-dictionary-configuration) | Enable local dictionary generation |
+| [LOCAL_DICTIONARY_THRESHOLD](#local-dictionary-configuration) | Cardinality upto which the local dictionary can be generated |
+| [LOCAL_DICTIONARY_INCLUDE](#local-dictionary-configuration) | Columns for which local dictionary needs to be generated.Useful when local dictionary need not be generated for all string/varchar/char columns |
+| [LOCAL_DICTIONARY_EXCLUDE](#local-dictionary-configuration) | Columns for which local dictionary generation should be skipped.Useful when local dictionary need not be generated for few string/varchar/char columns |
+| [COLUMN_META_CACHE](#caching-minmax-value-for-required-columns) | Columns whose metadata can be cached in Driver for efficient pruning and improved query performance |
+| [CACHE_LEVEL](#caching-at-block-or-blocklet-level) | Column metadata caching level.Whether to cache column metadata of block or blocklet |
+| [flat_folder](#support-flat-folder-same-as-hiveparquet) | Whether to write all the carbondata files in a single folder.Not writing segments folder during incremental load |
+| [LONG_STRING_COLUMNS](#string-longer-than-32000-characters) | Columns which are greater than 32K characters |
+| [BUCKETNUMBER](#bucketing) | Number of buckets to be created |
+| [BUCKETCOLUMNS](#bucketing) | Columns which are to be placed in buckets |
+
+ Following are the guidelines for TBLPROPERTIES, CarbonData's additional table options can be set via carbon.properties.
+
+ - ##### Dictionary Encoding Configuration
+
+ Dictionary encoding is turned off for all columns by default from 1.3 onwards, you can use this command for including or excluding columns to do dictionary encoding.
+ Suggested use cases : do dictionary encoding for low cardinality columns, it might help to improve data compression ratio and performance.
+
+ ```
+ TBLPROPERTIES ('DICTIONARY_INCLUDE'='column1, column2')
+ ```
+ NOTE: Dictionary Include/Exclude for complex child columns is not supported.
+
+ - ##### Inverted Index Configuration
+
+ By default inverted index is enabled, it might help to improve compression ratio and query speed, especially for low cardinality columns which are in reward position.
+ Suggested use cases : For high cardinality columns, you can disable the inverted index for improving the data loading performance.
+
+ ```
+ TBLPROPERTIES ('NO_INVERTED_INDEX'='column1, column3')
+ ```
+
+ - ##### Sort Columns Configuration
+
+ This property is for users to specify which columns belong to the MDK(Multi-Dimensions-Key) index.
+ * If users don't specify "SORT_COLUMN" property, by default MDK index be built by using all dimension columns except complex data type column.
+ * If this property is specified but with empty argument, then the table will be loaded without sort.
+ * This supports only string, date, timestamp, short, int, long, and boolean data types.
+ Suggested use cases : Only build MDK index for required columns,it might help to improve the data loading performance.
+
+ ```
+ TBLPROPERTIES ('SORT_COLUMNS'='column1, column3')
+ OR
+ TBLPROPERTIES ('SORT_COLUMNS'='')
+ ```
+ NOTE: Sort_Columns for Complex datatype columns is not supported.
+
+ - ##### Sort Scope Configuration
+
+ This property is for users to specify the scope of the sort during data load, following are the types of sort scope.
+
+ * LOCAL_SORT: It is the default sort scope.
+ * NO_SORT: It will load the data in unsorted manner, it will significantly increase load performance.
+ * BATCH_SORT: It increases the load performance but decreases the query performance if identified blocks > parallelism.
+ * GLOBAL_SORT: It increases the query performance, especially high concurrent point query.
+ And if you care about loading resources isolation strictly, because the system uses the spark GroupBy to sort data, the resource can be controlled by spark.
+
+ ### Example:
+
+ ```
+ CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
+ productNumber INT,
+ productName STRING,
+ storeCity STRING,
+ storeProvince STRING,
+ productCategory STRING,
+ productBatch STRING,
+ saleQuantity INT,
+ revenue INT)
+ STORED AS carbondata
+ TBLPROPERTIES ('SORT_COLUMNS'='productName,storeCity',
+ 'SORT_SCOPE'='NO_SORT')
+ ```
+
+ **NOTE:** CarbonData also supports "using carbondata". Find example code at [SparkSessionExample](https://github.com/apache/carbondata/blob/master/examples/spark2/src/main/scala/org/apache/carbondata/examples/SparkSessionExample.scala) in the CarbonData repo.
+
+ - ##### Table Block Size Configuration
+
+ This command is for setting block size of this table, the default value is 1024 MB and supports a range of 1 MB to 2048 MB.
+
+ ```
+ TBLPROPERTIES ('TABLE_BLOCKSIZE'='512')
+ ```
+ **NOTE:** 512 or 512M both are accepted.
+
+ - ##### Table Compaction Configuration
+
+ These properties are table level compaction configurations, if not specified, system level configurations in carbon.properties will be used.
+ Following are 5 configurations:
+
+ * MAJOR_COMPACTION_SIZE: same meaning as carbon.major.compaction.size, size in MB.
+ * AUTO_LOAD_MERGE: same meaning as carbon.enable.auto.load.merge.
+ * COMPACTION_LEVEL_THRESHOLD: same meaning as carbon.compaction.level.threshold.
+ * COMPACTION_PRESERVE_SEGMENTS: same meaning as carbon.numberof.preserve.segments.
+ * ALLOWED_COMPACTION_DAYS: same meaning as carbon.allowed.compaction.days.
+
+ ```
+ TBLPROPERTIES ('MAJOR_COMPACTION_SIZE'='2048',
+ 'AUTO_LOAD_MERGE'='true',
+ 'COMPACTION_LEVEL_THRESHOLD'='5,6',
+ 'COMPACTION_PRESERVE_SEGMENTS'='10',
+ 'ALLOWED_COMPACTION_DAYS'='5')
+ ```
+
+ - ##### Streaming
+
+ CarbonData supports streaming ingestion for real-time data. You can create the ‘streaming’ table using the following table properties.
+
+ ```
+ TBLPROPERTIES ('streaming'='true')
+ ```
+
+ - ##### Local Dictionary Configuration
+
+ Columns for which dictionary is not generated needs more storage space and in turn more IO. Also since more data will have to be read during query, query performance also would suffer.Generating dictionary per blocklet for such columns would help in saving storage space and assist in improving query performance as carbondata is optimized for handling dictionary encoded columns more effectively.Generating dictionary internally per blocklet is termed as local dictionary. Please refer to [File structure of Carbondata](./file-structure-of-carbondata.md) for understanding about the file structure of carbondata and meaning of terms like blocklet.
+
+ Local Dictionary helps in:
+ 1. Getting more compression.
+ 2. Filter queries and full scan queries will be faster as filter will be done on encoded data.
+ 3. Reducing the store size and memory footprint as only unique values will be stored as part of local dictionary and corresponding data will be stored as encoded data.
+ 4. Getting higher IO throughput.
+
+ **NOTE:**
+
+ * Following Data Types are Supported for Local Dictionary:
+ * STRING
+ * VARCHAR
+ * CHAR
+
+ * Following Data Types are not Supported for Local Dictionary:
+ * SMALLINT
+ * INTEGER
+ * BIGINT
+ * DOUBLE
+ * DECIMAL
+ * TIMESTAMP
+ * DATE
+ * BOOLEAN
+
+ * In case of multi-level complex dataType columns, primitive string/varchar/char columns are considered for local dictionary generation.
+
+ Local dictionary will have to be enabled explicitly during create table or by enabling the **system property** ***carbon.local.dictionary.enable***. By default, Local Dictionary will be disabled for the carbondata table.
+
+ Local Dictionary can be configured using the following properties during create table command:
+
+
+| Properties | Default value | Description |
+| ---------- | ------------- | ----------- |
+| LOCAL_DICTIONARY_ENABLE | false | Whether to enable local dictionary generation. **NOTE:** If this property is defined, it will override the value configured at system level by '***carbon.local.dictionary.enable***'.Local dictionary will be generated for all string/varchar/char columns unless LOCAL_DICTIONARY_INCLUDE, LOCAL_DICTIONARY_EXCLUDE is configured. |
+| LOCAL_DICTIONARY_THRESHOLD | 10000 | The maximum cardinality of a column upto which carbondata can try to generate local dictionary (maximum - 100000) |
+| LOCAL_DICTIONARY_INCLUDE | string/varchar/char columns| Columns for which Local Dictionary has to be generated.**NOTE:** Those string/varchar/char columns which are added into DICTIONARY_INCLUDE option will not be considered for local dictionary generation.This property needs to be configured only when local dictionary needs to be generated for few columns, skipping others.This property takes effect only when **LOCAL_DICTIONARY_ENABLE** is true or **carbon.local.dictionary.enable** is true |
+| LOCAL_DICTIONARY_EXCLUDE | none | Columns for which Local Dictionary need not be generated.This property needs to be configured only when local dictionary needs to be skipped for few columns, generating for others.This property takes effect only when **LOCAL_DICTIONARY_ENABLE** is true or **carbon.local.dictionary.enable** is true |
+
+ **Fallback behavior:**
+
+ * When the cardinality of a column exceeds the threshold, it triggers a fallback and the generated dictionary will be reverted and data loading will be continued without dictionary encoding.
+
+ **NOTE:** When fallback is triggered, the data loading performance will decrease as encoded data will be discarded and the actual data is written to the temporary sort files.
+
+ **Points to be noted:**
+
+ 1. Reduce Block size:
+
+ Number of Blocks generated is less in case of Local Dictionary as compression ratio is high. This may reduce the number of tasks launched during query, resulting in degradation of query performance if the pruned blocks are less compared to the number of parallel tasks which can be run. So it is recommended to configure smaller block size which in turn generates more number of blocks.
+
+ 2. All the page-level data for a blocklet needs to be maintained in memory until all the pages encoded for local dictionary is processed in order to handle fallback. Hence the memory required for local dictionary based table is more and this memory increase is proportional to number of columns.
+
+### Example:
+
+ ```
+ CREATE TABLE carbontable(
+
+ column1 string,
+
+ column2 string,
+
+ column3 LONG )
+
+ STORED AS carbondata
+ TBLPROPERTIES('LOCAL_DICTIONARY_ENABLE'='true','LOCAL_DICTIONARY_THRESHOLD'='1000',
+ 'LOCAL_DICTIONARY_INCLUDE'='column1','LOCAL_DICTIONARY_EXCLUDE'='column2')
+ ```
+
+ **NOTE:**
+
+ * We recommend to use Local Dictionary when cardinality is high but is distributed across multiple loads
+ * On a large cluster, decoding data can become a bottleneck for global dictionary as there will be many remote reads. In this scenario, it is better to use Local Dictionary.
+ * When cardinality is less, but loads are repetitive, it is better to use global dictionary as local dictionary generates multiple dictionary files at blocklet level increasing redundancy.
+
+ - ##### Caching Min/Max Value for Required Columns
+
+ By default, CarbonData caches min and max values of all the columns in schema. As the load increases, the memory required to hold the min and max values increases considerably. This feature enables you to configure min and max values only for the required columns, resulting in optimized memory usage.
+
+ Following are the valid values for COLUMN_META_CACHE:
+ * If you want no column min/max values to be cached in the driver.
+
+ ```
+ COLUMN_META_CACHE=’’
+ ```
+
+ * If you want only col1 min/max values to be cached in the driver.
+
+ ```
+ COLUMN_META_CACHE=’col1’
+ ```
+
+ * If you want min/max values to be cached in driver for all the specified columns.
+
+ ```
+ COLUMN_META_CACHE=’col1,col2,col3,…’
+ ```
+
+ Columns to be cached can be specified either while creating table or after creation of the table.
+ During create table operation; specify the columns to be cached in table properties.
+
+ Syntax:
+
+ ```
+ CREATE TABLE [dbName].tableName (col1 String, col2 String, col3 int,…) STORED BY ‘carbondata’ TBLPROPERTIES (‘COLUMN_META_CACHE’=’col1,col2,…’)
+ ```
+
+ Example:
+
+ ```
+ CREATE TABLE employee (name String, city String, id int) STORED BY ‘carbondata’ TBLPROPERTIES (‘COLUMN_META_CACHE’=’name’)
+ ```
+
+ After creation of table or on already created tables use the alter table command to configure the columns to be cached.
+
+ Syntax:
+
+ ```
+ ALTER TABLE [dbName].tableName SET TBLPROPERTIES (‘COLUMN_META_CACHE’=’col1,col2,…’)
+ ```
+
+ Example:
+
+ ```
+ ALTER TABLE employee SET TBLPROPERTIES (‘COLUMN_META_CACHE’=’city’)
+ ```
+
+ - ##### Caching at Block or Blocklet Level
+
+ This feature allows you to maintain the cache at Block level, resulting in optimized usage of the memory. The memory consumption is high if the Blocklet level caching is maintained as a Block can have multiple Blocklet.
+
+ Following are the valid values for CACHE_LEVEL:
+
+ *Configuration for caching in driver at Block level (default value).*
+
+ ```
+ CACHE_LEVEL= ‘BLOCK’
+ ```
+
+ *Configuration for caching in driver at Blocklet level.*
+
+ ```
+ CACHE_LEVEL= ‘BLOCKLET’
+ ```
+
+ Cache level can be specified either while creating table or after creation of the table.
+ During create table operation specify the cache level in table properties.
+
+ Syntax:
+
+ ```
+ CREATE TABLE [dbName].tableName (col1 String, col2 String, col3 int,…) STORED BY ‘carbondata’ TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
+ ```
+
+ Example:
+
+ ```
+ CREATE TABLE employee (name String, city String, id int) STORED BY ‘carbondata’ TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
+ ```
+
+ After creation of table or on already created tables use the alter table command to configure the cache level.
+
+ Syntax:
+
+ ```
+ ALTER TABLE [dbName].tableName SET TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
+ ```
+
+ Example:
+
+ ```
+ ALTER TABLE employee SET TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
+ ```
+
+ - ##### Support Flat folder same as Hive/Parquet
+
+ This feature allows all carbondata and index files to keep directy under tablepath. Currently all carbondata/carbonindex files written under tablepath/Fact/Part0/Segment_NUM folder and it is not same as hive/parquet folder structure. This feature makes all files written will be directly under tablepath, it does not maintain any segment folder structure.This is useful for interoperability between the execution engines and plugin with other execution engines like hive or presto becomes easier.
+
+ Following table property enables this feature and default value is false.
+ ```
+ 'flat_folder'='true'
+ ```
+ Example:
+ ```
+ CREATE TABLE employee (name String, city String, id int) STORED BY ‘carbondata’ TBLPROPERTIES ('flat_folder'='true')
+ ```
+
+ - ##### String longer than 32000 characters
+
+ In common scenarios, the length of string is less than 32000,
+ so carbondata stores the length of content using Short to reduce memory and space consumption.
+ To support string longer than 32000 characters, carbondata introduces a table property called `LONG_STRING_COLUMNS`.
+ For these columns, carbondata internally stores the length of content using Integer.
+
+ You can specify the columns as 'long string column' using below tblProperties:
+
+ ```
+ // specify col1, col2 as long string columns
+ TBLPROPERTIES ('LONG_STRING_COLUMNS'='col1,col2')
+ ```
+
+ Besides, you can also use this property through DataFrame by
+ ```
+ df.format("carbondata")
+ .option("tableName", "carbonTable")
+ .option("long_string_columns", "col1, col2")
+ .save()
+ ```
+
+ If you are using Carbon-SDK, you can specify the datatype of long string column as `varchar`.
+ You can refer to SDKwriterTestCase for example.
+
+ **NOTE:** The LONG_STRING_COLUMNS can only be string/char/varchar columns and cannot be dictionary_include/sort_columns/complex columns.
+
+## CREATE TABLE AS SELECT
+ This function allows user to create a Carbon table from any of the Parquet/Hive/Carbon table. This is beneficial when the user wants to create Carbon table from any other Parquet/Hive table and use the Carbon query engine to query and achieve better query results for cases where Carbon is faster than other file formats. Also this feature can be used for backing up the data.
+
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
+ STORED AS carbondata
+ [TBLPROPERTIES (key1=val1, key2=val2, ...)]
+ AS select_statement;
+ ```
+
+### Examples
+ ```
+ carbon.sql("CREATE TABLE source_table(
+ id INT,
+ name STRING,
+ city STRING,
+ age INT)
+ STORED AS parquet")
+ carbon.sql("INSERT INTO source_table SELECT 1,'bob','shenzhen',27")
+ carbon.sql("INSERT INTO source_table SELECT 2,'david','shenzhen',31")
+
+ carbon.sql("CREATE TABLE target_table
+ STORED AS carbondata
+ AS SELECT city,avg(age) FROM source_table GROUP BY city")
+
+ carbon.sql("SELECT * FROM target_table").show
+ // results:
+ // +--------+--------+
+ // | city|avg(age)|
+ // +--------+--------+
+ // |shenzhen| 29.0|
+ // +--------+--------+
+
+ ```
+
+## CREATE EXTERNAL TABLE
+ This function allows user to create external table by specifying location.
+ ```
+ CREATE EXTERNAL TABLE [IF NOT EXISTS] [db_name.]table_name
+ STORED AS carbondata LOCATION ‘$FilesPath’
+ ```
+
+### Create external table on managed table data location.
+ Managed table data location provided will have both FACT and Metadata folder.
+ This data can be generated by creating a normal carbon table and use this path as $FilesPath in the above syntax.
+
+ **Example:**
+ ```
+ sql("CREATE TABLE origin(key INT, value STRING) STORED AS carbondata")
+ sql("INSERT INTO origin select 100,'spark'")
+ sql("INSERT INTO origin select 200,'hive'")
+ // creates a table in $storeLocation/origin
+
+ sql(s"""
+ |CREATE EXTERNAL TABLE source
+ |STORED AS carbondata
+ |LOCATION '$storeLocation/origin'
+ """.stripMargin)
+ checkAnswer(sql("SELECT count(*) from source"), sql("SELECT count(*) from origin"))
+ ```
+
+### Create external table on Non-Transactional table data location.
+ Non-Transactional table data location will have only carbondata and carbonindex files, there will not be a metadata folder (table status and schema).
+ Our SDK module currently support writing data in this format.
+
+ **Example:**
+ ```
+ sql(
+ s"""CREATE EXTERNAL TABLE sdkOutputTable STORED AS carbondata LOCATION
+ |'$writerPath' """.stripMargin)
+ ```
+
+ Here writer path will have carbondata and index files.
+ This can be SDK output. Refer [SDK Guide](./sdk-guide.md).
+
+ **Note:**
+ 1. Dropping of the external table should not delete the files present in the location.
+ 2. When external table is created on non-transactional table data,
+ external table will be registered with the schema of carbondata files.
+ If multiple files with different schema is present, exception will be thrown.
+ So, If table registered with one schema and files are of different schema,
+ suggest to drop the external table and create again to register table with new schema.
+
+
+## CREATE DATABASE
+ This function creates a new database. By default the database is created in Carbon store location, but you can also specify custom location.
+ ```
+ CREATE DATABASE [IF NOT EXISTS] database_name [LOCATION path];
+ ```
+
+### Example
+ ```
+ CREATE DATABASE carbon LOCATION “hdfs://name_cluster/dir1/carbonstore”;
+ ```
+
+## TABLE MANAGEMENT
+
+### SHOW TABLE
+
+ This command can be used to list all the tables in current database or all the tables of a specific database.
+ ```
+ SHOW TABLES [IN db_Name]
+ ```
+
+ Example:
+ ```
+ SHOW TABLES
+ OR
+ SHOW TABLES IN defaultdb
+ ```
+
+### ALTER TABLE
+
+ The following section introduce the commands to modify the physical or logical state of the existing table(s).
+
+ - ##### RENAME TABLE
+
+ This command is used to rename the existing table.
+ ```
+ ALTER TABLE [db_name.]table_name RENAME TO new_table_name
+ ```
+
+ Examples:
+ ```
+ ALTER TABLE carbon RENAME TO carbonTable
+ OR
+ ALTER TABLE test_db.carbon RENAME TO test_db.carbonTable
+ ```
+
+ - ##### ADD COLUMNS
+
+ This command is used to add a new column to the existing table.
+ ```
+ ALTER TABLE [db_name.]table_name ADD COLUMNS (col_name data_type,...)
+ TBLPROPERTIES('DICTIONARY_INCLUDE'='col_name,...',
+ 'DEFAULT.VALUE.COLUMN_NAME'='default_value')
+ ```
+
+ Examples:
+ ```
+ ALTER TABLE carbon ADD COLUMNS (a1 INT, b1 STRING)
+ ```
+
+ ```
+ ALTER TABLE carbon ADD COLUMNS (a1 INT, b1 STRING) TBLPROPERTIES('DICTIONARY_INCLUDE'='a1')
+ ```
+
+ ```
+ ALTER TABLE carbon ADD COLUMNS (a1 INT, b1 STRING) TBLPROPERTIES('DEFAULT.VALUE.a1'='10')
+ ```
+ NOTE: Add Complex datatype columns is not supported.
+
+Users can specify which columns to include and exclude for local dictionary generation after adding new columns. These will be appended with the already existing local dictionary include and exclude columns of main table respectively.
+ ```
+ ALTER TABLE carbon ADD COLUMNS (a1 STRING, b1 STRING) TBLPROPERTIES('LOCAL_DICTIONARY_INCLUDE'='a1','LOCAL_DICTIONARY_EXCLUDE'='b1')
+ ```
+
+ - ##### DROP COLUMNS
+
+ This command is used to delete the existing column(s) in a table.
+ ```
+ ALTER TABLE [db_name.]table_name DROP COLUMNS (col_name, ...)
+ ```
+
+ Examples:
+ ```
+ ALTER TABLE carbon DROP COLUMNS (b1)
+ OR
+ ALTER TABLE test_db.carbon DROP COLUMNS (b1)
+
+ ALTER TABLE carbon DROP COLUMNS (c1,d1)
+ ```
+ NOTE: Drop Complex child column is not supported.
+
+ - ##### CHANGE DATA TYPE
+
+ This command is used to change the data type from INT to BIGINT or decimal precision from lower to higher.
+ Change of decimal data type from lower precision to higher precision will only be supported for cases where there is no data loss.
+ ```
+ ALTER TABLE [db_name.]table_name CHANGE col_name col_name changed_column_type
+ ```
+
+ Valid Scenarios
+ - Invalid scenario - Change of decimal precision from (10,2) to (10,5) is invalid as in this case only scale is increased but total number of digits remains the same.
+ - Valid scenario - Change of decimal precision from (10,2) to (12,3) is valid as the total number of digits are increased by 2 but scale is increased only by 1 which will not lead to any data loss.
+ - **NOTE:** The allowed range is 38,38 (precision, scale) and is a valid upper case scenario which is not resulting in data loss.
+
+ Example1:Changing data type of column a1 from INT to BIGINT.
+ ```
+ ALTER TABLE test_db.carbon CHANGE a1 a1 BIGINT
+ ```
+
+ Example2:Changing decimal precision of column a1 from 10 to 18.
+ ```
+ ALTER TABLE test_db.carbon CHANGE a1 a1 DECIMAL(18,2)
+ ```
+- ##### MERGE INDEX
+
+ This command is used to merge all the CarbonData index files (.carbonindex) inside a segment to a single CarbonData index merge file (.carbonindexmerge). This enhances the first query performance.
+ ```
+ ALTER TABLE [db_name.]table_name COMPACT 'SEGMENT_INDEX'
+ ```
+
+ Examples:
+ ```
+ ALTER TABLE test_db.carbon COMPACT 'SEGMENT_INDEX'
+ ```
+ **NOTE:**
+
+ * Merge index is not supported on streaming table.
+
+- ##### SET and UNSET for Local Dictionary Properties
+
+ When set command is used, all the newly set properties will override the corresponding old properties if exists.
+
+ Example to SET Local Dictionary Properties:
+ ```
+ ALTER TABLE tablename SET TBLPROPERTIES('LOCAL_DICTIONARY_ENABLE'='false','LOCAL_DICTIONARY_THRESHOLD'='1000','LOCAL_DICTIONARY_INCLUDE'='column1','LOCAL_DICTIONARY_EXCLUDE'='column2')
+ ```
+ When Local Dictionary properties are unset, corresponding default values will be used for these properties.
+
+ Example to UNSET Local Dictionary Properties:
+ ```
+ ALTER TABLE tablename UNSET TBLPROPERTIES('LOCAL_DICTIONARY_ENABLE','LOCAL_DICTIONARY_THRESHOLD','LOCAL_DICTIONARY_INCLUDE','LOCAL_DICTIONARY_EXCLUDE')
+ ```
+
+ **NOTE:** For old tables, by default, local dictionary is disabled. If user wants local dictionary for these tables, user can enable/disable local dictionary for new data at their discretion.
+ This can be achieved by using the alter table set command.
+
+### DROP TABLE
+
+ This command is used to delete an existing table.
+ ```
+ DROP TABLE [IF EXISTS] [db_name.]table_name
+ ```
+
+ Example:
+ ```
+ DROP TABLE IF EXISTS productSchema.productSalesTable
+ ```
+
+### REFRESH TABLE
+
+ This command is used to register Carbon table to HIVE meta store catalogue from existing Carbon table data.
+ ```
+ REFRESH TABLE $db_NAME.$table_NAME
+ ```
+
+ Example:
+ ```
+ REFRESH TABLE dbcarbon.productSalesTable
+ ```
+
+ **NOTE:**
+ * The new database name and the old database name should be same.
+ * Before executing this command the old table schema and data should be copied into the new database location.
+ * If the table is aggregate table, then all the aggregate tables should be copied to the new database location.
+ * For old store, the time zone of the source and destination cluster should be same.
+ * If old cluster used HIVE meta store to store schema, refresh will not work as schema file does not exist in file system.
+
+### Table and Column Comment
+
+ You can provide more information on table by using table comment. Similarly you can provide more information about a particular column using column comment.
+ You can see the column comment of an existing table using describe formatted command.
+
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name[(col_name data_type [COMMENT col_comment], ...)]
+ [COMMENT table_comment]
+ STORED AS carbondata
+ [TBLPROPERTIES (property_name=property_value, ...)]
+ ```
+
+ Example:
+ ```
+ CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
+ productNumber Int COMMENT 'unique serial number for product')
+ COMMENT “This is table comment”
+ STORED AS carbondata
+ TBLPROPERTIES ('DICTIONARY_INCLUDE'='productNumber')
+ ```
+ You can also SET and UNSET table comment using ALTER command.
+
+ Example to SET table comment:
+
+ ```
+ ALTER TABLE carbon SET TBLPROPERTIES ('comment'='this table comment is modified');
+ ```
+
+ Example to UNSET table comment:
+
+ ```
+ ALTER TABLE carbon UNSET TBLPROPERTIES ('comment');
+ ```
+
+## PARTITION
+
+### STANDARD PARTITION
+
+ The partition is similar as spark and hive partition, user can use any column to build partition:
+
+#### Create Partition Table
+
+ This command allows you to create table with partition.
+
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
+ [(col_name data_type , ...)]
+ [COMMENT table_comment]
+ [PARTITIONED BY (col_name data_type , ...)]
+ [STORED BY file_format]
+ [TBLPROPERTIES (property_name=property_value, ...)]
+ ```
+
+ Example:
+ ```
+ CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
+ productNumber INT,
+ productName STRING,
+ storeCity STRING,
+ storeProvince STRING,
+ saleQuantity INT,
+ revenue INT)
+ PARTITIONED BY (productCategory STRING, productBatch STRING)
+ STORED AS carbondata
+ ```
+ NOTE: Hive partition is not supported on complex datatype columns.
+
+
+#### Show Partitions
+
+ This command gets the Hive partition information of the table
+
+ ```
+ SHOW PARTITIONS [db_name.]table_name
+ ```
+
+#### Drop Partition
+
+ This command drops the specified Hive partition only.
+ ```
+ ALTER TABLE table_name DROP [IF EXISTS] PARTITION (part_spec, ...)
+ ```
+
+ Example:
+ ```
+ ALTER TABLE locationTable DROP PARTITION (country = 'US');
+ ```
+
+#### Insert OVERWRITE
+
+ This command allows you to insert or load overwrite on a specific partition.
+
+ ```
+ INSERT OVERWRITE TABLE table_name
+ PARTITION (column = 'partition_name')
+ select_statement
+ ```
+
+ Example:
+ ```
+ INSERT OVERWRITE TABLE partitioned_user
+ PARTITION (country = 'US')
+ SELECT * FROM another_user au
+ WHERE au.country = 'US';
+ ```
+
+### CARBONDATA PARTITION(HASH,RANGE,LIST) -- Alpha feature, this partition feature does not support update and delete data.
+
+ The partition supports three type:(Hash,Range,List), similar to other system's partition features, CarbonData's partition feature can be used to improve query performance by filtering on the partition column.
+
+### Create Hash Partition Table
+
+ This command allows us to create hash partition.
+
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
+ [(col_name data_type , ...)]
+ PARTITIONED BY (partition_col_name data_type)
+ STORED AS carbondata
+ [TBLPROPERTIES ('PARTITION_TYPE'='HASH',
+ 'NUM_PARTITIONS'='N' ...)]
+ ```
+ **NOTE:** N is the number of hash partitions
+
+
+ Example:
+ ```
+ CREATE TABLE IF NOT EXISTS hash_partition_table(
+ col_A STRING,
+ col_B INT,
+ col_C LONG,
+ col_D DECIMAL(10,2),
+ col_F TIMESTAMP
+ ) PARTITIONED BY (col_E LONG)
+ STORED AS carbondata TBLPROPERTIES('PARTITION_TYPE'='HASH','NUM_PARTITIONS'='9')
+ ```
+
+### Create Range Partition Table
+
+ This command allows us to create range partition.
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
+ [(col_name data_type , ...)]
+ PARTITIONED BY (partition_col_name data_type)
+ STORED AS carbondata
+ [TBLPROPERTIES ('PARTITION_TYPE'='RANGE',
+ 'RANGE_INFO'='2014-01-01, 2015-01-01, 2016-01-01, ...')]
+ ```
+
+ **NOTE:**
+ * The 'RANGE_INFO' must be defined in ascending order in the table properties.
+ * The default format for partition column of Date/Timestamp type is yyyy-MM-dd. Alternate formats for Date/Timestamp could be defined in CarbonProperties.
+
+ Example:
+ ```
+ CREATE TABLE IF NOT EXISTS range_partition_table(
+ col_A STRING,
+ col_B INT,
+ col_C LONG,
+ col_D DECIMAL(10,2),
+ col_E LONG
+ ) partitioned by (col_F Timestamp)
+ PARTITIONED BY 'carbondata'
+ TBLPROPERTIES('PARTITION_TYPE'='RANGE',
+ 'RANGE_INFO'='2015-01-01, 2016-01-01, 2017-01-01, 2017-02-01')
+ ```
+
+### Create List Partition Table
+
+ This command allows us to create list partition.
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
+ [(col_name data_type , ...)]
+ PARTITIONED BY (partition_col_name data_type)
+ STORED AS carbondata
+ [TBLPROPERTIES ('PARTITION_TYPE'='LIST',
+ 'LIST_INFO'='A, B, C, ...')]
+ ```
+ **NOTE:** List partition supports list info in one level group.
+
+ Example:
+ ```
+ CREATE TABLE IF NOT EXISTS list_partition_table(
+ col_B INT,
+ col_C LONG,
+ col_D DECIMAL(10,2),
+ col_E LONG,
+ col_F TIMESTAMP
+ ) PARTITIONED BY (col_A STRING)
+ STORED AS carbondata
+ TBLPROPERTIES('PARTITION_TYPE'='LIST',
+ 'LIST_INFO'='aaaa, bbbb, (cccc, dddd), eeee')
+ ```
+
+
+### Show Partitions
+
+ The following command is executed to get the partition information of the table
+
+ ```
+ SHOW PARTITIONS [db_name.]table_name
+ ```
+
+### Add a new partition
+
+ ```
+ ALTER TABLE [db_name].table_name ADD PARTITION('new_partition')
+ ```
+
+### Split a partition
+
+ ```
+ ALTER TABLE [db_name].table_name SPLIT PARTITION(partition_id) INTO('new_partition1', 'new_partition2'...)
+ ```
+
+### Drop a partition
+
+ Only drop partition definition, but keep data
+ ```
+ ALTER TABLE [db_name].table_name DROP PARTITION(partition_id)
+ ```
+
+ Drop both partition definition and data
+ ```
+ ALTER TABLE [db_name].table_name DROP PARTITION(partition_id) WITH DATA
+ ```
+
+ **NOTE:**
+ * Hash partition table is not supported for ADD, SPLIT and DROP commands.
+ * Partition Id: in CarbonData like the hive, folders are not used to divide partitions instead partition id is used to replace the task id. It could make use of the characteristic and meanwhile reduce some metadata.
+
+ ```
+ SegmentDir/0_batchno0-0-1502703086921.carbonindex
+ ^
+ SegmentDir/part-0-0_batchno0-0-1502703086921.carbondata
+ ^
+ ```
+
+ Here are some useful tips to improve query performance of carbonData partition table:
+ * The partitioned column can be excluded from SORT_COLUMNS, this will let other columns to do the efficient sorting.
+ * When writing SQL on a partition table, try to use filters on the partition column.
+
+## BUCKETING
+
+ Bucketing feature can be used to distribute/organize the table/partition data into multiple files such
+ that similar records are present in the same file. While creating a table, user needs to specify the
+ columns to be used for bucketing and the number of buckets. For the selection of bucket the Hash value
+ of columns is used.
+
+ ```
+ CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
+ [(col_name data_type, ...)]
+ STORED AS carbondata
+ TBLPROPERTIES('BUCKETNUMBER'='noOfBuckets',
+ 'BUCKETCOLUMNS'='columnname')
+ ```
+
+ **NOTE:**
+ * Bucketing cannot be performed for columns of Complex Data Types.
+ * Columns in the BUCKETCOLUMN parameter must be dimensions. The BUCKETCOLUMN parameter cannot be a measure or a combination of measures and dimensions.
+
+ Example:
+ ```
+ CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
+ productNumber INT,
+ saleQuantity INT,
+ productName STRING,
+ storeCity STRING,
+ storeProvince STRING,
+ productCategory STRING,
+ productBatch STRING,
+ revenue INT)
+ STORED AS carbondata
+ TBLPROPERTIES ('BUCKETNUMBER'='4', 'BUCKETCOLUMNS'='productName')
+ ```
+
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/dml-of-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/dml-of-carbondata.md b/docs/dml-of-carbondata.md
new file mode 100644
index 0000000..42da655
--- /dev/null
+++ b/docs/dml-of-carbondata.md
@@ -0,0 +1,469 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# CarbonData Data Manipulation Language
+
+CarbonData DML statements are documented here,which includes:
+
+* [LOAD DATA](#load-data)
+* [INSERT DATA](#insert-data-into-carbondata-table)
+* [Load Data Using Static Partition](#load-data-using-static-partition)
+* [Load Data Using Dynamic Partition](#load-data-using-dynamic-partition)
+* [UPDATE AND DELETE](#update-and-delete)
+* [COMPACTION](#compaction)
+* [SEGMENT MANAGEMENT](./segment-management-on-carbondata.md)
+
+
+## LOAD DATA
+
+### LOAD FILES TO CARBONDATA TABLE
+
+ This command is used to load csv files to carbondata, OPTIONS are not mandatory for data loading process.
+
+ ```
+ LOAD DATA [LOCAL] INPATH 'folder_path'
+ INTO TABLE [db_name.]table_name
+ OPTIONS(property_name=property_value, ...)
+ ```
+
+ **Supported Properties:**
+
+| Property | Description |
+| ------------------------------------------------------- | ------------------------------------------------------------ |
+| [DELIMITER](#delimiter) | Character used to separate the data in the input csv file |
+| [QUOTECHAR](#quotechar) | Character used to quote the data in the input csv file |
+| [COMMENTCHAR](#commentchar) | Character used to comment the rows in the input csv file.Those rows will be skipped from processing |
+| [HEADER](#header) | Whether the input csv files have header row |
+| [FILEHEADER](#fileheader) | If header is not present in the input csv, what is the column names to be used for data read from input csv |
+| [MULTILINE](#multiline) | Whether a row data can span across multiple lines. |
+| [ESCAPECHAR](#escapechar) | Escape character used to excape the data in input csv file.For eg.,\ is a standard escape character |
+| [SKIP_EMPTY_LINE](#skip_empty_line) | Whether empty lines in input csv file should be skipped or loaded as null row |
+| [COMPLEX_DELIMITER_LEVEL_1](#complex_delimiter_level_1) | Starting delimiter for complex type data in input csv file |
+| [COMPLEX_DELIMITER_LEVEL_2](#complex_delimiter_level_2) | Ending delimiter for complex type data in input csv file |
+| [ALL_DICTIONARY_PATH](#all_dictionary_path) | Path to read the dictionary data from all columns |
+| [COLUMNDICT](#columndict) | Path to read the dictionary data from for particular column |
+| [DATEFORMAT](#dateformat) | Format of date in the input csv file |
+| [TIMESTAMPFORMAT](#timestampformat) | Format of timestamp in the input csv file |
+| [SORT_COLUMN_BOUNDS](#sort-column-bounds) | How to parititon the sort columns to make the evenly distributed |
+| [SINGLE_PASS](#single_pass) | When to enable single pass data loading |
+| [BAD_RECORDS_LOGGER_ENABLE](#bad-records-handling) | Whether to enable bad records logging |
+| [BAD_RECORD_PATH](#bad-records-handling) | Bad records logging path.Useful when bad record logging is enabled |
+| [BAD_RECORDS_ACTION](#bad-records-handling) | Behavior of data loading when bad record is found |
+| [IS_EMPTY_DATA_BAD_RECORD](#bad-records-handling) | Whether empty data of a column to be considered as bad record or not |
+| [GLOBAL_SORT_PARTITIONS](#global_sort_partitions) | Number of partition to use for shuffling of data during sorting |
+
+ You can use the following options to load data:
+
+ - ##### DELIMITER:
+ Delimiters can be provided in the load command.
+
+ ```
+ OPTIONS('DELIMITER'=',')
+ ```
+
+ - ##### QUOTECHAR:
+ Quote Characters can be provided in the load command.
+
+ ```
+ OPTIONS('QUOTECHAR'='"')
+ ```
+
+ - ##### COMMENTCHAR:
+ Comment Characters can be provided in the load command if user want to comment lines.
+ ```
+ OPTIONS('COMMENTCHAR'='#')
+ ```
+
+ - ##### HEADER:
+ When you load the CSV file without the file header and the file header is the same with the table schema, then add 'HEADER'='false' to load data SQL as user need not provide the file header. By default the value is 'true'.
+ false: CSV file is without file header.
+ true: CSV file is with file header.
+
+ ```
+ OPTIONS('HEADER'='false')
+ ```
+
+ **NOTE:** If the HEADER option exist and is set to 'true', then the FILEHEADER option is not required.
+
+ - ##### FILEHEADER:
+ Headers can be provided in the LOAD DATA command if headers are missing in the source files.
+
+ ```
+ OPTIONS('FILEHEADER'='column1,column2')
+ ```
+
+ - ##### MULTILINE:
+
+ CSV with new line character in quotes.
+
+ ```
+ OPTIONS('MULTILINE'='true')
+ ```
+
+ - ##### ESCAPECHAR:
+
+ Escape char can be provided if user want strict validation of escape character in CSV files.
+
+ ```
+ OPTIONS('ESCAPECHAR'='\')
+ ```
+
+ - ##### SKIP_EMPTY_LINE:
+
+ This option will ignore the empty line in the CSV file during the data load.
+
+ ```
+ OPTIONS('SKIP_EMPTY_LINE'='TRUE/FALSE')
+ ```
+
+ - ##### COMPLEX_DELIMITER_LEVEL_1:
+
+ Split the complex type data column in a row (eg., a$b$c --> Array = {a,b,c}).
+
+ ```
+ OPTIONS('COMPLEX_DELIMITER_LEVEL_1'='$')
+ ```
+
+ - ##### COMPLEX_DELIMITER_LEVEL_2:
+
+ Split the complex type nested data column in a row. Applies level_1 delimiter & applies level_2 based on complex data type (eg., a:b$c:d --> Array> = {{a,b},{c,d}}).
+
+ ```
+ OPTIONS('COMPLEX_DELIMITER_LEVEL_2'=':')
+ ```
+
+ - ##### ALL_DICTIONARY_PATH:
+
+ All dictionary files path.
+
+ ```
+ OPTIONS('ALL_DICTIONARY_PATH'='/opt/alldictionary/data.dictionary')
+ ```
+
+ - ##### COLUMNDICT:
+
+ Dictionary file path for specified column.
+
+ ```
+ OPTIONS('COLUMNDICT'='column1:dictionaryFilePath1,column2:dictionaryFilePath2')
+ ```
+ **NOTE:** ALL_DICTIONARY_PATH and COLUMNDICT can't be used together.
+
+ - ##### DATEFORMAT/TIMESTAMPFORMAT:
+
+ Date and Timestamp format for specified column.
+
+ ```
+ OPTIONS('DATEFORMAT' = 'yyyy-MM-dd','TIMESTAMPFORMAT'='yyyy-MM-dd HH:mm:ss')
+ ```
+ **NOTE:** Date formats are specified by date pattern strings. The date pattern letters in CarbonData are same as in JAVA. Refer to [SimpleDateFormat](http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html).
+
+ - ##### SORT COLUMN BOUNDS:
+
+ Range bounds for sort columns.
+
+ Suppose the table is created with 'SORT_COLUMNS'='name,id' and the range for name is aaa~zzz, the value range for id is 0~1000. Then during data loading, we can specify the following option to enhance data loading performance.
+ ```
+ OPTIONS('SORT_COLUMN_BOUNDS'='f,250;l,500;r,750')
+ ```
+ Each bound is separated by ';' and each field value in bound is separated by ','. In the example above, we provide 3 bounds to distribute records to 4 partitions. The values 'f','l','r' can evenly distribute the records. Inside carbondata, for a record we compare the value of sort columns with that of the bounds and decide which partition the record will be forwarded to.
+
+ **NOTE:**
+ * SORT_COLUMN_BOUNDS will be used only when the SORT_SCOPE is 'local_sort'.
+ * Carbondata will use these bounds as ranges to process data concurrently during the final sort percedure. The records will be sorted and written out inside each partition. Since the partition is sorted, all records will be sorted.
+ * Since the actual order and literal order of the dictionary column are not necessarily the same, we do not recommend you to use this feature if the first sort column is 'dictionary_include'.
+ * The option works better if your CPU usage during loading is low. If your system is already CPU tense, better not to use this option. Besides, it depends on the user to specify the bounds. If user does not know the exactly bounds to make the data distributed evenly among the bounds, loading performance will still be better than before or at least the same as before.
+ * Users can find more information about this option in the description of PR1953.
+
+ - ##### SINGLE_PASS:
+
+ Single Pass Loading enables single job to finish data loading with dictionary generation on the fly. It enhances performance in the scenarios where the subsequent data loading after initial load involves fewer incremental updates on the dictionary.
+
+ This option specifies whether to use single pass for loading data or not. By default this option is set to FALSE.
+
+ ```
+ OPTIONS('SINGLE_PASS'='TRUE')
+ ```
+
+ **NOTE:**
+ * If this option is set to TRUE then data loading will take less time.
+ * If this option is set to some invalid value other than TRUE or FALSE then it uses the default value.
+
+ Example:
+
+ ```
+ LOAD DATA local inpath '/opt/rawdata/data.csv' INTO table carbontable
+ options('DELIMITER'=',', 'QUOTECHAR'='"','COMMENTCHAR'='#',
+ 'HEADER'='false',
+ 'FILEHEADER'='empno,empname,designation,doj,workgroupcategory,
+ workgroupcategoryname,deptno,deptname,projectcode,
+ projectjoindate,projectenddate,attendance,utilization,salary',
+ 'MULTILINE'='true','ESCAPECHAR'='\','COMPLEX_DELIMITER_LEVEL_1'='$',
+ 'COMPLEX_DELIMITER_LEVEL_2'=':',
+ 'ALL_DICTIONARY_PATH'='/opt/alldictionary/data.dictionary',
+ 'SINGLE_PASS'='TRUE')
+ ```
+
+ - ##### BAD RECORDS HANDLING:
+
+ Methods of handling bad records are as follows:
+
+ * Load all of the data before dealing with the errors.
+ * Clean or delete bad records before loading data or stop the loading when bad records are found.
+
+ ```
+ OPTIONS('BAD_RECORDS_LOGGER_ENABLE'='true', 'BAD_RECORD_PATH'='hdfs://hacluster/tmp/carbon', 'BAD_RECORDS_ACTION'='REDIRECT', 'IS_EMPTY_DATA_BAD_RECORD'='false')
+ ```
+
+ **NOTE:**
+ * BAD_RECORDS_ACTION property can have four type of actions for bad records FORCE, REDIRECT, IGNORE and FAIL.
+ * FAIL option is its Default value. If the FAIL option is used, then data loading fails if any bad records are found.
+ * If the REDIRECT option is used, CarbonData will add all bad records in to a separate CSV file. However, this file must not be used for subsequent data loading because the content may not exactly match the source record. You are advised to cleanse the original source record for further data ingestion. This option is used to remind you which records are bad records.
+ * If the FORCE option is used, then it auto-converts the data by storing the bad records as NULL before Loading data.
+ * If the IGNORE option is used, then bad records are neither loaded nor written to the separate CSV file.
+ * In loaded data, if all records are bad records, the BAD_RECORDS_ACTION is invalid and the load operation fails.
+ * The default maximum number of characters per column is 32000. If there are more than 32000 characters in a column, please refer to *String longer than 32000 characters* section.
+ * Since Bad Records Path can be specified in create, load and carbon properties.
+ Therefore, value specified in load will have the highest priority, and value specified in carbon properties will have the least priority.
+
+ **Bad Records Path:**
+ This property is used to specify the location where bad records would be written.
+
+
+ ```
+ TBLPROPERTIES('BAD_RECORDS_PATH'='/opt/badrecords'')
+ ```
+
+ Example:
+
+ ```
+ LOAD DATA INPATH 'filepath.csv' INTO TABLE tablename
+ OPTIONS('BAD_RECORDS_LOGGER_ENABLE'='true','BAD_RECORD_PATH'='hdfs://hacluster/tmp/carbon',
+ 'BAD_RECORDS_ACTION'='REDIRECT','IS_EMPTY_DATA_BAD_RECORD'='false')
+ ```
+
+ - ##### GLOBAL_SORT_PARTITIONS:
+
+ If the SORT_SCOPE is defined as GLOBAL_SORT, then user can specify the number of partitions to use while shuffling data for sort using GLOBAL_SORT_PARTITIONS. If it is not configured, or configured less than 1, then it uses the number of map task as reduce task. It is recommended that each reduce task deal with 512MB-1GB data.
+
+ ```
+ OPTIONS('GLOBAL_SORT_PARTITIONS'='2')
+ ```
+
+ NOTE:
+ * GLOBAL_SORT_PARTITIONS should be Integer type, the range is [1,Integer.MaxValue].
+ * It is only used when the SORT_SCOPE is GLOBAL_SORT.
+
+### INSERT DATA INTO CARBONDATA TABLE
+
+ This command inserts data into a CarbonData table, it is defined as a combination of two queries Insert and Select query respectively.
+ It inserts records from a source table into a target CarbonData table, the source table can be a Hive table, Parquet table or a CarbonData table itself.
+ It comes with the functionality to aggregate the records of a table by performing Select query on source table and load its corresponding resultant records into a CarbonData table.
+
+ ```
+ INSERT INTO TABLE <CARBONDATA TABLE> SELECT * FROM sourceTableName
+ [ WHERE { <filter_condition> } ]
+ ```
+
+ You can also omit the `table` keyword and write your query as:
+
+ ```
+ INSERT INTO <CARBONDATA TABLE> SELECT * FROM sourceTableName
+ [ WHERE { <filter_condition> } ]
+ ```
+
+ Overwrite insert data:
+ ```
+ INSERT OVERWRITE TABLE <CARBONDATA TABLE> SELECT * FROM sourceTableName
+ [ WHERE { <filter_condition> } ]
+ ```
+
+ **NOTE:**
+ * The source table and the CarbonData table must have the same table schema.
+ * The data type of source and destination table columns should be same
+ * INSERT INTO command does not support partial success if bad records are found, it will fail.
+ * Data cannot be loaded or updated in source table while insert from source table to target table is in progress.
+
+ Examples
+ ```
+ INSERT INTO table1 SELECT item1, sum(item2 + 1000) as result FROM table2 group by item1
+ ```
+
+ ```
+ INSERT INTO table1 SELECT item1, item2, item3 FROM table2 where item2='xyz'
+ ```
+
+ ```
+ INSERT OVERWRITE TABLE table1 SELECT * FROM TABLE2
+ ```
+
+### Load Data Using Static Partition
+
+ This command allows you to load data using static partition.
+
+ ```
+ LOAD DATA [LOCAL] INPATH 'folder_path'
+ INTO TABLE [db_name.]table_name PARTITION (partition_spec)
+ OPTIONS(property_name=property_value, ...)
+ INSERT INTO INTO TABLE [db_name.]table_name PARTITION (partition_spec) <SELECT STATEMENT>
+ ```
+
+ Example:
+ ```
+ LOAD DATA LOCAL INPATH '${env:HOME}/staticinput.csv'
+ INTO TABLE locationTable
+ PARTITION (country = 'US', state = 'CA')
+ INSERT INTO TABLE locationTable
+ PARTITION (country = 'US', state = 'AL')
+ SELECT <columns list excluding partition columns> FROM another_user
+ ```
+
+### Load Data Using Dynamic Partition
+
+ This command allows you to load data using dynamic partition. If partition spec is not specified, then the partition is considered as dynamic.
+
+ Example:
+ ```
+ LOAD DATA LOCAL INPATH '${env:HOME}/staticinput.csv'
+ INTO TABLE locationTable
+ INSERT INTO TABLE locationTable
+ SELECT <columns list excluding partition columns> FROM another_user
+ ```
+
+## UPDATE AND DELETE
+
+### UPDATE
+
+ This command will allow to update the CarbonData table based on the column expression and optional filter conditions.
+
+ ```
+ UPDATE <table_name>
+ SET (column_name1, column_name2, ... column_name n) = (column1_expression , column2_expression, ... column n_expression )
+ [ WHERE { <filter_condition> } ]
+ ```
+
+ alternatively the following command can also be used for updating the CarbonData Table :
+
+ ```
+ UPDATE <table_name>
+ SET (column_name1, column_name2) =(select sourceColumn1, sourceColumn2 from sourceTable [ WHERE { <filter_condition> } ] )
+ [ WHERE { <filter_condition> } ]
+ ```
+
+ **NOTE:** The update command fails if multiple input rows in source table are matched with single row in destination table.
+
+ Examples:
+ ```
+ UPDATE t3 SET (t3_salary) = (t3_salary + 9) WHERE t3_name = 'aaa1'
+ ```
+
+ ```
+ UPDATE t3 SET (t3_date, t3_country) = ('2017-11-18', 'india') WHERE t3_salary < 15003
+ ```
+
+ ```
+ UPDATE t3 SET (t3_country, t3_name) = (SELECT t5_country, t5_name FROM t5 WHERE t5_id = 5) WHERE t3_id < 5
+ ```
+
+ ```
+ UPDATE t3 SET (t3_date, t3_serialname, t3_salary) = (SELECT '2099-09-09', t5_serialname, '9999' FROM t5 WHERE t5_id = 5) WHERE t3_id < 5
+ ```
+
+
+ ```
+ UPDATE t3 SET (t3_country, t3_salary) = (SELECT t5_country, t5_salary FROM t5 FULL JOIN t3 u WHERE u.t3_id = t5_id and t5_id=6) WHERE t3_id >6
+ ```
+ NOTE: Update Complex datatype columns is not supported.
+
+### DELETE
+
+ This command allows us to delete records from CarbonData table.
+ ```
+ DELETE FROM table_name [WHERE expression]
+ ```
+
+ Examples:
+
+ ```
+ DELETE FROM carbontable WHERE column1 = 'china'
+ ```
+
+ ```
+ DELETE FROM carbontable WHERE column1 IN ('china', 'USA')
+ ```
+
+ ```
+ DELETE FROM carbontable WHERE column1 IN (SELECT column11 FROM sourceTable2)
+ ```
+
+ ```
+ DELETE FROM carbontable WHERE column1 IN (SELECT column11 FROM sourceTable2 WHERE column1 = 'USA')
+ ```
+
+## COMPACTION
+
+ Compaction improves the query performance significantly.
+
+ There are several types of compaction.
+
+ ```
+ ALTER TABLE [db_name.]table_name COMPACT 'MINOR/MAJOR/CUSTOM'
+ ```
+
+ - **Minor Compaction**
+
+ In Minor compaction, user can specify the number of loads to be merged.
+ Minor compaction triggers for every data load if the parameter carbon.enable.auto.load.merge is set to true.
+ If any segments are available to be merged, then compaction will run parallel with data load, there are 2 levels in minor compaction:
+ * Level 1: Merging of the segments which are not yet compacted.
+ * Level 2: Merging of the compacted segments again to form a larger segment.
+
+ ```
+ ALTER TABLE table_name COMPACT 'MINOR'
+ ```
+
+ - **Major Compaction**
+
+ In Major compaction, multiple segments can be merged into one large segment.
+ User will specify the compaction size until which segments can be merged, Major compaction is usually done during the off-peak time.
+ Configure the property carbon.major.compaction.size with appropriate value in MB.
+
+ This command merges the specified number of segments into one segment:
+
+ ```
+ ALTER TABLE table_name COMPACT 'MAJOR'
+ ```
+
+ - **Custom Compaction**
+
+ In Custom compaction, user can directly specify segment ids to be merged into one large segment.
+ All specified segment ids should exist and be valid, otherwise compaction will fail.
+ Custom compaction is usually done during the off-peak time.
+
+ ```
+ ALTER TABLE table_name COMPACT 'CUSTOM' WHERE SEGMENT.ID IN (2,3,4)
+ ```
+ NOTE: Compaction is unsupported for table containing Complex columns.
+
+
+ - **CLEAN SEGMENTS AFTER Compaction**
+
+ Clean the segments which are compacted:
+ ```
+ CLEAN FILES FOR TABLE carbon_table
+ ```
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/documentation.md
----------------------------------------------------------------------
diff --git a/docs/documentation.md b/docs/documentation.md
new file mode 100644
index 0000000..537a9d3
--- /dev/null
+++ b/docs/documentation.md
@@ -0,0 +1,66 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Apache CarbonData Documentation
+
+
+
+Apache CarbonData is a new big data file format for faster interactive query using advanced columnar storage, index, compression and encoding techniques to improve computing efficiency, which helps in speeding up queries by an order of magnitude faster over PetaBytes of data.
+
+
+
+## Getting Started
+
+**File Format Concepts:** Start with the basics of understanding the [CarbonData file format](./file-structure-of-carbondata.md#carbondata-file-format) and its [storage structure](./file-structure-of-carbondata.md).This will help to understand other parts of the documentation, including deployment, programming and usage guides.
+
+**Quick Start:** [Run an example program](./quick-start-guide.md#installing-and-configuring-carbondata-to-run-locally-with-spark-shell) on your local machine or [study some examples](https://github.com/apache/carbondata/tree/master/examples/spark2/src/main/scala/org/apache/carbondata/examples).
+
+**CarbonData SQL Language Reference:** CarbonData extends the Spark SQL language and adds several [DDL](./ddl-of-carbondata.md) and [DML](./dml-of-carbondata.md) statements to support operations on it.Refer to the [Reference Manual](./language-manual.md) to understand the supported features and functions.
+
+**Programming Guides:** You can read our guides about [APIs supported](./sdk-guide.md) to learn how to integrate CarbonData with your applications.
+
+
+
+## Integration
+
+CarbonData can be integrated with popular Execution engines like [Spark](./quick-start-guide.md#spark) and [Presto](./quick-start-guide.md#presto).Refer to the [Installation and Configuration](./quick-start-guide.md#integration) section to understand all modes of Integrating CarbonData.
+
+
+
+## Contributing to CarbonData
+
+The Apache CarbonData community welcomes all kinds of contributions from anyone with a passion for
+faster data format.Contributing to CarbonData doesn’t just mean writing code. Helping new users on the mailing list, testing releases, and improving documentation are also welcome.Please follow the [Contributing to CarbonData guidelines](./how-to-contribute-to-apache-carbondata.md) before proposing a design or code change.
+
+
+
+**Compiling CarbonData:** This [guide](https://github.com/apache/carbondata/tree/master/build) will help you to compile and generate the jars for test.
+
+
+
+## External Resources
+
+**Wiki:** You can read the [Apache CarbonData wiki](https://cwiki.apache.org/confluence/display/CARBONDATA/CarbonData+Home) page for upcoming release plan, blogs and training materials.
+
+**Summit:** Presentations from past summits and conferences can be found [here](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66850609).
+
+**Blogs:** Blogs by external users can be found [here](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67635497).
+
+**Performance reports:** TPC-H performance reports can be found [here](https://cwiki.apache.org/confluence/display/CARBONDATA/Performance+-+TPCH+Report+of+CarbonData+%281.2+version%29+and+Parquet+on+Spark+Execution+Engine).
+
+**Trainings:** Training records on design and code flows can be found [here](https://cwiki.apache.org/confluence/display/CARBONDATA/CarbonData+Training+Materials).
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/faq.md
----------------------------------------------------------------------
diff --git a/docs/faq.md b/docs/faq.md
index 9f74842..8ec7290 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -7,7 +7,7 @@
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -26,10 +26,27 @@
* [How to resolve Abstract Method Error?](#how-to-resolve-abstract-method-error)
* [How Carbon will behave when execute insert operation in abnormal scenarios?](#how-carbon-will-behave-when-execute-insert-operation-in-abnormal-scenarios)
* [Why aggregate query is not fetching data from aggregate table?](#why-aggregate-query-is-not-fetching-data-from-aggregate-table)
-* [Why all executors are showing success in Spark UI even after Dataload command failed at Driver side?](#Why-all-executors-are-showing-success-in-Spark-UI-even-after-Dataload-command-failed-at-driver-side)
-* [Why different time zone result for select query output when query SDK writer output?](#Why-different-time-zone-result-for-select-query-output-when-query-SDK-writer-output)
+* [Why all executors are showing success in Spark UI even after Dataload command failed at Driver side?](#why-all-executors-are-showing-success-in-spark-ui-even-after-dataload-command-failed-at-driver-side)
+* [Why different time zone result for select query output when query SDK writer output?](#why-different-time-zone-result-for-select-query-output-when-query-sdk-writer-output)
+
+# TroubleShooting
+
+- [Getting tablestatus.lock issues When loading data](#getting-tablestatuslock-issues-when-loading-data)
+- [Failed to load thrift libraries](#failed-to-load-thrift-libraries)
+- [Failed to launch the Spark Shell](#failed-to-launch-the-spark-shell)
+- [Failed to execute load query on cluster](#failed-to-execute-load-query-on-cluster)
+- [Failed to execute insert query on cluster](#failed-to-execute-insert-query-on-cluster)
+- [Failed to connect to hiveuser with thrift](#failed-to-connect-to-hiveuser-with-thrift)
+- [Failed to read the metastore db during table creation](#failed-to-read-the-metastore-db-during-table-creation)
+- [Failed to load data on the cluster](#failed-to-load-data-on-the-cluster)
+- [Failed to insert data on the cluster](#failed-to-insert-data-on-the-cluster)
+- [Failed to execute Concurrent Operations(Load,Insert,Update) on table by multiple workers](#failed-to-execute-concurrent-operations-on-table-by-multiple-workers)
+- [Failed to create a table with a single numeric column](#failed-to-create-a-table-with-a-single-numeric-column)
+
+##
## What are Bad Records?
+
Records that fail to get loaded into the CarbonData due to data type incompatibility or are empty or have incompatible format are classified as Bad Records.
## Where are Bad Records Stored in CarbonData?
@@ -81,7 +98,7 @@ The property carbon.lock.type configuration specifies the type of lock to be acq
In order to build CarbonData project it is necessary to specify the spark profile. The spark profile sets the Spark Version. You need to specify the ``spark version`` while using Maven to build project.
## How Carbon will behave when execute insert operation in abnormal scenarios?
-Carbon support insert operation, you can refer to the syntax mentioned in [DML Operations on CarbonData](dml-operation-on-carbondata.md).
+Carbon support insert operation, you can refer to the syntax mentioned in [DML Operations on CarbonData](./dml-of-carbondata.md).
First, create a source table in spark-sql and load data into this created table.
```
@@ -109,7 +126,7 @@ CREATE TABLE IF NOT EXISTS carbon_table(
id String,
city String,
name String)
-STORED BY 'carbondata';
+STORED AS carbondata;
```
```
@@ -153,7 +170,7 @@ When SubQuery predicate is present in the query.
Example:
```
-create table gdp21(cntry smallint, gdp double, y_year date) stored by 'carbondata';
+create table gdp21(cntry smallint, gdp double, y_year date) stored as carbondata;
create datamap ag1 on table gdp21 using 'preaggregate' as select cntry, sum(gdp) from gdp21 group by cntry;
select ctry from pop1 where ctry in (select cntry from gdp21 group by cntry);
```
@@ -164,7 +181,7 @@ When aggregate function along with 'in' filter.
Example:
```
-create table gdp21(cntry smallint, gdp double, y_year date) stored by 'carbondata';
+create table gdp21(cntry smallint, gdp double, y_year date) stored as carbondata;
create datamap ag1 on table gdp21 using 'preaggregate' as select cntry, sum(gdp) from gdp21 group by cntry;
select cntry, sum(gdp) from gdp21 where cntry in (select ctry from pop1) group by cntry;
```
@@ -175,7 +192,7 @@ When aggregate function having 'join' with equal filter.
Example:
```
-create table gdp21(cntry smallint, gdp double, y_year date) stored by 'carbondata';
+create table gdp21(cntry smallint, gdp double, y_year date) stored as carbondata;
create datamap ag1 on table gdp21 using 'preaggregate' as select cntry, sum(gdp) from gdp21 group by cntry;
select cntry,sum(gdp) from gdp21,pop1 where cntry=ctry group by cntry;
```
@@ -195,3 +212,253 @@ cluster timezone is Asia/Shanghai
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"))
```
+
+
+## Getting tablestatus.lock issues When loading data
+
+ **Symptom**
+```
+17/11/11 16:48:13 ERROR LocalFileLock: main hdfs:/localhost:9000/carbon/store/default/hdfstable/tablestatus.lock (No such file or directory)
+java.io.FileNotFoundException: hdfs:/localhost:9000/carbon/store/default/hdfstable/tablestatus.lock (No such file or directory)
+ at java.io.FileOutputStream.open0(Native Method)
+ at java.io.FileOutputStream.open(FileOutputStream.java:270)
+ at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
+ at java.io.FileOutputStream.<init>(FileOutputStream.java:101)
+```
+
+ **Possible Cause**
+ If you use `<hdfs path>` as store path when creating carbonsession, may get the errors,because the default is LOCALLOCK.
+
+ **Procedure**
+ Before creating carbonsession, sets as below:
+ ```
+ import org.apache.carbondata.core.util.CarbonProperties
+ import org.apache.carbondata.core.constants.CarbonCommonConstants
+ CarbonProperties.getInstance().addProperty(CarbonCommonConstants.LOCK_TYPE, "HDFSLOCK")
+ ```
+
+## Failed to load thrift libraries
+
+ **Symptom**
+
+ Thrift throws following exception :
+
+ ```
+ thrift: error while loading shared libraries:
+ libthriftc.so.0: cannot open shared object file: No such file or directory
+ ```
+
+ **Possible Cause**
+
+ The complete path to the directory containing the libraries is not configured correctly.
+
+ **Procedure**
+
+ Follow the Apache thrift docs at [https://thrift.apache.org/docs/install](https://thrift.apache.org/docs/install) to install thrift correctly.
+
+## Failed to launch the Spark Shell
+
+ **Symptom**
+
+ The shell prompts the following error :
+
+ ```
+ org.apache.spark.sql.CarbonContext$$anon$$apache$spark$sql$catalyst$analysis
+ $OverrideCatalog$_setter_$org$apache$spark$sql$catalyst$analysis
+ $OverrideCatalog$$overrides_$e
+ ```
+
+ **Possible Cause**
+
+ The Spark Version and the selected Spark Profile do not match.
+
+ **Procedure**
+
+ 1. Ensure your spark version and selected profile for spark are correct.
+
+ 2. Use the following command :
+
+```
+"mvn -Pspark-2.1 -Dspark.version {yourSparkVersion} clean package"
+```
+Note : Refrain from using "mvn clean package" without specifying the profile.
+
+## Failed to execute load query on cluster
+
+ **Symptom**
+
+ Load query failed with the following exception:
+
+ ```
+ Dictionary file is locked for updation.
+ ```
+
+ **Possible Cause**
+
+ The carbon.properties file is not identical in all the nodes of the cluster.
+
+ **Procedure**
+
+ Follow the steps to ensure the carbon.properties file is consistent across all the nodes:
+
+ 1. Copy the carbon.properties file from the master node to all the other nodes in the cluster.
+ For example, you can use ssh to copy this file to all the nodes.
+
+ 2. For the changes to take effect, restart the Spark cluster.
+
+## Failed to execute insert query on cluster
+
+ **Symptom**
+
+ Load query failed with the following exception:
+
+ ```
+ Dictionary file is locked for updation.
+ ```
+
+ **Possible Cause**
+
+ The carbon.properties file is not identical in all the nodes of the cluster.
+
+ **Procedure**
+
+ Follow the steps to ensure the carbon.properties file is consistent across all the nodes:
+
+ 1. Copy the carbon.properties file from the master node to all the other nodes in the cluster.
+ For example, you can use scp to copy this file to all the nodes.
+
+ 2. For the changes to take effect, restart the Spark cluster.
+
+## Failed to connect to hiveuser with thrift
+
+ **Symptom**
+
+ We get the following exception :
+
+ ```
+ Cannot connect to hiveuser.
+ ```
+
+ **Possible Cause**
+
+ The external process does not have permission to access.
+
+ **Procedure**
+
+ Ensure that the Hiveuser in mysql must allow its access to the external processes.
+
+## Failed to read the metastore db during table creation
+
+ **Symptom**
+
+ We get the following exception on trying to connect :
+
+ ```
+ Cannot read the metastore db
+ ```
+
+ **Possible Cause**
+
+ The metastore db is dysfunctional.
+
+ **Procedure**
+
+ Remove the metastore db from the carbon.metastore in the Spark Directory.
+
+## Failed to load data on the cluster
+
+ **Symptom**
+
+ Data loading fails with the following exception :
+
+ ```
+ Data Load failure exception
+ ```
+
+ **Possible Cause**
+
+ The following issue can cause the failure :
+
+ 1. The core-site.xml, hive-site.xml, yarn-site and carbon.properties are not consistent across all nodes of the cluster.
+
+ 2. Path to hdfs ddl is not configured correctly in the carbon.properties.
+
+ **Procedure**
+
+ Follow the steps to ensure the following configuration files are consistent across all the nodes:
+
+ 1. Copy the core-site.xml, hive-site.xml, yarn-site,carbon.properties files from the master node to all the other nodes in the cluster.
+ For example, you can use scp to copy this file to all the nodes.
+
+ Note : Set the path to hdfs ddl in carbon.properties in the master node.
+
+ 2. For the changes to take effect, restart the Spark cluster.
+
+
+
+## Failed to insert data on the cluster
+
+ **Symptom**
+
+ Insertion fails with the following exception :
+
+ ```
+ Data Load failure exception
+ ```
+
+ **Possible Cause**
+
+ The following issue can cause the failure :
+
+ 1. The core-site.xml, hive-site.xml, yarn-site and carbon.properties are not consistent across all nodes of the cluster.
+
+ 2. Path to hdfs ddl is not configured correctly in the carbon.properties.
+
+ **Procedure**
+
+ Follow the steps to ensure the following configuration files are consistent across all the nodes:
+
+ 1. Copy the core-site.xml, hive-site.xml, yarn-site,carbon.properties files from the master node to all the other nodes in the cluster.
+ For example, you can use scp to copy this file to all the nodes.
+
+ Note : Set the path to hdfs ddl in carbon.properties in the master node.
+
+ 2. For the changes to take effect, restart the Spark cluster.
+
+## Failed to execute Concurrent Operations on table by multiple workers
+
+ **Symptom**
+
+ Execution fails with the following exception :
+
+ ```
+ Table is locked for updation.
+ ```
+
+ **Possible Cause**
+
+ Concurrency not supported.
+
+ **Procedure**
+
+ Worker must wait for the query execution to complete and the table to release the lock for another query execution to succeed.
+
+## Failed to create a table with a single numeric column
+
+ **Symptom**
+
+ Execution fails with the following exception :
+
+ ```
+ Table creation fails.
+ ```
+
+ **Possible Cause**
+
+ Behaviour not supported.
+
+ **Procedure**
+
+ A single column that can be considered as dimension is mandatory for table creation.
+
+
[2/4] carbondata git commit: [CARBONDATA-2915] Reformat Documentation
of CarbonData
Posted by ch...@apache.org.
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/file-structure-of-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/file-structure-of-carbondata.md b/docs/file-structure-of-carbondata.md
index 303d0e0..ba9004c 100644
--- a/docs/file-structure-of-carbondata.md
+++ b/docs/file-structure-of-carbondata.md
@@ -6,35 +6,173 @@
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
+```
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+```
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-->
-# CarbonData File Structure
+# CarbonData table structure
CarbonData files contain groups of data called blocklets, along with all required information like schema, offsets and indices etc, in a file header and footer, co-located in HDFS.
The file footer can be read once to build the indices in memory, which can be utilized for optimizing the scans and processing for all subsequent queries.
-### Understanding CarbonData File Structure
-* Block : It would be as same as HDFS block, CarbonData creates one file for each data block, user can specify TABLE_BLOCKSIZE during creation table. Each file contains File Header, Blocklets and File Footer.
+This document describes the what a CarbonData table looks like in a HDFS directory, files written and content of each file.
+
+- [File Directory Structure](#file-directory-structure)
+
+- [File Content details](#file-content-details)
+ - [Schema file format](#schema-file-format)
+ - [CarbonData file format](#carbondata-file-format)
+ - [Blocklet format](#blocklet-format)
+ - [V1](#v1)
+ - [V2](#v2)
+ - [V3](#v3)
+ - [Footer format](#footer-format)
+ - [carbonindex file format](#carbonindex-file-format)
+ - [Dictionary file format](#dictionary-file-format)
+ - [tablestatus file format](#tablestatus-file-format)
+
+## File Directory Structure
+
+The CarbonData files are stored in the location specified by the ***carbon.storelocation*** configuration (configured in carbon.properties; if not configured, the default is ../carbon.store).
+
+ The file directory structure is as below:
+
+
+
+1. ModifiedTime.mdt records the timestamp of the metadata with the modification time attribute of the file. When the drop table and create table are used, the modification time of the file is updated.This is common to all databases and hence is kept in parallel to databases
+2. The **default** is the database name and contains the user tables.default is used when user doesn't specify any database name;else user configured database name will be the directory name. user_table is the table name.
+3. Metadata directory stores schema files, tablestatus and dictionary files (including .dict, .dictmeta and .sortindex). There are three types of metadata data information files.
+4. data and index files are stored under directory named **Fact**. The Fact directory has a Part0 partition directory, where 0 is the partition number.
+5. There is a Segment_0 directory under the Part0 directory, where 0 is the segment number.
+6. There are two types of files, carbondata and carbonindex, in the Segment_0 directory.
+
+
+
+## File Content details
+
+When the table is created, the user_table directory is generated, and a schema file is generated in the Metadata directory for recording the table structure.
+
+When loading data in batches, each batch loading generates a new segment directory. The scheduling tries to control a task processing data loading task on each node. Each task will generate multiple carbondata files and one carbonindex file.
+
+During global dictionary generation, if the two-pass scheme is used, before the data is loaded, the corresponding dict, dictmeta and sortindex files are generated for each dictionary-encoded column, and partial dictionary files can be provided by the pre-define dictionary method to reduce the need. A dictionary-encoded column is generated by scanning the full amount of data; a dictionary file of all dictionary code columns can also be provided by the all dictionary method to avoid scanning data. If the single-pass scheme is adopted, the global dictionary code is generated in real time during data loading, and after the data is loaded, the dictionary is solidified into a dictionary file.
+
+The following sections use the Java object generated by the thrift file describing the carbondata file format to explain the contents of each file one by one (you can also directly read the format defined in the [thrift file](https://github.com/apache/carbondata/tree/master/format/src/main/thrift))
+
+### Schema file format
+
+The contents of the schema file is as shown below
+
+
+
+1. TableSchema class
+ The TableSchema class does not store the table name, it is infered from the directory name(user_table).
+ tableProperties is used to record table-related properties, such as: table_blocksize.
+2. ColumnSchema class
+ Encoders are used to record the encoding used in column storage.
+ columnProperties is used to record column related properties.
+3. BucketingInfo class
+ When creating a bucket table, you can specify the number of buckets in the table and the column to splitbuckets.
+4. DataType class
+ Describes the data types supported by CarbonData.
+5. Encoding class
+ Several encodings that may be used in CarbonData files.
+
+### CarbonData file format
+
+#### File Header
+
+It contains CarbonData file version number, list of column schema and schema updation timestamp.
+
+
+
+The carbondata file consists of multiple blocklets and footer parts. The blocklet is the dataset inside the carbondata file (the latest V3 format, the default configuration is 64MB), each blocklet contains a ColumnChunk for each column, and a ColumnChunk may contain one or more Column Pages.
+
+The carbondata file currently supports V1, V2 and V3 versions. The main difference is the change of the blocklet part, which is introduced one by one.
+
+#### Blocklet format
+
+##### V1
+
+ Blocket consists of all column data pages, RLE pages, and rowID pages. Since the pages in the blocklet are grouped according to the page type, the three pieces of data of each column are distributed and stored in the blocklet, and the offset and length information of all the pages need to be recorded in the footer part.
+
+
+
+##### V2
+
+The blocklet consists of ColumnChunk for all columns. The ColumnChunk for a column consists of a ColumnPage, which includes the data chunk header, data page, RLE page, and rowID page. Since ColumnChunk aggregates the three types of Page data of the column together, it can read the column data using fewer readers. Since the header part records the length information of all the pages, the footer part only needs to record the offset and length of the ColumnChunk, and also reduces the amount of footer data.
+
+
+
+##### V3
+
+The blocklet is also composed of ColumnChunks of all columns. What is changed is that a ColumnChunk consists of one or more Column Pages, and Column Page adds a new BlockletMinMaxIndex.
+
+Compared with V2: The blocklet data volume of V2 format defaults to 120,000 lines, and the blocklet data volume of V3 format defaults to 64MB. For the same size data file, the information of the footer part index metadata may be further reduced; meanwhile, the V3 format adds a new page. Level data filtering, and the amount of data per page is only 32,000 lines by default, which is much less than the 120,000 lines of V2 format. The accuracy of data filtering hits further, and more data can be filtered out before decompressing data.
+
+
+
+#### Footer format
+
+Footer records each carbondata
+All blocklet data distribution information and statistical related metadata information (minmax, startkey/endkey) inside the file.
+
+
+
+1. BlockletInfo3 is used to record the offset and length of all ColumnChunk3.
+2. SegmentInfo is used to record the number of columns and the cardinality of each column.
+3. BlockletIndex includes BlockletMinMaxIndex and BlockletBTreeIndex.
+
+BlockletBTreeIndex is used to record the startkey/endkey of all blocklets in the block. When querying, the startkey/endkey of the query is generated by filtering conditions combined with mdkey. With BlocketBtreeIndex, the range of blocklets satisfying the conditions in each block can be delineated.
+
+BlockletMinMaxIndex is used to record the min/max value of all columns in the blocklet. By using the min/max check on the filter condition, you can skip the block/blocklet that does not satisfy the condition.
+
+### carbonindex file format
+
+Extract the BlockletIndex part of the footer part to generate the carbonindex file. Load data in batches, schedule as much as possible to control a node to start a task, each task generates multiple carbondata files and a carbonindex file. The carbonindex file records the index information of all the blocklets in all the carbondata files generated by the task.
+
+As shown in the figure, the index information corresponding to a block is recorded by a BlockIndex object, including carbondata filename, footer offset and BlockletIndex. The BlockIndex data volume is less than the footer. The file is directly used to build the index on the driver side when querying, without having to skip the footer part of the data volume of multiple data files.
+
+
+
+### Dictionary file format
+
+
+For each dictionary encoded column, a dictionary file is used to store the dictionary metadata for that column.
+
+1. dict file records the distinct value list of a column
+
+For the first time dataloading, the file is generated using a distinct value list of a column. The value in the file is unordered; the subsequent append is used. In the second step of dataloading (Data Convert Step), the dictionary code column will replace the true value of the data with the dictionary key.
+
+
+
+
+2. dictmeta records the metadata description of the new distinct value of each dataloading
+
+The dictionary cache uses this information to incrementally flush the cache.
+
+
+
+
+3. sortindex records the result set of the key code of the dictionary code sorted by value.
+
+In dataLoading, if there is a new dictionary value, the sortindex file will be regenerated using all the dictionary codes.
+
+Filtering queries based on dictionary code columns need to convert the value filter filter to the key filter condition. Using the sortindex file, you can quickly construct an ordered value sequence to quickly find the key value corresponding to the value, thus speeding up the conversion process.
+
+
-
+### tablestatus file format
-* File Header : It contains CarbonData file version number, list of column schema and schema updation timestamp.
-* File Footer : it contains Number of rows, segmentinfo ,all blocklets’ info and index, you can find the detail from the below diagram.
-* Blocklet : Rows are grouped to form a blocklet, the size of the blocklet is configurable and default size is 64MB, Blocklet contains Column Page groups for each column.
-* Column Page Group : Data of one column and it is further divided into pages, it is guaranteed to be contiguous in file.
-* Page : It has the data of one column and the number of row is fixed to 32000 size.
+Tablestatus records the segment-related information (in gson format) for each load and merge, including load time, load status, segment name, whether it was deleted, and the segment name incorporated. Regenerate the tablestatusfile after each load or merge.
-
+
-### Each page contains three types of data
-* Data Page: Contains the encoded data of a column of columns.
-* Row ID Page (optional): Contains the row ID mappings used when the data page is stored as an inverted index.
-* RLE Page (optional): Contains additional metadata used when the data page is RLE coded.
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/hive-guide.md
----------------------------------------------------------------------
diff --git a/docs/hive-guide.md b/docs/hive-guide.md
new file mode 100644
index 0000000..c38a539
--- /dev/null
+++ b/docs/hive-guide.md
@@ -0,0 +1,100 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Quick Start
+This tutorial provides a quick introduction to using current integration/hive module.
+
+## Build (In 1.2.0, hive integration only support spark2.1 and hadoop2.7.2)
+mvn -DskipTests -Pspark-2.1 -Phadoop-2.7.2 clean package
+
+## Prepare CarbonData in Spark
+* Create a sample.csv file using the following commands. The CSV file is required for loading data into CarbonData.
+
+ ```
+ cd carbondata
+ cat > sample.csv << EOF
+ id,name,scale,country,salary
+ 1,yuhai,1.77,china,33000.1
+ 2,runlin,1.70,china,33000.2
+ EOF
+ ```
+
+* copy data to HDFS
+
+```
+$HADOOP_HOME/bin/hadoop fs -put sample.csv <hdfs store path>/sample.csv
+```
+
+* Add the following params to $SPARK_CONF_DIR/conf/hive-site.xml
+```xml
+<property>
+ <name>hive.metastore.pre.event.listeners</name>
+ <value>org.apache.carbondata.hive.CarbonHiveMetastoreListener</value>
+</property>
+```
+* Start Spark shell by running the following command in the Spark directory
+
+```
+./bin/spark-shell --jars <carbondata assembly jar path, carbon hive jar path>
+```
+
+```
+import org.apache.spark.sql.SparkSession
+import org.apache.spark.sql.CarbonSession._
+val rootPath = "hdfs:////user/hadoop/carbon"
+val storeLocation = s"$rootPath/store"
+val warehouse = s"$rootPath/warehouse"
+val metastoredb = s"$rootPath/metastore_db"
+
+val carbon = SparkSession.builder().enableHiveSupport().config("spark.sql.warehouse.dir", warehouse).config(org.apache.carbondata.core.constants.CarbonCommonConstants.STORE_LOCATION, storeLocation).getOrCreateCarbonSession(storeLocation, metastoredb)
+
+carbon.sql("create table hive_carbon(id int, name string, scale decimal, country string, salary double) STORED BY 'carbondata'")
+carbon.sql("LOAD DATA INPATH '<hdfs store path>/sample.csv' INTO TABLE hive_carbon")
+scala>carbon.sql("SELECT * FROM hive_carbon").show()
+```
+
+## Query Data in Hive
+### Configure hive classpath
+```
+mkdir hive/auxlibs/
+cp carbondata/assembly/target/scala-2.11/carbondata_2.11*.jar hive/auxlibs/
+cp carbondata/integration/hive/target/carbondata-hive-*.jar hive/auxlibs/
+cp $SPARK_HOME/jars/spark-catalyst*.jar hive/auxlibs/
+cp $SPARK_HOME/jars/scala*.jar hive/auxlibs/
+export HIVE_AUX_JARS_PATH=hive/auxlibs/
+```
+### Fix snappy issue
+```
+copy snappy-java-xxx.jar from "./<SPARK_HOME>/jars/" to "./Library/Java/Extensions"
+export HADOOP_OPTS="-Dorg.xerial.snappy.lib.path=/Library/Java/Extensions -Dorg.xerial.snappy.lib.name=libsnappyjava.jnilib -Dorg.xerial.snappy.tempdir=/Users/apple/DEMO/tmp"
+```
+
+### Start hive client
+$HIVE_HOME/bin/hive
+
+### Query data from hive table
+
+```
+set hive.mapred.supports.subdirectories=true;
+set mapreduce.input.fileinputformat.input.dir.recursive=true;
+
+select * from hive_carbon;
+select count(*) from hive_carbon;
+select * from hive_carbon order by id;
+```
+
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/how-to-contribute-to-apache-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/how-to-contribute-to-apache-carbondata.md b/docs/how-to-contribute-to-apache-carbondata.md
new file mode 100644
index 0000000..f64c948
--- /dev/null
+++ b/docs/how-to-contribute-to-apache-carbondata.md
@@ -0,0 +1,192 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# How to contribute to Apache CarbonData
+
+The Apache CarbonData community welcomes all kinds of contributions from anyone with a passion for
+faster data format! Apache CarbonData is a new file format for faster interactive query using
+advanced columnar storage, index, compression and encoding techniques to improve computing
+efficiency,in turn it will help speedup queries an order of magnitude faster over PetaBytes of data.
+
+We use a review-then-commit workflow in CarbonData for all contributions.
+
+* Engage -> Design -> Code -> Review -> Commit
+
+## Engage
+
+### Mailing list(s)
+
+We discuss design and implementation issues on dev@carbondata.apache.org Join by
+emailing dev-subscribe@carbondata.apache.org
+
+### Apache JIRA
+
+We use [Apache JIRA](https://issues.apache.org/jira/browse/CARBONDATA) as an issue tracking and
+project management tool, as well as a way to communicate among a very diverse and distributed set
+of contributors. To be able to gather feedback, avoid frustration, and avoid duplicated efforts all
+CarbonData-related work should be tracked there.
+
+If you do not already have an Apache JIRA account, sign up [here](https://issues.apache.org/jira/).
+
+If a quick search doesn’t turn up an existing JIRA issue for the work you want to contribute,
+create it. Please discuss your proposal with a committer or the component lead in JIRA or,
+alternatively, on the developer mailing list(dev@carbondata.apache.org).
+
+If there’s an existing JIRA issue for your intended contribution, please comment about your
+intended work. Once the work is understood, a committer will assign the issue to you.
+(If you don’t have a JIRA role yet, you’ll be added to the “contributor” role.) If an issue is
+currently assigned, please check with the current assignee before reassigning.
+
+For moderate or large contributions, you should not start coding or writing a design doc unless
+there is a corresponding JIRA issue assigned to you for that work. Simple changes,
+like fixing typos, do not require an associated issue.
+
+### Design
+
+To clearly express your thoughts and get early feedback from other community members, we encourage you to clearly scope, document the design of non-trivial contributions and discuss with the CarbonData community before you start coding.
+
+Generally, the JIRA issue is the best place to gather relevant design docs, comments, or references. It’s great to explicitly include relevant stakeholders early in the conversation. For designs that may be generally interesting, we also encourage conversations on the developer’s mailing list.
+
+### Code
+
+We use GitHub’s pull request functionality to review proposed code changes.
+If you do not already have a personal GitHub account, sign up [here](https://github.com).
+
+### Git config
+
+Ensure to finish the below config(user.email, user.name) before starting PR works.
+```
+$ git config --global user.email "you@example.com"
+$ git config --global user.name "Your Name"
+```
+
+#### Fork the repository on GitHub
+
+Go to the [Apache CarbonData GitHub mirror](https://github.com/apache/carbondata) and
+fork the repository to your account.
+This will be your private workspace for staging changes.
+
+#### Clone the repository locally
+
+You are now ready to create the development environment on your local machine.
+Clone CarbonData’s read-only GitHub mirror.
+```
+$ git clone https://github.com/apache/carbondata.git
+$ cd carbondata
+```
+Add your forked repository as an additional Git remote, where you’ll push your changes.
+```
+$ git remote add <GitHub_user> https://github.com/<GitHub_user>/carbondata.git
+```
+You are now ready to start developing!
+
+#### Create a branch in your fork
+
+You’ll work on your contribution in a branch in your own (forked) repository. Create a local branch,
+initialized with the state of the branch you expect your changes to be merged into.
+Keep in mind that we use several branches, including master, feature-specific, and
+release-specific branches. If you are unsure, initialize with the state of the master branch.
+```
+$ git fetch --all
+$ git checkout -b <my-branch> origin/master
+```
+At this point, you can start making and committing changes to this branch in a standard way.
+
+#### Syncing and pushing your branch
+
+Periodically while you work, and certainly before submitting a pull request, you should update
+your branch with the most recent changes to the target branch.
+```
+$ git pull --rebase
+```
+Remember to always use --rebase parameter to avoid extraneous merge commits.
+
+To push your local, committed changes to your (forked) repository on GitHub, run:
+```
+$ git push <GitHub_user> <my-branch>
+```
+#### Testing
+
+All code should have appropriate unit testing coverage. New code should have new tests in the
+same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
+
+For contributions to the Java code, run unit tests locally via Maven.
+```
+$ mvn clean verify
+```
+
+### Review
+
+Once the initial code is complete and the tests pass, it’s time to start the code review process.
+We review and discuss all code, no matter who authors it. It’s a great way to build community,
+since you can learn from other developers, and they become familiar with your contribution.
+It also builds a strong project by encouraging a high quality bar and keeping code consistent
+throughout the project.
+
+#### Create a pull request
+
+Organize your commits to make your reviewer’s job easier. Use the following command to
+re-order, squash, edit, or change description of individual commits.
+```
+$ git rebase -i origin/master
+```
+Navigate to the CarbonData GitHub mirror to create a pull request. The title of the pull request
+should be strictly in the following format:
+```
+[CARBONDATA-JiraTicketNumer][FeatureName] Description of pull request
+```
+Please include a descriptive pull request message to help make the reviewer’s job easier:
+```
+ - The root cause/problem statement
+ - What is the implemented solution
+ ```
+
+If you know a good committer to review your pull request, please make a comment like the following.
+If not, don’t worry, a committer will pick it up.
+```
+Hi @<committer/reviewer name>, can you please take a look?
+```
+
+#### Code Review and Revision
+
+During the code review process, don’t rebase your branch or otherwise modify published commits,
+since this can remove existing comment history and be confusing to the reviewer,
+When you make a revision, always push it in a new commit.
+
+Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins.
+Please make sure those tests pass,the contribution cannot be merged otherwise.
+
+#### LGTM
+Once the reviewer is happy with the change, they’ll respond with an LGTM (“looks good to me!”).
+At this point, the committer will take over, possibly make some additional touch ups,
+and merge your changes into the codebase.
+
+In the case both the author and the reviewer are committers, either can merge the pull request.
+Just be sure to communicate clearly whose responsibility it is in this particular case.
+
+Thank you for your contribution to Apache CarbonData!
+
+#### Deleting your branch(optional)
+Once the pull request is merged into the Apache CarbonData repository, you can safely delete the
+branch locally and purge it from your forked repository.
+
+From another local branch, run:
+```
+$ git fetch --all
+$ git branch -d <my-branch>
+$ git push <GitHub_user> --delete <my-branch>
+```
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-1_1.png
----------------------------------------------------------------------
diff --git a/docs/images/2-1_1.png b/docs/images/2-1_1.png
new file mode 100644
index 0000000..676e041
Binary files /dev/null and b/docs/images/2-1_1.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-2_1.png
----------------------------------------------------------------------
diff --git a/docs/images/2-2_1.png b/docs/images/2-2_1.png
new file mode 100644
index 0000000..3369d45
Binary files /dev/null and b/docs/images/2-2_1.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-3_1.png
----------------------------------------------------------------------
diff --git a/docs/images/2-3_1.png b/docs/images/2-3_1.png
new file mode 100644
index 0000000..bdd346e
Binary files /dev/null and b/docs/images/2-3_1.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-3_2.png
----------------------------------------------------------------------
diff --git a/docs/images/2-3_2.png b/docs/images/2-3_2.png
new file mode 100644
index 0000000..b5b33aa
Binary files /dev/null and b/docs/images/2-3_2.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-3_3.png
----------------------------------------------------------------------
diff --git a/docs/images/2-3_3.png b/docs/images/2-3_3.png
new file mode 100644
index 0000000..be39323
Binary files /dev/null and b/docs/images/2-3_3.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-3_4.png
----------------------------------------------------------------------
diff --git a/docs/images/2-3_4.png b/docs/images/2-3_4.png
new file mode 100644
index 0000000..6da4cc1
Binary files /dev/null and b/docs/images/2-3_4.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-4_1.png
----------------------------------------------------------------------
diff --git a/docs/images/2-4_1.png b/docs/images/2-4_1.png
new file mode 100644
index 0000000..52b3b42
Binary files /dev/null and b/docs/images/2-4_1.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-5_1.png
----------------------------------------------------------------------
diff --git a/docs/images/2-5_1.png b/docs/images/2-5_1.png
new file mode 100644
index 0000000..b219d8b
Binary files /dev/null and b/docs/images/2-5_1.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-5_2.png
----------------------------------------------------------------------
diff --git a/docs/images/2-5_2.png b/docs/images/2-5_2.png
new file mode 100644
index 0000000..ca9d627
Binary files /dev/null and b/docs/images/2-5_2.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-5_3.png
----------------------------------------------------------------------
diff --git a/docs/images/2-5_3.png b/docs/images/2-5_3.png
new file mode 100644
index 0000000..27aaca8
Binary files /dev/null and b/docs/images/2-5_3.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/2-6_1.png
----------------------------------------------------------------------
diff --git a/docs/images/2-6_1.png b/docs/images/2-6_1.png
new file mode 100644
index 0000000..d61c084
Binary files /dev/null and b/docs/images/2-6_1.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/images/carbondata-performance.png
----------------------------------------------------------------------
diff --git a/docs/images/carbondata-performance.png b/docs/images/carbondata-performance.png
new file mode 100644
index 0000000..eee7bf6
Binary files /dev/null and b/docs/images/carbondata-performance.png differ
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/introduction.md
----------------------------------------------------------------------
diff --git a/docs/introduction.md b/docs/introduction.md
new file mode 100644
index 0000000..434ccfa
--- /dev/null
+++ b/docs/introduction.md
@@ -0,0 +1,117 @@
+## What is CarbonData
+
+CarbonData is a fully indexed columnar and Hadoop native data-store for processing heavy analytical workloads and detailed queries on big data with Spark SQL. CarbonData allows faster interactive queries over PetaBytes of data.
+
+
+
+## What does this mean
+
+CarbonData has specially engineered optimizations like multi level indexing, compression and encoding techniques targeted to improve performance of analytical queries which can include filters, aggregation and distinct counts where users expect sub second response time for queries on TB level data on commodity hardware clusters with just a few nodes.
+
+CarbonData has
+
+- **Unique data organisation** for faster retrievals and minimise amount of data retrieved
+
+- **Advanced push down optimisations** for deep integration with Spark so as to improvise the Spark DataSource API and other experimental features thereby ensure computing is performed close to the data to minimise amount of data read, processed, converted and transmitted(shuffled)
+
+- **Multi level indexing** to efficiently prune the files and data to be scanned and hence reduce I/O scans and CPU processing
+
+## CarbonData Features & Functions
+
+CarbonData has rich set of featues to support various use cases in Big Data analytics.The below table lists the major features supported by CarbonData.
+
+
+
+### Table Management
+
+- ##### DDL (Create, Alter,Drop,CTAS)
+
+ CarbonData provides its own DDL to create and manage carbondata tables.These DDL conform to Hive,Spark SQL format and support additional properties and configuration to take advantages of CarbonData functionalities.
+
+- ##### DML(Load,Insert)
+
+ CarbonData provides its own DML to manage data in carbondata tables.It adds many customizations through configurations to completely customize the behavior as per user requirement scenarios.
+
+- ##### Update and Delete
+
+ CarbonData supports Update and Delete on Big Data.CarbonData provides the syntax similar to Hive to support IUD operations on CarbonData tables.
+
+- ##### Segment Management
+
+ CarbonData has unique concept of segments to manage incremental loads to CarbonData tables effectively.Segment management helps to easily control the table, perform easy retention, and is also used to provide transaction capability for operations being performed.
+
+- ##### Partition
+
+ CarbonData supports 2 kinds of partitions.1.partition similar to hive partition.2.CarbonData partition supporting hash,list,range partitioning.
+
+- ##### Compaction
+
+ CarbonData manages incremental loads as segments.Compaction help to compact the growing number of segments and also to improve query filter pruning.
+
+- ##### External Tables
+
+ CarbonData can read any carbondata file and automatically infer schema from the file and provide a relational table view to perform sql queries using Spark or any other applicaion.
+
+### DataMaps
+
+- ##### Pre-Aggregate
+
+ CarbonData has concept of datamaps to assist in pruning of data while querying so that performance is faster.Pre Aggregate tables are kind of datamaps which can improve the query performance by order of magnitude.CarbonData will automatically pre-aggregae the incremental data and re-write the query to automatically fetch from the most appropriate pre-aggregate table to serve the query faster.
+
+- ##### Time Series
+
+ CarbonData has built in understanding of time order(Year, month,day,hour, minute,second).Time series is a pre-aggregate table which can automatically roll-up the data to the desired level during incremental load and serve the query from the most appropriate pre-aggregate table.
+
+- ##### Bloom filter
+
+ CarbonData supports bloom filter as a datamap in order to quickly and efficiently prune the data for scanning and acheive faster query performance.
+
+- ##### Lucene
+
+ Lucene is popular for indexing text data which are long.CarbonData provides a lucene datamap so that text columns can be indexed using lucene and use the index result for efficient pruning of data to be retrieved during query.
+
+- ##### MV (Materialized Views)
+
+ MVs are kind of pre-aggregate tables which can support efficent query re-write and processing.CarbonData provides MV which can rewrite query to fetch from any table(including non-carbondata tables).Typical usecase is to store the aggregated data of a non-carbondata fact table into carbondata and use mv to rewrite the query to fetch from carbondata.
+
+### Streaming
+
+- ##### Spark Streaming
+
+ CarbonData supports streaming of data into carbondata in near-realtime and make it immediately available for query.CarbonData provides a DSL to create source and sink tables easily without the need for the user to write his application.
+
+### SDK
+
+- ##### CarbonData writer
+
+ CarbonData supports writing data from non-spark application using SDK.Users can use SDK to generate carbondata files from custom applications.Typical usecase is to write the streaming application plugged in to kafka and use carbondata as sink(target) table for storing.
+
+- ##### CarbonData reader
+
+ CarbonData supports reading of data from non-spark application using SDK.Users can use the SDK to read the carbondata files from their application and do custom processing.
+
+### Storage
+
+- ##### S3
+
+ CarbonData can write to S3, OBS or any cloud storage confirming to S3 protocol.CarbonData uses the HDFS api to write to cloud object stores.
+
+- ##### HDFS
+
+ CarbonData uses HDFS api to write and read data from HDFS.CarbonData can take advantage of the locality information to efficiently suggest spark to run tasks near to the data.
+
+
+
+## Integration with Big Data ecosystem
+
+Refer to Integration with [Spark](./quick-start-guide.md#spark), [Presto](./quick-start-guide.md#presto) for detailed information on integrating CarbonData with these execution engines.
+
+## Scenarios where CarbonData is suitable
+
+CarbonData is useful in various analytical work loads.Some of the most typical usecases where CarbonData is being used is [documented here](./usecases.md).
+
+
+
+## Performance Results
+
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/language-manual.md
----------------------------------------------------------------------
diff --git a/docs/language-manual.md b/docs/language-manual.md
new file mode 100644
index 0000000..123cae3
--- /dev/null
+++ b/docs/language-manual.md
@@ -0,0 +1,39 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Overview
+
+
+
+CarbonData has its own parser, in addition to Spark's SQL Parser, to parse and process certain Commands related to CarbonData table handling. You can interact with the SQL interface using the [command-line](https://spark.apache.org/docs/latest/sql-programming-guide.html#running-the-spark-sql-cli) or over [JDBC/ODBC](https://spark.apache.org/docs/latest/sql-programming-guide.html#running-the-thrift-jdbcodbc-server).
+
+- [Data Types](./supported-data-types-in-carbondata.md)
+- Data Definition Statements
+ - [DDL:](./ddl-of-carbondata.md)[Create](./ddl-of-carbondata.md#create-table),[Drop](./ddl-of-carbondata.md#drop-table),[Partition](./ddl-of-carbondata.md#partition),[Bucketing](./ddl-of-carbondata.md#bucketing),[Alter](./ddl-of-carbondata.md#alter-table),[CTAS](./ddl-of-carbondata.md#create-table-as-select),[External Table](./ddl-of-carbondata.md#create-external-table)
+ - [DataMaps](./datamap/datamap-management.md)
+ - [Bloom](./datamap/bloomfilter-datamap-guide.md)
+ - [Lucene](./datamap/lucene-datamap-guide.md)
+ - [Pre-Aggregate](./datamap/preaggregate-datamap-guide.md)
+ - [Time Series](./datamap/timeseries-datamap-guide.md)
+ - Materialized Views (MV)
+ - [Streaming](./streaming-guide.md)
+- Data Manipulation Statements
+ - [DML:](./dml-of-carbondata.md) [Load](./dml-of-carbondata.md#load-data), [Insert](./ddl-of-carbondata.md#insert-overwrite), [Update](./dml-of-carbondata.md#update), [Delete](./dml-of-carbondata.md#delete)
+ - [Segment Management](./segment-management-on-carbondata.md)
+- [Configuration Properties](./configuration-parameters.md)
+
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/performance-tuning.md
----------------------------------------------------------------------
diff --git a/docs/performance-tuning.md b/docs/performance-tuning.md
new file mode 100644
index 0000000..f56a63b
--- /dev/null
+++ b/docs/performance-tuning.md
@@ -0,0 +1,246 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Useful Tips
+ This tutorial guides you to create CarbonData Tables and optimize performance.
+ The following sections will elaborate on the below topics :
+
+ * [Suggestions to create CarbonData Table](#suggestions-to-create-carbondata-table)
+ * [Configuration for Optimizing Data Loading performance for Massive Data](#configuration-for-optimizing-data-loading-performance-for-massive-data)
+ * [Optimizing Query Performance](#configurations-for-optimizing-carbondata-performance)
+ * [Compaction Configurations for Optimizing CarbonData Query Performance](#compaction-configurations-for-optimizing-carbondata-query-performance)
+
+## Suggestions to Create CarbonData Table
+
+ For example, the results of the analysis for table creation with dimensions ranging from 10 thousand to 10 billion rows and 100 to 300 columns have been summarized below.
+ The following table describes some of the columns from the table used.
+
+ - **Table Column Description**
+
+| Column Name | Data Type | Cardinality | Attribution |
+|-------------|---------------|-------------|-------------|
+| msisdn | String | 30 million | Dimension |
+| BEGIN_TIME | BigInt | 10 Thousand | Dimension |
+| HOST | String | 1 million | Dimension |
+| Dime_1 | String | 1 Thousand | Dimension |
+| counter_1 | Decimal | NA | Measure |
+| counter_2 | Numeric(20,0) | NA | Measure |
+| ... | ... | NA | Measure |
+| counter_100 | Decimal | NA | Measure |
+
+
+ - **Put the frequently-used column filter in the beginning of SORT_COLUMNS**
+
+ For example, MSISDN filter is used in most of the query then we must put the MSISDN as the first column in SORT_COLUMNS property.
+ The create table command can be modified as suggested below :
+
+ ```
+ create table carbondata_table(
+ msisdn String,
+ BEGIN_TIME bigint,
+ HOST String,
+ Dime_1 String,
+ counter_1, Decimal
+ ...
+
+ )STORED AS carbondata
+ TBLPROPERTIES ('SORT_COLUMNS'='msisdn, Dime_1')
+ ```
+
+ Now the query with MSISDN in the filter will be more efficient.
+
+ - **Put the frequently-used columns in the order of low to high cardinality in SORT_COLUMNS**
+
+ If the table in the specified query has multiple columns which are frequently used to filter the results, it is suggested to put
+ the columns in the order of cardinality low to high in SORT_COLUMNS configuration. This ordering of frequently used columns improves the compression ratio and
+ enhances the performance of queries with filter on these columns.
+
+ For example, if MSISDN, HOST and Dime_1 are frequently-used columns, then the column order of table is suggested as
+ Dime_1>HOST>MSISDN, because Dime_1 has the lowest cardinality.
+ The create table command can be modified as suggested below :
+
+ ```
+ create table carbondata_table(
+ msisdn String,
+ BEGIN_TIME bigint,
+ HOST String,
+ Dime_1 String,
+ counter_1, Decimal
+ ...
+
+ )STORED AS carbondata
+ TBLPROPERTIES ('SORT_COLUMNS'='Dime_1, HOST, MSISDN')
+ ```
+
+ - **For measure type columns with non high accuracy, replace Numeric(20,0) data type with Double data type**
+
+ For columns of measure type, not requiring high accuracy, it is suggested to replace Numeric data type with Double to enhance query performance.
+ The create table command can be modified as below :
+
+```
+ create table carbondata_table(
+ Dime_1 String,
+ BEGIN_TIME bigint,
+ END_TIME bigint,
+ HOST String,
+ MSISDN String,
+ counter_1 decimal,
+ counter_2 double,
+ ...
+ )STORED AS carbondata
+ TBLPROPERTIES ('SORT_COLUMNS'='Dime_1, HOST, MSISDN')
+```
+ The result of performance analysis of test-case shows reduction in query execution time from 15 to 3 seconds, thereby improving performance by nearly 5 times.
+
+ - **Columns of incremental character should be re-arranged at the end of dimensions**
+
+ Consider the following scenario where data is loaded each day and the begin_time is incremental for each load, it is suggested to put begin_time at the end of dimensions.
+ Incremental values are efficient in using min/max index. The create table command can be modified as below :
+
+ ```
+ create table carbondata_table(
+ Dime_1 String,
+ HOST String,
+ MSISDN String,
+ counter_1 double,
+ counter_2 double,
+ BEGIN_TIME bigint,
+ END_TIME bigint,
+ ...
+ counter_100 double
+ )STORED AS carbondata
+ TBLPROPERTIES ('SORT_COLUMNS'='Dime_1, HOST, MSISDN')
+ ```
+
+ **NOTE:**
+ + BloomFilter can be created to enhance performance for queries with precise equal/in conditions. You can find more information about it in BloomFilter datamap [document](./datamap/bloomfilter-datamap-guide.md).
+
+
+## Configuration for Optimizing Data Loading performance for Massive Data
+
+
+ CarbonData supports large data load, in this process sorting data while loading consumes a lot of memory and disk IO and
+ this can result sometimes in "Out Of Memory" exception.
+ If you do not have much memory to use, then you may prefer to slow the speed of data loading instead of data load failure.
+ You can configure CarbonData by tuning following properties in carbon.properties file to get a better performance.
+
+| Parameter | Default Value | Description/Tuning |
+|-----------|-------------|--------|
+|carbon.number.of.cores.while.loading|Default: 2.This value should be >= 2|Specifies the number of cores used for data processing during data loading in CarbonData. |
+|carbon.sort.size|Default: 100000. The value should be >= 100.|Threshold to write local file in sort step when loading data|
+|carbon.sort.file.write.buffer.size|Default: 50000.|DataOutputStream buffer. |
+|carbon.merge.sort.reader.thread|Default: 3 |Specifies the number of cores used for temp file merging during data loading in CarbonData.|
+|carbon.merge.sort.prefetch|Default: true | You may want set this value to false if you have not enough memory|
+
+ For example, if there are 10 million records, and i have only 16 cores, 64GB memory, will be loaded to CarbonData table.
+ Using the default configuration always fail in sort step. Modify carbon.properties as suggested below:
+
+ ```
+ carbon.merge.sort.reader.thread=1
+ carbon.sort.size=5000
+ carbon.sort.file.write.buffer.size=5000
+ carbon.merge.sort.prefetch=false
+ ```
+
+## Configurations for Optimizing CarbonData Performance
+
+ Recently we did some performance POC on CarbonData for Finance and telecommunication Field. It involved detailed queries and aggregation
+ scenarios. After the completion of POC, some of the configurations impacting the performance have been identified and tabulated below :
+
+| Parameter | Location | Used For | Description | Tuning |
+|----------------------------------------------|-----------------------------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| carbon.sort.intermediate.files.limit | spark/carbonlib/carbon.properties | Data loading | During the loading of data, local temp is used to sort the data. This number specifies the minimum number of intermediate files after which the merge sort has to be initiated. | Increasing the parameter to a higher value will improve the load performance. For example, when we increase the value from 20 to 100, it increases the data load performance from 35MB/S to more than 50MB/S. Higher values of this parameter consumes more memory during the load. |
+| carbon.number.of.cores.while.loading | spark/carbonlib/carbon.properties | Data loading | Specifies the number of cores used for data processing during data loading in CarbonData. | If you have more number of CPUs, then you can increase the number of CPUs, which will increase the performance. For example if we increase the value from 2 to 4 then the CSV reading performance can increase about 1 times |
+| carbon.compaction.level.threshold | spark/carbonlib/carbon.properties | Data loading and Querying | For minor compaction, specifies the number of segments to be merged in stage 1 and number of compacted segments to be merged in stage 2. | Each CarbonData load will create one segment, if every load is small in size it will generate many small file over a period of time impacting the query performance. Configuring this parameter will merge the small segment to one big segment which will sort the data and improve the performance. For Example in one telecommunication scenario, the performance improves about 2 times after minor compaction. |
+| spark.sql.shuffle.partitions | spark/conf/spark-defaults.conf | Querying | The number of task started when spark shuffle. | The value can be 1 to 2 times as much as the executor cores. In an aggregation scenario, reducing the number from 200 to 32 reduced the query time from 17 to 9 seconds. |
+| spark.executor.instances/spark.executor.cores/spark.executor.memory | spark/conf/spark-defaults.conf | Querying | The number of executors, CPU cores, and memory used for CarbonData query. | In the bank scenario, we provide the 4 CPUs cores and 15 GB for each executor which can get good performance. This 2 value does not mean more the better. It needs to be configured properly in case of limited resources. For example, In the bank scenario, it has enough CPU 32 cores each node but less memory 64 GB each node. So we cannot give more CPU but less memory. For example, when 4 cores and 12GB for each executor. It sometimes happens GC during the query which impact the query performance very much from the 3 second to more than 15 seconds. In this scenario need to increase the memory or decrease the CPU cores. |
+| carbon.detail.batch.size | spark/carbonlib/carbon.properties | Data loading | The buffer size to store records, returned from the block scan. | In limit scenario this parameter is very important. For example your query limit is 1000. But if we set this value to 3000 that means we get 3000 records from scan but spark will only take 1000 rows. So the 2000 remaining are useless. In one Finance test case after we set it to 100, in the limit 1000 scenario the performance increase about 2 times in comparison to if we set this value to 12000. |
+| carbon.use.local.dir | spark/carbonlib/carbon.properties | Data loading | Whether use YARN local directories for multi-table load disk load balance | If this is set it to true CarbonData will use YARN local directories for multi-table load disk load balance, that will improve the data load performance. |
+| carbon.use.multiple.temp.dir | spark/carbonlib/carbon.properties | Data loading | Whether to use multiple YARN local directories during table data loading for disk load balance | After enabling 'carbon.use.local.dir', if this is set to true, CarbonData will use all YARN local directories during data load for disk load balance, that will improve the data load performance. Please enable this property when you encounter disk hotspot problem during data loading. |
+| carbon.sort.temp.compressor | spark/carbonlib/carbon.properties | Data loading | Specify the name of compressor to compress the intermediate sort temporary files during sort procedure in data loading. | The optional values are 'SNAPPY','GZIP','BZIP2','LZ4','ZSTD' and empty. By default, empty means that Carbondata will not compress the sort temp files. This parameter will be useful if you encounter disk bottleneck. |
+| carbon.load.skewedDataOptimization.enabled | spark/carbonlib/carbon.properties | Data loading | Whether to enable size based block allocation strategy for data loading. | When loading, carbondata will use file size based block allocation strategy for task distribution. It will make sure that all the executors process the same size of data -- It's useful if the size of your input data files varies widely, say 1MB~1GB. |
+| carbon.load.min.size.enabled | spark/carbonlib/carbon.properties | Data loading | Whether to enable node minumun input data size allocation strategy for data loading.| When loading, carbondata will use node minumun input data size allocation strategy for task distribution. It will make sure the node load the minimum amount of data -- It's useful if the size of your input data files very small, say 1MB~256MB,Avoid generating a large number of small files. |
+
+ Note: If your CarbonData instance is provided only for query, you may specify the property 'spark.speculation=true' which is in conf directory of spark.
+
+## Compaction Configurations for Optimizing CarbonData Query Performance
+
+CarbonData provides many configurations to tune the compaction behavior so that query peformance is improved.
+
+
+
+Based on the number of cores available in the node, it is recommended to tune the configuration ***carbon.number.of.cores.while.compacting*** appropriately.Configuring a higher value will improve the overall compaction performance.
+
+<p> </p>
+<table style="width: 777px;">
+<tbody>
+<tr style="height: 23px;">
+<td style="height: 23px; width: 95.375px;">No</td>
+<td style="height: 23px; width: 299.625px;"> Data Loading frequency</td>
+<td style="height: 23px; width: 144px;">Data Size of each load</td>
+<td style="height: 23px; width: 204px;">Minor Compaction configuration</td>
+<td style="height: 23px; width: 197px;"> Major compaction configuration</td>
+</tr>
+<tr style="height: 29.5px;">
+<td style="height: 29.5px; width: 95.375px;">1</td>
+<td style="height: 29.5px; width: 299.625px;"> Batch(Once is several Hours)</td>
+<td style="height: 29.5px; width: 144px;">Big</td>
+<td style="height: 29.5px; width: 204px;"> Not Suggested</td>
+<td style="height: 29.5px; width: 197px;">Configure Major Compaction size of 3-4 load size.Perform Major compaction once in a day</td>
+</tr>
+<tr style="height: 23px;">
+<td style="height: 23px; width: 95.375px;" rowspan="2">2</td>
+<td style="height: 23px; width: 299.625px;" rowspan="2"> Batch(Once in few minutes) </td>
+<td style="height: 23px; width: 144px;">Big </td>
+<td style="height: 23px; width: 204px;">
+<p> Minor compaction (2,2).</p>
+<p>Enable Auto compaction, if high rate data loading speed is not required or the time between loads is sufficient to run the compaction</p>
+</td>
+<td style="height: 23px; width: 197px;">Major compaction size of 10 load size.Perform Major compaction once in a day</td>
+</tr>
+<tr style="height: 23px;">
+<td style="height: 23px; width: 144px;">Small</td>
+<td style="height: 23px; width: 204px;">
+<p>Minor compaction (6,6).</p>
+<p>Enable Auto compaction, if high rate data loading speed is not required or the time between loads is sufficient to run the compaction</p>
+</td>
+<td style="height: 23px; width: 197px;">Major compaction size of 10 load size.Perform Major compaction once in a day</td>
+</tr>
+<tr style="height: 23px;">
+<td style="height: 23px; width: 95.375px;">3</td>
+<td style="height: 23px; width: 299.625px;"> History data loaded as single load,incremental loads matches (1) or (2)</td>
+<td style="height: 23px; width: 144px;">Big</td>
+<td style="height: 23px; width: 204px;">
+<p> Configure ALLOWED_COMPACTION_DAYS to exclude the History load.</p>
+<p>Configure Minor compaction configuration based condition (1) or (2)</p>
+</td>
+<td style="height: 23px; width: 197px;"> Configure Major compaction size smaller than the history load size.</td>
+</tr>
+<tr style="height: 23px;">
+<td style="height: 23px; width: 95.375px;">4</td>
+<td style="height: 23px; width: 299.625px;"> There can be error in recent data loaded.Need reload sometimes</td>
+<td style="height: 23px; width: 144px;"> (1) or (2)</td>
+<td style="height: 23px; width: 204px;">
+<p> Configure COMPACTION_PRESERVE_SEGMENTS</p>
+<p>to exclude the recent few segments from compacting.</p>
+<p>Configure Minor compaction configuration based condition (1) or (2)</p>
+</td>
+<td style="height: 23px; width: 197px;">Same as (1) or (2) </td>
+</tr>
+</tbody>
+</table>
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/quick-start-guide.md
----------------------------------------------------------------------
diff --git a/docs/quick-start-guide.md b/docs/quick-start-guide.md
index 1b3ffc2..37c398c 100644
--- a/docs/quick-start-guide.md
+++ b/docs/quick-start-guide.md
@@ -19,9 +19,9 @@
This tutorial provides a quick introduction to using CarbonData.To follow along with this guide, first download a packaged release of CarbonData from the [CarbonData website](https://dist.apache.org/repos/dist/release/carbondata/).Alternatively it can be created following [Building CarbonData](https://github.com/apache/carbondata/tree/master/build) steps.
## Prerequisites
-* Spark 2.2.1 version is installed and running.CarbonData supports Spark versions upto 2.2.1.Please follow steps described in [Spark docs website](https://spark.apache.org/docs/latest) for installing and running Spark.
+* CarbonData supports Spark versions upto 2.2.1.Please download Spark package from [Spark website](https://spark.apache.org/downloads.html)
-* Create a sample.csv file using the following commands. The CSV file is required for loading data into CarbonData.
+* Create a sample.csv file using the following commands. The CSV file is required for loading data into CarbonData
```
cd carbondata
@@ -33,7 +33,27 @@ This tutorial provides a quick introduction to using CarbonData.To follow along
EOF
```
-## Interactive Analysis with Spark Shell Version 2.1
+## Integration
+
+CarbonData can be integrated with Spark and Presto Execution Engines.The below documentation guides on Installing and Configuring with these execution engines.
+
+### Spark
+
+[Installing and Configuring CarbonData to run locally with Spark Shell](#installing-and-configuring-carbondata-to-run-locally-with-spark-shell)
+
+[Installing and Configuring CarbonData on Standalone Spark Cluster](#installing-and-configuring-carbondata-on-standalone-spark-cluster)
+
+[Installing and Configuring CarbonData on Spark on YARN Cluster](#installing-and-configuring-carbondata-on-spark-on-yarn-cluster)
+
+[Installing and Configuring CarbonData Thrift Server for Query Execution](#query-execution-using-carbondata-thrift-server)
+
+
+### Presto
+[Installing and Configuring CarbonData on Presto](#installing-and-configuring-carbondata-on-presto)
+
+
+
+## Installing and Configuring CarbonData to run locally with Spark Shell
Apache Spark Shell provides a simple way to learn the API, as well as a powerful tool to analyze data interactively. Please visit [Apache Spark Documentation](http://spark.apache.org/docs/latest/) for more details on Spark shell.
@@ -72,12 +92,12 @@ val carbon = SparkSession.builder().config(sc.getConf)
```
scala>carbon.sql("CREATE TABLE
- IF NOT EXISTS test_table(
- id string,
- name string,
- city string,
- age Int)
- STORED BY 'carbondata'")
+ IF NOT EXISTS test_table(
+ id string,
+ name string,
+ city string,
+ age Int)
+ STORED AS carbondata")
```
###### Loading Data to a Table
@@ -87,7 +107,7 @@ scala>carbon.sql("LOAD DATA INPATH '/path/to/sample.csv'
INTO TABLE test_table")
```
**NOTE**: Please provide the real file path of `sample.csv` for the above script.
-If you get "tablestatus.lock" issue, please refer to [troubleshooting](troubleshooting.md)
+If you get "tablestatus.lock" issue, please refer to [FAQ](faq.md)
###### Query Data from a Table
@@ -98,3 +118,341 @@ scala>carbon.sql("SELECT city, avg(age), sum(age)
FROM test_table
GROUP BY city").show()
```
+
+
+
+## Installing and Configuring CarbonData on Standalone Spark Cluster
+
+### Prerequisites
+
+- Hadoop HDFS and Yarn should be installed and running.
+- Spark should be installed and running on all the cluster nodes.
+- CarbonData user should have permission to access HDFS.
+
+### Procedure
+
+1. [Build the CarbonData](https://github.com/apache/carbondata/blob/master/build/README.md) project and get the assembly jar from `./assembly/target/scala-2.1x/carbondata_xxx.jar`.
+
+2. Copy `./assembly/target/scala-2.1x/carbondata_xxx.jar` to `$SPARK_HOME/carbonlib` folder.
+
+ **NOTE**: Create the carbonlib folder if it does not exist inside `$SPARK_HOME` path.
+
+3. Add the carbonlib folder path in the Spark classpath. (Edit `$SPARK_HOME/conf/spark-env.sh` file and modify the value of `SPARK_CLASSPATH` by appending `$SPARK_HOME/carbonlib/*` to the existing value)
+
+4. Copy the `./conf/carbon.properties.template` file from CarbonData repository to `$SPARK_HOME/conf/` folder and rename the file to `carbon.properties`.
+
+5. Repeat Step 2 to Step 5 in all the nodes of the cluster.
+
+6. In Spark node[master], configure the properties mentioned in the following table in `$SPARK_HOME/conf/spark-defaults.conf` file.
+
+| Property | Value | Description |
+| ------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| spark.driver.extraJavaOptions | `-Dcarbon.properties.filepath = $SPARK_HOME/conf/carbon.properties` | A string of extra JVM options to pass to the driver. For instance, GC settings or other logging. |
+| spark.executor.extraJavaOptions | `-Dcarbon.properties.filepath = $SPARK_HOME/conf/carbon.properties` | A string of extra JVM options to pass to executors. For instance, GC settings or other logging. **NOTE**: You can enter multiple values separated by space. |
+
+1. Add the following properties in `$SPARK_HOME/conf/carbon.properties` file:
+
+| Property | Required | Description | Example | Remark |
+| -------------------- | -------- | ------------------------------------------------------------ | ------------------------------------ | ----------------------------- |
+| carbon.storelocation | NO | Location where data CarbonData will create the store and write the data in its own format. If not specified then it takes spark.sql.warehouse.dir path. | hdfs://HOSTNAME:PORT/Opt/CarbonStore | Propose to set HDFS directory |
+
+1. Verify the installation. For example:
+
+```
+./spark-shell --master spark://HOSTNAME:PORT --total-executor-cores 2
+--executor-memory 2G
+```
+
+**NOTE**: Make sure you have permissions for CarbonData JARs and files through which driver and executor will start.
+
+
+
+## Installing and Configuring CarbonData on Spark on YARN Cluster
+
+ This section provides the procedure to install CarbonData on "Spark on YARN" cluster.
+
+### Prerequisites
+
+- Hadoop HDFS and Yarn should be installed and running.
+- Spark should be installed and running in all the clients.
+- CarbonData user should have permission to access HDFS.
+
+### Procedure
+
+ The following steps are only for Driver Nodes. (Driver nodes are the one which starts the spark context.)
+
+1. [Build the CarbonData](https://github.com/apache/carbondata/blob/master/build/README.md) project and get the assembly jar from `./assembly/target/scala-2.1x/carbondata_xxx.jar` and copy to `$SPARK_HOME/carbonlib` folder.
+
+ **NOTE**: Create the carbonlib folder if it does not exists inside `$SPARK_HOME` path.
+
+2. Copy the `./conf/carbon.properties.template` file from CarbonData repository to `$SPARK_HOME/conf/` folder and rename the file to `carbon.properties`.
+
+3. Create `tar.gz` file of carbonlib folder and move it inside the carbonlib folder.
+
+```
+cd $SPARK_HOME
+tar -zcvf carbondata.tar.gz carbonlib/
+mv carbondata.tar.gz carbonlib/
+```
+
+1. Configure the properties mentioned in the following table in `$SPARK_HOME/conf/spark-defaults.conf` file.
+
+| Property | Description | Value |
+| ------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| spark.master | Set this value to run the Spark in yarn cluster mode. | Set yarn-client to run the Spark in yarn cluster mode. |
+| spark.yarn.dist.files | Comma-separated list of files to be placed in the working directory of each executor. | `$SPARK_HOME/conf/carbon.properties` |
+| spark.yarn.dist.archives | Comma-separated list of archives to be extracted into the working directory of each executor. | `$SPARK_HOME/carbonlib/carbondata.tar.gz` |
+| spark.executor.extraJavaOptions | A string of extra JVM options to pass to executors. For instance **NOTE**: You can enter multiple values separated by space. | `-Dcarbon.properties.filepath = carbon.properties` |
+| spark.executor.extraClassPath | Extra classpath entries to prepend to the classpath of executors. **NOTE**: If SPARK_CLASSPATH is defined in spark-env.sh, then comment it and append the values in below parameter spark.driver.extraClassPath | `carbondata.tar.gz/carbonlib/*` |
+| spark.driver.extraClassPath | Extra classpath entries to prepend to the classpath of the driver. **NOTE**: If SPARK_CLASSPATH is defined in spark-env.sh, then comment it and append the value in below parameter spark.driver.extraClassPath. | `$SPARK_HOME/carbonlib/*` |
+| spark.driver.extraJavaOptions | A string of extra JVM options to pass to the driver. For instance, GC settings or other logging. | `-Dcarbon.properties.filepath = $SPARK_HOME/conf/carbon.properties` |
+
+1. Add the following properties in `$SPARK_HOME/conf/carbon.properties`:
+
+| Property | Required | Description | Example | Default Value |
+| -------------------- | -------- | ------------------------------------------------------------ | ------------------------------------ | ----------------------------- |
+| carbon.storelocation | NO | Location where CarbonData will create the store and write the data in its own format. If not specified then it takes spark.sql.warehouse.dir path. | hdfs://HOSTNAME:PORT/Opt/CarbonStore | Propose to set HDFS directory |
+
+1. Verify the installation.
+
+```
+ ./bin/spark-shell --master yarn-client --driver-memory 1g
+ --executor-cores 2 --executor-memory 2G
+```
+
+ **NOTE**: Make sure you have permissions for CarbonData JARs and files through which driver and executor will start.
+
+
+
+## Query Execution Using CarbonData Thrift Server
+
+### Starting CarbonData Thrift Server.
+
+ a. cd `$SPARK_HOME`
+
+ b. Run the following command to start the CarbonData thrift server.
+
+```
+./bin/spark-submit
+--class org.apache.carbondata.spark.thriftserver.CarbonThriftServer
+$SPARK_HOME/carbonlib/$CARBON_ASSEMBLY_JAR <carbon_store_path>
+```
+
+| Parameter | Description | Example |
+| ------------------- | ------------------------------------------------------------ | ---------------------------------------------------------- |
+| CARBON_ASSEMBLY_JAR | CarbonData assembly jar name present in the `$SPARK_HOME/carbonlib/` folder. | carbondata_2.xx-x.x.x-SNAPSHOT-shade-hadoop2.7.2.jar |
+| carbon_store_path | This is a parameter to the CarbonThriftServer class. This a HDFS path where CarbonData files will be kept. Strongly Recommended to put same as carbon.storelocation parameter of carbon.properties. If not specified then it takes spark.sql.warehouse.dir path. | `hdfs://<host_name>:port/user/hive/warehouse/carbon.store` |
+
+**NOTE**: From Spark 1.6, by default the Thrift server runs in multi-session mode. Which means each JDBC/ODBC connection owns a copy of their own SQL configuration and temporary function registry. Cached tables are still shared though. If you prefer to run the Thrift server in single-session mode and share all SQL configuration and temporary function registry, please set option `spark.sql.hive.thriftServer.singleSession` to `true`. You may either add this option to `spark-defaults.conf`, or pass it to `spark-submit.sh` via `--conf`:
+
+```
+./bin/spark-submit
+--conf spark.sql.hive.thriftServer.singleSession=true
+--class org.apache.carbondata.spark.thriftserver.CarbonThriftServer
+$SPARK_HOME/carbonlib/$CARBON_ASSEMBLY_JAR <carbon_store_path>
+```
+
+**But** in single-session mode, if one user changes the database from one connection, the database of the other connections will be changed too.
+
+**Examples**
+
+- Start with default memory and executors.
+
+```
+./bin/spark-submit
+--class org.apache.carbondata.spark.thriftserver.CarbonThriftServer
+$SPARK_HOME/carbonlib
+/carbondata_2.xx-x.x.x-SNAPSHOT-shade-hadoop2.7.2.jar
+hdfs://<host_name>:port/user/hive/warehouse/carbon.store
+```
+
+- Start with Fixed executors and resources.
+
+```
+./bin/spark-submit
+--class org.apache.carbondata.spark.thriftserver.CarbonThriftServer
+--num-executors 3 --driver-memory 20g --executor-memory 250g
+--executor-cores 32
+/srv/OSCON/BigData/HACluster/install/spark/sparkJdbc/lib
+/carbondata_2.xx-x.x.x-SNAPSHOT-shade-hadoop2.7.2.jar
+hdfs://<host_name>:port/user/hive/warehouse/carbon.store
+```
+
+### Connecting to CarbonData Thrift Server Using Beeline.
+
+```
+ cd $SPARK_HOME
+ ./sbin/start-thriftserver.sh
+ ./bin/beeline -u jdbc:hive2://<thriftserver_host>:port
+
+ Example
+ ./bin/beeline -u jdbc:hive2://10.10.10.10:10000
+```
+
+
+
+## Installing and Configuring CarbonData on Presto
+
+**NOTE:** **CarbonData tables cannot be created nor loaded from Presto.User need to create CarbonData Table and load data into it
+either with [Spark](#installing-and-configuring-carbondata-to-run-locally-with-spark-shell) or [SDK](./sdk-guide.md).
+Once the table is created,it can be queried from Presto.**
+
+
+### Installing Presto
+
+ 1. Download the 0.187 version of Presto using:
+ `wget https://repo1.maven.org/maven2/com/facebook/presto/presto-server/0.187/presto-server-0.187.tar.gz`
+
+ 2. Extract Presto tar file: `tar zxvf presto-server-0.187.tar.gz`.
+
+ 3. Download the Presto CLI for the coordinator and name it presto.
+
+ ```
+ wget https://repo1.maven.org/maven2/com/facebook/presto/presto-cli/0.187/presto-cli-0.187-executable.jar
+
+ mv presto-cli-0.187-executable.jar presto
+
+ chmod +x presto
+ ```
+
+### Create Configuration Files
+
+ 1. Create `etc` folder in presto-server-0.187 directory.
+ 2. Create `config.properties`, `jvm.config`, `log.properties`, and `node.properties` files.
+ 3. Install uuid to generate a node.id.
+
+ ```
+ sudo apt-get install uuid
+
+ uuid
+ ```
+
+
+##### Contents of your node.properties file
+
+ ```
+ node.environment=production
+ node.id=<generated uuid>
+ node.data-dir=/home/ubuntu/data
+ ```
+
+##### Contents of your jvm.config file
+
+ ```
+ -server
+ -Xmx16G
+ -XX:+UseG1GC
+ -XX:G1HeapRegionSize=32M
+ -XX:+UseGCOverheadLimit
+ -XX:+ExplicitGCInvokesConcurrent
+ -XX:+HeapDumpOnOutOfMemoryError
+ -XX:OnOutOfMemoryError=kill -9 %p
+ ```
+
+##### Contents of your log.properties file
+ ```
+ com.facebook.presto=INFO
+ ```
+
+ The default minimum level is `INFO`. There are four levels: `DEBUG`, `INFO`, `WARN` and `ERROR`.
+
+### Coordinator Configurations
+
+##### Contents of your config.properties
+ ```
+ coordinator=true
+ node-scheduler.include-coordinator=false
+ http-server.http.port=8086
+ query.max-memory=50GB
+ query.max-memory-per-node=2GB
+ discovery-server.enabled=true
+ discovery.uri=<coordinator_ip>:8086
+ ```
+The options `node-scheduler.include-coordinator=false` and `coordinator=true` indicate that the node is the coordinator and tells the coordinator not to do any of the computation work itself and to use the workers.
+
+**Note**: It is recommended to set `query.max-memory-per-node` to half of the JVM config max memory, though the workload is highly concurrent, lower value for `query.max-memory-per-node` is to be used.
+
+Also relation between below two configuration-properties should be like:
+If, `query.max-memory-per-node=30GB`
+Then, `query.max-memory=<30GB * number of nodes>`.
+
+### Worker Configurations
+
+##### Contents of your config.properties
+
+ ```
+ coordinator=false
+ http-server.http.port=8086
+ query.max-memory=50GB
+ query.max-memory-per-node=2GB
+ discovery.uri=<coordinator_ip>:8086
+ ```
+
+**Note**: `jvm.config` and `node.properties` files are same for all the nodes (worker + coordinator). All the nodes should have different `node.id`.(generated by uuid command).
+
+### Catalog Configurations
+
+1. Create a folder named `catalog` in etc directory of presto on all the nodes of the cluster including the coordinator.
+
+##### Configuring Carbondata in Presto
+1. Create a file named `carbondata.properties` in the `catalog` folder and set the required properties on all the nodes.
+
+### Add Plugins
+
+1. Create a directory named `carbondata` in plugin directory of presto.
+2. Copy `carbondata` jars to `plugin/carbondata` directory on all nodes.
+
+### Start Presto Server on all nodes
+
+```
+./presto-server-0.187/bin/launcher start
+```
+To run it as a background process.
+
+```
+./presto-server-0.187/bin/launcher run
+```
+To run it in foreground.
+
+### Start Presto CLI
+```
+./presto
+```
+To connect to carbondata catalog use the following command:
+
+```
+./presto --server <coordinator_ip>:8086 --catalog carbondata --schema <schema_name>
+```
+Execute the following command to ensure the workers are connected.
+
+```
+select * from system.runtime.nodes;
+```
+Now you can use the Presto CLI on the coordinator to query data sources in the catalog using the Presto workers.
+
+List the schemas(databases) available
+
+```
+show schemas;
+```
+
+Selected the schema where CarbonData table resides
+
+```
+use carbonschema;
+```
+
+List the available tables
+
+```
+show tables;
+```
+
+Query from the available tables
+
+```
+select * from carbon_table;
+```
+
+**Note :** Create Tables and data loads should be done before executing queries as we can not create carbon table from this interface.
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/s3-guide.md
----------------------------------------------------------------------
diff --git a/docs/s3-guide.md b/docs/s3-guide.md
index 7e989ac..a2e5f07 100644
--- a/docs/s3-guide.md
+++ b/docs/s3-guide.md
@@ -46,7 +46,7 @@ For example:
CREATE TABLE IF NOT EXISTS db1.table1(col1 string, col2 int) STORED AS carbondata LOCATION 's3a://mybucket/carbonstore'
```
-For more details on create table, Refer [data-management-on-carbondata](./data-management-on-carbondata.md#create-table)
+For more details on create table, Refer [DDL of CarbonData](ddl-of-carbondata.md#create-table)
# Authentication
@@ -84,6 +84,7 @@ sparkSession.sparkContext.hadoopConfiguration.set("fs.s3a.access.key","456")
1. Object Storage like S3 does not support file leasing mechanism(supported by HDFS) that is
required to take locks which ensure consistency between concurrent operations therefore, it is
-recommended to set the configurable lock path property([carbon.lock.path](https://github.com/apache/carbondata/blob/master/docs/configuration-parameters.md#miscellaneous-configuration))
+recommended to set the configurable lock path property([carbon.lock.path](./configuration-parameters.md#system-configuration))
to a HDFS directory.
2. Concurrent data manipulation operations are not supported. Object stores follow eventual consistency semantics, i.e., any put request might take some time to reflect when trying to list. This behaviour causes the data read is always not consistent or not the latest.
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/sdk-guide.md
----------------------------------------------------------------------
diff --git a/docs/sdk-guide.md b/docs/sdk-guide.md
index 7ed8fc2..d786406 100644
--- a/docs/sdk-guide.md
+++ b/docs/sdk-guide.md
@@ -7,7 +7,7 @@
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -16,8 +16,16 @@
-->
# SDK Guide
-In the carbon jars package, there exist a carbondata-store-sdk-x.x.x-SNAPSHOT.jar, including SDK writer and reader.
+
+CarbonData provides SDK to facilitate
+
+1. [Writing carbondata files from other application which does not use Spark](#sdk-writer)
+2. [Reading carbondata files from other application which does not use Spark](#sdk-reader)
+
# SDK Writer
+
+In the carbon jars package, there exist a carbondata-store-sdk-x.x.x-SNAPSHOT.jar, including SDK writer and reader.
+
This SDK writer, writes carbondata file and carbonindex file at a given path.
External client can make use of this writer to convert other format data or live data to create carbondata and index files.
These SDK writer output contains just a carbondata and carbonindex files. No metadata folder will be present.
@@ -865,4 +873,5 @@ public String getProperty(String key);
*/
public String getProperty(String key, String defaultValue);
```
-Reference : [list of carbon properties](http://carbondata.apache.org/configuration-parameters.html)
+Reference : [list of carbon properties](./configuration-parameters.md)
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/segment-management-on-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/segment-management-on-carbondata.md b/docs/segment-management-on-carbondata.md
new file mode 100644
index 0000000..fe0cbd4
--- /dev/null
+++ b/docs/segment-management-on-carbondata.md
@@ -0,0 +1,142 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## SEGMENT MANAGEMENT
+
+Each load into CarbonData is written into a separate folder called Segment.Segments is a powerful
+concept which helps to maintain consistency of data and easy transaction management.CarbonData provides DML (Data Manipulation Language) commands to maintain the segments.
+
+- [Show Segments](#show-segment)
+- [Delete Segment by ID](#delete-segment-by-id)
+- [Delete Segment by Date](#delete-segment-by-date)
+- [Query Data with Specified Segments](#query-data-with-specified-segments)
+
+### SHOW SEGMENT
+
+ This command is used to list the segments of CarbonData table.
+
+ ```
+ SHOW [HISTORY] SEGMENTS FOR TABLE [db_name.]table_name LIMIT number_of_segments
+ ```
+
+ Example:
+ Show visible segments
+ ```
+ SHOW SEGMENTS FOR TABLE CarbonDatabase.CarbonTable LIMIT 4
+ ```
+ Show all segments, include invisible segments
+ ```
+ SHOW HISTORY SEGMENTS FOR TABLE CarbonDatabase.CarbonTable LIMIT 4
+ ```
+
+### DELETE SEGMENT BY ID
+
+ This command is used to delete segment by using the segment ID. Each segment has a unique segment ID associated with it.
+ Using this segment ID, you can remove the segment.
+
+ The following command will get the segmentID.
+
+ ```
+ SHOW SEGMENTS FOR TABLE [db_name.]table_name LIMIT number_of_segments
+ ```
+
+ After you retrieve the segment ID of the segment that you want to delete, execute the following command to delete the selected segment.
+
+ ```
+ DELETE FROM TABLE [db_name.]table_name WHERE SEGMENT.ID IN (segment_id1, segments_id2, ...)
+ ```
+
+ Example:
+
+ ```
+ DELETE FROM TABLE CarbonDatabase.CarbonTable WHERE SEGMENT.ID IN (0)
+ DELETE FROM TABLE CarbonDatabase.CarbonTable WHERE SEGMENT.ID IN (0,5,8)
+ ```
+
+### DELETE SEGMENT BY DATE
+
+ This command will allow to delete the CarbonData segment(s) from the store based on the date provided by the user in the DML command.
+ The segment created before the particular date will be removed from the specific stores.
+
+ ```
+ DELETE FROM TABLE [db_name.]table_name WHERE SEGMENT.STARTTIME BEFORE DATE_VALUE
+ ```
+
+ Example:
+ ```
+ DELETE FROM TABLE CarbonDatabase.CarbonTable WHERE SEGMENT.STARTTIME BEFORE '2017-06-01 12:05:06'
+ ```
+
+### QUERY DATA WITH SPECIFIED SEGMENTS
+
+ This command is used to read data from specified segments during CarbonScan.
+
+ Get the Segment ID:
+ ```
+ SHOW SEGMENTS FOR TABLE [db_name.]table_name LIMIT number_of_segments
+ ```
+
+ Set the segment IDs for table
+ ```
+ SET carbon.input.segments.<database_name>.<table_name> = <list of segment IDs>
+ ```
+
+ **NOTE:**
+ carbon.input.segments: Specifies the segment IDs to be queried. This property allows you to query specified segments of the specified table. The CarbonScan will read data from specified segments only.
+
+ If user wants to query with segments reading in multi threading mode, then CarbonSession. threadSet can be used instead of SET query.
+ ```
+ CarbonSession.threadSet ("carbon.input.segments.<database_name>.<table_name>","<list of segment IDs>");
+ ```
+
+ Reset the segment IDs
+ ```
+ SET carbon.input.segments.<database_name>.<table_name> = *;
+ ```
+
+ If user wants to query with segments reading in multi threading mode, then CarbonSession. threadSet can be used instead of SET query.
+ ```
+ CarbonSession.threadSet ("carbon.input.segments.<database_name>.<table_name>","*");
+ ```
+
+ **Examples:**
+
+ * Example to show the list of segment IDs,segment status, and other required details and then specify the list of segments to be read.
+
+ ```
+ SHOW SEGMENTS FOR carbontable1;
+
+ SET carbon.input.segments.db.carbontable1 = 1,3,9;
+ ```
+
+ * Example to query with segments reading in multi threading mode:
+
+ ```
+ CarbonSession.threadSet ("carbon.input.segments.db.carbontable_Multi_Thread","1,3");
+ ```
+
+ * Example for threadset in multithread environment (following shows how it is used in Scala code):
+
+ ```
+ def main(args: Array[String]) {
+ Future {
+ CarbonSession.threadSet ("carbon.input.segments.db.carbontable_Multi_Thread","1")
+ spark.sql("select count(empno) from carbon.input.segments.db.carbontable_Multi_Thread").show();
+ }
+ }
+ ```
[4/4] carbondata git commit: [CARBONDATA-2915] Reformat Documentation
of CarbonData
Posted by ch...@apache.org.
[CARBONDATA-2915] Reformat Documentation of CarbonData
1.Split Our carbondata command into DDL and DML,2.Add Presto integration along with Spark into quick start,3.Add a master reference manual which lists all the commands supported in carbondata.This manual shall have links to DDL and DML supported, 4.Add a introduction to carbondata covering architecture,design and features supported, 5.Merge FAQ and troubleshooting documents into single document , 6.Add a separate md file to explain user how to navigate across our documentation, 7.Add the TOC (Table of Contents) to all the md files which has multiple sections , 8.Add list of supported properties at the beginning of each DDL or DML so that user knows all the properties that are supported, 9.Rewrite the configuration properties description to explain the property in bit more detail and also highlight when to use the command and any caveats, 10.ReOrder our configuration properties table to group features wise, 11.Change the grammar and sentences.
This closes #2693
Project: http://git-wip-us.apache.org/repos/asf/carbondata/repo
Commit: http://git-wip-us.apache.org/repos/asf/carbondata/commit/6e50c1c6
Tree: http://git-wip-us.apache.org/repos/asf/carbondata/tree/6e50c1c6
Diff: http://git-wip-us.apache.org/repos/asf/carbondata/diff/6e50c1c6
Branch: refs/heads/master
Commit: 6e50c1c6fc1d6e82a4faf6dc6e0824299786ccc0
Parents: 3894e1d
Author: Raghunandan S <ca...@gmail.com>
Authored: Mon Aug 27 19:15:42 2018 +0800
Committer: chenliang613 <ch...@huawei.com>
Committed: Fri Sep 7 23:53:19 2018 +0800
----------------------------------------------------------------------
docs/How-to-contribute-to-Apache-CarbonData.md | 192 ---
docs/configuration-parameters.md | 8 +-
docs/data-management-on-carbondata.md | 1402 -------------------
docs/datamap-developer-guide.md | 13 +-
docs/datamap/bloomfilter-datamap-guide.md | 5 +-
docs/datamap/datamap-management.md | 17 +-
docs/datamap/lucene-datamap-guide.md | 4 +-
docs/datamap/preaggregate-datamap-guide.md | 7 +-
docs/datamap/timeseries-datamap-guide.md | 38 +-
docs/ddl-of-carbondata.md | 957 +++++++++++++
docs/dml-of-carbondata.md | 469 +++++++
docs/documentation.md | 66 +
docs/faq.md | 283 +++-
docs/file-structure-of-carbondata.md | 178 ++-
docs/hive-guide.md | 100 ++
docs/how-to-contribute-to-apache-carbondata.md | 192 +++
docs/images/2-1_1.png | Bin 0 -> 91864 bytes
docs/images/2-2_1.png | Bin 0 -> 103559 bytes
docs/images/2-3_1.png | Bin 0 -> 18316 bytes
docs/images/2-3_2.png | Bin 0 -> 33150 bytes
docs/images/2-3_3.png | Bin 0 -> 42102 bytes
docs/images/2-3_4.png | Bin 0 -> 81039 bytes
docs/images/2-4_1.png | Bin 0 -> 11212 bytes
docs/images/2-5_1.png | Bin 0 -> 6386 bytes
docs/images/2-5_2.png | Bin 0 -> 16141 bytes
docs/images/2-5_3.png | Bin 0 -> 9395 bytes
docs/images/2-6_1.png | Bin 0 -> 17016 bytes
docs/images/carbondata-performance.png | Bin 0 -> 375287 bytes
docs/introduction.md | 117 ++
docs/language-manual.md | 39 +
docs/performance-tuning.md | 246 ++++
docs/quick-start-guide.md | 378 ++++-
docs/s3-guide.md | 5 +-
docs/sdk-guide.md | 15 +-
docs/segment-management-on-carbondata.md | 142 ++
docs/streaming-guide.md | 172 ++-
docs/supported-data-types-in-carbondata.md | 5 +-
docs/troubleshooting.md | 267 ----
docs/usecases.md | 215 +++
docs/useful-tips-on-carbondata.md | 177 ---
integration/hive/hive-guide.md | 100 --
41 files changed, 3578 insertions(+), 2231 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/How-to-contribute-to-Apache-CarbonData.md
----------------------------------------------------------------------
diff --git a/docs/How-to-contribute-to-Apache-CarbonData.md b/docs/How-to-contribute-to-Apache-CarbonData.md
deleted file mode 100644
index 8cda54a..0000000
--- a/docs/How-to-contribute-to-Apache-CarbonData.md
+++ /dev/null
@@ -1,192 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to you under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# How to contribute to Apache CarbonData
-
-The Apache CarbonData community welcomes all kinds of contributions from anyone with a passion for
-faster data format! Apache CarbonData is a new file format for faster interactive query using
-advanced columnar storage, index, compression and encoding techniques to improve computing
-efficiency,in turn it will help speedup queries an order of magnitude faster over PetaBytes of data.
-
-We use a review-then-commit workflow in CarbonData for all contributions.
-
-* Engage -> Design -> Code -> Review -> Commit
-
-## Engage
-
-### Mailing list(s)
-
-We discuss design and implementation issues on dev@carbondata.apache.org Join by
-emailing dev-subscribe@carbondata.apache.org
-
-### Apache JIRA
-
-We use [Apache JIRA](https://issues.apache.org/jira/browse/CARBONDATA) as an issue tracking and
-project management tool, as well as a way to communicate among a very diverse and distributed set
-of contributors. To be able to gather feedback, avoid frustration, and avoid duplicated efforts all
-CarbonData-related work should be tracked there.
-
-If you do not already have an Apache JIRA account, sign up [here](https://issues.apache.org/jira/).
-
-If a quick search doesn’t turn up an existing JIRA issue for the work you want to contribute,
-create it. Please discuss your proposal with a committer or the component lead in JIRA or,
-alternatively, on the developer mailing list(dev@carbondata.apache.org).
-
-If there’s an existing JIRA issue for your intended contribution, please comment about your
-intended work. Once the work is understood, a committer will assign the issue to you.
-(If you don’t have a JIRA role yet, you’ll be added to the “contributor” role.) If an issue is
-currently assigned, please check with the current assignee before reassigning.
-
-For moderate or large contributions, you should not start coding or writing a design doc unless
-there is a corresponding JIRA issue assigned to you for that work. Simple changes,
-like fixing typos, do not require an associated issue.
-
-### Design
-
-To clearly express your thoughts and get early feedback from other community members, we encourage you to clearly scope, document the design of non-trivial contributions and discuss with the CarbonData community before you start coding.
-
-Generally, the JIRA issue is the best place to gather relevant design docs, comments, or references. It’s great to explicitly include relevant stakeholders early in the conversation. For designs that may be generally interesting, we also encourage conversations on the developer’s mailing list.
-
-### Code
-
-We use GitHub’s pull request functionality to review proposed code changes.
-If you do not already have a personal GitHub account, sign up [here](https://github.com).
-
-### Git config
-
-Ensure to finish the below config(user.email, user.name) before starting PR works.
-```
-$ git config --global user.email "you@example.com"
-$ git config --global user.name "Your Name"
-```
-
-#### Fork the repository on GitHub
-
-Go to the [Apache CarbonData GitHub mirror](https://github.com/apache/carbondata) and
-fork the repository to your account.
-This will be your private workspace for staging changes.
-
-#### Clone the repository locally
-
-You are now ready to create the development environment on your local machine.
-Clone CarbonData’s read-only GitHub mirror.
-```
-$ git clone https://github.com/apache/carbondata.git
-$ cd carbondata
-```
-Add your forked repository as an additional Git remote, where you’ll push your changes.
-```
-$ git remote add <GitHub_user> https://github.com/<GitHub_user>/carbondata.git
-```
-You are now ready to start developing!
-
-#### Create a branch in your fork
-
-You’ll work on your contribution in a branch in your own (forked) repository. Create a local branch,
-initialized with the state of the branch you expect your changes to be merged into.
-Keep in mind that we use several branches, including master, feature-specific, and
-release-specific branches. If you are unsure, initialize with the state of the master branch.
-```
-$ git fetch --all
-$ git checkout -b <my-branch> origin/master
-```
-At this point, you can start making and committing changes to this branch in a standard way.
-
-#### Syncing and pushing your branch
-
-Periodically while you work, and certainly before submitting a pull request, you should update
-your branch with the most recent changes to the target branch.
-```
-$ git pull --rebase
-```
-Remember to always use --rebase parameter to avoid extraneous merge commits.
-
-To push your local, committed changes to your (forked) repository on GitHub, run:
-```
-$ git push <GitHub_user> <my-branch>
-```
-#### Testing
-
-All code should have appropriate unit testing coverage. New code should have new tests in the
-same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
-
-For contributions to the Java code, run unit tests locally via Maven.
-```
-$ mvn clean verify
-```
-
-### Review
-
-Once the initial code is complete and the tests pass, it’s time to start the code review process.
-We review and discuss all code, no matter who authors it. It’s a great way to build community,
-since you can learn from other developers, and they become familiar with your contribution.
-It also builds a strong project by encouraging a high quality bar and keeping code consistent
-throughout the project.
-
-#### Create a pull request
-
-Organize your commits to make your reviewer’s job easier. Use the following command to
-re-order, squash, edit, or change description of individual commits.
-```
-$ git rebase -i origin/master
-```
-Navigate to the CarbonData GitHub mirror to create a pull request. The title of the pull request
-should be strictly in the following format:
-```
-[CARBONDATA-JiraTicketNumer][FeatureName] Description of pull request
-```
-Please include a descriptive pull request message to help make the reviewer’s job easier:
-```
- - The root cause/problem statement
- - What is the implemented solution
- ```
-
-If you know a good committer to review your pull request, please make a comment like the following.
-If not, don’t worry, a committer will pick it up.
-```
-Hi @<committer/reviewer name>, can you please take a look?
-```
-
-#### Code Review and Revision
-
-During the code review process, don’t rebase your branch or otherwise modify published commits,
-since this can remove existing comment history and be confusing to the reviewer,
-When you make a revision, always push it in a new commit.
-
-Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins.
-Please make sure those tests pass,the contribution cannot be merged otherwise.
-
-#### LGTM
-Once the reviewer is happy with the change, they’ll respond with an LGTM (“looks good to me!”).
-At this point, the committer will take over, possibly make some additional touch ups,
-and merge your changes into the codebase.
-
-In the case both the author and the reviewer are committers, either can merge the pull request.
-Just be sure to communicate clearly whose responsibility it is in this particular case.
-
-Thank you for your contribution to Apache CarbonData!
-
-#### Deleting your branch(optional)
-Once the pull request is merged into the Apache CarbonData repository, you can safely delete the
-branch locally and purge it from your forked repository.
-
-From another local branch, run:
-```
-$ git fetch --all
-$ git branch -d <my-branch>
-$ git push <GitHub_user> --delete <my-branch>
-```
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/configuration-parameters.md
----------------------------------------------------------------------
diff --git a/docs/configuration-parameters.md b/docs/configuration-parameters.md
index 9eca358..c8c74f2 100644
--- a/docs/configuration-parameters.md
+++ b/docs/configuration-parameters.md
@@ -16,7 +16,7 @@
-->
# Configuring CarbonData
- This guide explains the configurations that can be used to tune CarbonData to achieve better performance.Some of the properties can be set dynamically and are explained in the section Dynamic Configuration In CarbonData Using SET-RESET.Most of the properties that control the internal settings have reasonable default values.They are listed along with the properties along with explanation.
+ This guide explains the configurations that can be used to tune CarbonData to achieve better performance.Most of the properties that control the internal settings have reasonable default values.They are listed along with the properties along with explanation.
* [System Configuration](#system-configuration)
* [Data Loading Configuration](#data-loading-configuration)
@@ -59,7 +59,7 @@ This section provides the details of all the configurations required for the Car
| carbon.bad.records.action | FAIL | CarbonData in addition to identifying the bad records, can take certain actions on such data.This configuration can have four types of actions for bad records namely FORCE, REDIRECT, IGNORE and FAIL. If set to FORCE then it auto-corrects the data by storing the bad records as NULL. If set to REDIRECT then bad records are written to the raw CSV instead of being loaded. If set to IGNORE then bad records are neither loaded nor written to the raw CSV. If set to FAIL then data loading fails if any bad records are found. |
| carbon.options.is.empty.data.bad.record | false | Based on the business scenarios, empty("" or '' or ,,) data can be valid or invalid. This configuration controls how empty data should be treated by CarbonData. If false, then empty ("" or '' or ,,) data will not be considered as bad record and vice versa. |
| carbon.options.bad.record.path | (none) | Specifies the HDFS path where bad records are to be stored. By default the value is Null. This path must to be configured by the user if ***carbon.options.bad.records.logger.enable*** is **true** or ***carbon.bad.records.action*** is **REDIRECT**. |
-| carbon.blockletgroup.size.in.mb | 64 | Please refer to [file-structure-of-carbondata](../file-structure-of-carbondata.md ) to understand the storage format of CarbonData.The data are read as a group of blocklets which are called blocklet groups. This parameter specifies the size of each blocklet group. Higher value results in better sequential IO access.The minimum value is 16MB, any value lesser than 16MB will reset to the default value (64MB).**NOTE:** Configuring a higher value might lead to poor performance as an entire blocklet group will have to read into memory before processing.For filter queries with limit, it is **not advisable** to have a bigger blocklet size.For Aggregation queries which need to return more number of rows,bigger blocklet size is advisable. |
+| carbon.blockletgroup.size.in.mb | 64 | Please refer to [file-structure-of-carbondata](./file-structure-of-carbondata.md#carbondata-file-format) to understand the storage format of CarbonData.The data are read as a group of blocklets which are called blocklet groups. This parameter specifies the size of each blocklet group. Higher value results in better sequential IO access.The minimum value is 16MB, any value lesser than 16MB will reset to the default value (64MB).**NOTE:** Configuring a higher value might lead to poor performance as an entire blocklet group will have to read into memory before processing.For filter queries with limit, it is **not advisable** to have a bigger blocklet size.For Aggregation queries which need to return more number of rows,bigger blocklet size is advisable. |
| carbon.sort.file.write.buffer.size | 16384 | CarbonData sorts and writes data to intermediate files to limit the memory usage.This configuration determines the buffer size to be used for reading and writing such files. **NOTE:** This configuration is useful to tune IO and derive optimal performance.Based on the OS and underlying harddisk type, these values can significantly affect the overall performance.It is ideal to tune the buffersize equivalent to the IO buffer size of the OS.Recommended range is between 10240 to 10485760 bytes. |
| carbon.sort.intermediate.files.limit | 20 | CarbonData sorts and writes data to intermediate files to limit the memory usage.Before writing the target carbondat file, the data in these intermediate files needs to be sorted again so as to ensure the entire data in the data load is sorted.This configuration determines the minimum number of intermediate files after which merged sort is applied on them sort the data.**NOTE:** Intermediate merging happens on a separate thread in the background.Number of threads used is determined by ***carbon.merge.sort.reader.thread***.Configuring a low value will cause more time to be spent in merging these intermediate merged files which can cause more IO.Configuring a high value would cause not to use the idle threads to do intermediate sort merges.Range of recommended values are between 2 and 50 |
| carbon.csv.read.buffersize.byte | 1048576 | CarbonData uses Hadoop InputFormat to read the csv files.This configuration value is used to pass buffer size as input for the Hadoop MR job when reading the csv files.This value is configured in bytes.**NOTE:** Refer to ***org.apache.hadoop.mapreduce.InputFormat*** documentation for additional information. |
@@ -70,7 +70,7 @@ This section provides the details of all the configurations required for the Car
| carbon.enable.calculate.size | true | **For Load Operation**: Setting this property calculates the size of the carbon data file (.carbondata) and carbon index file (.carbonindex) for every load and updates the table status file. **For Describe Formatted**: Setting this property calculates the total size of the carbon data files and carbon index files for the respective table and displays in describe formatted command.**NOTE:** This is useful to determine the overall size of the carbondata table and also get an idea of how the table is growing in order to take up other backup strategy decisions. |
| carbon.cutOffTimestamp | (none) | CarbonData has capability to generate the Dictionary values for the timestamp columns from the data itself without the need to store the computed dictionary values. This configuration sets the start date for calculating the timestamp. Java counts the number of milliseconds from start of "1970-01-01 00:00:00". This property is used to customize the start of position. For example "2000-01-01 00:00:00". **NOTE:** The date must be in the form ***carbon.timestamp.format***. CarbonData supports storing data for upto 68 years.For example, if the cut-off time is 1970-01-01 05:30:00, then data upto 2038-01-01 05:30:00 will be supported by CarbonData. |
| carbon.timegranularity | SECOND | The configuration is used to specify the data granularity level such as DAY, HOUR, MINUTE, or SECOND.This helps to store more than 68 years of data into CarbonData. |
-| carbon.use.local.dir | false | CarbonData during data loading, writes files to local temp directories before copying the files to HDFS.This configuration is used to specify whether CarbonData can write locally to tmp directory of the container or to the YARN application directory. |
+| carbon.use.local.dir | false | CarbonData,during data loading, writes files to local temp directories before copying the files to HDFS.This configuration is used to specify whether CarbonData can write locally to tmp directory of the container or to the YARN application directory. |
| carbon.use.multiple.temp.dir | false | When multiple disks are present in the system, YARN is generally configured with multiple disks to be used as temp directories for managing the containers.This configuration specifies whether to use multiple YARN local directories during data loading for disk IO load balancing.Enable ***carbon.use.local.dir*** for this configuration to take effect.**NOTE:** Data Loading is an IO intensive operation whose performance can be limited by the disk IO threshold, particularly during multi table concurrent data load.Configuring this parameter, balances the disk IO across multiple disks there by improving the over all load performance. |
| carbon.sort.temp.compressor | (none) | CarbonData writes every ***carbon.sort.size*** number of records to intermediate temp files during data loading to ensure memory footprint is within limits.These temporary files cab be compressed and written in order to save the storage space.This configuration specifies the name of compressor to be used to compress the intermediate sort temp files during sort procedure in data loading.The valid values are 'SNAPPY','GZIP','BZIP2','LZ4','ZSTD' and empty. By default, empty means that Carbondata will not compress the sort temp files.**NOTE:** Compressor will be useful if you encounter disk bottleneck.Since the data needs to be compressed and decompressed,it involves additional CPU cycles,but is compensated by the high IO throughput due to less data to be written or read from the disks. |
| carbon.load.skewedDataOptimization.enabled | false | During data loading,CarbonData would divide the number of blocks equally so as to ensure all executors process same number of blocks.This mechanism satisfies most of the scenarios and ensures maximum parallel processing for optimal data loading performance.In some business scenarios, there might be scenarios where the size of blocks vary significantly and hence some executors would have to do more work if they get blocks containing more data. This configuration enables size based block allocation strategy for data loading.When loading, carbondata will use file size based block allocation strategy for task distribution. It will make sure that all the executors process the same size of data.**NOTE:** This configuration is useful if the size of your input data files varies widely, say 1MB~1GB.For this configuration to work effectively,knowing the data pattern and size is important and necessary. |
@@ -107,7 +107,7 @@ This section provides the details of all the configurations required for the Car
| carbon.numberof.preserve.segments | 0 | If the user wants to preserve some number of segments from being compacted then he can set this configuration. Example: carbon.numberof.preserve.segments = 2 then 2 latest segments will always be excluded from the compaction. No segments will be preserved by default.**NOTE:** This configuration is useful when the chances of input data can be wrong due to environment scenarios.Preserving some of the latest segments from being compacted can help to easily delete the wrongly loaded segments.Once compacted,it becomes more difficult to determine the exact data to be deleted(except when data is incrementing according to time) |
| carbon.allowed.compaction.days | 0 | This configuration is used to control on the number of recent segments that needs to be compacted, ignoring the older ones.This congifuration is in days.For Example: If the configuration is 2, then the segments which are loaded in the time frame of past 2 days only will get merged. Segments which are loaded earlier than 2 days will not be merged. This configuration is disabled by default.**NOTE:** This configuration is useful when a bulk of history data is loaded into the carbondata.Query on this data is less frequent.In such cases involving these segments also into compacation will affect the resource consumption, increases overall compaction time. |
| carbon.enable.auto.load.merge | false | Compaction can be automatically triggered once data load completes.This ensures that the segments are merged in time and thus query times doesnt increase with increase in segments.This configuration enables to do compaction along with data loading.**NOTE: **Compaction will be triggered once the data load completes.But the status of data load wait till the compaction is completed.Hence it might look like data loading time has increased, but thats not the case.Moreover failure of compaction will not affect the data loading status.If data load had completed successfully, the status would be updated and segments are committed.However, failure while data loading, will not trigger compaction and error is returned immediately. |
-| carbon.enable.page.level.reader.in.compaction|true|Enabling page level reader for compaction reduces the memory usage while compacting more number of segments. It allows reading only page by page instead of reading whole blocklet to memory.**NOTE:** Please refer to [file-structure-of-carbondata](../file-structure-of-carbondata.md ) to understand the storage format of CarbonData and concepts of pages.|
+| carbon.enable.page.level.reader.in.compaction|true|Enabling page level reader for compaction reduces the memory usage while compacting more number of segments. It allows reading only page by page instead of reading whole blocklet to memory.**NOTE:** Please refer to [file-structure-of-carbondata](./file-structure-of-carbondata.md#carbondata-file-format) to understand the storage format of CarbonData and concepts of pages.|
| carbon.concurrent.compaction | true | Compaction of different tables can be executed concurrently.This configuration determines whether to compact all qualifying tables in parallel or not.**NOTE: **Compacting concurrently is a resource demanding operation and needs more resouces there by affecting the query performance also.This configuration is **deprecated** and might be removed in future releases. |
| carbon.compaction.prefetch.enable | false | Compaction operation is similar to Query + data load where in data from qualifying segments are queried and data loading performed to generate a new single segment.This configuration determines whether to query ahead data from segments and feed it for data loading.**NOTE: **This configuration is disabled by default as it needs extra resources for querying ahead extra data.Based on the memory availability on the cluster, user can enable it to improve compaction performance. |
| carbon.merge.index.in.segment | true | Each CarbonData file has a companion CarbonIndex file which maintains the metadata about the data.These CarbonIndex files are read and loaded into driver and is used subsequently for pruning of data during queries.These CarbonIndex files are very small in size(few KB) and are many.Reading many small files from HDFS is not efficient and leads to slow IO performance.Hence these CarbonIndex files belonging to a segment can be combined into a single file and read once there by increasing the IO throughput.This configuration enables to merge all the CarbonIndex files into a single MergeIndex file upon data loading completion.**NOTE:** Reading a single big file is more efficient in HDFS and IO throughput is very high.Due to this the time needed to load the index files into memory when query is received for the first time on that table is significantly reduced and there by significantly reduces the delay in serving the first query. |
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/data-management-on-carbondata.md
----------------------------------------------------------------------
diff --git a/docs/data-management-on-carbondata.md b/docs/data-management-on-carbondata.md
deleted file mode 100644
index 2cde334..0000000
--- a/docs/data-management-on-carbondata.md
+++ /dev/null
@@ -1,1402 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to you under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Data Management on CarbonData
-
-This tutorial is going to introduce all commands and data operations on CarbonData.
-
-* [CREATE TABLE](#create-table)
-* [CREATE DATABASE](#create-database)
-* [TABLE MANAGEMENT](#table-management)
-* [LOAD DATA](#load-data)
-* [UPDATE AND DELETE](#update-and-delete)
-* [COMPACTION](#compaction)
-* [PARTITION](#partition)
-* [BUCKETING](#bucketing)
-* [SEGMENT MANAGEMENT](#segment-management)
-
-## CREATE TABLE
-
- This command can be used to create a CarbonData table by specifying the list of fields along with the table properties. You can also specify the location where the table needs to be stored.
-
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name[(col_name data_type , ...)]
- STORED AS carbondata
- [TBLPROPERTIES (property_name=property_value, ...)]
- [LOCATION 'path']
- ```
- **NOTE:** CarbonData also supports "STORED AS carbondata" and "USING carbondata". Find example code at [CarbonSessionExample](https://github.com/apache/carbondata/blob/master/examples/spark2/src/main/scala/org/apache/carbondata/examples/CarbonSessionExample.scala) in the CarbonData repo.
-### Usage Guidelines
-
- Following are the guidelines for TBLPROPERTIES, CarbonData's additional table options can be set via carbon.properties.
-
- - **Dictionary Encoding Configuration**
-
- Dictionary encoding is turned off for all columns by default from 1.3 onwards, you can use this command for including or excluding columns to do dictionary encoding.
- Suggested use cases : do dictionary encoding for low cardinality columns, it might help to improve data compression ratio and performance.
-
- ```
- TBLPROPERTIES ('DICTIONARY_INCLUDE'='column1, column2')
- ```
- NOTE: Dictionary Include/Exclude for complex child columns is not supported.
-
- - **Inverted Index Configuration**
-
- By default inverted index is enabled, it might help to improve compression ratio and query speed, especially for low cardinality columns which are in reward position.
- Suggested use cases : For high cardinality columns, you can disable the inverted index for improving the data loading performance.
-
- ```
- TBLPROPERTIES ('NO_INVERTED_INDEX'='column1, column3')
- ```
-
- - **Sort Columns Configuration**
-
- This property is for users to specify which columns belong to the MDK(Multi-Dimensions-Key) index.
- * If users don't specify "SORT_COLUMN" property, by default MDK index be built by using all dimension columns except complex data type column.
- * If this property is specified but with empty argument, then the table will be loaded without sort.
- * This supports only string, date, timestamp, short, int, long, and boolean data types.
- Suggested use cases : Only build MDK index for required columns,it might help to improve the data loading performance.
-
- ```
- TBLPROPERTIES ('SORT_COLUMNS'='column1, column3')
- OR
- TBLPROPERTIES ('SORT_COLUMNS'='')
- ```
- NOTE: Sort_Columns for Complex datatype columns is not supported.
-
- - **Sort Scope Configuration**
-
- This property is for users to specify the scope of the sort during data load, following are the types of sort scope.
-
- * LOCAL_SORT: It is the default sort scope.
- * NO_SORT: It will load the data in unsorted manner, it will significantly increase load performance.
- * BATCH_SORT: It increases the load performance but decreases the query performance if identified blocks > parallelism.
- * GLOBAL_SORT: It increases the query performance, especially high concurrent point query.
- And if you care about loading resources isolation strictly, because the system uses the spark GroupBy to sort data, the resource can be controlled by spark.
-
- ### Example:
-
- ```
- CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
- productNumber INT,
- productName STRING,
- storeCity STRING,
- storeProvince STRING,
- productCategory STRING,
- productBatch STRING,
- saleQuantity INT,
- revenue INT)
- STORED BY 'carbondata'
- TBLPROPERTIES ('SORT_COLUMNS'='productName,storeCity',
- 'SORT_SCOPE'='NO_SORT')
- ```
-
- **NOTE:** CarbonData also supports "using carbondata". Find example code at [SparkSessionExample](https://github.com/apache/carbondata/blob/master/examples/spark2/src/main/scala/org/apache/carbondata/examples/SparkSessionExample.scala) in the CarbonData repo.
-
- - **Table Block Size Configuration**
-
- This property is for setting block size of this table, the default value is 1024 MB and supports a range of 1 MB to 2048 MB.
-
- ```
- TBLPROPERTIES ('TABLE_BLOCKSIZE'='512')
- ```
- **NOTE:** 512 or 512M both are accepted.
-
- - **Table Blocklet Size Configuration**
-
- This property is for setting blocklet size of this table, the default value is 64 MB.
-
- ```
- TBLPROPERTIES ('TABLE_BLOCKLET_SIZE'='32')
- ```
-
- - **Table Compaction Configuration**
-
- These properties are table level compaction configurations, if not specified, system level configurations in carbon.properties will be used.
- Following are 5 configurations:
-
- * MAJOR_COMPACTION_SIZE: same meaning as carbon.major.compaction.size, size in MB.
- * AUTO_LOAD_MERGE: same meaning as carbon.enable.auto.load.merge.
- * COMPACTION_LEVEL_THRESHOLD: same meaning as carbon.compaction.level.threshold.
- * COMPACTION_PRESERVE_SEGMENTS: same meaning as carbon.numberof.preserve.segments.
- * ALLOWED_COMPACTION_DAYS: same meaning as carbon.allowed.compaction.days.
-
- ```
- TBLPROPERTIES ('MAJOR_COMPACTION_SIZE'='2048',
- 'AUTO_LOAD_MERGE'='true',
- 'COMPACTION_LEVEL_THRESHOLD'='5,6',
- 'COMPACTION_PRESERVE_SEGMENTS'='10',
- 'ALLOWED_COMPACTION_DAYS'='5')
- ```
-
- - **Streaming**
-
- CarbonData supports streaming ingestion for real-time data. You can create the ‘streaming’ table using the following table properties.
-
- ```
- TBLPROPERTIES ('streaming'='true')
- ```
-
- - **Local Dictionary Configuration**
-
- Columns for which dictionary is not generated needs more storage space and in turn more IO. Also since more data will have to be read during query, query performance also would suffer.Generating dictionary per blocklet for such columns would help in saving storage space and assist in improving query performance as carbondata is optimized for handling dictionary encoded columns more effectively.Generating dictionary internally per blocklet is termed as local dictionary. Please refer to [File structure of Carbondata](../file-structure-of-carbondata.md) for understanding about the file structure of carbondata and meaning of terms like blocklet.
-
- Local Dictionary helps in:
- 1. Getting more compression.
- 2. Filter queries and full scan queries will be faster as filter will be done on encoded data.
- 3. Reducing the store size and memory footprint as only unique values will be stored as part of local dictionary and corresponding data will be stored as encoded data.
- 4. Getting higher IO throughput.
-
- **NOTE:**
-
- * Following Data Types are Supported for Local Dictionary:
- * STRING
- * VARCHAR
- * CHAR
-
- * Following Data Types are not Supported for Local Dictionary:
- * SMALLINT
- * INTEGER
- * BIGINT
- * DOUBLE
- * DECIMAL
- * TIMESTAMP
- * DATE
- * BOOLEAN
-
- * In case of multi-level complex dataType columns, primitive string/varchar/char columns are considered for local dictionary generation.
-
- Local dictionary will have to be enabled explicitly during create table or by enabling the system property 'carbon.local.dictionary.enable'. By default, Local Dictionary will be disabled for the carbondata table.
-
- Local Dictionary can be configured using the following properties during create table command:
-
- | Properties | Default value | Description |
- | ---------- | ------------- | ----------- |
- | LOCAL_DICTIONARY_ENABLE | false | Whether to enable local dictionary generation. **NOTE:** If this property is defined, it will override the value configured at system level by 'carbon.local.dictionary.enable' |
- | LOCAL_DICTIONARY_THRESHOLD | 10000 | The maximum cardinality of a column upto which carbondata can try to generate local dictionary (maximum - 100000) |
- | LOCAL_DICTIONARY_INCLUDE | string/varchar/char columns| Columns for which Local Dictionary has to be generated.**NOTE:** Those string/varchar/char columns which are added into DICTIONARY_INCLUDE option will not be considered for local dictionary generation.|
- | LOCAL_DICTIONARY_EXCLUDE | none | Columns for which Local Dictionary need not be generated. |
-
- **Fallback behavior:**
-
- * When the cardinality of a column exceeds the threshold, it triggers a fallback and the generated dictionary will be reverted and data loading will be continued without dictionary encoding.
-
- **NOTE:** When fallback is triggered, the data loading performance will decrease as encoded data will be discarded and the actual data is written to the temporary sort files.
-
- **Points to be noted:**
-
- 1. Reduce Block size:
-
- Number of Blocks generated is less in case of Local Dictionary as compression ratio is high. This may reduce the number of tasks launched during query, resulting in degradation of query performance if the pruned blocks are less compared to the number of parallel tasks which can be run. So it is recommended to configure smaller block size which in turn generates more number of blocks.
-
- 2. All the page-level data for a blocklet needs to be maintained in memory until all the pages encoded for local dictionary is processed in order to handle fallback. Hence the memory required for local dictionary based table is more and this memory increase is proportional to number of columns.
-
-### Example:
-
- ```
- CREATE TABLE carbontable(
-
- column1 string,
-
- column2 string,
-
- column3 LONG )
-
- STORED BY 'carbondata'
- TBLPROPERTIES('LOCAL_DICTIONARY_ENABLE'='true','LOCAL_DICTIONARY_THRESHOLD'='1000',
- 'LOCAL_DICTIONARY_INCLUDE'='column1','LOCAL_DICTIONARY_EXCLUDE'='column2')
- ```
-
- **NOTE:**
-
- * We recommend to use Local Dictionary when cardinality is high but is distributed across multiple loads
- * On a large cluster, decoding data can become a bottleneck for global dictionary as there will be many remote reads. In this scenario, it is better to use Local Dictionary.
- * When cardinality is less, but loads are repetitive, it is better to use global dictionary as local dictionary generates multiple dictionary files at blocklet level increasing redundancy.
-
- - **Caching Min/Max Value for Required Columns**
- By default, CarbonData caches min and max values of all the columns in schema. As the load increases, the memory required to hold the min and max values increases considerably. This feature enables you to configure min and max values only for the required columns, resulting in optimized memory usage.
-
- Following are the valid values for COLUMN_META_CACHE:
- * If you want no column min/max values to be cached in the driver.
-
- ```
- COLUMN_META_CACHE=’’
- ```
-
- * If you want only col1 min/max values to be cached in the driver.
-
- ```
- COLUMN_META_CACHE=’col1’
- ```
-
- * If you want min/max values to be cached in driver for all the specified columns.
-
- ```
- COLUMN_META_CACHE=’col1,col2,col3,…’
- ```
-
- Columns to be cached can be specified either while creating table or after creation of the table.
- During create table operation; specify the columns to be cached in table properties.
-
- Syntax:
-
- ```
- CREATE TABLE [dbName].tableName (col1 String, col2 String, col3 int,…) STORED BY ‘carbondata’ TBLPROPERTIES (‘COLUMN_META_CACHE’=’col1,col2,…’)
- ```
-
- Example:
-
- ```
- CREATE TABLE employee (name String, city String, id int) STORED BY ‘carbondata’ TBLPROPERTIES (‘COLUMN_META_CACHE’=’name’)
- ```
-
- After creation of table or on already created tables use the alter table command to configure the columns to be cached.
-
- Syntax:
-
- ```
- ALTER TABLE [dbName].tableName SET TBLPROPERTIES (‘COLUMN_META_CACHE’=’col1,col2,…’)
- ```
-
- Example:
-
- ```
- ALTER TABLE employee SET TBLPROPERTIES (‘COLUMN_META_CACHE’=’city’)
- ```
-
- - **Caching at Block or Blocklet Level**
-
- This feature allows you to maintain the cache at Block level, resulting in optimized usage of the memory. The memory consumption is high if the Blocklet level caching is maintained as a Block can have multiple Blocklet.
-
- Following are the valid values for CACHE_LEVEL:
-
- *Configuration for caching in driver at Block level (default value).*
-
- ```
- CACHE_LEVEL= ‘BLOCK’
- ```
-
- *Configuration for caching in driver at Blocklet level.*
-
- ```
- CACHE_LEVEL= ‘BLOCKLET’
- ```
-
- Cache level can be specified either while creating table or after creation of the table.
- During create table operation specify the cache level in table properties.
-
- Syntax:
-
- ```
- CREATE TABLE [dbName].tableName (col1 String, col2 String, col3 int,…) STORED BY ‘carbondata’ TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
- ```
-
- Example:
-
- ```
- CREATE TABLE employee (name String, city String, id int) STORED BY ‘carbondata’ TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
- ```
-
- After creation of table or on already created tables use the alter table command to configure the cache level.
-
- Syntax:
-
- ```
- ALTER TABLE [dbName].tableName SET TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
- ```
-
- Example:
-
- ```
- ALTER TABLE employee SET TBLPROPERTIES (‘CACHE_LEVEL’=’Blocklet’)
- ```
-
- - **Support Flat folder same as Hive/Parquet**
-
- This feature allows all carbondata and index files to keep directy under tablepath. Currently all carbondata/carbonindex files written under tablepath/Fact/Part0/Segment_NUM folder and it is not same as hive/parquet folder structure. This feature makes all files written will be directly under tablepath, it does not maintain any segment folder structure.This is useful for interoperability between the execution engines and plugin with other execution engines like hive or presto becomes easier.
-
- Following table property enables this feature and default value is false.
- ```
- 'flat_folder'='true'
- ```
- Example:
- ```
- CREATE TABLE employee (name String, city String, id int) STORED BY ‘carbondata’ TBLPROPERTIES ('flat_folder'='true')
- ```
-
- - **String longer than 32000 characters**
-
- In common scenarios, the length of string is less than 32000,
- so carbondata stores the length of content using Short to reduce memory and space consumption.
- To support string longer than 32000 characters, carbondata introduces a table property called `LONG_STRING_COLUMNS`.
- For these columns, carbondata internally stores the length of content using Integer.
-
- You can specify the columns as 'long string column' using below tblProperties:
-
- ```
- // specify col1, col2 as long string columns
- TBLPROPERTIES ('LONG_STRING_COLUMNS'='col1,col2')
- ```
-
- Besides, you can also use this property through DataFrame by
- ```
- df.format("carbondata")
- .option("tableName", "carbonTable")
- .option("long_string_columns", "col1, col2")
- .save()
- ```
-
- If you are using Carbon-SDK, you can specify the datatype of long string column as `varchar`.
- You can refer to SDKwriterTestCase for example.
-
- **NOTE:** The LONG_STRING_COLUMNS can only be string/char/varchar columns and cannot be dictionary_include/sort_columns/complex columns.
-
-## CREATE TABLE AS SELECT
- This function allows user to create a Carbon table from any of the Parquet/Hive/Carbon table. This is beneficial when the user wants to create Carbon table from any other Parquet/Hive table and use the Carbon query engine to query and achieve better query results for cases where Carbon is faster than other file formats. Also this feature can be used for backing up the data.
-
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
- STORED BY 'carbondata'
- [TBLPROPERTIES (key1=val1, key2=val2, ...)]
- AS select_statement;
- ```
-
-### Examples
- ```
- carbon.sql("CREATE TABLE source_table(
- id INT,
- name STRING,
- city STRING,
- age INT)
- STORED AS parquet")
- carbon.sql("INSERT INTO source_table SELECT 1,'bob','shenzhen',27")
- carbon.sql("INSERT INTO source_table SELECT 2,'david','shenzhen',31")
-
- carbon.sql("CREATE TABLE target_table
- STORED BY 'carbondata'
- AS SELECT city,avg(age) FROM source_table GROUP BY city")
-
- carbon.sql("SELECT * FROM target_table").show
- // results:
- // +--------+--------+
- // | city|avg(age)|
- // +--------+--------+
- // |shenzhen| 29.0|
- // +--------+--------+
-
- ```
-
-## CREATE EXTERNAL TABLE
- This function allows user to create external table by specifying location.
- ```
- CREATE EXTERNAL TABLE [IF NOT EXISTS] [db_name.]table_name
- STORED BY 'carbondata' LOCATION ‘$FilesPath’
- ```
-
-### Create external table on managed table data location.
- Managed table data location provided will have both FACT and Metadata folder.
- This data can be generated by creating a normal carbon table and use this path as $FilesPath in the above syntax.
-
- **Example:**
- ```
- sql("CREATE TABLE origin(key INT, value STRING) STORED BY 'carbondata'")
- sql("INSERT INTO origin select 100,'spark'")
- sql("INSERT INTO origin select 200,'hive'")
- // creates a table in $storeLocation/origin
-
- sql(s"""
- |CREATE EXTERNAL TABLE source
- |STORED BY 'carbondata'
- |LOCATION '$storeLocation/origin'
- """.stripMargin)
- checkAnswer(sql("SELECT count(*) from source"), sql("SELECT count(*) from origin"))
- ```
-
-### Create external table on Non-Transactional table data location.
- Non-Transactional table data location will have only carbondata and carbonindex files, there will not be a metadata folder (table status and schema).
- Our SDK module currently support writing data in this format.
-
- **Example:**
- ```
- sql(
- s"""CREATE EXTERNAL TABLE sdkOutputTable STORED BY 'carbondata' LOCATION
- |'$writerPath' """.stripMargin)
- ```
-
- Here writer path will have carbondata and index files.
- This can be SDK output. Refer [SDK Writer Guide](https://github.com/apache/carbondata/blob/master/docs/sdk-writer-guide.md).
-
- **Note:**
- 1. Dropping of the external table should not delete the files present in the location.
- 2. When external table is created on non-transactional table data,
- external table will be registered with the schema of carbondata files.
- If multiple files with different schema is present, exception will be thrown.
- So, If table registered with one schema and files are of different schema,
- suggest to drop the external table and create again to register table with new schema.
-
-
-## CREATE DATABASE
- This function creates a new database. By default the database is created in Carbon store location, but you can also specify custom location.
- ```
- CREATE DATABASE [IF NOT EXISTS] database_name [LOCATION path];
- ```
-
-### Example
- ```
- CREATE DATABASE carbon LOCATION “hdfs://name_cluster/dir1/carbonstore”;
- ```
-
-## TABLE MANAGEMENT
-
-### SHOW TABLE
-
- This command can be used to list all the tables in current database or all the tables of a specific database.
- ```
- SHOW TABLES [IN db_Name]
- ```
-
- Example:
- ```
- SHOW TABLES
- OR
- SHOW TABLES IN defaultdb
- ```
-
-### ALTER TABLE
-
- The following section introduce the commands to modify the physical or logical state of the existing table(s).
-
- - **RENAME TABLE**
-
- This command is used to rename the existing table.
- ```
- ALTER TABLE [db_name.]table_name RENAME TO new_table_name
- ```
-
- Examples:
- ```
- ALTER TABLE carbon RENAME TO carbonTable
- OR
- ALTER TABLE test_db.carbon RENAME TO test_db.carbonTable
- ```
-
- - **ADD COLUMNS**
-
- This command is used to add a new column to the existing table.
- ```
- ALTER TABLE [db_name.]table_name ADD COLUMNS (col_name data_type,...)
- TBLPROPERTIES('DICTIONARY_INCLUDE'='col_name,...',
- 'DEFAULT.VALUE.COLUMN_NAME'='default_value')
- ```
-
- Examples:
- ```
- ALTER TABLE carbon ADD COLUMNS (a1 INT, b1 STRING)
- ```
-
- ```
- ALTER TABLE carbon ADD COLUMNS (a1 INT, b1 STRING) TBLPROPERTIES('DICTIONARY_INCLUDE'='a1')
- ```
-
- ```
- ALTER TABLE carbon ADD COLUMNS (a1 INT, b1 STRING) TBLPROPERTIES('DEFAULT.VALUE.a1'='10')
- ```
- NOTE: Add Complex datatype columns is not supported.
-
-Users can specify which columns to include and exclude for local dictionary generation after adding new columns. These will be appended with the already existing local dictionary include and exclude columns of main table respectively.
- ```
- ALTER TABLE carbon ADD COLUMNS (a1 STRING, b1 STRING) TBLPROPERTIES('LOCAL_DICTIONARY_INCLUDE'='a1','LOCAL_DICTIONARY_EXCLUDE'='b1')
- ```
-
- - **DROP COLUMNS**
-
- This command is used to delete the existing column(s) in a table.
- ```
- ALTER TABLE [db_name.]table_name DROP COLUMNS (col_name, ...)
- ```
-
- Examples:
- ```
- ALTER TABLE carbon DROP COLUMNS (b1)
- OR
- ALTER TABLE test_db.carbon DROP COLUMNS (b1)
-
- ALTER TABLE carbon DROP COLUMNS (c1,d1)
- ```
- NOTE: Drop Complex child column is not supported.
-
- - **CHANGE DATA TYPE**
-
- This command is used to change the data type from INT to BIGINT or decimal precision from lower to higher.
- Change of decimal data type from lower precision to higher precision will only be supported for cases where there is no data loss.
- ```
- ALTER TABLE [db_name.]table_name CHANGE col_name col_name changed_column_type
- ```
-
- Valid Scenarios
- - Invalid scenario - Change of decimal precision from (10,2) to (10,5) is invalid as in this case only scale is increased but total number of digits remains the same.
- - Valid scenario - Change of decimal precision from (10,2) to (12,3) is valid as the total number of digits are increased by 2 but scale is increased only by 1 which will not lead to any data loss.
- - **NOTE:** The allowed range is 38,38 (precision, scale) and is a valid upper case scenario which is not resulting in data loss.
-
- Example1:Changing data type of column a1 from INT to BIGINT.
- ```
- ALTER TABLE test_db.carbon CHANGE a1 a1 BIGINT
- ```
-
- Example2:Changing decimal precision of column a1 from 10 to 18.
- ```
- ALTER TABLE test_db.carbon CHANGE a1 a1 DECIMAL(18,2)
- ```
-- **MERGE INDEX**
-
- This command is used to merge all the CarbonData index files (.carbonindex) inside a segment to a single CarbonData index merge file (.carbonindexmerge). This enhances the first query performance.
- ```
- ALTER TABLE [db_name.]table_name COMPACT 'SEGMENT_INDEX'
- ```
-
- Examples:
- ```
- ALTER TABLE test_db.carbon COMPACT 'SEGMENT_INDEX'
- ```
- **NOTE:**
- * Merge index is not supported on streaming table.
-
-- **SET and UNSET for Local Dictionary Properties**
-
- When set command is used, all the newly set properties will override the corresponding old properties if exists.
-
- Example to SET Local Dictionary Properties:
- ```
- ALTER TABLE tablename SET TBLPROPERTIES('LOCAL_DICTIONARY_ENABLE'='false','LOCAL_DICTIONARY_THRESHOLD'='1000','LOCAL_DICTIONARY_INCLUDE'='column1','LOCAL_DICTIONARY_EXCLUDE'='column2')
- ```
- When Local Dictionary properties are unset, corresponding default values will be used for these properties.
-
- Example to UNSET Local Dictionary Properties:
- ```
- ALTER TABLE tablename UNSET TBLPROPERTIES('LOCAL_DICTIONARY_ENABLE','LOCAL_DICTIONARY_THRESHOLD','LOCAL_DICTIONARY_INCLUDE','LOCAL_DICTIONARY_EXCLUDE')
- ```
-
- **NOTE:** For old tables, by default, local dictionary is disabled. If user wants local dictionary for these tables, user can enable/disable local dictionary for new data at their discretion.
- This can be achieved by using the alter table set command.
-
-### DROP TABLE
-
- This command is used to delete an existing table.
- ```
- DROP TABLE [IF EXISTS] [db_name.]table_name
- ```
-
- Example:
- ```
- DROP TABLE IF EXISTS productSchema.productSalesTable
- ```
-
-### REFRESH TABLE
-
- This command is used to register Carbon table to HIVE meta store catalogue from existing Carbon table data.
- ```
- REFRESH TABLE $db_NAME.$table_NAME
- ```
-
- Example:
- ```
- REFRESH TABLE dbcarbon.productSalesTable
- ```
-
- **NOTE:**
- * The new database name and the old database name should be same.
- * Before executing this command the old table schema and data should be copied into the new database location.
- * If the table is aggregate table, then all the aggregate tables should be copied to the new database location.
- * For old store, the time zone of the source and destination cluster should be same.
- * If old cluster used HIVE meta store to store schema, refresh will not work as schema file does not exist in file system.
-
-### Table and Column Comment
-
- You can provide more information on table by using table comment. Similarly you can provide more information about a particular column using column comment.
- You can see the column comment of an existing table using describe formatted command.
-
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name[(col_name data_type [COMMENT col_comment], ...)]
- [COMMENT table_comment]
- STORED BY 'carbondata'
- [TBLPROPERTIES (property_name=property_value, ...)]
- ```
-
- Example:
- ```
- CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
- productNumber Int COMMENT 'unique serial number for product')
- COMMENT “This is table comment”
- STORED BY 'carbondata'
- TBLPROPERTIES ('DICTIONARY_INCLUDE'='productNumber')
- ```
- You can also SET and UNSET table comment using ALTER command.
-
- Example to SET table comment:
-
- ```
- ALTER TABLE carbon SET TBLPROPERTIES ('comment'='this table comment is modified');
- ```
-
- Example to UNSET table comment:
-
- ```
- ALTER TABLE carbon UNSET TBLPROPERTIES ('comment');
- ```
-
-## LOAD DATA
-
-### LOAD FILES TO CARBONDATA TABLE
-
- This command is used to load csv files to carbondata, OPTIONS are not mandatory for data loading process.
- Inside OPTIONS user can provide any options like DELIMITER, QUOTECHAR, FILEHEADER, ESCAPECHAR, MULTILINE as per requirement.
-
- ```
- LOAD DATA [LOCAL] INPATH 'folder_path'
- INTO TABLE [db_name.]table_name
- OPTIONS(property_name=property_value, ...)
- ```
-
- You can use the following options to load data:
-
- - **DELIMITER:** Delimiters can be provided in the load command.
-
- ```
- OPTIONS('DELIMITER'=',')
- ```
-
- - **QUOTECHAR:** Quote Characters can be provided in the load command.
-
- ```
- OPTIONS('QUOTECHAR'='"')
- ```
-
- - **COMMENTCHAR:** Comment Characters can be provided in the load command if user want to comment lines.
-
- ```
- OPTIONS('COMMENTCHAR'='#')
- ```
-
- - **HEADER:** When you load the CSV file without the file header and the file header is the same with the table schema, then add 'HEADER'='false' to load data SQL as user need not provide the file header. By default the value is 'true'.
- false: CSV file is without file header.
- true: CSV file is with file header.
-
- ```
- OPTIONS('HEADER'='false')
- ```
-
- **NOTE:** If the HEADER option exist and is set to 'true', then the FILEHEADER option is not required.
-
- - **FILEHEADER:** Headers can be provided in the LOAD DATA command if headers are missing in the source files.
-
- ```
- OPTIONS('FILEHEADER'='column1,column2')
- ```
-
- - **MULTILINE:** CSV with new line character in quotes.
-
- ```
- OPTIONS('MULTILINE'='true')
- ```
-
- - **ESCAPECHAR:** Escape char can be provided if user want strict validation of escape character in CSV files.
-
- ```
- OPTIONS('ESCAPECHAR'='\')
- ```
- - **SKIP_EMPTY_LINE:** This option will ignore the empty line in the CSV file during the data load.
-
- ```
- OPTIONS('SKIP_EMPTY_LINE'='TRUE/FALSE')
- ```
-
- - **COMPLEX_DELIMITER_LEVEL_1:** Split the complex type data column in a row (eg., a$b$c --> Array = {a,b,c}).
-
- ```
- OPTIONS('COMPLEX_DELIMITER_LEVEL_1'='$')
- ```
-
- - **COMPLEX_DELIMITER_LEVEL_2:** Split the complex type nested data column in a row. Applies level_1 delimiter & applies level_2 based on complex data type (eg., a:b$c:d --> Array> = {{a,b},{c,d}}).
-
- ```
- OPTIONS('COMPLEX_DELIMITER_LEVEL_2'=':')
- ```
-
- - **ALL_DICTIONARY_PATH:** All dictionary files path.
-
- ```
- OPTIONS('ALL_DICTIONARY_PATH'='/opt/alldictionary/data.dictionary')
- ```
-
- - **COLUMNDICT:** Dictionary file path for specified column.
-
- ```
- OPTIONS('COLUMNDICT'='column1:dictionaryFilePath1,column2:dictionaryFilePath2')
- ```
- **NOTE:** ALL_DICTIONARY_PATH and COLUMNDICT can't be used together.
-
- - **DATEFORMAT/TIMESTAMPFORMAT:** Date and Timestamp format for specified column.
-
- ```
- OPTIONS('DATEFORMAT' = 'yyyy-MM-dd','TIMESTAMPFORMAT'='yyyy-MM-dd HH:mm:ss')
- ```
- **NOTE:** Date formats are specified by date pattern strings. The date pattern letters in CarbonData are same as in JAVA. Refer to [SimpleDateFormat](http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html).
-
- - **SORT COLUMN BOUNDS:** Range bounds for sort columns.
-
- Suppose the table is created with 'SORT_COLUMNS'='name,id' and the range for name is aaa~zzz, the value range for id is 0~1000. Then during data loading, we can specify the following option to enhance data loading performance.
- ```
- OPTIONS('SORT_COLUMN_BOUNDS'='f,250;l,500;r,750')
- ```
- Each bound is separated by ';' and each field value in bound is separated by ','. In the example above, we provide 3 bounds to distribute records to 4 partitions. The values 'f','l','r' can evenly distribute the records. Inside carbondata, for a record we compare the value of sort columns with that of the bounds and decide which partition the record will be forwarded to.
-
- **NOTE:**
- * SORT_COLUMN_BOUNDS will be used only when the SORT_SCOPE is 'local_sort'.
- * Carbondata will use these bounds as ranges to process data concurrently during the final sort percedure. The records will be sorted and written out inside each partition. Since the partition is sorted, all records will be sorted.
- * Since the actual order and literal order of the dictionary column are not necessarily the same, we do not recommend you to use this feature if the first sort column is 'dictionary_include'.
- * The option works better if your CPU usage during loading is low. If your system is already CPU tense, better not to use this option. Besides, it depends on the user to specify the bounds. If user does not know the exactly bounds to make the data distributed evenly among the bounds, loading performance will still be better than before or at least the same as before.
- * Users can find more information about this option in the description of PR1953.
-
- - **SINGLE_PASS:** Single Pass Loading enables single job to finish data loading with dictionary generation on the fly. It enhances performance in the scenarios where the subsequent data loading after initial load involves fewer incremental updates on the dictionary.
-
- This option specifies whether to use single pass for loading data or not. By default this option is set to FALSE.
-
- ```
- OPTIONS('SINGLE_PASS'='TRUE')
- ```
-
- **NOTE:**
- * If this option is set to TRUE then data loading will take less time.
- * If this option is set to some invalid value other than TRUE or FALSE then it uses the default value.
-
- Example:
-
- ```
- LOAD DATA local inpath '/opt/rawdata/data.csv' INTO table carbontable
- options('DELIMITER'=',', 'QUOTECHAR'='"','COMMENTCHAR'='#',
- 'HEADER'='false',
- 'FILEHEADER'='empno,empname,designation,doj,workgroupcategory,
- workgroupcategoryname,deptno,deptname,projectcode,
- projectjoindate,projectenddate,attendance,utilization,salary',
- 'MULTILINE'='true','ESCAPECHAR'='\','COMPLEX_DELIMITER_LEVEL_1'='$',
- 'COMPLEX_DELIMITER_LEVEL_2'=':',
- 'ALL_DICTIONARY_PATH'='/opt/alldictionary/data.dictionary',
- 'SINGLE_PASS'='TRUE')
- ```
-
- - **BAD RECORDS HANDLING:** Methods of handling bad records are as follows:
-
- * Load all of the data before dealing with the errors.
- * Clean or delete bad records before loading data or stop the loading when bad records are found.
-
- ```
- OPTIONS('BAD_RECORDS_LOGGER_ENABLE'='true', 'BAD_RECORD_PATH'='hdfs://hacluster/tmp/carbon', 'BAD_RECORDS_ACTION'='REDIRECT', 'IS_EMPTY_DATA_BAD_RECORD'='false')
- ```
-
- **NOTE:**
- * BAD_RECORDS_ACTION property can have four type of actions for bad records FORCE, REDIRECT, IGNORE and FAIL.
- * FAIL option is its Default value. If the FAIL option is used, then data loading fails if any bad records are found.
- * If the REDIRECT option is used, CarbonData will add all bad records in to a separate CSV file. However, this file must not be used for subsequent data loading because the content may not exactly match the source record. You are advised to cleanse the original source record for further data ingestion. This option is used to remind you which records are bad records.
- * If the FORCE option is used, then it auto-converts the data by storing the bad records as NULL before Loading data.
- * If the IGNORE option is used, then bad records are neither loaded nor written to the separate CSV file.
- * In loaded data, if all records are bad records, the BAD_RECORDS_ACTION is invalid and the load operation fails.
- * The default maximum number of characters per column is 32000. If there are more than 32000 characters in a column, please refer to *String longer than 32000 characters* section.
- * Since Bad Records Path can be specified in create, load and carbon properties.
- Therefore, value specified in load will have the highest priority, and value specified in carbon properties will have the least priority.
-
- **Bad Records Path:**
-
- This property is used to specify the location where bad records would be written.
-
- ```
- TBLPROPERTIES('BAD_RECORDS_PATH'='/opt/badrecords'')
- ```
-
- Example:
-
- ```
- LOAD DATA INPATH 'filepath.csv' INTO TABLE tablename
- OPTIONS('BAD_RECORDS_LOGGER_ENABLE'='true','BAD_RECORD_PATH'='hdfs://hacluster/tmp/carbon',
- 'BAD_RECORDS_ACTION'='REDIRECT','IS_EMPTY_DATA_BAD_RECORD'='false')
- ```
-
- - **GLOBAL_SORT_PARTITIONS:** If the SORT_SCOPE is defined as GLOBAL_SORT, then user can specify the number of partitions to use while shuffling data for sort using GLOBAL_SORT_PARTITIONS. If it is not configured, or configured less than 1, then it uses the number of map task as reduce task. It is recommended that each reduce task deal with 512MB-1GB data.
-
- ```
- OPTIONS('GLOBAL_SORT_PARTITIONS'='2')
- ```
-
- NOTE:
- * GLOBAL_SORT_PARTITIONS should be Integer type, the range is [1,Integer.MaxValue].
- * It is only used when the SORT_SCOPE is GLOBAL_SORT.
-
-### INSERT DATA INTO CARBONDATA TABLE
-
- This command inserts data into a CarbonData table, it is defined as a combination of two queries Insert and Select query respectively.
- It inserts records from a source table into a target CarbonData table, the source table can be a Hive table, Parquet table or a CarbonData table itself.
- It comes with the functionality to aggregate the records of a table by performing Select query on source table and load its corresponding resultant records into a CarbonData table.
-
- ```
- INSERT INTO TABLE <CARBONDATA TABLE> SELECT * FROM sourceTableName
- [ WHERE { <filter_condition> } ]
- ```
-
- You can also omit the `table` keyword and write your query as:
-
- ```
- INSERT INTO <CARBONDATA TABLE> SELECT * FROM sourceTableName
- [ WHERE { <filter_condition> } ]
- ```
-
- Overwrite insert data:
- ```
- INSERT OVERWRITE TABLE <CARBONDATA TABLE> SELECT * FROM sourceTableName
- [ WHERE { <filter_condition> } ]
- ```
-
- **NOTE:**
- * The source table and the CarbonData table must have the same table schema.
- * The data type of source and destination table columns should be same
- * INSERT INTO command does not support partial success if bad records are found, it will fail.
- * Data cannot be loaded or updated in source table while insert from source table to target table is in progress.
-
- Examples
- ```
- INSERT INTO table1 SELECT item1, sum(item2 + 1000) as result FROM table2 group by item1
- ```
-
- ```
- INSERT INTO table1 SELECT item1, item2, item3 FROM table2 where item2='xyz'
- ```
-
- ```
- INSERT OVERWRITE TABLE table1 SELECT * FROM TABLE2
- ```
-
-## UPDATE AND DELETE
-
-### UPDATE
-
- This command will allow to update the CarbonData table based on the column expression and optional filter conditions.
-
- ```
- UPDATE <table_name>
- SET (column_name1, column_name2, ... column_name n) = (column1_expression , column2_expression, ... column n_expression )
- [ WHERE { <filter_condition> } ]
- ```
-
- alternatively the following command can also be used for updating the CarbonData Table :
-
- ```
- UPDATE <table_name>
- SET (column_name1, column_name2) =(select sourceColumn1, sourceColumn2 from sourceTable [ WHERE { <filter_condition> } ] )
- [ WHERE { <filter_condition> } ]
- ```
-
- **NOTE:** The update command fails if multiple input rows in source table are matched with single row in destination table.
-
- Examples:
- ```
- UPDATE t3 SET (t3_salary) = (t3_salary + 9) WHERE t3_name = 'aaa1'
- ```
-
- ```
- UPDATE t3 SET (t3_date, t3_country) = ('2017-11-18', 'india') WHERE t3_salary < 15003
- ```
-
- ```
- UPDATE t3 SET (t3_country, t3_name) = (SELECT t5_country, t5_name FROM t5 WHERE t5_id = 5) WHERE t3_id < 5
- ```
-
- ```
- UPDATE t3 SET (t3_date, t3_serialname, t3_salary) = (SELECT '2099-09-09', t5_serialname, '9999' FROM t5 WHERE t5_id = 5) WHERE t3_id < 5
- ```
-
-
- ```
- UPDATE t3 SET (t3_country, t3_salary) = (SELECT t5_country, t5_salary FROM t5 FULL JOIN t3 u WHERE u.t3_id = t5_id and t5_id=6) WHERE t3_id >6
- ```
- NOTE: Update Complex datatype columns is not supported.
-
-### DELETE
-
- This command allows us to delete records from CarbonData table.
- ```
- DELETE FROM table_name [WHERE expression]
- ```
-
- Examples:
-
- ```
- DELETE FROM carbontable WHERE column1 = 'china'
- ```
-
- ```
- DELETE FROM carbontable WHERE column1 IN ('china', 'USA')
- ```
-
- ```
- DELETE FROM carbontable WHERE column1 IN (SELECT column11 FROM sourceTable2)
- ```
-
- ```
- DELETE FROM carbontable WHERE column1 IN (SELECT column11 FROM sourceTable2 WHERE column1 = 'USA')
- ```
-
-## COMPACTION
-
- Compaction improves the query performance significantly.
-
- There are several types of compaction.
-
- ```
- ALTER TABLE [db_name.]table_name COMPACT 'MINOR/MAJOR/CUSTOM'
- ```
-
- - **Minor Compaction**
-
- In Minor compaction, user can specify the number of loads to be merged.
- Minor compaction triggers for every data load if the parameter carbon.enable.auto.load.merge is set to true.
- If any segments are available to be merged, then compaction will run parallel with data load, there are 2 levels in minor compaction:
- * Level 1: Merging of the segments which are not yet compacted.
- * Level 2: Merging of the compacted segments again to form a larger segment.
-
- ```
- ALTER TABLE table_name COMPACT 'MINOR'
- ```
-
- - **Major Compaction**
-
- In Major compaction, multiple segments can be merged into one large segment.
- User will specify the compaction size until which segments can be merged, Major compaction is usually done during the off-peak time.
- Configure the property carbon.major.compaction.size with appropriate value in MB.
-
- This command merges the specified number of segments into one segment:
-
- ```
- ALTER TABLE table_name COMPACT 'MAJOR'
- ```
-
- - **Custom Compaction**
-
- In Custom compaction, user can directly specify segment ids to be merged into one large segment.
- All specified segment ids should exist and be valid, otherwise compaction will fail.
- Custom compaction is usually done during the off-peak time.
-
- ```
- ALTER TABLE table_name COMPACT 'CUSTOM' WHERE SEGMENT.ID IN (2,3,4)
- ```
- NOTE: Compaction is unsupported for table containing Complex columns.
-
-
- - **CLEAN SEGMENTS AFTER Compaction**
-
- Clean the segments which are compacted:
- ```
- CLEAN FILES FOR TABLE carbon_table
- ```
-
-## PARTITION
-
-### STANDARD PARTITION
-
- The partition is similar as spark and hive partition, user can use any column to build partition:
-
-#### Create Partition Table
-
- This command allows you to create table with partition.
-
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
- [(col_name data_type , ...)]
- [COMMENT table_comment]
- [PARTITIONED BY (col_name data_type , ...)]
- [STORED BY file_format]
- [TBLPROPERTIES (property_name=property_value, ...)]
- ```
-
- Example:
- ```
- CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
- productNumber INT,
- productName STRING,
- storeCity STRING,
- storeProvince STRING,
- saleQuantity INT,
- revenue INT)
- PARTITIONED BY (productCategory STRING, productBatch STRING)
- STORED BY 'carbondata'
- ```
- NOTE: Hive partition is not supported on complex datatype columns.
-
-#### Load Data Using Static Partition
-
- This command allows you to load data using static partition.
-
- ```
- LOAD DATA [LOCAL] INPATH 'folder_path'
- INTO TABLE [db_name.]table_name PARTITION (partition_spec)
- OPTIONS(property_name=property_value, ...)
- INSERT INTO INTO TABLE [db_name.]table_name PARTITION (partition_spec) <SELECT STATEMENT>
- ```
-
- Example:
- ```
- LOAD DATA LOCAL INPATH '${env:HOME}/staticinput.csv'
- INTO TABLE locationTable
- PARTITION (country = 'US', state = 'CA')
- INSERT INTO TABLE locationTable
- PARTITION (country = 'US', state = 'AL')
- SELECT <columns list excluding partition columns> FROM another_user
- ```
-
-#### Load Data Using Dynamic Partition
-
- This command allows you to load data using dynamic partition. If partition spec is not specified, then the partition is considered as dynamic.
-
- Example:
- ```
- LOAD DATA LOCAL INPATH '${env:HOME}/staticinput.csv'
- INTO TABLE locationTable
- INSERT INTO TABLE locationTable
- SELECT <columns list excluding partition columns> FROM another_user
- ```
-
-#### Show Partitions
-
- This command gets the Hive partition information of the table
-
- ```
- SHOW PARTITIONS [db_name.]table_name
- ```
-
-#### Drop Partition
-
- This command drops the specified Hive partition only.
- ```
- ALTER TABLE table_name DROP [IF EXISTS] PARTITION (part_spec, ...)
- ```
-
- Example:
- ```
- ALTER TABLE locationTable DROP PARTITION (country = 'US');
- ```
-
-#### Insert OVERWRITE
-
- This command allows you to insert or load overwrite on a specific partition.
-
- ```
- INSERT OVERWRITE TABLE table_name
- PARTITION (column = 'partition_name')
- select_statement
- ```
-
- Example:
- ```
- INSERT OVERWRITE TABLE partitioned_user
- PARTITION (country = 'US')
- SELECT * FROM another_user au
- WHERE au.country = 'US';
- ```
-
-### CARBONDATA PARTITION(HASH,RANGE,LIST) -- Alpha feature, this partition feature does not support update and delete data.
-
- The partition supports three type:(Hash,Range,List), similar to other system's partition features, CarbonData's partition feature can be used to improve query performance by filtering on the partition column.
-
-### Create Hash Partition Table
-
- This command allows us to create hash partition.
-
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
- [(col_name data_type , ...)]
- PARTITIONED BY (partition_col_name data_type)
- STORED BY 'carbondata'
- [TBLPROPERTIES ('PARTITION_TYPE'='HASH',
- 'NUM_PARTITIONS'='N' ...)]
- ```
- **NOTE:** N is the number of hash partitions
-
-
- Example:
- ```
- CREATE TABLE IF NOT EXISTS hash_partition_table(
- col_A STRING,
- col_B INT,
- col_C LONG,
- col_D DECIMAL(10,2),
- col_F TIMESTAMP
- ) PARTITIONED BY (col_E LONG)
- STORED BY 'carbondata' TBLPROPERTIES('PARTITION_TYPE'='HASH','NUM_PARTITIONS'='9')
- ```
-
-### Create Range Partition Table
-
- This command allows us to create range partition.
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
- [(col_name data_type , ...)]
- PARTITIONED BY (partition_col_name data_type)
- STORED BY 'carbondata'
- [TBLPROPERTIES ('PARTITION_TYPE'='RANGE',
- 'RANGE_INFO'='2014-01-01, 2015-01-01, 2016-01-01, ...')]
- ```
-
- **NOTE:**
- * The 'RANGE_INFO' must be defined in ascending order in the table properties.
- * The default format for partition column of Date/Timestamp type is yyyy-MM-dd. Alternate formats for Date/Timestamp could be defined in CarbonProperties.
-
- Example:
- ```
- CREATE TABLE IF NOT EXISTS range_partition_table(
- col_A STRING,
- col_B INT,
- col_C LONG,
- col_D DECIMAL(10,2),
- col_E LONG
- ) partitioned by (col_F Timestamp)
- PARTITIONED BY 'carbondata'
- TBLPROPERTIES('PARTITION_TYPE'='RANGE',
- 'RANGE_INFO'='2015-01-01, 2016-01-01, 2017-01-01, 2017-02-01')
- ```
-
-### Create List Partition Table
-
- This command allows us to create list partition.
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
- [(col_name data_type , ...)]
- PARTITIONED BY (partition_col_name data_type)
- STORED BY 'carbondata'
- [TBLPROPERTIES ('PARTITION_TYPE'='LIST',
- 'LIST_INFO'='A, B, C, ...')]
- ```
- **NOTE:** List partition supports list info in one level group.
-
- Example:
- ```
- CREATE TABLE IF NOT EXISTS list_partition_table(
- col_B INT,
- col_C LONG,
- col_D DECIMAL(10,2),
- col_E LONG,
- col_F TIMESTAMP
- ) PARTITIONED BY (col_A STRING)
- STORED BY 'carbondata'
- TBLPROPERTIES('PARTITION_TYPE'='LIST',
- 'LIST_INFO'='aaaa, bbbb, (cccc, dddd), eeee')
- ```
-
-
-### Show Partitions
-
- The following command is executed to get the partition information of the table
-
- ```
- SHOW PARTITIONS [db_name.]table_name
- ```
-
-### Add a new partition
-
- ```
- ALTER TABLE [db_name].table_name ADD PARTITION('new_partition')
- ```
-
-### Split a partition
-
- ```
- ALTER TABLE [db_name].table_name SPLIT PARTITION(partition_id) INTO('new_partition1', 'new_partition2'...)
- ```
-
-### Drop a partition
-
- Only drop partition definition, but keep data
- ```
- ALTER TABLE [db_name].table_name DROP PARTITION(partition_id)
- ```
-
- Drop both partition definition and data
- ```
- ALTER TABLE [db_name].table_name DROP PARTITION(partition_id) WITH DATA
- ```
-
- **NOTE:**
- * Hash partition table is not supported for ADD, SPLIT and DROP commands.
- * Partition Id: in CarbonData like the hive, folders are not used to divide partitions instead partition id is used to replace the task id. It could make use of the characteristic and meanwhile reduce some metadata.
-
- ```
- SegmentDir/0_batchno0-0-1502703086921.carbonindex
- ^
- SegmentDir/part-0-0_batchno0-0-1502703086921.carbondata
- ^
- ```
-
- Here are some useful tips to improve query performance of carbonData partition table:
- * The partitioned column can be excluded from SORT_COLUMNS, this will let other columns to do the efficient sorting.
- * When writing SQL on a partition table, try to use filters on the partition column.
-
-## BUCKETING
-
- Bucketing feature can be used to distribute/organize the table/partition data into multiple files such
- that similar records are present in the same file. While creating a table, user needs to specify the
- columns to be used for bucketing and the number of buckets. For the selection of bucket the Hash value
- of columns is used.
-
- ```
- CREATE TABLE [IF NOT EXISTS] [db_name.]table_name
- [(col_name data_type, ...)]
- STORED BY 'carbondata'
- TBLPROPERTIES('BUCKETNUMBER'='noOfBuckets',
- 'BUCKETCOLUMNS'='columnname')
- ```
-
- **NOTE:**
- * Bucketing cannot be performed for columns of Complex Data Types.
- * Columns in the BUCKETCOLUMN parameter must be dimensions. The BUCKETCOLUMN parameter cannot be a measure or a combination of measures and dimensions.
-
- Example:
- ```
- CREATE TABLE IF NOT EXISTS productSchema.productSalesTable (
- productNumber INT,
- saleQuantity INT,
- productName STRING,
- storeCity STRING,
- storeProvince STRING,
- productCategory STRING,
- productBatch STRING,
- revenue INT)
- STORED BY 'carbondata'
- TBLPROPERTIES ('BUCKETNUMBER'='4', 'BUCKETCOLUMNS'='productName')
- ```
-
-## SEGMENT MANAGEMENT
-
-### SHOW SEGMENT
-
- This command is used to list the segments of CarbonData table.
-
- ```
- SHOW [HISTORY] SEGMENTS FOR TABLE [db_name.]table_name LIMIT number_of_segments
- ```
-
- Example:
- Show visible segments
- ```
- SHOW SEGMENTS FOR TABLE CarbonDatabase.CarbonTable LIMIT 4
- ```
- Show all segments, include invisible segments
- ```
- SHOW HISTORY SEGMENTS FOR TABLE CarbonDatabase.CarbonTable LIMIT 4
- ```
-
-### DELETE SEGMENT BY ID
-
- This command is used to delete segment by using the segment ID. Each segment has a unique segment ID associated with it.
- Using this segment ID, you can remove the segment.
-
- The following command will get the segmentID.
-
- ```
- SHOW SEGMENTS FOR TABLE [db_name.]table_name LIMIT number_of_segments
- ```
-
- After you retrieve the segment ID of the segment that you want to delete, execute the following command to delete the selected segment.
-
- ```
- DELETE FROM TABLE [db_name.]table_name WHERE SEGMENT.ID IN (segment_id1, segments_id2, ...)
- ```
-
- Example:
-
- ```
- DELETE FROM TABLE CarbonDatabase.CarbonTable WHERE SEGMENT.ID IN (0)
- DELETE FROM TABLE CarbonDatabase.CarbonTable WHERE SEGMENT.ID IN (0,5,8)
- ```
-
-### DELETE SEGMENT BY DATE
-
- This command will allow to delete the CarbonData segment(s) from the store based on the date provided by the user in the DML command.
- The segment created before the particular date will be removed from the specific stores.
-
- ```
- DELETE FROM TABLE [db_name.]table_name WHERE SEGMENT.STARTTIME BEFORE DATE_VALUE
- ```
-
- Example:
- ```
- DELETE FROM TABLE CarbonDatabase.CarbonTable WHERE SEGMENT.STARTTIME BEFORE '2017-06-01 12:05:06'
- ```
-
-### QUERY DATA WITH SPECIFIED SEGMENTS
-
- This command is used to read data from specified segments during CarbonScan.
-
- Get the Segment ID:
- ```
- SHOW SEGMENTS FOR TABLE [db_name.]table_name LIMIT number_of_segments
- ```
-
- Set the segment IDs for table
- ```
- SET carbon.input.segments.<database_name>.<table_name> = <list of segment IDs>
- ```
-
- **NOTE:**
- carbon.input.segments: Specifies the segment IDs to be queried. This property allows you to query specified segments of the specified table. The CarbonScan will read data from specified segments only.
-
- If user wants to query with segments reading in multi threading mode, then CarbonSession. threadSet can be used instead of SET query.
- ```
- CarbonSession.threadSet ("carbon.input.segments.<database_name>.<table_name>","<list of segment IDs>");
- ```
-
- Reset the segment IDs
- ```
- SET carbon.input.segments.<database_name>.<table_name> = *;
- ```
-
- If user wants to query with segments reading in multi threading mode, then CarbonSession. threadSet can be used instead of SET query.
- ```
- CarbonSession.threadSet ("carbon.input.segments.<database_name>.<table_name>","*");
- ```
-
- **Examples:**
-
- * Example to show the list of segment IDs,segment status, and other required details and then specify the list of segments to be read.
-
- ```
- SHOW SEGMENTS FOR carbontable1;
-
- SET carbon.input.segments.db.carbontable1 = 1,3,9;
- ```
-
- * Example to query with segments reading in multi threading mode:
-
- ```
- CarbonSession.threadSet ("carbon.input.segments.db.carbontable_Multi_Thread","1,3");
- ```
-
- * Example for threadset in multithread environment (following shows how it is used in Scala code):
-
- ```
- def main(args: Array[String]) {
- Future {
- CarbonSession.threadSet ("carbon.input.segments.db.carbontable_Multi_Thread","1")
- spark.sql("select count(empno) from carbon.input.segments.db.carbontable_Multi_Thread").show();
- }
- }
- ```
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/datamap-developer-guide.md
----------------------------------------------------------------------
diff --git a/docs/datamap-developer-guide.md b/docs/datamap-developer-guide.md
index 31afd34..6bac9b5 100644
--- a/docs/datamap-developer-guide.md
+++ b/docs/datamap-developer-guide.md
@@ -3,14 +3,17 @@
### Introduction
DataMap is a data structure that can be used to accelerate certain query of the table. Different DataMap can be implemented by developers.
Currently, there are two 2 types of DataMap supported:
-1. IndexDataMap: DataMap that leveraging index to accelerate filter query
-2. MVDataMap: DataMap that leveraging Materialized View to accelerate olap style query, like SPJG query (select, predicate, join, groupby)
+1. IndexDataMap: DataMap that leverages index to accelerate filter query
+2. MVDataMap: DataMap that leverages Materialized View to accelerate olap style query, like SPJG query (select, predicate, join, groupby)
### DataMap provider
When user issues `CREATE DATAMAP dm ON TABLE main USING 'provider'`, the corresponding DataMapProvider implementation will be created and initialized.
Currently, the provider string can be:
-1. preaggregate: one type of MVDataMap that do pre-aggregate of single table
-2. timeseries: one type of MVDataMap that do pre-aggregate based on time dimension of the table
+1. preaggregate: A type of MVDataMap that do pre-aggregate of single table
+2. timeseries: A type of MVDataMap that do pre-aggregate based on time dimension of the table
3. class name IndexDataMapFactory implementation: Developer can implement new type of IndexDataMap by extending IndexDataMapFactory
-When user issues `DROP DATAMAP dm ON TABLE main`, the corresponding DataMapProvider interface will be called.
\ No newline at end of file
+When user issues `DROP DATAMAP dm ON TABLE main`, the corresponding DataMapProvider interface will be called.
+
+Details about [DataMap Management](./datamap/datamap-management.md#datamap-management) and supported [DSL](./datamap/datamap-management.md#overview) are documented [here](./datamap/datamap-management.md).
+
http://git-wip-us.apache.org/repos/asf/carbondata/blob/6e50c1c6/docs/datamap/bloomfilter-datamap-guide.md
----------------------------------------------------------------------
diff --git a/docs/datamap/bloomfilter-datamap-guide.md b/docs/datamap/bloomfilter-datamap-guide.md
index 92810f8..b2e7d60 100644
--- a/docs/datamap/bloomfilter-datamap-guide.md
+++ b/docs/datamap/bloomfilter-datamap-guide.md
@@ -73,7 +73,7 @@ For instance, main table called **datamap_test** which is defined as:
age int,
city string,
country string)
- STORED BY 'carbondata'
+ STORED AS carbondata
TBLPROPERTIES('SORT_COLUMNS'='id')
```
@@ -144,4 +144,5 @@ You can refer to the corresponding section in `CarbonData Lucene DataMap`.
+ In some scenarios, the BloomFilter datamap may not enhance the query performance significantly
but if it can reduce the number of spark task,
there is still a chance that BloomFilter datamap can enhance the performance for concurrent query.
-+ Note that BloomFilter datamap will decrease the data loading performance and may cause slightly storage expansion (for datamap index file).
\ No newline at end of file
++ Note that BloomFilter datamap will decrease the data loading performance and may cause slightly storage expansion (for datamap index file).
+