New Impala contributors: IMPALA-5440

[Jim Apple]

If you'd like to contribute a patch to Impala, but aren't sure what you
want to work on, you can look at Impala's newbie issues:
https://issues.apache.org/jira/issues/?filter=12341668. You can find
detailed instructions on submitting patches at
https://cwiki.apache.org/confluence/display/IMPALA/Contributing+to+Impala.
This is a walkthrough of a ticket a new contributor could take on, with
hopefully enough detail to get you going but not so much to take away the
fun.

How can we fix https://issues.apache.org/jira/browse/IMPALA-5440, "Add
planner tests with extreme statistics values"? The comments on the ticket
address a number of ways, some of them rather ambitious for a new
contributor, so let's talk about a smaller chunk of it.

This ticket was filed in response to
https://issues.apache.org/jira/browse/IMPALA-5282, which included an
exception in the frontend (which does parsing, analyzing, and planning for
queries) from an overflow. Take a look at the patch which fixed the issue,
https://gerrit.cloudera.org/#/c/7084. It doesn't include any new tests,
which is why IMPALA-5440 was filed. You can see this in the comments on the
patch: "For now, I feel pretty good about the computePerHostResources()
with respect to overflow since I read all the code carefully. We should
still have tests to not break it sometime later. I filed IMPALA-5440 to
address the long-standing bug in test coverage."

Reading the comments on a patch are a good way to understand why something
in Impala is the way it is. All recent Impala patches have a line in the
bottom of the commit message with a URL of the code review so you can do
archaeology for information that wasn't included in the patch itself. All
code review comments are also sent to
https://lists.apache.org/list.html?revi...@impala.apache.org, which you can
subscribe to in the same way you subscribed to this list, by mailing
reviews-subscr...@impala.incubator.apache.org.

In this case, the question to address is arithmetic overflow in the
frontend. The previous patch shows many places where overflow is checked,
and you may be able to add new tests for each line in that patch. For now,
let's just work on two categories of overflow: cardinality estimation and
memory estimates.

Impala's planner, in order to execute a query efficiently, makes estimates
about the number of rows that will be produced by different parts of the
query. If cardinality estimations have arithmetic overflow, they will
estimate a negative number of rows!

To see if you can get arithmetic overflow, start up impala-shell.sh and set
explain_level=2. This will show the planner's estimates on the number of
rows each part of a query produces. Then explain the plans for some cross
joins:

use tpch;
explain select * from lineitem a;
explain select * from lineitem a, lineitem b;
explain select * from lineitem a, lineitem b, lineitem c;
...

At some point in that sequence, you will see that the cardinality estimate
reaches a ceiling, even though those queries would actually produce more
and more rows with each cross-join. This is because the overflow check is
working and capping the cardinality estimate at the largest long value,
2^63 - 1.

To see how to test this, take a look at
fe/src/test/java/org/apache/impala/planner/PlannerTest.java. Each of the
tests in that file references a file in
testdata/workloads/functional-planner/queries/PlannerTest/. To look for a
test that can check that cardinality is bounded, look for the string
"cardinality" in the PlannerTest directory. Check out the test method in
PlannerTest.java that corresponds, and write a similar test file and test
method.

Have fun, and don't hesitate to ask on d...@impala.apache.org if you get
stuck and need help!

Re: jenkins.impala.io pre-existing workspace

[Matthew Jacobs]

https://issues.apache.org/jira/browse/IMPALA-5959

