?

Log in

No account? Create an account
Давние мои читатели наверное помнят, что в 2010 я публиковал серию постов с с тегом "Фундаментальная МТС". Поначалу обновлял прогноз каждый квартал, однако так как она в натуре фундаментальная, то как там было "strong buy" там так и оставалось годами. Ну и собственно с тех пор индекс SP500 рос и рос (+125%).

Теперь это уже естественно, а тогда весьма уважаемые мной аналитики писали, что это пузырь и т.д. Однако всему приходит конец и вот, спустя 10 лет, по моим расчетам, лавочка таки прикрывается. Это не значит, что завтра будет обвал или даже что он будет через год. Просто загас тот драйвер, который по моим расчетам толкал цены вверх и теперь нас вероятнее всего ожидает стагнация, т.е. боковичок. Так что при падении индекса на существенную величину и без реальных признаков проблем в экономике вполне возможно зайти в короткий лонг, однако это уже надо смотреть по ситуации.

Соответственно я на прошлой неделе зафиксировал прибыль и перехожу в режим ожидания. В чем заключается МТС  я, конечно, рассказывать бесплатно не планирую, однако общеизвестные и очевидные вещи стоит отметить:
Read more...Collapse )
Запилил статейку на хабре:

--

Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать HBase в качестве хранилища оперативных данных. В ходе его изучения накопился опыт, который захотелось систематизировать и описать (надеемся, что многим будет полезно). Все описанные ниже эксперименты проводились с версиями HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.
-
1. Общая архитектура
2. Запись данных в HBASE
3. Чтение данных из HBASE
4. Кэширование данных
5. Пакетная обработка данных MultiGet/MultiPut
6. Стратегия разбивки таблиц на регионы (спилитинг)
7. Отказоустойчивость, компактификация и локальность данных
8. Настройки и производительность
9. Нагрузочное тестирование
10. Выводы

Tags:



В рамках проекта интеграции GridGain и хранилища на базе Hadoop (HDFS + HBASE) мы столкнулись с задачей получения и обработки существенного объема данных, примерно до 80 Тб в день. Это необходимо для построения витрин и для восстановления удаленных в GridGain данных после их выгрузки в наше долговременное хранилище. В общем виде, можно сказать, что мы передаём данные между двумя распределёнными системами обработки данных при помощи распределённой системы передачи данных. Соответственно, мы хотим рассказать о тех проблемах, с которыми столкнулась наша команда при реализации данной задачи и как они были решены.

Так как инструментом интеграции является кафка (весьма подробно о ней описано в статье Михаила Голованова), естественным и легким решением тут выглядит использование SparkStreaming. Легким, потому что не нужно особо беспокоиться о падениях, переподключениях, коммитах и т.д. Spark известен, как быстрая альтернатива классическому MapReduce, благодаря многочисленным оптимизациям. Нужно лишь настроиться на топик, обработать батч и сохранить в файл, что и было реализовано. Однако в ходе разработки и тестирования была замечена нестабильность работы модуля приема данных. Для того чтобы исключить влияние потенциальных ошибок в коде, был произведен следующий эксперимент. Был выпилен весь функционал обработки сообщений и оставлено только прямое сохранение сразу в avro:

JavaRDD<AvroWrapper<GenericRecord>> map = rdd.map(messageTuple -> {
SeekableByteArrayInput sin =
new SeekableByteArrayInput(messageTuple.value());
DataFileReader dataFileReader =
new DataFileReader<>(sin, new GenericDatumReader<>());
GenericRecord record = (GenericRecord) dataFileReader.next();

return new AvroWrapper<>(record);
});

Timestamp ts =
new Timestamp(System.currentTimeMillis());
map.mapToPair(recordAvroWrapper ->

new Tuple2<AvroWrapper<GenericRecord>, NullWritable>(recordAvroWrapper, NullWritable.get()))
.saveAsHadoopFile(
"/tmp/SSTest/" + ts.getTime(),
AvroWrapper.class, NullWritable.class, AvroOutputFormat.class, jobConf);


Продолжение: https://habr.com/company/sberbank/blog/358786/

Tags:


Сейчас сел просматривать записи и комментарии в них. Лютый ад, местами)
Многие конечно вполне нормально воспринимают информацию, но кого-то прямо корёжит если ожидания не совпадают с прочитанным. Причем занятно наблюдать в действии эффект вытеснения нежелательной информации из сознания. Во всех своих прогнозах я вставлял принципиальное условие:

