Если вы используете Spark с HDFS, я решаю проблему, обычно записывая файлы csv и используя HDFS для слияния. Я непосредственно делаю это в Spark (1.6):
import org.apache.hadoop.conf.Configuration
import org.apache.hadoop.fs._
def merge(srcPath: String, dstPath: String): Unit = {
val hadoopConfig = new Configuration()
val hdfs = FileSystem.get(hadoopConfig)
FileUtil.copyMerge(hdfs, new Path(srcPath), hdfs, new Path(dstPath), true, hadoopConfig, null)
// the "true" setting deletes the source files once they are merged into the new output
}
val newData = << create your dataframe >>
val outputfile = "/user/feeds/project/outputs/subject"
var filename = "myinsights"
var outputFileName = outputfile + "/temp_" + filename
var mergedFileName = outputfile + "/merged_" + filename
var mergeFindGlob = outputFileName
newData.write
.format("com.databricks.spark.csv")
.option("header", "false")
.mode("overwrite")
.save(outputFileName)
merge(mergeFindGlob, mergedFileName )
newData.unpersist()
Не могу вспомнить, где я узнал этот трюк, но он может сработать для вас.
long int
должно быть AT LEAST 32-бит, но стандарт C99 НЕ ограничивает его 32-разрядным. Стандарт C99 предоставляет удобные типы, такие как int16_t
и amp; int32_t
и т. д., которые соответствуют размерам бит для целевой платформы.
ftell()
и fseek()
ограничены 32 битами (включая знаковый бит) на подавляющем большинстве 32-битных систем архитектуры. Поэтому, когда есть большая поддержка файлов, вы сталкиваетесь с этой проблемой 2 ГБ.
Функции POSIX.1-2001 и SysV для fseek
и ftell
- fseeko
и ftello
, потому что они используют off_t как параметр для смещения.
вам нужно определить компиляцию с помощью -D_FILE_OFFSET_BITS=64
или определить его где-нибудь, прежде чем включать stdio.h, чтобы убедиться, что off_t
- 64-разрядный.
Прочитайте об этом в cert.org безопасном руководстве по кодированию .
C99 говорит, что long int
должен быть не менее 32-бит, он НЕ говорит, что он не может быть больше
попробуйте следующее в архитектуре x86_64:
#include <stdio.h>
int main(int argc, char *argv[]) {
FILE *fp;
fp = fopen( "test.out", "w");
if ( !fp )
return -1;
fseek(fp, (1L << 34), SEEK_SET);
fprintf(fp, "\nhello world\n");
fclose(fp);
return 0;
}
Обратите внимание, что 1L
просто long
, это приведет к созданию файла с 17 ГБ и прикрепляет "\nhello world\n"
до конца. Вы можете проверить это путем тривиального использования tail -n1 test.out
или явно используя:
dd if = test.out skip = $ ((1 & lt; 25))
< / blockquote>Обратите внимание, что dd обычно использует размер блока
(1 << 9)
, поэтому34 - 9 = 25
выгрузит'\nhello world\n'
По крайней мере, на 32-битной ОС ftell()
он переполняется или ошибочен или просто запускается в Undefined Behavior.
Чтобы обойти это, вы можете использовать off_t ftello(FILE *stream);
и #define _FILE_OFFSET_BITS 64
.
Verbatim from man ftello
:
Функции fseeko () и ftello () идентичны функциям fseek (3) и ftell (3) (см. fseek (3)), соответственно, за исключением того, что аргумент offset fseeko () и возвращаемое значение ftello () имеет тип off_t вместо long.
На многих архитектурах off_t и long являются 32-битными типами, но компиляция с
#define _FILE_OFFSET_BITS 64
выключит_t в 64-разрядный тип.
Обновление:
Согласно IEEE Std 1003.1, выпуск 2013 года
ftell()
должен возвращать-1
и устанавливатьerrno
наEOVERFLOW
в таких случаях:EOVERFLOW
Для ftell ( ), текущее смещение файла не может быть правильно отображено в объекте типа long.
ftell
всегда возвращает 0
в таких случаях, но переполнение, по-видимому, подразумевает возможность отрицательного возврата. Являются ли переполнения гарантированными "обертывание" в стандарте C99 , или это определяется реализацией?
– Vilhelm Gray
22 May 2013 в 17:00
0
, я не вижу никакого резонанса для этого. Наверное, все это столкнется с UB? Просто избегайте этого! Однако UB может привести ко всему ... он также может вернуться тогда! ;-)
– alk
22 May 2013 в 17:02
If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.
– Vilhelm Gray
22 May 2013 в 17:12
ftell
вызывает переполнение - или это значение, которое оно возвращает для этих случаев, не указано?
– Vilhelm Gray
22 May 2013 в 17:14
В стандарте C99 отсутствует метод распознавания 64b. Какую ОС / среду вы используете? На окнах есть _ftelli64
.
На других платформах посмотрите http://forums.codeguru.com/showthread.php?277234-Cannot-use-fopen () -open -file-больше, чем 4-ГБ [/ д2]
_ftelli64()
и не на на ftell()
.
– alk
22 May 2013 в 17:00
long
& quot; имел длину не менее 32 бит i> & quot; означает, что может быть точно длиной 32 бит. Существует нет необходимости , чтобы он был 64 бит. Кроме того, I do i> соглашается с вами в том, что для 64-битной ОС будет тихо странно иметь long
менее 64 бит длиной ... ;-) Однако, исходя из моей аргументации, ответ будет правильно, не так ли?
– alk
22 May 2013 в 17:16