So one more follow-up: The 16-.25-Success turns to a fail if I throw more data (and hence more partitions) at the problem. Could there be some sort of issue that rears it's head based on the number of output dynamic partitions?
Thanks all! On Sun, Apr 27, 2014 at 3:33 PM, John Omernik <j...@omernik.com> wrote: > Here is some testing, I focused on two variables (Not really understanding > what they do) > orc.compress.size (256k by default) > hive.exec.orc.memory.pool (0.50 by default). > > The job I am running is a admittedly complex job running through a Python > Transform script. However, as noted above, RCFile writes have NO issues. > Another point... the results of this job end up being is LOTs of Dynamic > partitions. I am not sure if that plays a role here, or could help in > troubleshooting. > > So for these two I ran a bunch of tests, the results are in the format > (compress.size in k-memory.pool-Success/fail) > 256-0.50-Fail > 128-0.50-Fail > 64-0.50-Fail > 32-0.50-Fail > 16-0.50-Fail > 16-0.25-Success > 32-0.25-Fail > 16-0.35-Success > 16-0.45-Success > > > So after doing this I have questions: > 1. On the memory.pool what is happening when I change this? Is this > affecting the written files on subsequent reads? > 2. Does the hive memory pool change the speed of things? (I'll take slower > speed if it "works") > 3. On the compress.size, do I hurt subsequent reads with the smaller > compress size? > 4. These two variables, changed by themselves do not fix the problem, but > together they seem to... lucky? Or are they related? > 5. Is there a better approach I can take on this? > 6. Any other variables I could look at? > > > > > > > > > > On Sun, Apr 27, 2014 at 11:56 AM, John Omernik <j...@omernik.com> wrote: > >> Hello all, >> >> I am working with Hive 0.12 right now on YARN. When I am writing a table >> that is admittedly quite "wide" (there are lots of columns, near 60, >> including one binary field that can get quite large). Some tasks will >> fail on ORC file write with Java Heap Space Issues. >> >> I have confirmed that using RCFiles on the same data produces no >> failures. >> >> This led me down the path of experimenting with the table properties. >> Obviously, living on the cutting edge here makes it so there is not tons of >> documentation on what these settings do, I have lots of slide shows showing >> me the settings that be used to tune ORC, but not what they do, or what the >> ramifications may be. >> >> For example, I've gone ahead and reduced the orc.compress.size to 64k >> This seems to address lots of the failures, (all other things being >> unchanged). But what does that mean for me in the long run? Larger files? >> More files? How is this negatively affecting me from a file perspective? >> >> In addition, would this be a good time to try SNAPPY over ZLIB as my >> default compression? I tried to find some direct memory comparisons but >> didn't see anything. >> >> So, give my data and the issues on write for my wide table, how would you >> recommend I address this? Is the compress.size the way to go? What are the >> long term affects of this? Any thoughts would be welcome. >> >> Thanks! >> >> John >> > >