"Если же предположить, что ОПЕК будет придерживаться договоренностей, реальная цена вероятно достигнет уровня $75"

"расчет баланса спроса/предложения (и как производной - цены), основывался на предположении, что ОПЕК не превысит квоту 30 мбд"

Когда ОПЕК взялся за ум и перестал наращивать производство, цена вышла на расчетный уровень.

Но до тех пор, чего только тут не писали. И про то, что цены на самом деле формируются на рынке фьючерсов (очевидно согласно тайным соглашениям бильдербергского клуба). И про то что теперь все оборудование выкупят у банкротов за копейки и начнут юзать его в хвост и гриву втаптывая цены в пол невзирая ни на что. Или совсем незатейливое: Самым лучшим прогнозом в каждый момент времени является утверждение "цена будет такой же, как сейчас".

Конечно, такие рассуждения весьма эффективны в плане экономии мыслительной активности. Зачем выкачивать данные по тысячам скважин, строить модели, анализировать балансы и т.д., когда всему есть простое и понятное объяснение.

Еще забавляют такие персоны, которые ведут себя так, как будто им кто-то что-то по жизни должен. Уважаемая Валентина, я вам ничего не обещал, окститесь. Я потратил свое личное время на то, чтобы рассказать вам о своих мыслях абсолютно бесплатно, т.е. даром. Нормальной человеческой реакцией будет или игнорирование, если знаете тему лучше, или благодарность за расширение кругозора, даже если в чем-то не совсем согласны.

Однако к счастью большинство комментариев, конечно, были корректные по форме, с интересными мыслями по существу и это очень приятно. Хочу поблагодарить вас за участие, ради таких собеседников я собственно и писал эти статьи)

На данный момент нет особого настроения писать по этой теме, может быть потом, посмотрим.
Пока что тезисно повторю только основные моменты, которые позволяют понимать, как на самом деле формируется долгосрочная цена. Как говорится, знание нескольких принципов избавляет он необходимости знать множество фактов.

1. Баланс спроса и предложения. Понимая этот механизм вы не дадите запудрить себе мозги теорией заговора пришельцев с Нибиру. Если рынок не монополизирован, то все в конечном счете решается через вот такие графики:


Просто удивительно, насколько не очевидно это для многих, даже весьма интересных авторов, например как pound_sterling. Например я как-то обсуждал такую фразу: "Дороже $80 стоит добыча только 2,8% нефти, которая поступает на рынок". Как говорится в одной песне "Я как в магазине все за 1 доллар, а у меня, ..., 99 центов". В общем рекомендую ознакомиться с этим постом, для прояснения этой темы supply/demand.
Read more...Collapse )

Tags:



Многие думают, что все зависит от решений вашингтонского обкома, но это конечно же чушь, наши судьбы находятся в мозолистых лапах суровых челябинских техасских нефтедобытчиков. Ибо в Техассе находится крупнейшей сланцевый бассейн Permian, разработка которого теоретически способна вогнать цену барреля на уровень царства Аида, превратив рассказы россиян успевших побывать в Турции в легенды эпикурейцев.

Чтобы ответить на вопрос, что же будет с баррелем и с нами, необходимо построить модель месторождения, что позволит рассчитать потенциальные объемы добычи при тех или иных условиях. В качестве основы можно взять данные Drilling Productivity Report (DPR), однако тут есть ряд проблем, которые налагают существенные ограничения на возможности прогнозирования.

Для начала стоит понять, что кажущиеся гладенькими линии такого ключевого показателя как "Продукция с одной буровой за первый месяц" указаны с точностью не большей, чем ответ первоклашки о смысле жизни в рамках концепции трансгуманизма. Если у вас есть привычка просыпаться по ночам, выпивать кефир и регулярно скачивать отчеты DPR, то просматривая их вы можете заметить, что разница между изначальной оценкой и уточнением через год может достигать 34% и еще значительно меняться даже после этого:
Read more...Collapse )

Сланцы и ОПЕК

Несколько пояснений к предыдущему посту:

1. По состоянию на февраль 2017 роста сланцевой добычи практически не было (бугорок в самом конце лишь на уровне сентября-октября). Это прекрасно видно на данных от EIA:

Read more...Collapse )

Tags:



