Re: carbondata1.5 compatible with spark2.3.1

2018-10-12 Thread xm_zzc
Hi Sujith: Currently it can't compile with Spark 2.3.1 after merging PR#2779, because Spark 2.3.2 has some interface changes, please see https://github.com/apache/carbondata/pull/2779 -- Sent from:

Re: carbondata1.5 compatible with spark2.3.1

2018-10-12 Thread sujith chacko
Hi , Carbon is compatible with both versions spark 2.3.1 and spark 2.3.2 . but it will be always better to use more stable versions for online deployment. Spark 2.3.2 has many blockers and data inconsistency issues fixed including few security bugs. Thanks, Sujith On Sun, 30 Sep 2018 at 1:46

Re: [Issue] Long string columns config for big strings not work

2018-10-12 Thread xuchuanyin
Hi, aaron: A PR has been raised for this issue https://github.com/apache/carbondata/pull/2812, please check. -- Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/

Re: carbondata1.5 compatible with spark2.3.1

2018-10-12 Thread xm_zzc
Hi: CarbonData community decide to support spark 2.3.2 only, because spark 2.3.1 has some critical issues. If you need to integrate spark 2.3.1 , please contact me on mailling list and I will told you how to do. -- Sent from:

Re: Reduce the size of assembly jar

2018-10-12 Thread xm_zzc
Hi: This is not an issue. I found that assembly jar includes aws-sdk-java-bundle module (1.11.X) which is about 60MB, if you don't need this module, add 'com.amazonaws:*' in maven-shade-plugin of assembly pom.xml. -- Sent from:

Re: [Issue] Long string columns config for big strings not work

2018-10-12 Thread xuchuanyin
Hi, arron, I go through the code and find the root cause. While writing dataframe to carbontable, we have to keep the order of the fields in dataframe the same as that in carbontable. The code lies in `NewCarbonDataLoadRDD.scala#486`. This is because we judge whether the field is a

RE: Proposal to integrate QATCodec into Carbondata

2018-10-12 Thread Xu, Cheng A
Thanks Chuanyin. This PR looks cool. Allowing customized codec is a good option. Comparing with the existing built-in Snappy codec in CarbonData, I think QATCodec with better performance and better compression ratio is also a good candidate for built-in support. Any thoughts? Thanks Ferdinand