On Tue, Sep 19, 2017 at 2:54 PM, Jim Apple  wrote:
> Nobody did.
>
> On Tue, Sep 19, 2017 at 2:29 PM, Matthew Jacobs  wrote:
>
>> Did anyone file a JIRA for this? I saw this again.
>>
>> On Thu, Aug 31, 2017 at 1:36 PM, Jim Apple  wrote:
>> > Also, to be clear, I don't have the cycles to lead the fix-the-cleanup
>> > task at the moment.
>> >
>> > On Wed, Aug 30, 2017 at 4:45 PM, Jim Apple  wrote:
>> >> The workspace cleanup isn't working - see the last bit of any recent
>> >> ub1604 job: https://jenkins.impala.io/view/Utility/job/ubuntu-16.04-
>> from-scratch/206/console
>> >>
>> >> 03:56:40.920 [WS-CLEANUP] Deleting project workspace...Cannot delete
>> >> workspace :remote file operation failed: /home/ubuntu at
>> >> hudson.remoting.Channel@4384d5b9:ubuntu-16.04 (i-032d527b9c801df4c):
>> >> java.io.IOException: Unable to delete '/home/ubuntu'. Tried 3 times
>> >> (of a maximum of 3) waiting 0.1 sec between attempts.
>> >> 03:56:48.161 ERROR: Step ‘Delete workspace when build is done’ failed:
>> >> Cannot delete workspace: remote file operation failed: /home/ubuntu at
>> >> hudson.remoting.Channel@4384d5b9:ubuntu-16.04 (i-032d527b9c801df4c):
>> >> java.io.IOException: Unable to delete '/home/ubuntu'. Tried 3 times
>> >> (of a maximum of 3) waiting 0.1 sec between attempts.
>> >>
>> >> The workspace is $HOME, so you can't just delete it without being root.
>> >>
>> >> This could be changed to
>> >>
>> >> 1. A post-build script to "rm -rf ~/*". This doesn't reset everything,
>> >> though - the job makes changes to other parts of the filesystem.
>> >>
>> >> 2. A post-build script to "sudo shutdown -h now" to make sure ec2
>> >> instances are not re-used. I'm not sure how Jenkins would feel about
>> >> this. :-)
>> >>
>> >> 3. A post-build script to move $HOME to some archived location on the
>> >> disk, to preserve debuggability.
>> >>
>> >> 4. A bash trap in the script to do one of the above.
>> >>
>> >> 5. Run the whole thing in a docker in the build machine, then delete
>> >> the container when the script is done. Or don't, if there's enough
>> >> disk space to not worry about that.
>> >>
>> >> 6. Do all of the work in a workspace inside $HOME. This would require
>> >> some changes to bootstrap_development.sh.
>> >>
>> >> #5 is the most hermetic, I'd guess.
>> >>
>> >> On Thu, Aug 24, 2017 at 8:29 AM, Michael Brown 
>> wrote:
>> >>> Looks like someone has done this.
>> >>>
>> >>> On Wed, Aug 23, 2017 at 8:16 PM, Alexander Behm <
>> alex.b...@cloudera.com>
>> >>> wrote:
>> >>>
>>  Yes, let's please add the post-build action for sanity and
>> consistency with
>>  our other jobs.
>> 
>>  On Wed, Aug 23, 2017 at 7:42 PM, Tim Armstrong <
>> tarmstr...@cloudera.com>
>>  wrote:
>> 
>>  > Maybe the workspace just got left in a weird state - I think in most
>>  cases
>>  > "git init" followed by checking out a branch and doing a clean would
>>  work.
>>  >
>>  > Should we add the delete workspace post-build action?
>>  >
>>  > On Wed, Aug 23, 2017 at 5:32 PM, Michael Brown 
>>  wrote:
>>  >
>>  > > Not a known issue. I noticed ubuntu-16.04-from-scratch is not set
>> to
>>  > clean
>>  > > up its workspace, and its config has not been touched since Aug
>> 11. It
>>  > > seems strange we only saw this now
>>  > >
>>  > > On Wed, Aug 23, 2017 at 5:25 PM, Tim Armstrong <
>>  tarmstr...@cloudera.com>
>>  > > wrote:
>>  > >
>>  > > > Is this a known problem? My job failed because the Impala repo
>>  already
>>  > > > existed on the machine:
>>  > > >
>>  > > > https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/164/
>>  > > >
>>  > > > *23:00:24* + /usr/bin/git init /home/ubuntu/Impala*23:00:24*
>>  > > > Reinitialized existing Git repository in
>> /home/ubuntu/Impala/.git/
>>  > > > 
>>  > > > *23:02:18* + for ITER in '$(seq 1 10)'*23:02:18* + echo
>> 'ATTEMPT:
>>  > > > 1'*23:02:18* ATTEMPT: 1*23:02:18* + /usr/bin/git checkout
>>  > > > FETCH_HEAD*23:02:18* + cat
>>  > > > /home/ubuntu/Impala/tmp.3tYBn0GUga*23:02:18* 23:02:18.712300
>>  git.c:344
>>  > > >   trace: built-in: git 'checkout'
>> 'FETCH_HEAD'*23:02:18*
>>  > > > error: The following untracked working tree files would be
>>  overwritten
>>  > > > by checkout:*23:02:18*  .clang-format*23:02:18*
>>  > > >  .clang-tidy*23:02:18*
>>  > > > .gitignore*23:02:18*CMakeLists.txt*23:02:18*
>>  > > > DISCLAIMER*23:02:18*
>>  > > > EXPORT_CONTROL.md*23:02:18* LICENSE.txt*23:02:18*
>>  > > >  LOGS.md*23:02:18*
>>  > > > NOTICE.txt*23:02:18*README.md*23:02:18*
>>  > > >  be/.gitignore*23:02:18*
>>  > > > be/.impala.doxy*23:02:18*