Итак, пришло время сбросить очередную порцию лапши про то, как сланцевики лихо возмещают (или якобы возместят) то, что недопоставляет ОПЕК. Как известно, с января добыча ОПЕК ограничена 32 мбд, что меньше среднего за второе полугодие 2016 на 0.9 мбд. Рассмотрим, что происходит со сланцевиками. Мои расчеты по Бакеену оказались идеально точными. Там кончились жирные участки и бурить осталось практически нечего при таких ценах. По EF ситуация чуть лучше, но в целом похожая:


А вот Permian сильно отличается. Если на картинке выше мы четко видим связь между количеством буровых и динамикой добычи, то для Permian все совсем не так очевидно:
Read more...Collapse )
Всем привет!

Разбираясь со Spark Apache, столкнулся с тем, что после достаточно небольшого усложнения алгоритмов подготовки данных расчеты стали выполняться крайне медленно. Поэтому захотелось реализовать что-нибудь на C# и сравнить производительность с аналогичным по классу решением на стеке python (pandas-numpy-skilearn). Аналогичным, потому что они выполняются на локальной машине. Подготовка данных на C# осуществлялась встроенными средствами (linq), расчет линейной регрессии библиотекой extremeoptimization.

В качестве тестовой использовалась задача «B. Предсказание трат клиентов» с ноябрьского соревнования Sberbank Data Science Journey.

Сразу стоит подчеркнуть, что в данной статье описан исключительно аспект сравнения производительности платформ, а не качества модели и предсказаний.

Итак, сначала краткое описание последовательности действий реализованных на C# (куски кода будут ниже):

1. Загрузить данные из csv. Использовалась библиотека Fast Csv Reader.
2. Отфильтровать расходные операции и выполнить группировку по месяцам.
3. Добавить каждому клиенту те категории, по которым у него не было операций. Для того, чтобы избежать длительный перебор цикл-в-цикле использовал фильтр Блума. Реализацию на C# нашел тут.
4. Формирование массива Hashing trick. Так как готовой реализации под C# не удалось найти, пришлось реализовать самому. Для этого скачал и допилил реализацию хеширования murmurhash3
5. Собственно расчет регрессии.

Read more...Collapse )
Пусть Жираф был не прав,
Но виновен не Жираф,
А тот, кто крикнул из ветвей:
«Жираф большой — ему видней!» (с)

Потребовалось оперативно разобраться с технологией Spark заточенную для использования Big Data. В процессе выяснения активно использовал habrahabr, так что попробую вернуть информационный должок, поделившись приобретенным опытом.

А именно: установкой системы с нуля, настройкой и собственно программированием кода решающего задачу обработки данных для создания модели, вычисляющей вероятность банкротства клиента банка по набору таких признаков как сумма кредита, ставка и т.д.

Больших данных вроде как должно быть много, но почему-то не просто найти то злачное место, где их все щупают. Сначала попробовал вариант с ambari, но на моей Window7 валились ошибки настроек сетевого моста. В итоге прокатил вариант с преднастроенной виртуальной машиной от Cloudera (CDH). Просто устанавливаем VirtualBox, запускаем скачанный файл, указываем основные параметры (память, место) и через 5 минут достопочтенный джин Hadoop жаждет ваших указаний.

Несколько слов, почему именно Spark. Насколько я понимаю, ключевые отличия от изначальной MapReduce в том, что данные удерживаются в памяти, вместо сброса на диск, что дает ускорение во много раз. Но, пожалуй, более важны реализации целого ряда статистических функций и удобным интерфейсом для загрузки/обработки данных.

Дальше собственно код для решения следующей задачи. Есть реально большие данные (ибо рука очень устает скролить эти 2000 строк) в формате:



Есть предположение, что дефолт как-то связан с остальными параметрами (кроме первого, к уважаемым Ивановым1…N претензий нет) и нужно построить модель линейной регрессии. Прежде чем начать, стоит оговориться, что это мой первый код на Java, сам я работаю аналитиком и вообще это мой первый запуск Eclipse, настройка Maven и т.д. Так что не стоит ждать изысканных чудес, ниже решение задачи в лоб тем способом, который почему-то заработал.
Поехали:
Read more...Collapse )

Tags:

Гелик Вани (пародия)

Сделал клип-пародию на "Гелик Вани" Сереги (Полиграф ШарикOFF):


Только имеет смысл сначала посмотреть оригинал, если раньше не видели:

Latest Month

February 2019
S M T W T F S
     12
3456789
10111213141516
17181920212223
2425262728  

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow