MV
Проблема в том, что это не логи, а csv. С кодировками проблем как раз нет, везде юникод, текст только на английском.
ну если в датасете нет bigint на over 25 символов или timestamp c 6 знаками после . в секундах, то Вам повезло.
Size: a a a
2019 December 01
ME
ну если в датасете нет bigint на over 25 символов или timestamp c 6 знаками после . в секундах, то Вам повезло.
Да, точно, есть проблема с длинными числами) иногда они в научный формат конвертируются :( но пока решали просто пересохранением, если данные дали на вход кривые. А так при просмотре не надо просто сохранять и всё хорошо)
A4
Или это экзаменационный билет по курсу больших данных?
вопрос на отчет лабораторной
T
Привет кто-нибудь сталкивался стем что спарк 2.4.4 на скале 2.11 не может читать авро фаилы?
java.lang.AbstractMethodError: org.apache.spark.sql.avro.AvroFileFormat.shouldPrefetchData(Lorg/apache/spark/sql/SparkSession;Lorg/apache/spark/sql/types/StructType;Lorg/apache/spark/sql/types/StructType;)
A4
Традиционные средства: всё что не паралелится на кластер, а работает на одной машине, наверное. Как простой питон скрипт так и всякие инструменты типа alteryx и sas
для распараллеливания на кластер есть MPI. Но как я понимаю, он с большими данными не очень, потому что надо вручную программировать порядок взаимодействия узлов. Долго короче (мб очень очень долго?)
GP
Привет кто-нибудь сталкивался стем что спарк 2.4.4 на скале 2.11 не может читать авро фаилы?
java.lang.AbstractMethodError: org.apache.spark.sql.avro.AvroFileFormat.shouldPrefetchData(Lorg/apache/spark/sql/SparkSession;Lorg/apache/spark/sql/types/StructType;Lorg/apache/spark/sql/types/StructType;)
где-то слышал; но решилось переходом на 2.12; может какой-то баг в 2.4.4?
GP
попробуй на их жире поискать
FL
вопрос на отчет лабораторной
Тогда ответ такой.
Традиционный подход к обработке данных подразумевает, что данные помещаются в память одной машины или хотя бы на один диск. Также, как правило, традиционный подход подразумевает обработку всего массива данных мощностями одной машины. В терминальном случае - в один поток.
Для данных действительно больших объемов такое не применимо. Во-первых, они не вмещаются на одну машину, во-вторых, их обработка мощностями одного процессорного узла или, тем более, одного ядра будет занимать неприемлемо много времени.
Я бы через это определял большие данные. Если данных слишком много для их обработки на одной машине - то это бигдата.
Традиционный подход к обработке данных подразумевает, что данные помещаются в память одной машины или хотя бы на один диск. Также, как правило, традиционный подход подразумевает обработку всего массива данных мощностями одной машины. В терминальном случае - в один поток.
Для данных действительно больших объемов такое не применимо. Во-первых, они не вмещаются на одну машину, во-вторых, их обработка мощностями одного процессорного узла или, тем более, одного ядра будет занимать неприемлемо много времени.
Я бы через это определял большие данные. Если данных слишком много для их обработки на одной машине - то это бигдата.
FL
Не уверен, можно ли MPI отнести к традиционным средствам.
FL
Тогда ответ такой.
Традиционный подход к обработке данных подразумевает, что данные помещаются в память одной машины или хотя бы на один диск. Также, как правило, традиционный подход подразумевает обработку всего массива данных мощностями одной машины. В терминальном случае - в один поток.
Для данных действительно больших объемов такое не применимо. Во-первых, они не вмещаются на одну машину, во-вторых, их обработка мощностями одного процессорного узла или, тем более, одного ядра будет занимать неприемлемо много времени.
Я бы через это определял большие данные. Если данных слишком много для их обработки на одной машине - то это бигдата.
Традиционный подход к обработке данных подразумевает, что данные помещаются в память одной машины или хотя бы на один диск. Также, как правило, традиционный подход подразумевает обработку всего массива данных мощностями одной машины. В терминальном случае - в один поток.
Для данных действительно больших объемов такое не применимо. Во-первых, они не вмещаются на одну машину, во-вторых, их обработка мощностями одного процессорного узла или, тем более, одного ядра будет занимать неприемлемо много времени.
Я бы через это определял большие данные. Если данных слишком много для их обработки на одной машине - то это бигдата.
При этом, надо понимать, что машины бывают разные. Например, для кого-то 150 ГБ уже на ноутбук не лезут, а кому-то 5 ТБ можно в память упихать.
T
где-то слышал; но решилось переходом на 2.12; может какой-то баг в 2.4.4?
спасибо, решил даунгрейдом до 2.4.3 (emr 5.28.0 -> 5.26.0)
AS
Тогда ответ такой.
Традиционный подход к обработке данных подразумевает, что данные помещаются в память одной машины или хотя бы на один диск. Также, как правило, традиционный подход подразумевает обработку всего массива данных мощностями одной машины. В терминальном случае - в один поток.
Для данных действительно больших объемов такое не применимо. Во-первых, они не вмещаются на одну машину, во-вторых, их обработка мощностями одного процессорного узла или, тем более, одного ядра будет занимать неприемлемо много времени.
Я бы через это определял большие данные. Если данных слишком много для их обработки на одной машине - то это бигдата.
Традиционный подход к обработке данных подразумевает, что данные помещаются в память одной машины или хотя бы на один диск. Также, как правило, традиционный подход подразумевает обработку всего массива данных мощностями одной машины. В терминальном случае - в один поток.
Для данных действительно больших объемов такое не применимо. Во-первых, они не вмещаются на одну машину, во-вторых, их обработка мощностями одного процессорного узла или, тем более, одного ядра будет занимать неприемлемо много времени.
Я бы через это определял большие данные. Если данных слишком много для их обработки на одной машине - то это бигдата.
тут еще такой момент. смотря как мерять если у вас JSON то там могут быть теребайты а сконвертил в авро или еще лучше в паркет и получил маленький данные. Так что для pr лучше мерять json. Тотже csv при преобразовании в бинарную форму в памяти станет гораздо меньше
AS
У нас практика показывает преобразование нашего json в avro(правда с дефлейтом) жмет в 500 раз
FL
тут еще такой момент. смотря как мерять если у вас JSON то там могут быть теребайты а сконвертил в авро или еще лучше в паркет и получил маленький данные. Так что для pr лучше мерять json. Тотже csv при преобразовании в бинарную форму в памяти станет гораздо меньше
Как это вообще хоть что-то в ответе меняет? :)
AS
Как это вообще хоть что-то в ответе меняет? :)
Это просто информация. Оценить обьем можно по разному. Возможно все эти терабайты на диске спокойно влезут на один комп в память или их можно будет обработать последовательно инкрементальным алгоритмом.
AS
Или влезет на один диск когда преобразуешь
AS
это ничего не меняет в ответе . скорее показывает что это все PR Хрень
AS
я не берусь гворить про гугл и т.п.
MV
это ничего не меняет в ответе . скорее показывает что это все PR Хрень
я бы добавил к последнему тезису, что БигДата - заезженный термин используемый юными HR-барышнями и прочими гуманитариями