В прошлый раз обсуждение битвы тяжеловесов Cassandra VS HBase вызвало весьма бурную дискуссию, в ходе которой была много раз упомянута Scylla — которая позиционируется как более быстрый аналог Cassandra (далее CS). Также меня заинтересовал весьма любопытный Aerospike (далее AS), который в своих тестах предсказуемо побеждает CS с разгромным счетом.



По удивительному совпадению Scylla (далее SC) также легко бьет CS, о чем гордо сообщает прямо на своей заглавной странице:

Высокая производительность — одно из ключевых требований при работе с большими данными. Мы в управлении загрузки данных в Сбере занимаемся прокачкой практически всех транзакций в наше Облако Данных на базе Hadoop и поэтому имеем дело с действительно большими потоками информации. Естественно, что мы все время ищем способы повысить производительность, и теперь хотим рассказать, как удалось пропатчить RegionServer HBase и HDFS-клиент, благодаря чему удалось значительно увеличить скорость операции чтения.

Это даже не шутка, похоже, что именно эта картинка наиболее точно отражает суть этих БД, и в конце будет понятно почему:



Согласно DB-Engines Ranking, две самых популярных NoSQL колоночных базы — это Cassandra (далее CS) и HBase (HB).



Волею судеб наша команда управления загрузки данных в Сбербанке уже давно и плотно работает с HB. За это время мы достаточно хорошо изучили её сильные и слабые стороны и научились её готовить. Однако наличие альтернативы в виде CS все время заставляло немного терзать себя сомнениями: а правильный ли выбор мы сделали? Тем более, что результаты сравнения, выполненного DataStax, говорили, что CS легко побеждает HB практически с разгромным счетом. С другой стороны, DataStax — заинтересованное лицо, и верить на слово тут не стоит. Также смущало достаточно малое количество информации об условиях тестирования, поэтому мы решили выяснить самостоятельно, кто же является королем BigData NoSql, и полученные результаты оказались весьма интересны.

Понятное для тех, кто захочет разобраться, конечно. Пост состоит из трех частей. Для понимания сути явления, достаточно ознакомиться только со второй частью.

1. Вводная (зачем, да почему)
2. Конкретные расчеты
3. Философско-практическая часть.

1. Вводная (зачем, да почему)

Сподвигло меня на этот пост следующее обстоятельство. В инете достаточно много материалов на эту тему. Однако 80% процентов из них страдают трагическим недостатком – они достаточно подробно рассказывают, почему классическая логика не права и ограничиваются констатацией факта, что в квантовой механике все по-другому и наблюдения соответствуют предсказанным ей значениям. Остававшаяся часть грузит математическим аппаратом и после вереницы формул говорит – ну вот видите, будет вот так-то. После этого возникает ощущение боли от изнасилования мозга, ибо реального удовольствия понимания при этом не возникает.

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

Пять лет назад меня осенила идея. Я решил смоделировать ни много ни мало мировую экономику, для того чтобы точно знать какую динамику ожидать от акций, облигаций, курсов валют и т.д. Была только одна маленькая проблемка, модели всего этого не существует. И хуже того, экономисты десятки лет спорят, какая из их куцых эконометрических моделей хотя бы приблизительно верно описывает эти сложнейшие процессы. Поэтому, вместо попыток натянуть выдуманную (и конечно безумно упрощенную) модель на многоликую реальность я вступил на концептуально иной путь – моделировать агентов на микроуровне, чтобы они в изнуряющей борьбе за выживание, путем проб и ошибок приходили к равновесному состоянию, которое на макроуровне выражается в динамике цен, ставок и т.д.

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


Зачем это вообще нужно легко понять, например, по актуальным сейчас спорам вокруг «торговых войн». Одни (в основном профессиональные экономисты) говорят, что тарифы вредят в конечном итоге экономике в целом. Другие же думают, что страна окажется в выигрыше.

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

Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать 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. Выводы

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

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

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

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

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

Всем привет! Разбираясь со 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. Собственно расчет регрессии.

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

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

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

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

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

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



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

Всем привет! Хочу поделиться небольшой историей допиливания HeatonResearchNeural — библиотеки разнообразных нейросетей. Сразу оговорюсь, что работаю аналитиком, а честным программистом перестал быть лет 10 назад.

Однако у меня есть собственный проект на C#, который развиваю в свободное время. Чтобы не заморачиваться написанием велосипеда когда-то скачал HeatonResearchNeural прикрутил скотчем и спокойно гонял тесты, дорабатывал логику своего кода и т.д. Для максимального ускорения заложил в архитектуру решения параллелизацию выполнения расчетов и глядя на загрузку CPU по 80-90% по телу разливалось приятное хозяйское тепло — все пашут, все при деле!