Re: jenkins.impala.io pre-existing workspace

[Jim Apple]

Nobody did.

On Tue, Sep 19, 2017 at 2:29 PM, Matthew Jacobs  wrote:

> Did anyone file a JIRA for this? I saw this again.
>
> On Thu, Aug 31, 2017 at 1:36 PM, Jim Apple  wrote:
> > Also, to be clear, I don't have the cycles to lead the fix-the-cleanup
> > task at the moment.
> >
> > On Wed, Aug 30, 2017 at 4:45 PM, Jim Apple  wrote:
> >> The workspace cleanup isn't working - see the last bit of any recent
> >> ub1604 job: https://jenkins.impala.io/view/Utility/job/ubuntu-16.04-
> from-scratch/206/console
> >>
> >> 03:56:40.920 [WS-CLEANUP] Deleting project workspace...Cannot delete
> >> workspace :remote file operation failed: /home/ubuntu at
> >> hudson.remoting.Channel@4384d5b9:ubuntu-16.04 (i-032d527b9c801df4c):
> >> java.io.IOException: Unable to delete '/home/ubuntu'. Tried 3 times
> >> (of a maximum of 3) waiting 0.1 sec between attempts.
> >> 03:56:48.161 ERROR: Step ‘Delete workspace when build is done’ failed:
> >> Cannot delete workspace: remote file operation failed: /home/ubuntu at
> >> hudson.remoting.Channel@4384d5b9:ubuntu-16.04 (i-032d527b9c801df4c):
> >> java.io.IOException: Unable to delete '/home/ubuntu'. Tried 3 times
> >> (of a maximum of 3) waiting 0.1 sec between attempts.
> >>
> >> The workspace is $HOME, so you can't just delete it without being root.
> >>
> >> This could be changed to
> >>
> >> 1. A post-build script to "rm -rf ~/*". This doesn't reset everything,
> >> though - the job makes changes to other parts of the filesystem.
> >>
> >> 2. A post-build script to "sudo shutdown -h now" to make sure ec2
> >> instances are not re-used. I'm not sure how Jenkins would feel about
> >> this. :-)
> >>
> >> 3. A post-build script to move $HOME to some archived location on the
> >> disk, to preserve debuggability.
> >>
> >> 4. A bash trap in the script to do one of the above.
> >>
> >> 5. Run the whole thing in a docker in the build machine, then delete
> >> the container when the script is done. Or don't, if there's enough
> >> disk space to not worry about that.
> >>
> >> 6. Do all of the work in a workspace inside $HOME. This would require
> >> some changes to bootstrap_development.sh.
> >>
> >> #5 is the most hermetic, I'd guess.
> >>
> >> On Thu, Aug 24, 2017 at 8:29 AM, Michael Brown 
> wrote:
> >>> Looks like someone has done this.
> >>>
> >>> On Wed, Aug 23, 2017 at 8:16 PM, Alexander Behm <
> alex.b...@cloudera.com>
> >>> wrote:
> >>>
>  Yes, let's please add the post-build action for sanity and
> consistency with
>  our other jobs.
> 
>  On Wed, Aug 23, 2017 at 7:42 PM, Tim Armstrong <
> tarmstr...@cloudera.com>
>  wrote:
> 
>  > Maybe the workspace just got left in a weird state - I think in most
>  cases
>  > "git init" followed by checking out a branch and doing a clean would
>  work.
>  >
>  > Should we add the delete workspace post-build action?
>  >
>  > On Wed, Aug 23, 2017 at 5:32 PM, Michael Brown 
>  wrote:
>  >
>  > > Not a known issue. I noticed ubuntu-16.04-from-scratch is not set
> to
>  > clean
>  > > up its workspace, and its config has not been touched since Aug
> 11. It
>  > > seems strange we only saw this now
>  > >
>  > > On Wed, Aug 23, 2017 at 5:25 PM, Tim Armstrong <
>  tarmstr...@cloudera.com>
>  > > wrote:
>  > >
>  > > > Is this a known problem? My job failed because the Impala repo
>  already
>  > > > existed on the machine:
>  > > >
>  > > > https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/164/
>  > > >
>  > > > *23:00:24* + /usr/bin/git init /home/ubuntu/Impala*23:00:24*
>  > > > Reinitialized existing Git repository in
> /home/ubuntu/Impala/.git/
>  > > > 
>  > > > *23:02:18* + for ITER in '$(seq 1 10)'*23:02:18* + echo
> 'ATTEMPT:
>  > > > 1'*23:02:18* ATTEMPT: 1*23:02:18* + /usr/bin/git checkout
>  > > > FETCH_HEAD*23:02:18* + cat
>  > > > /home/ubuntu/Impala/tmp.3tYBn0GUga*23:02:18* 23:02:18.712300
>  git.c:344
>  > > >   trace: built-in: git 'checkout'
> 'FETCH_HEAD'*23:02:18*
>  > > > error: The following untracked working tree files would be
>  overwritten
>  > > > by checkout:*23:02:18*  .clang-format*23:02:18*
>  > > >  .clang-tidy*23:02:18*
>  > > > .gitignore*23:02:18*CMakeLists.txt*23:02:18*
>  > > > DISCLAIMER*23:02:18*
>  > > > EXPORT_CONTROL.md*23:02:18* LICENSE.txt*23:02:18*
>  > > >  LOGS.md*23:02:18*
>  > > > NOTICE.txt*23:02:18*README.md*23:02:18*
>  > > >  be/.gitignore*23:02:18*
>  > > > be/.impala.doxy*23:02:18*
>  be/CMakeLists.txt*23:02:18*
>  > > > be/src/benchmarks/CMakeLists.txt*23:02:18*
>  > > > be/src/benchmarks/atod-benchmark.cc*23:02:18*
>  > > > be/src/benchmarks/atof-benchmark.cc*23:02:18*
>  > > >   

