This is an automated email from the ASF dual-hosted git repository.
jackylk pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/carbondata.git
The following commit(s) were added to refs/heads/master by this push:
new 71a4cf4 [DOC] Add an introduction documention for detailed data query
71a4cf4 is described below
commit 71a4cf46a7dfe20698e77c83c6e3cff7cc3cd07d
Author: litao <litao_xid...@126.com>
AuthorDate: Fri Dec 20 19:20:13 2019 +0800
[DOC] Add an introduction documention for detailed data query
Add a use case of carbondata detailed data query
This closes #3523
---
...277\207\346\273\244\346\235\241\344\273\266.md" | 533 +++++++++++++++++++++
docs/zh_cn/images/SortColumns.png | Bin 0 -> 6789 bytes
2 files changed, 533 insertions(+)
diff --git
"a/docs/zh_cn/CarbonData\345\205\270\345\236\213\345\272\224\347\224\250\345\234\272\346\231\257\344\271\213\346\230\216\347\273\206\346\225\260\346\215\256\346\237\245\350\257\242\357\274\232\347\202\271\346\237\245+\350\277\207\346\273\244\346\235\241\344\273\266.md"
"b/docs/zh_cn/CarbonData\345\205\270\345\236\213\345\272\224\347\224\250\345\234\272\346\231\257\344\271\213\346\230\216\347\273\206\346\225\260\346\215\256\346\237\245\350\257\242\357\274\232\347\202\271\346\237
[...]
new file mode 100644
index 0000000..191326f
--- /dev/null
+++
"b/docs/zh_cn/CarbonData\345\205\270\345\236\213\345\272\224\347\224\250\345\234\272\346\231\257\344\271\213\346\230\216\347\273\206\346\225\260\346\215\256\346\237\245\350\257\242\357\274\232\347\202\271\346\237\245+\350\277\207\346\273\244\346\235\241\344\273\266.md"
@@ -0,0 +1,533 @@
+<!--
+ 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典型应用场景之明细数据查询：点查+过滤条件
+
+## 背景
+
+
本文主要描述在使用CarbonData进行明细数据查询时，如何设置建表、加载、查询时的参数，以提升对应的性能。具体来说，包括在建表时如何选择合适的字典、SORT_COLUMNS、SORT_SCOPE等配置，同时我们还给出了验证场景下的环境规格、数据规格等，同时给出了配置项及对应达到的数据加载和查询性能，以便大家根据自己的业务特点和场景选择进行参数调整。
+
+ 本文中用例数据表特点：
+
+ 1.表记录数都比较大，范围从数千万到数百亿。
+
+ 2.列数比较多，大约在100-600列之间。
+
+ 使用特点：
+
+ 1.主要是进行点查和过滤，没有汇聚计算，偶尔有关联维表的场景。
+
+ 2.数据入库采取分批入库的方式，周期约为5分钟，按天建表。
+
+ 3.查询时可能有不少于20的并发查询。
+
+典型的查询的使用框架，其中第五个求sum仅为作性能对比。
+
+| 编号 | 描述 | 查询SQL样例
|
+| ---- | ----------------------- |
------------------------------------------------------- |
+| 1 | 点查 | select * from table where id_a=' ' limit
1000; |
+| 2 | 模糊查询 | select * from table where id_a like '1234%'
limit 1000; |
+| 3 | 求记录总数 | select count(1) from table;
|
+| 4 | 求最大/最小值 | select max(id_a), min(id_a) from table;
|
+| 5 | 求sum(仅为了做性能对比) | select sum(id_a) from table;
|
+
+数据的特点，列主要是以int, bigint, string列构成，描述一些号码列，时间列，ID列等，无复杂数据类型。
+
+## 测试环境
+
+| 集群 | CPU | vCore | Memory | 硬盘 | 描述
|
+| ---------- | -------------------- | ----- | ------ | ------------------ |
------------------------------------------------------------ |
+| Hadoop集群 | Gold 6132 CPU@2.60GZ | 56 | 256GB | SATA磁盘，4T数据盘 |
2个namenode，6个datanode， 查询队列分配1/6的资源，等同于一个节点 |
+
+
+
+## 建表 Create table
+
+### 建表 Create table 时字典的选择
+
+ 建表时用户可以选择使用本地字典或者不使用字典。通常情况下使用本地字典数据加载时比较耗时，但是查询时较快;
而不使用本地字典时加载较快，查询不如使用本地字典。用户在实际使用时可以根据自身业务的诉求来选择合适的模式。关于CarbonData本地字典的具体描述可以参考官网的[文档](http://carbondata.apache.org/ddl-of-carbondata.html#create-table)。
+
+ 为此这里做了一个验证，分别对不使用字典，使用本地字典的数据表进行加载和点查操作，分析其加载和查询性能。
+
+建表语句结构如下：
+
+1）不使用字典：
+
+```sql
+create table if not exists test.detail_benchmark1
+('id', BIGINT, 'imsi' STRING,'msisdn' STRING, `imei` STRING, ...)
+TBLPROPERTIES ( 'LOCAL_DICTIONARY_ENABLE'='false', 'table_blocksize'='256')
+```
+
+2) 使用本地字典：
+
+```sql
+create table if not exists test.detail_loacl_dict
+('id', BIGINT, 'imsi' STRING,'msisdn' STRING, `imei` STRING, ...)
+TBLPROPERTIES (
'LOCAL_DICTIONARY_INCLUDE'='IMSI,MSISDN,IMEI','table_blocksize'='256')
+```
+
+使用16亿数据量样本作为表数据，分168个批次分别加载到如上表中，其加载性能如下：
+
+| 表 | 数据量 | 加载耗时 秒 |
+| ---------------------- | ---------- | ----------- |
+| test.detail_benchmark1 | 1613149548 | 1109 |
+| test.detail_loacl_dict | 1613149548 | 1876 |
+
+下面列表记录了每一个批次的加载耗时
+
+| 加载批次 | 耗时 秒 detail_benchmark | 耗时 秒 detail_loacl_dict |
+| -------- | ------------------------- | ------------------------- |
+| 1 | 6.584 | 19.31 |
+| 2 | 10.255 | 21.406 |
+| 3 | 5.079 | 21.619 |
+| 4 | 5.004 | 21.538 |
+| 5 | 10.877 | 18.191 |
+| 6 | 7.868 | 17.457 |
+| 7 | 5.295 | 20.919 |
+| 8 | 4.43 | 17.048 |
+| 9 | 5.373 | 18.584 |
+| 10 | 6.074 | 17.668 |
+| 11 | 5.889 | 19.553 |
+| 12 | 4.8 | 14.819 |
+| 13 | 4.972 | 12 |
+| 14 | 5.144 | 11.909 |
+| 15 | 5.403 | 18.428 |
+| 16 | 5.314 | 19.536 |
+| 17 | 4.519 | 22.373 |
+| 18 | 9.327 | 24.507 |
+| 19 | 5.277 | 7.219 |
+| 20 | 10.882 | 6.552 |
+| 21 | 4.74 | 11.911 |
+| 22 | 5.38 | 11.908 |
+| 23 | 9.046 | 7.076 |
+| 24 | 4.399 | 6.391 |
+| 25 | 5.079 | 7.697 |
+| 26 | 4.177 | 6.114 |
+| 27 | 4.441 | 6.349 |
+| 28 | 4.951 | 7.034 |
+| 29 | 5.09 | 13.404 |
+| 30 | 4.286 | 7.455 |
+| 31 | 7.821 | 13.776 |
+| 32 | 4.623 | 7.025 |
+| 33 | 9.304 | 7.273 |
+| 34 | 4.806 | 13.23 |
+| 35 | 5.469 | 6.562 |
+| 36 | 10.045 | 6.581 |
+| 37 | 4.619 | 11.716 |
+| 38 | 5.807 | 5.939 |
+| 39 | 9.101 | 6.531 |
+| 40 | 4.968 | 6.675 |
+| 41 | 4.654 | 6.389 |
+| 42 | 4.763 | 6.774 |
+| 43 | 4.155 | 6.203 |
+| 44 | 4.672 | 6.288 |
+| 45 | 5.052 | 12.845 |
+| 46 | 4.812 | 6.185 |
+| 47 | 7.941 | 6.653 |
+| 48 | 5.401 | 5.775 |
+| 49 | 4.684 | 5.776 |
+| 50 | 4.698 | 10.646 |
+| 51 | 4.604 | 6.359 |
+| 52 | 8.843 | 5.899 |
+| 53 | 4.785 | 11.284 |
+| 54 | 4.969 | 7.116 |
+| 55 | 7.634 | 6.291 |
+| 56 | 4.424 | 6.534 |
+| 57 | 5.086 | 11.372 |
+| 58 | 4.461 | 5.613 |
+| 59 | 7.809 | 19.169 |
+| 60 | 4.852 | 7.34 |
+| 61 | 8.486 | 7.182 |
+| 62 | 4.412 | 10.598 |
+| 63 | 4.168 | 17.974 |
+| 64 | 4.287 | 6.998 |
+| 65 | 8.867 | 6.526 |
+| 66 | 4.37 | 6.457 |
+| 67 | 4.23 | 12.335 |
+| 68 | 5.28 | 13.638 |
+| 69 | 7.945 | 7.597 |
+| 70 | 4.647 | 41.695 |
+| 71 | 4.429 | 22.057 |
+| 72 | 8.659 | 11.863 |
+| 73 | 10.062 | 17.561 |
+| 74 | 5.514 | 8.366 |
+| 75 | 7.608 | 14.011 |
+| 76 | 4.586 | 7.205 |
+| 77 | 7.692 | 6.602 |
+| 78 | 5.319 | 6.103 |
+| 79 | 4.884 | 18.043 |
+| 80 | 4.13 | 6.89 |
+| 81 | 8.511 | 11.561 |
+| 82 | 4.983 | 7.434 |
+| 83 | 8.486 | 5.779 |
+| 84 | 5.158 | 6.033 |
+| 85 | 4.224 | 6.359 |
+| 86 | 4.444 | 6.736 |
+| 87 | 4.546 | 6.397 |
+| 88 | 4.799 | 6.904 |
+| 89 | 3.967 | 7.01 |
+| 90 | 4.437 | 5.612 |
+| 91 | 4.541 | 10.904 |
+| 92 | 4.649 | 6.64 |
+| 93 | 4.665 | 6.508 |
+| 94 | 62.925 | 17.063 |
+| 95 | 4.335 | 7.104 |
+| 96 | 7.366 | 7.699 |
+| 97 | 5.028 | 6.881 |
+| 98 | 5.097 | 5.803 |
+| 99 | 4.345 | 6.36 |
+| 100 | 4.251 | 9.569 |
+| 101 | 4.671 | 6.121 |
+| 102 | 7.432 | 5.491 |
+| 103 | 4.508 | 6.412 |
+| 104 | 4.866 | 6.104 |
+| 105 | 4.58 | 12.243 |
+| 106 | 4.94 | 6.362 |
+| 107 | 7.842 | 5.697 |
+| 108 | 4.332 | 11.934 |
+| 109 | 4.646 | 29.469 |
+| 110 | 4.534 | 14.249 |
+| 111 | 9.206 | 13.585 |
+| 112 | 4.802 | 10.479 |
+| 113 | 4.119 | 8.238 |
+| 114 | 4.139 | 9.334 |
+| 115 | 4.588 | 8.438 |
+| 116 | 4.537 | 8.621 |
+| 117 | 4.688 | 7.742 |
+| 118 | 4.055 | 8.27 |
+| 119 | 4.703 | 6.958 |
+| 120 | 4.51 | 23.409 |
+| 121 | 4.178 | 9.167 |
+| 122 | 9.22 | 6.772 |
+| 123 | 4.359 | 12.718 |
+| 124 | 4.926 | 7.611 |
+| 125 | 4.487 | 14.572 |
+| 126 | 4.571 | 13.044 |
+| 127 | 8.108 | 8.975 |
+| 128 | 4.472 | 18.712 |
+| 129 | 4.66 | 45.553 |
+| 130 | 7.791 | 12.255 |
+| 131 | 8.569 | 13.897 |
+| 132 | 5.671 | 12.073 |
+| 133 | 9.43 | 21.305 |
+| 134 | 4.015 | 6.391 |
+| 135 | 8.961 | 47.173 |
+| 136 | 5.955 | 9.856 |
+| 137 | 7.095 | 6.996 |
+| 138 | 4.641 | 11.802 |
+| 139 | 5.156 | 6.072 |
+| 140 | 7.757 | 6.365 |
+| 141 | 4.71 | 10.944 |
+| 142 | 4.346 | 7.061 |
+| 143 | 8.663 | 6.19 |
+| 144 | 4.641 | 13.49 |
+| 145 | 4.864 | 6.598 |
+| 146 | 7.932 | 7.13 |
+| 147 | 4.56 | 11.359 |
+| 148 | 3.941 | 6.113 |
+| 149 | 7.729 | 10.987 |
+| 150 | 4.7 | 7.347 |
+| 151 | 8.089 | 7.309 |
+| 152 | 4.016 | 12.875 |
+| 153 | 4.468 | 7.873 |
+| 154 | 9.136 | 6.559 |
+| 155 | 5.69 | 16.854 |
+| 156 | 4.253 | 6.499 |
+| 157 | 8.223 | 5.983 |
+| 158 | 4.733 | 16.357 |
+| 159 | 4.347 | 15.032 |
+| 160 | 4.276 | 13.735 |
+| 161 | 17.02 | 13.094 |
+| 162 | 4.765 | 22.683 |
+| 163 | 5.941 | 12.033 |
+| 164 | 66.877 | 11.795 |
+| 165 | 15.101 | 6.563 |
+| 166 | 8.748 | 9.21 |
+| 167 | 5.412 | 10.025 |
+| 168 | 11.692 | 8.565 |
+| 总计 | 1109.742 | 1876.579 |
+
+
从数据中可以看出，使用本地字典在数据加载时将花费更多的时间，不使用字典时耗时明显少，从168个批次的统计数据看使用本地字典将比不使用本地字典多消耗70%的加载时长，但是在查询性能上又有提升，详细见后续介绍。
+
+查询性能的对比
+
+ 这里使用了一组点查的SQL对使用本地字典、全局字典和不使用字典的数据表进行了查询统计，记录一些统计结论。
+
+点查询SQL分别使用
+
+```sql
+select * from test.detail_benchmark where MSISDN="13900000000" limit 2000;
+select * from test.detail_loacl_dict where MSISDN="13900000000" limit 2000;
+
+```
+
+模糊查询SQL分别使用
+
+```sql
+select * from test.detail_benchmark where MSISDN like "1361%" limit 2000;
+select * from test.detail_loacl_dict where MSISDN like "1391%" limit 2000;
+```
+
+
+
+记录查询耗时情况如下：
+
+| 查询用例 | 耗时 秒 detail_benchmark | 耗时 秒 detail_loacl_dict |
+| ------------------ | ------------------------ | ------------------------- |
+| 点查询五次平均值 | 18.5 | 14.543 |
+| 模糊查询五次平均值 | 10.832 | 4.118 |
+
+
从结果可以看出，使用本地字典查询较不使用本地字典点查的时候性能有较大的提升。使用本地字典点查询性能提升在30%左右，模糊查询性能提升超过1倍。
+
+
用户在选择字典的使用上时，可以根据自身对数据加载的要求和查询要求来选择字典，本案例由于对数据入库的时效性有较高要求，为了避免数据加载的延迟，因此在建表的时候选择无字典的方案，牺牲了一些查询性能。
+
+
+
+### 建表 Create table 时SORT_COLUMNS和SORT_SCOPE的选择
+
+
关于SORT_COLUMNS的配置可以参考CarbonData[官网](http://carbondata.apache.org/ddl-of-carbondata.html#create-table)的说明,
当用户不指定SORT_COLUMNS时，默认将不建立SORT_COLUMNS，当前的SORT_COLUMNS只支持：string, date,
timestamp, short, int, long, byte, boolean类型。SORT_COLUMNS
在用户指定的列上建立MKD索引，将有助于查询性能的提升，但是将稍微影响加载性能，因此只需要给需要的列上设置SORT_COLUMNS即可，无需给所有列都设置SORT_COLUMNS。
+
+
[SORT_SCOPE](http://carbondata.apache.org/ddl-of-carbondata.html#create-table)参数用户在指定了SORT_COLUMNS后，数据加载时排序的设置，当前支持的设置有：
+
+NO_SORT: 对加载的数据不排序
+
+LOCAL_SORT: 加载的数据在本地排序
+
+GLOBAL_SORT: 加载的数据全局排序，它提升了高并发下点查的效率，对加载的性能的影响较大。
+
+在建表时，对使用SORT_COLUMNS时“NO_SORT”，“LOCAL_SORT”， “GLOBAL_SORT”的性能进行分析。
+
+建表语句：
+
+```基准表```
+
+```sql
+create table if not exists test.detail_benchmark1
+('id', BIGINT, 'imsi' STRING,'msisdn' STRING, `imei` STRING, ...)
+TBLPROPERTIES ( 'LOCAL_DICTIONARY_ENABLE'='false', 'table_blocksize'='256')
+```
+
+```全局排序```
+
+```sql
+create table if not exists test.detail_global_sort
+('id', BIGINT, 'imsi' STRING,'msisdn' STRING, `imei` STRING, ...)
+ TBLPROPERTIES ( 'LOCAL_DICTIONARY_ENABLE'='false', TBLPROPERTIES (
'LOCAL_DICTIONARY_ENABLE'='false', 'table_blocksize'='256',
'SORT_COLUMNS'='msisdn,req_time_sec,req_succed_flag',
'SORT_SCOPE'='GLOBAL_SORT')
+```
+
+```本地排序```
+
+```sql
+create table if not exists test.detail_local_sort
+('id', BIGINT, 'imsi' STRING,'msisdn' STRING, `imei` STRING, ...)
+ TBLPROPERTIES ( 'LOCAL_DICTIONARY_ENABLE'='false', TBLPROPERTIES (
'LOCAL_DICTIONARY_ENABLE'='false', 'table_blocksize'='256',
'SORT_COLUMNS'='msisdn,req_time_sec,req_succed_flag', 'SORT_SCOPE'='LOCAL_SORT')
+```
+
+```不排序```
+
+```sql
+create table if not exists test.detail_no_sort
+('id', BIGINT, 'imsi' STRING,'msisdn' STRING, `imei` STRING, ...)
+ TBLPROPERTIES ( 'LOCAL_DICTIONARY_ENABLE'='false', TBLPROPERTIES (
'LOCAL_DICTIONARY_ENABLE'='false', 'table_blocksize'='256',
'SORT_COLUMNS'='msisdn,req_time_sec,req_succed_flag', 'SORT_SCOPE'='NO_SORT')
+```
+
+验证其加载性能如下：
+
+| 表 | 数据量 | 加载耗时 秒 |
+| ----------------------- | ---------- | ----------- |
+| test.detail_benchmark | 1613149548 | 1109 |
+| test.detail_global_sort | 1613149548 | 6674 |
+| test.detail_local_sort | 1613149548 | 2473 |
+| test.detail_no_sort | 1613149548 | 1576 |
+
+
通过验证的结果可以看出，在SORT_COLUMNS配置后，使用GLOBAL_SORT加载耗时最高，约为local_sort的2.7倍，约为no_sort的4.2倍；使用NO_SORT加载耗时最低，LOCAL_SORT的耗时略高于NO_SORT高约50%左右。实际中采取哪种策略还要考虑对查询的诉求。
+
+下面给出了基于上述几种场景下的点查和模糊查询的性能对比。
+
+查询时使用的ＳＱＬ：
+
+```sql
+select * from test.detail_global_sort where MSISDN="13900000000" limit 2000;
+select * from test.detail_global_sort where MSISDN like "1391%" limit 2000;
+
+select * from test.detail_locall_sort where MSISDN="13900000000" limit 2000;
+select * from test.detail_locall_sort where MSISDN like "1391%" limit 2000;
+
+select * from test.detail_no_sort where MSISDN="13900000000" limit 2000;
+select * from test.detail_no_sort where MSISDN like "1391%" limit 2000;
+```
+
+验证后性能结果如下：
+
+| 查询五次平均值 | detail_benchmark | detail_global_sort | detail_local_sort |
detail_no_sort |
+| -------------- | ---------------- | ------------------ | ----------------- |
-------------- |
+| 点查询 | 18.5 | 1.357 | 2.457 |
5.847 |
+| 模糊查询 | 10.832 | 1.785 | 1.835 |
2.164 |
+
+
通过查询结果可以看出，点查询和模糊查询，global_sort最快，local_sort次之，no_sort最差。点查时no_sort耗时约为global_sort的4.2倍，约为local_sort的2.3倍；global_sort比local_sort快80%左右。模糊查询时global_sort与local_sort差别不大，但是与no_sort有20%以上的提升。
+
+
综合考虑global_sort虽然查询最快，但是加载耗时也最高，相比local_sort在加载耗时与no_sort差别在50%左右，点查询性能提升在2倍以上，本案例最终使用local_sort作为排序方式。
+
+ 在业务具体选择时需根据自身的诉求，结合加载和查询性能诉求综合选择采用哪种排序方式。
+
+### 总结：
+
+ 用户在选择字典和设置SORT_COLUMNS、SORT_SCOPE的时候需要结合自身的加载和查询诉求，综合考虑使用哪种方案。
+
+
本例中，明细数据查询场景对数据加载入库有较强的时效性要求，数据是一批次一批次的到来，一个批次一个批次进行加载，因此加载不可以延迟，否则将导致数据积压无法入库的问题。但是对查询也有一定的性能要求，希望用户的点查要尽可能的快。因此在综合考虑和分析后采用不建立字典，设置SORT_COLUMNS为最长查询的三个字段，SORT_SCOPE设置为LOCAL_SORT，这样的组合性能是能满足本例业务诉求。
+
+```sql
+create table IF NOT EXISTS example_table
+(
+`SID` BIGINT,
+`IMSI` STRING,
+`MSISDN` STRING,
+`IMEI` STRING,
+`MS_IP` STRING,
+`TMSI` STRING,
+`TRANS_TYPE` INT,
+`REQ_TIME_SEC` BIGINT,
+`REQ_SUCCED_FLAG` INT
+.....
+) STORED BY 'org.apache.carbondata.format'
+TBLPROPERTIES (
'LOCAL_DICTIONARY_ENABLE'='false','SORT_COLUMNS'='msisdn,req_time_sec,req_succed_flag',
'SORT_SCOPE'='LOCAL_SORT' )
+```
+
+
+
+
+
+## 加载 Load data
+
+加载样例：
+
+```sql
+LOAD DATA INPATH 'hdfs://hacluster/somepath'
+INTO TABLE example_table
+OPTIONS('DELIMITER'='|', 'QUOTECHAR'='|', 'BAD_RECORDS_ACTION'='FORCE',
+'BAD_RECORDS_LOGGER_ENABLE'='false',
+'FILEHEADER'='SID,IMSI,MSISDN,IMEI,MS_IP,TMSI,TRANS_TYPE,
+REQ_TIME_SEC,REQ_SUCCED_FLAG',
+'MULTILINE'='true', 'ESCAPECHAR'='\')
+```
+
+ 数据入库的时候是采用分批入库，每一个批次对应一个文件夹，加载时没有什么特殊的，主要是一些与数据相关的参数的配置。
+
+这里面有一些参数起使用和含义如下：
+
+DELIMITER：加载命令中可以指定数据的分隔符，本案例中是以“|”为分割，使用中可以根据数据中的具体格式来指定。
+
+QUOTECHAR：加载命令中可以指定数据的引用字符，引用字符内的分割符将被忽略。
+
+BAD_RECORDS_ACTION：对于坏记录，BAD_RECORDS_ACTION 属性主要有四种操作类型：FORCE, REDIRECT,
IGNORE 和 FAIL。这里使用了 FORCE选项。对于该参数的其他几种选项在中文文档中有如下说明：
+
+ a) FAIL 是其默认的值。如果使用 FAIL 选项，则如果发现任何坏记录，数据加载将会失败。
+
+ b) 如果使用了 REDIRECT 选项, CarbonData 会将所有坏记录添加到单独的 CSV 文件中。
但是，在后续的数据加载我们不能使用这个文件，因为其内容可能与原始记录不完全匹配。建议你事先对原始源数据进行清理，以进行下一步的数据处理。此选项主要用于提醒你哪些记录是坏记录.
+
+ c) 如果使用了 FORCE 选项，那么会在加载数据之前将坏记录存储为 NULL，然后再存储
+
+ d) 如果使用了 IGNORE 选项，那么坏记录不会被加载，也不会写到单独的 CSV 文件中。
+
+ e) 在加载的数据中，如果所有记录都是坏记录，则 BAD_RECORDS_ACTION 选项将会无效，加载操作会失败。
+
+BAD_RECORDS_LOGGER_ENABLE: 这里配置false是为了提交加载性能，遇到坏记录的时候不记录。
+
+FILEHEADER：是对应的文件的文件头，也就是列名，实际上在加载csv文件的时候,如果源文件不存在头信息，可以在加载命令中增加该选项，来提供文件头。当加载不带头文件的csv文件，并且文件头和表的模式一致时，可以在加载时选择
'HEADER'='false'，这样就可以不指定FILEHEADER了。
+
+MULTILINE： 设置为true，表示CSV 引号中带有换行符。
+
+ESCAPECHAR：如果用户希望严格验证 CSV 文件中的转义字符，可以提供转义字符。
+
+除此以外还有一些控制参数，详细可以参考：http://carbondata.iteblog.com/data-management-on-carbondata.html
中的描述。
+
+下面给出一些加载队列的主要配置参数以供参考，更详细的信息可以参考CarbonData的官方文档：
+
+http://carbondata.apache.org/configuration-parameters.html
+
+| 参数名 | 设置数值 | 参数描述
|
+| --------------------------------------- | -------- |
------------------------------------------------------------ |
+| enable.unsafe.sort | true | 指定在数据加载期间是否使用unsafe
api，提升内存操作的性能。 |
+| carbon.use.local.dir | true |
在数据加载期间，CarbonData在将文件复制到HDFS之前将文件写入本地临时目录。此配置用于指定CarbonData是否可以本地写入容器的tmp目录或YARN应用程序目录。
|
+| carbon.number.of.cores.while.loading | 15 |
该值默认为2，增加加载时的核数有助于提升数据加载的效率。 |
+| carbon.detail.batch.size | 100 |
存储记录的缓冲区大小，这里是从bolck扫描返回的数据量。该值的设置需要根据查询是需要返回的数据量的大小，当查询时返回数据限制是1000条，参数配置为3000条就有数据浪费了。
|
+| carbon.sort.file.buffer.size | 50 |
排序期间使用的文件读取缓冲区大小（以MB为单位）：MIN=1:MAX=100。 |
+| max.query.execution.time | 60 | 查询执行的最大时间，该值的单位是分钟。
|
+| carbon.unsafe.working.memory.in.mb | 16000 |
该数值是CarbonData支持将数据存储在堆外内存中，以便在数据加载和查询期间执行某些操作。这有助于避免Java
GC，从而提高整体性能。建议的最小值为512MB。低于此值的任何值都将重置为默认值512MB。官网有公式介绍了如何计算对外内存的大小：（carbon.number.of.cores.while.Loading）*（要并行加载的表数）*（off
heap.sort.chunk.size.in
mb+carbon.blockletgroup.size.in.mb+carbon.blockletgroup.size.in.mb/3.5） |
+| carbon.compaction.level.threshold | 6,0 |
配置此参数用于将小文件合并，提升查询性能。6表示第一阶段压缩，每6个文件将触发一次level1的压缩，这里并没有使用level2压缩，为了节省入库时间。配置时由于有大表，有小表，因此对于合并是单表控制的，未设置全局开关。详见社区配置[说明](http://carbondata.apache.org/ddl-of-carbondata.html#create-table)中Table
Compaction Configuration章节。 |
+| carbon.number.of.cores.while.compacting | 15 |
在压缩过程中写数据使用到的核数，这里默认数值是2。 |
+| carbon.sort.storage.inmemory.size.inmb | 1024 |
CarbonData在数据加载期间将每个carbon.sort.size记录数写入中间临时文件，以确保内存占用在限制范围内。启用enable.unsafe.sort配置时，将使用内存中占用的大小（本参数）来确定何时将数据页刷新到中间临时文件，而不是使用基于行数的carbon.sort.size。此配置确定用于在内存中存储数据页的内存。注意：配置一个更高的值可以确保在内存中保留更多的数据，从而由于IO减少或没有IO而提高数据加载性能。根据集群节点中的内存可用性，相应地配置这些值。
|
+
+
在进行数据加载时，根据数据量可以划分多个加载队列，分配不同的资源，加载时根据入库的数据量选择不同的加载队列进行加载，这样可以有效避免大数据量表的加载阻塞加载队列，导致小数据量表入库延迟，这部分数据具体的业务规划和实现，就不在这里过多介绍了。
+
+ 数据加载耗时情况根据选择的配置参数不同而不同，详细数据参见建表章节的性能对比。
+
+## 查询 Select
+查询主要的测试用例在背景处已经介绍。
+
+一些主要的查询配置：
+
+| 参数名 | 参数数值 | 参数描述
|
+| ------------------------------- | -------- |
------------------------------------------------------------ |
+| spark.dynamicAllocation.enabled | false |
是否开启动态资源配置参数，这里选择关闭，executor选择常驻方式启动，在查询时如果开启动态分配可能消耗掉额外的时间。 |
+| spark.sql.shuffle.partitions | 78 |
该数值配置为spark_executor_instances*spark_executor_cores |
+| spark.driver.cores | 3 |
在集群模式下管理资源时，用于driver程序的CPU内核数量，这里设置为3。 |
+| spark.driver.maxResultSize | 4G | 存储分区中结果集大小。
|
+| spark.locality.wait | 500 |
task在执行前都会获取数据的分区信息进行分配，总是会优先将其分配到它要计算的数据所在节点，尽可能的减少网络传输，一般在进行数据本地化分配的时候会选择PROCESS_LOCAL，一旦分配超时失败将降级分配，这里将超时时间改为0.5秒。
|
+| spark.speculation | true |
启动spark推测执行，这里目的是为了解决集群中拖尾任务耗时较长的场景。 |
+| spark.speculation.quantile | 0.75 | 同一个stage里面所有task完成的百分比。
|
+| spark.speculation.multiplier | 5 |
这个参数是一个时间比例，让task完成了spark.speculation.quantile定义的比例的时候，取完成了的task的执行时间的中位数，再乘以这个时间比例，当未完成的时间超过这个乘积时，启动推测执行。
|
+| spark.blacklist.enabled | false | 关闭黑名单，避免可用executor数量不足。
|
+
+查询性能统计
+
+单并发场景：
+
+| 测试用例描述 | 数据量 | 并发数 | 耗时（秒） |
+| :------------------------- | ------ | ------ | ---------- |
+| 点查非SORT_COLUMNS字段 | 27亿 | 1 | 2.790 |
+| 点查SORT_COLUMNS字段 | 27亿 | 1 | 3.047 |
+| 模糊查询非SORT_COLUMNS字段 | 27亿 | 1 | 1.517 |
+| 模糊查询SORT_COLUMNS字段 | 27亿 | 1 | 1.673 |
+| 求记录总数 | 27亿 | 1 | 2.017 |
+| 求最大最小值 | 27亿 | 1 | 2.567 |
+| 求sum | 27亿 | 1 | 3.413 |
+
+多并发场景：
+
+| 测试用例描述 | 数据量 | 并发数 | 耗时（秒） |
+| -------------------------- | ------ | ------ | ---------- |
+| 点查非SORT_COLUMNS字段 | 27亿 | 10 | 5.886 |
+| | 27亿 | 20 | 8.657 |
+| 点查SORT_COLUMNS字段 | 27亿 | 10 | 5.737 |
+| | 27亿 | 20 | 8.564 |
+| 模糊查询非SORT_COLUMNS字段 | 27亿 | 10 | 2.906 |
+| | 27亿 | 20 | 3.957 |
+| 模糊查询SORT_COLUMNS字段 | 27亿 | 10 | 2.794 |
+| | 27亿 | 20 | 3.988 |
+| 求记录总数 | 27亿 | 10 | 12.556 |
+| | 27亿 | 20 | 22.660 |
+| 求最大最小值 | 27亿 | 10 | 18.201 |
+| | 27亿 | 20 | 33.917 |
+| 求sum | 27亿 | 10 | 19.811 |
+| | 27亿 | 20 | 36.595 |
+
+
通过测试结果数据可以看出，在27亿左右数据量场景下，单并发点查、模糊查询、记录数、最大、最小值、求和的耗时在4秒以内，模糊查询耗时短于精确查询；在多并发场景下，耗时较单并发有增加，在10并发时点查和模糊查询耗时增加一倍，求记录数，最大，最小值，求和的耗时增加比较明显，达到5-8倍。在20并发情况下，点查、模糊查询、求记录数、最大、最小、求和的耗时又在10并发的基础上增加接近1倍。但是即使在20并发情况下点查和模糊查询的耗时依然在10秒以内，还可用通过增加查询资源来提高并发查询的效率。
+
+
本案例给出了一个使用CarbonData进行明细数据查询的场景的建表、加载、查询的整个流程，也对建表时字典和SORT_COLUMNS的配置及SORT_SCOPE的配置方式给出了介绍和对比。通过本文可以指导用户使用CarbonData进行明细数据的查询场景的方案设置和参数选择。从最终的结果看，CarbonData在明细数据查询的场景下也具有不错的性能表现。
+
diff --git a/docs/zh_cn/images/SortColumns.png
b/docs/zh_cn/images/SortColumns.png
new file mode 100644
index 0000000..5a221ee
Binary files /dev/null and b/docs/zh_cn/images/SortColumns.png differ
