carbondata-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jack...@apache.org
Subject [carbondata] branch master updated: [DOC] Add an introduction documention for detailed data query
Date Tue, 07 Jan 2020 15:27:29 GMT
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_xidian@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:
+
+```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


Mime
View raw message