Re: jenkins.impala.io pre-existing workspace

[Matthew Jacobs]

Did anyone file a JIRA for this? I saw this again.

On Thu, Aug 31, 2017 at 1:36 PM, Jim Apple  wrote:
> Also, to be clear, I don't have the cycles to lead the fix-the-cleanup
> task at the moment.
>
> On Wed, Aug 30, 2017 at 4:45 PM, Jim Apple  wrote:
>> The workspace cleanup isn't working - see the last bit of any recent
>> ub1604 job: 
>> https://jenkins.impala.io/view/Utility/job/ubuntu-16.04-from-scratch/206/console
>>
>> 03:56:40.920 [WS-CLEANUP] Deleting project workspace...Cannot delete
>> workspace :remote file operation failed: /home/ubuntu at
>> hudson.remoting.Channel@4384d5b9:ubuntu-16.04 (i-032d527b9c801df4c):
>> java.io.IOException: Unable to delete '/home/ubuntu'. Tried 3 times
>> (of a maximum of 3) waiting 0.1 sec between attempts.
>> 03:56:48.161 ERROR: Step ‘Delete workspace when build is done’ failed:
>> Cannot delete workspace: remote file operation failed: /home/ubuntu at
>> hudson.remoting.Channel@4384d5b9:ubuntu-16.04 (i-032d527b9c801df4c):
>> java.io.IOException: Unable to delete '/home/ubuntu'. Tried 3 times
>> (of a maximum of 3) waiting 0.1 sec between attempts.
>>
>> The workspace is $HOME, so you can't just delete it without being root.
>>
>> This could be changed to
>>
>> 1. A post-build script to "rm -rf ~/*". This doesn't reset everything,
>> though - the job makes changes to other parts of the filesystem.
>>
>> 2. A post-build script to "sudo shutdown -h now" to make sure ec2
>> instances are not re-used. I'm not sure how Jenkins would feel about
>> this. :-)
>>
>> 3. A post-build script to move $HOME to some archived location on the
>> disk, to preserve debuggability.
>>
>> 4. A bash trap in the script to do one of the above.
>>
>> 5. Run the whole thing in a docker in the build machine, then delete
>> the container when the script is done. Or don't, if there's enough
>> disk space to not worry about that.
>>
>> 6. Do all of the work in a workspace inside $HOME. This would require
>> some changes to bootstrap_development.sh.
>>
>> #5 is the most hermetic, I'd guess.
>>
>> On Thu, Aug 24, 2017 at 8:29 AM, Michael Brown  wrote:
>>> Looks like someone has done this.
>>>
>>> On Wed, Aug 23, 2017 at 8:16 PM, Alexander Behm 
>>> wrote:
>>>
 Yes, let's please add the post-build action for sanity and consistency with
 our other jobs.

 On Wed, Aug 23, 2017 at 7:42 PM, Tim Armstrong 
 wrote:

 > Maybe the workspace just got left in a weird state - I think in most
 cases
 > "git init" followed by checking out a branch and doing a clean would
 work.
 >
 > Should we add the delete workspace post-build action?
 >
 > On Wed, Aug 23, 2017 at 5:32 PM, Michael Brown 
 wrote:
 >
 > > Not a known issue. I noticed ubuntu-16.04-from-scratch is not set to
 > clean
 > > up its workspace, and its config has not been touched since Aug 11. It
 > > seems strange we only saw this now
 > >
 > > On Wed, Aug 23, 2017 at 5:25 PM, Tim Armstrong <
 tarmstr...@cloudera.com>
 > > wrote:
 > >
 > > > Is this a known problem? My job failed because the Impala repo
 already
 > > > existed on the machine:
 > > >
 > > > https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/164/
 > > >
 > > > *23:00:24* + /usr/bin/git init /home/ubuntu/Impala*23:00:24*
 > > > Reinitialized existing Git repository in /home/ubuntu/Impala/.git/
 > > > 
 > > > *23:02:18* + for ITER in '$(seq 1 10)'*23:02:18* + echo 'ATTEMPT:
 > > > 1'*23:02:18* ATTEMPT: 1*23:02:18* + /usr/bin/git checkout
 > > > FETCH_HEAD*23:02:18* + cat
 > > > /home/ubuntu/Impala/tmp.3tYBn0GUga*23:02:18* 23:02:18.712300
 git.c:344
 > > >   trace: built-in: git 'checkout' 'FETCH_HEAD'*23:02:18*
 > > > error: The following untracked working tree files would be
 overwritten
 > > > by checkout:*23:02:18*  .clang-format*23:02:18*
 > > >  .clang-tidy*23:02:18*
 > > > .gitignore*23:02:18*CMakeLists.txt*23:02:18*
 > > > DISCLAIMER*23:02:18*
 > > > EXPORT_CONTROL.md*23:02:18* LICENSE.txt*23:02:18*
 > > >  LOGS.md*23:02:18*
 > > > NOTICE.txt*23:02:18*README.md*23:02:18*
 > > >  be/.gitignore*23:02:18*
 > > > be/.impala.doxy*23:02:18*   be/CMakeLists.txt*23:02:18*
 > > > be/src/benchmarks/CMakeLists.txt*23:02:18*
 > > > be/src/benchmarks/atod-benchmark.cc*23:02:18*
 > > > be/src/benchmarks/atof-benchmark.cc*23:02:18*
 > > > be/src/benchmarks/atoi-benchmark.cc*23:02:18*
 > > > be/src/benchmarks/bit-packing-benchmark.cc*23:02:18*
 > > > be/src/benchmarks/bitmap-benchmark.cc
 > > > ...
 > > >
 > >
 >

