drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vdiravka <...@git.apache.org>
Subject [GitHub] drill pull request #846: DRILL-5544: Out of heap running CTAS against text d...
Date Wed, 07 Jun 2017 17:41:42 GMT
Github user vdiravka commented on a diff in the pull request:

    https://github.com/apache/drill/pull/846#discussion_r120694784
  
    --- Diff: exec/java-exec/src/main/java/org/apache/parquet/hadoop/ParquetColumnChunkPageWriteStore.java
---
    @@ -0,0 +1,269 @@
    +/*
    + * 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.
    + */
    +package org.apache.parquet.hadoop;
    +
    +import static org.apache.parquet.column.statistics.Statistics.getStatsBasedOnType;
    +
    +import java.io.Closeable;
    +import java.io.IOException;
    +import java.util.List;
    +import java.util.Map;
    +import java.util.Set;
    +
    +import com.google.common.collect.Lists;
    +import com.google.common.collect.Maps;
    +import com.google.common.collect.Sets;
    +import org.apache.drill.exec.store.parquet.ParquetDirectByteBufferAllocator;
    +import org.apache.parquet.bytes.BytesInput;
    +import org.apache.parquet.bytes.CapacityByteArrayOutputStream;
    +import org.apache.parquet.column.ColumnDescriptor;
    +import org.apache.parquet.column.Encoding;
    +import org.apache.parquet.column.page.DictionaryPage;
    +import org.apache.parquet.column.page.PageWriteStore;
    +import org.apache.parquet.column.page.PageWriter;
    +import org.apache.parquet.column.statistics.Statistics;
    +import org.apache.parquet.format.converter.ParquetMetadataConverter;
    +import org.apache.parquet.hadoop.CodecFactory.BytesCompressor;
    +import org.apache.parquet.io.ParquetEncodingException;
    +import org.apache.parquet.schema.MessageType;
    +import org.apache.parquet.bytes.ByteBufferAllocator;
    +import org.slf4j.Logger;
    +import org.slf4j.LoggerFactory;
    +
    +/**
    + * This is a copy of ColumnChunkPageWriteStore from parquet library except of OutputStream
that is used here.
    + * Using of CapacityByteArrayOutputStream allows to use different ByteBuffer allocators.
    --- End diff --
    
    I meant a special case regarding 20Gb. Usually 40 threads can be used in sufficiently
powerful machines with enough RAM space. But we can control the memory usage by reducing number
of threads per node to prevent OOM while buffering data.
    
    512Mb is the default `store.parquet.block-size`, but according [Drill doc](https://drill.apache.org/docs/parquet-format/#configuring-the-size-of-parquet-files)
it is recommended to set this value to the number of bytes less than or equal to the block
size of MFS, HDFS, or the file system. Then only 320K will be buffered in memory. 
    
    Nothing wrong with `BufferedOutputStream`. Original `ColumnChunkPageWriter` uses it, but
together with `ConcatenatingByteArrayCollector` (which can buffer data only in `List<byte[]>`).
I suppose it is possible to upgrade the last class to use `ByteBuffers`, but the result will
be similar to `CapacityByteArrayOutputStream`.
    
    As I understand, data buffering allows to write into the disk entire block without going
back and writing anything else, ideally one row group per one fs block. Looks like it is suitable
for HDFS as well.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message