Likable C++ debuggers

[Philip Zeyliger]

Hi folks!

Thanks for your responses to my previous survey about editors and vim
tools! I added some of the responses to
https://cwiki.apache.org/confluence/display/IMPALA/Useful+Tips+for+New+Impala+Developers
.

My next survey is about C++ debuggers. I know many of you use raw gdb. I'm
curious what other tools/debuggers folks use!

-- Philip

Re: FW: Письмо о проблемах Impala and IGFS.

[Bharath Vissapragada]

In Impala's context, disk-ID corresponds to the ID of a local disk (on a
data node) hosting a particular block replica of a given file. I'm not
familiar with the internals of IGFS but from a quick read [1], it looks
like an in-memory FS. So, I don't think the idea of "disk ID" makes sense.

To fix this, I think we need to make some Impala side changes to ignore
loading disk IDs in such cases (patches are welcome :)).

FWIW, we did somewhat similar things while integrating S3/ADLS filesystems
where there is no concept of block replicas and we just systhesized dummy
metadata based on file range splits [2].

[1] https://ignite.apache.org/features/igfs.html
[2]
https://github.com/cloudera/Impala/blob/cdh5-trunk/fe/src/main/java/org/apache/impala/catalog/HdfsTable.java#L292

On Tue, Sep 19, 2017 at 4:28 AM, Andrey Kuznetsov  wrote:

> Hi folk,
> We have a problem with integration Impala and IGFS.  Select from tables on
> IGFS causes a warning:
>
> WARNINGS: Unknown disk id.  This will negatively affect performance.
> Check your hdfs settings to enable block location metadata. (1 of 2
> similar).
>
> Is this problem of IGFS? Can we enable  on IGFS?
>
> Best regards,
> ANDREY KUZNETSOV
> Software Engineering Team Leader
>
> Office: +7 482 263 00 70 x 42766
>  Cell: +7 920 154 05 72   Email:
> andrey_kuznet...@epam.com
> Tver, Russia   epam.com
>
> CONFIDENTIALITY CAUTION AND DISCLAIMER
> This message is intended only for the use of the individual(s) or
> entity(ies) to which it is addressed and contains information that is
> legally privileged and confidential. If you are not the intended recipient,
> or the person responsible for delivering the message to the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. All unintended
> recipients are obliged to delete this message and destroy any printed
> copies.
>

FW: Письмо о проблемах Impala and IGFS.

[Andrey Kuznetsov]

Hi folk,
We have a problem with integration Impala and IGFS.  Select from tables on IGFS 
causes a warning:

WARNINGS: Unknown disk id.  This will negatively affect performance.
Check your hdfs settings to enable block location metadata. (1 of 2 similar).

Is this problem of IGFS? Can we enable  on IGFS?

Best regards,
ANDREY KUZNETSOV
Software Engineering Team Leader

Office: +7 482 263 00 70 x 42766   
Cell: +7 920 154 05 72   Email: 
andrey_kuznet...@epam.com
Tver, Russia   epam.com

CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies) 
to which it is addressed and contains information that is legally privileged 
and confidential. If you are not the intended recipient, or the person 
responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. All unintended recipients are obliged to 
delete this message and destroy any printed copies.

Re: Re: Impala Driver Source Code

[Jeszy]

Can you clarify what driver are you referring to?
Kudu doesn't have JDBC/ODBC drivers at all:
"Is there a JDBC driver available?
Kudu is not a SQL engine. The availability of JDBC and ODBC drivers
will be dictated by the SQL engine used in combination with Kudu."

https://kudu.apache.org/faq.html

FWIW, you can use Hive's open source driver to connect to impala, but
since it's not as widely used as Cloudera's drivers you may run into a
few issues.

On 19 September 2017 at 10:55, sky  wrote:
> Thank you Jeszy.
>  But doesn't impala provide an open-source driver like kudu? Or, where 
> have open source available drivers?
>
>
>
>
>
>
>
> At 2017-09-18 17:57:21, "Jeszy"  wrote:
>>If you are referring to Cloudera's JDBC and ODBC connectors,
>>unfortunately those are proprietary.
>>
>>On 18 September 2017 at 11:55, sky  wrote:
>>> Hi all,
>>> Could you give me a impala driver source code connection?

Re:Re: Impala Driver Source Code

[sky]

Thank you Jeszy.
 But doesn't impala provide an open-source driver like kudu? Or, where have 
open source available drivers?







At 2017-09-18 17:57:21, "Jeszy"  wrote:
>If you are referring to Cloudera's JDBC and ODBC connectors,
>unfortunately those are proprietary.
>
>On 18 September 2017 at 11:55, sky  wrote:
>> Hi all,
>> Could you give me a impala driver source code connection?