kaipa: (Default)
Оказывается, существуют видео в свободном доступе. Кому интересно:

1. HL++ 2013. Распределенные системы хранения данных для аналитики: Vertica и другие системы. Достаточно большая часть доклада -- это общие архитектурные соображения.

2. HL++ 2016. Переезжаем на Yandex ClickHouse.

Некоторый апдейт по КликХаусу. Я продолжаю активно общаться с Яндексом на тему, как развивать, улучшать и продвигать КХ для того, чтобы он начал широко использоваться вне-Яндекса. Запрос на (бесплатную) аналитическую DBMS есть, но в текущем состоянии КХ не способен конкурировать ни с бесплатным Хадупом (за счет отсутствия экосистемы и интеграций), ни с коммерческими аналитическими DBMS (в первую очередь из-за слабой SQL-функциональности). Это не говоря о том, что о нем знает всего пара тысяч человек, нет подтвержденных продакшн инсталляций вне Яндекса (скоро будут), у него нечеткое позиционирование и нет нормального сопровождения. Есть много идей и планов, как это все исправлять, и если получится, то через пару лет у КХ есть все шансы занять достойное место на рынке.

Update. Нашел и залил видео от 2012.

3. HL++ 2012. Аналитическая инфраструктура непрерывного тестирования интернет рекламы.
kaipa: (Default)
Некоторое время назад я обратил внимание на то (линк), что команда Обамы в кампанию 2012г активно использовала технологии машинного обучения для идентификации и коммуникации с колеблющимися избирателями. После победы Трампа стали известны (интервью после выборов, статья Bloomberg до выборов или поиск по словам Brad Parscale) некоторые детали его кампании. Основное внимание его команды было уделено прямому маркетингу (direct marketing), то есть правильно сфокусированной рекламе и анти-рекламе (что тоже важно) через различные каналы интернета. Только официально Трамп потратил на это в несколько раз больше Клинтон. Учитывая, что пресса в основном была за демократов, Интернет для Трампа оставался чуть ли не единственным способом "дойти" до своего избирателя. В процессе кампании команда Трампа кроме того собрала через интернет (в основоном объявлениями на Фейсбуке) $260-280 миллионов пожертвований вместе с е-мейл и физическими адресами -- 12-14 миллионов реальных людей поддерживающих Трампа. Это колоссальный ресурс, которым команда Трампа сумела правильно распорядиться.

В общем, современные технологии снова на "страже добра" / "службе зла" (нужное подчеркнуть).

ClickHouse

Nov. 9th, 2016 06:25 pm
kaipa: (Default)
Вчера, пока Америка голосовала за Трампа, я выступил на юбилейной конференции HighLoad++, которая в этот раз проводилась в Школе Управления Сколково. Это было мое третье выступление на HL++ (предыдущие -- в 2012 и 2013гг) и, наверное, самое успешное. Рассказывал я про Яндекс.ClickHouse -- аналитическую массивно-параллельную СУБД, разработанную Яндексом для своих потребностей и выпущенную в OpenSource летом этого года.

Надо сказать, что Яндекс произвел некоторую революцию. КликХаус -- это очень быстрая и очень хорошо масштабируемая система, которая по скорости может померяться с кем угодно, включая Vertica. Яндекс -- большие молодцы, что ее сделали, и еще большие, что открыли для всех желающих. В КликХаусе применен ряд удачных технических решений, за счет чего достигаются впечатляющие результаты производительности на тестах и реальных задачах. Впрочем, в большей степени они впечатляют тех, кто до этого имел дело только с простыми OLTP базами данных или с Хадупом. Интерес к КликХаусу в России и в ИТ-мире большой и вполне заслуженный. Яндекс выступил с докладом и провел несколько митапов. А потом выступал я.

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

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

А Сколково -- http://school.skolkovo.ru/ru/ -- мне понравилось.
kaipa: (Default)
В продолжение к предыдущему.

Увы, но Блекберри как производитель смарфтонов умирает. Компания переориентируется на программное обеспечение, портируя свои корпоративные решения и технологии безопасности на Android. В качестве производителя ПО у нее все может еще хорошо получиться, потому что один раз уже получилось. Я имею ввиду QNX.

Многие близкие к ИТ-индустрии слышали про эту древнюю операционную систему реального времени, о надежности которой ходят легенды. Не немногие в курсе, что 1) она уже давно принадлежит Blackberry (собственно, Blackeberry 10 OS -- это развитие QNX для мобильных устройств) и 2) занимает больше 50% рынка встроенных автомобильных систем (помимо приложений в разных областях промышленности, от медицины то ядерных реакторов). Так что если у вас последние модели таких марок как Audi, BMW, Chrysler, GM, Honda, Maserati, Mercedes-Benz, Porsche, Toyota, Volkswagen, Land Rover и даже Ford, который переходит на QNX с микрософтовской платформы, -- то шансы, что внутри вашей машины есть QNX весьма высоки. И динамика рынка такова, что доля QNX будет только расти, Блекберри тут на переднем крае технологии.

Узнал я это совершенно случайно, разбираясь с инфотейнмент системой своего автомобиля. Она у меня довольно простая, но с самого начала удивила продуманностью. В рекламных буклетах было еще много плюшек, которые на нее навешиваются, включая такую экзотику как чтение дорожных знаков. Но вот какой станет машина всего через несколько лет, можно посмотреть на презентациях концептов ниже. Мне было очень интересно, в числе прочего узнал про технологию V2X.
+2 )

Sailfish

Oct. 24th, 2016 12:46 am
kaipa: (Default)
Мне всегда было жаль компании Эриксон и Нокия, которые достаточно внезапно проиграли рынок мобильных телефонов, потому что телефоны неожиданно стали не для звонков. Отличная операционная система Symbian OS с их уходом с рынка тоже приказала долго жить (у меня остался последний симбиановский флагман -- Нокия E-7). Но оказывается, что из осколков Нокии все же выплыла независимая опенсорсная операционная система для мобилок Sailfish OS, развитие платформы MeeGo, и телефон Jolla. Насколько я понимаю, Sailfish может портироваться на более-менее любое железо (например, ее используют на Nexus 5), но есть и устройства, которые выпускаются специально для этой платформы. Я был немало удивлен, узнав что один из последних таких телефонов был выпущен российской компанией Oysters.

В целом, достаточно интересная альтернатива Андроидам и Эпплам, у которой вполне может быть будущее. Платформа развивается на энтузиазме и краудфандинге, поэтому перспектив у нее даже больше, чем у Blackberry OS, которая неумолимо проигрывает свой родной корпоративный сегмент и вряд ли переживет 2017г.
kaipa: (Default)
Похоже, что в ближайшие несколько лет IoT станет основным трендом. Я как-то не следил особо за развитием, но в последнее время приходят новости из совершенно не связанных областей, но сходящиеся на IoT.

Сегодняшняя успешная посадка Фалькона -- это эпохальное событие. Но я обратил внимание на то, а что за спутники он выводил на орбиту. Спутники компании ORBCOMM, которые "следят" за 1.3 миллиарда устройств по всему миру, установленных в грузовиках, кораблях, контейнерах и проч. (цифра 1.3 миллиарда -- это всего устройств с модулями Orbcomm; передают данные на спутники, видимо, не все).

Один мой знакомый работает в компании ParStream -- это распределенная аналитическая база данных, позиционируемая для приложений IoT. То есть ее можно и для других целей использовать, конечно, если есть постоянный поток данных от большого количества источников, который надо как-то анализировать и оперативно на него реагировать. Традиционно для этого существует класс систем Complex Event Processing или CEP, но насколько я понимаю, ParStream это полноценная RDBMS, предоставляющая комбинацию постоянной высокоскоростной загрузки больших данных (не пакетами, а потоками) и быстрых запросов к ним же. В принципе, это можно сделать и на других технологиях, но специализированное решение на специализированных задачах всегда лучше универсального. Во всяком случае они метят именно в IoT.

Вроде бы курьезный случай, берем на работу парня, который разворачивает Amazon EC2 на андроидовском планшете. Зачем? В принципе, особенно незачем, хотя можно представить себе ситуацию, когда это может быть удобно. Но основная суть в том, что планшетов все больше и больше, процессоры там мощные, памяти достаточно, чего им просто так лежать. И тут даже не идет речь о том, что их можно в кластеры объединять, и что-нибудь на них считать -- секвестировать геном, ломать пароли или генерить биткойны. Даже без специальных чипов, вокруг уже множество устройств, на которых можно программировать что угодно, объединять их в сети, вычислительные облака и т.п.

В общем, из относительно новых IT-мемов Интернет Вещей, как мне кажется, превращается или уже превратился во что-то реальное. Гугление выводит на какие-то триллионные цифры, кучу компаний, которые этим занимаются, и т.п. Это как-то несколько в тени, но стремительно развивается.
kaipa: (Default)
Технический айтишный пост.

Коллега опубликовала статью на Хабре о Snowflake. Snowflake (снежинка, намек на тип схемы для DWH) -- это эластичное хранилище данных (data warehouse) на Амазоновской облачной инфраструктуре. И хотя наш вердикт о готовности решения к реальным сценариям был отрицательным, сама идея очень здравая.

Если очень вкратце, то:
- данные хранятся в S3 -- то есть надежно, неограничено и т.д.
- данные обрабатываются произвольным количеством compute nodes -- инстансы EC2

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

К чести разработчиков они уделили пристальное внимание "прочим равным" и сделали первую настоящую колоночную базу данных на EC2/S3. То есть ограничения S3 частично компенсируется правильной организацией данных. Вряд ли они сходу сделали это так же хорошо, как это вылизывалось годами в Вертике, но судя по результатам -- как минимум неплохо. Я думаю, что в течение года-двух Snowflake вылечит детские болезни и станет более чем приемлимым вариантом облачного хранилища. Особенно, если ваши данные уже на Амазоне.

P.S. Уже после окончания нашего проекта я узнал, что ключевой разработчик Snowflake -- Вадим Антонов -- один из основателей русского интернета, с которым мне довелось некоторое время работать в одной команде в начале 2000х.

P.P.S. А Вертика на днях выпустила версию 7.2, где, о чудо, в числе прочего ответила на многолетние стоны клиентов по поводу ряда раздражающих мелочей (у каждого свой, поэтому приводить не буду). С каждой версией они убирают ограничения, которые, как казалось (и как они объясняли) были естественными следствиями колоночной структуры данных. Молодцы.
kaipa: (Default)
Почти год назад наколеночная нейронная сеть научилась играть в шахматы просто имея массив готовых игр. В опубликованной недавно статье (магистрская работа) описывается шахматная программа, использующая  нейронную сеть для оценки позиции и оптимизации перебора. По утверждению авторов программа играет в силу мастера.

Хотя это звучит круто-круто, на самом деле это круто, но не настолько :) Так как начальной точкой оптимизации была программа, основанная на традиционных алгоритмах, которая уже играла чуть хуже кандидата в мастера. Нейронные сети использовались для ее улучшения и замены некоторых алгоритмических частей на обучаемые.

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

Для начала, авторы поставили задачу оценки позиции при помощи нейронный сети. Они построили и натренировали сеть так, чтобы получить функцию оценки максимально близкую к известной функции оценки Stockfish (есть массив позиций оцененных Stockfish). А потом проверили на позициях из Strategic Test Suite. Натренированная нейронная сеть смогла оценивать позиции на уровне лучших шахматных программ, не имея практически никаких априорных знаний -- только опыт обучения!

Следующая логичная задача, которую поставили перед собой авторы -- это использовать нейронную сеть для предсказания лучшего хода. Здесь они использовали нестандартный, как мне кажется, подход для определения глубины поиска: отсечение по вероятности выиграть. То есть для каждой позиции вычисляется вероятность выигрыша, перебор идет в сторону позиций с более высокой вероятностью (или отсечение низких). Это дает преимущество при оценке длинных "вынужденных" комбинаций, когда в позиции не очень много ходов, но ее надо просмотреть глубоко. Нейронная сеть была натренирована для предсказания этих вероятностей. По сравнению с вариантом вычисления вероятностей "в лоб" (чисто через оценку позиций), нейронная сеть "угадывала" наилучший ход несколько чаще, то есть и в этом случае удалось повторить (в смысле результата) и превзойти закодированный алгоритм!

В обоих случаях существующий жесткий алгоритм был заменен гибкой и обучаемой нейронной сетью, то есть при дальнейшем обучении (на лучших данных или в режиме self-play) можно ожидать еще большего роста качества игры.

Это, конечно, не так круто, как "научиться играть" по партиям, но все равно впечатляет.
kaipa: (Default)
Продолжение серии статей на geektimes. (начало тут). Я ожидал одну заключительную статью, но уже появилось целых три, и обещают самую последнюю.

5. Каспаров против Deep Blue. Часть III: Междуматчье. (1996-1997).

6. Каспаров против Deep Blue. Часть IV: Нью-Йоркские тайны (1997)

7. Каспаров против Deep Junior. Возвращение в Нью-Йорк (2003)

Пятая (III) часть для меня была самой интересной, где опираясь на книгу "отца" Deep Blue рассказывается, как компьютер учили "мыслить" позиционно и стратегически.

Следующая часть -- это кульминация, исторический матч в Нью-Йорке. Каспаров, конечно, молодец. Он играл против компьютера очень и очень сильно, во всю силу используя позиционную, плохо просчитываемую игру, и мог выиграть матч, если бы не сломался психологически от нескольких "непонятных" и откровенно слабых ходов Deep Blue. Каспаров проиграл. Он хотел и мог бы выиграть матч-реванш, но IBM от реванша уклонилась, видимо, справедливо полагая, что выигрыш Каспарова обнулит маркетинговые приобретения.

Последняя на сегодня часть -- это матч уже не против суперкомпьютера, а против "обычной" четырехпроцессорной рабочей станции, на которой работала одна из лучших на тот момент шахматных программ Deep Juniour 8. В отличие от предыдущего матча, в этот раз Каспаров азартно играл в "обычные" шахматы, то есть так, как он играл бы с человеком. Только в последней партии матча он согласился на ничью, хотя с человеком бы продолжил играть до победы, понимая, что цена ошибки от усталости слишком высока, а компьютер не устает. Интересно, изменился бы результат, если бы Каспаров играл так же, как и в предыдущем Нью-Йоркском матче. Думаю да, так как глубина анализа Deep Juniour была заведомо меньше, чем у его куда более мощного предшественника.

В общем, в начале - первой половине нулевых, компьютерные программы на вполне компромиссном по сегодняшним меркам железе догнали по силе лучших гроссмейстеров. Мне кажется, что примерно с этого времени интерес к шахматам в мире стал плавно угасать. Увы.
kaipa: (Default)
На geektimes опубликована интересная серия статей про историю противостояния Каспарова и шахматных компьютеров. Заключительной статьи пока нет, но вдруг я пропущу и забуду.

1. Каспаров – Deep Thought. Игра в одни ворота (1989)

2. Первые обидчики. Fritz и Genius (1994-1995)

3. Каспаров против Deep Blue. Часть I: черный ящик (1996)

4. Каспаров против Deep Blue. Часть II: Филадельфийский эксперимент (1996)

В следующем матче в 1997г с усовершенствованным Deep Blue Каспаров проиграл (статья об этом, видимо, еще будет), но примерно до середины 2000х лучшие гроссмейстеры все еще сражались с компьютерами примерно на равных. Есть "закон Мура для шахмат", по которому считается, что удвоение вычислительной мощности вдвое увеличивает силу шахматной программы на 30 пунктов рейтинга Эло. Если учесть, что каждые полтора-два года производительность удваивается, то за 10 лет компьютеры "умнеют" минимум на 300 пунктов, что ОЧЕНЬ много. А если добавить к этому постоянное совершенствование алгоритмов, то понятно, что в шахматах у человека уже шансов нет. Лучшие шахматные программы на довольно скромных четырехпроцессорных компьютерах играют в силу 3300+, тогда как лучшие гроссмейстеры "всего лишь" 2800-2900.

Гроссмейстеры все еще могут что-то противопоставить шахмтаным программам только в середине партии, так как дебюты машина "знает" лучше, а для эндшпилей (5 и 6, а недавно и 7 фигур) рассчитали полные эндшпильные таблицы. Компьютеры не допускают тактических ошибок, и могут быть обыграны только стратегически. Но это еще надо уметь.

Впрочем, интересно было бы сравнить силу компьютеров и человека при равном энергопотреблении. Есть ощущение, что человек тут будет все еще впереди. С другой стороны, я играл или играю примерно в силу второго взрослого разряда (1700-1800). Шахматная программа в моем макбуке меня уже стабильно обыгрывает. Даже если я не допускаю явных ошибок и зевков, так как играю между делом. По-моему, дважды мне удалось сделать ничью. Оба раза позиционную (с повторением ходов).

Кстати, на днях, разбирая книги, нашел книгу по лингвистической геометрии, технологии, которую придумала группа Ботвинника, о которой я писал пару лет назад. Начал было разбираться тогда, но не хватило времени или желания. Суть в том -- что эта технология позволяет радикально, на порядки, сократить дерево перебора. Во всяком случае, так считают авторы.

(продолжение)
kaipa: (Default)
На собеседование приходил студент-пятикурсник, который занимается аппроксимацией модели аэродинамики самолета при помощи нейронных сетей. Модель большая и сложная, у нее около 700 переменных и 70 критериев. Поскольку эту тему он по идее должен знать лучше всего, в основном говорили о нейронных сетях.

Маленькое отступление. А зачем вообще использовать нейронную сеть для аппроксимации функции, если известно, как ее вычислять? Это имеет смысл в двух случаях:
- когда вычисление достаточно дорого
- когда размерность задачи очень большая
Обычно из второго следует первое. В задачах вроде моделирования самолета каждый расчет -- это отдельная вычислительная задача, решаемая численными отнюдь не быстрыми методами. Причем, интерес представляет именно результат, образ функции, взаимозависимость критериев. Это требует аппроксимации образа функции, который неизвестен, а не самой функции. Но чтобы аппроксимировать образ, надо много-много раз вычислять функцию. Вот где на помощь может прийти нейронная сеть.

А может и не прийти. Поэтому меня, как математика, сразу же заинтересовал вопрос, а почему вообще известно, если известно, что нейронная сеть -- это хороший способ аппроксимации? Есть ли гарантия, что нейронная сеть вообще "сойдется"? Как оценить точность аппроксимации? Какой объем обучающей "выборки" необходим для достижения желаемой точности и т.д. К сожалению, мой собеседник ни на один вопрос ответить не смог. Видимо, физикам достаточно знать что метод "работает", а как он работает -- это их мало волнует.

Тем не менее, вопрос, на мой взгляд, отнюдь не праздный. Более строго, тут возникают следующие вопросы:
- Какие классы функций может точно или приближенно аппроксимировать нейронная сеть и какие требования на ее конструкцию?
- Какой объем обучения необходим для аппроксимации с заданной точностью?

Исчерпывающий ответ на вопрос, какие функции может аппроскимировать нейронная сеть, дан в этой статье А.Н. Горбаня. Если очень грубо, то это не что иное, как обобщение известной теоремы Веерштрасса об аппроксимации непрерывной функции многочленами. Что такое нейронная сеть? "Нейрон получает на входе вектор сигналов x, вычисляет его скалярное произведение на вектор весов α и некоторую функцию одного переменного φ(x,α) [функцию активации]. Результат рассылается на входы других нейронов или передается на выход. Таким образом, нейронные сети вычисляют суперпозиции простых функций одного переменного и их линейных комбинаций." То есть вопрос переформулируется в вид, можно ли аппроксимировать произвольную непрерывную функцию суперпозицией и линейной комбинацией простых функций одного переменного. Ответ положительный (это следствие из более общего утверждения). Никаких специальных условий на функцию активации не накладывается.

Однако, с практической точки зрения это лишь пол-ответа. Можно утверждать, что для любой функции существует нейронная сеть, которая аппроксимирует ее с любой точностью. Но нельзя утверждать, что, скажем, трех- или четырехслойная сеть на это способна. Сходу, статей, которые бы отвечали на этот вопрос, я не нашел. Но он должен быть, так как, скажем, Колмогоров доказал, что любую непрерывную функцию размерности n можно точно представить в виде суммы из 2n+1 произведений функций одного переменного. Для приближенного представления должны быть похожие оценки, которые можно перевести на язык "слоев" нейронных сетей.

Ответ на второй вопрос, как я подозреваю, сильно зависит от архитектуры и стратегии обучения нейронной сети. Кроме того, есть ряд "не нейронных" методов, которые позволяют оценить точность аппроксимации. Простейший способ, это использовать известную функцию и подсчитать точность апроксимации точно (прошу прощения за тавтологию) при разных архитектурах сети, как это показано, например, в этой статье.
kaipa: (Default)
Некоторое время назад [livejournal.com profile] plakhov рассказал о любопытном эксперименте. Суть его в том, что программа с нейронной сетью, собранная на коленке, научилась играть в шахматы, даже не зная правил, а только обучившись на довольно большом количестве партий (100 миллионов). Единственное, что "знала" программа -- это функцию оценки позиции (довольно примитивную), и метод отсечения ветвей для уменьшения перебора. Это, конечно, круто. Очень круто и напоминает фантастику. Но гораздо круче, когда AI начинает сам взаимодействовать со средой, чтобы научиться. Это то, что в общем случае называется обучение с подкреплением или reinforcеment learning.

Оказывается, и здесь есть значительные успехи в последнее время. Гугл во всех смыслах недаром купил небольшую компанию DeepMind. Они занимаются разработкой искусственного интеллекта, который учится играть в компьютерные игры, те самые из домашних ПК 80х. От этого уже совсем недалеко до обучения взаимодействия со средой в общем случае.

Любопытно, что Илон Маск, основатель SpaceX и Tesla, инвестировал и в DeepMind и был хорошо знаком с тем, что они делают. Несколько недель назад он оставил комментарий к статье The Myth Of AI", который был довольно быстро удален, но сохранились копии. Маск предупреждает, что полноценный AI будет создан в ближайшие 5-10 лет.

Я посмотрел, что сейчас делает Джефф Хоукинс и его компания Numenta (Хоукинс -- автор On Intelligence). То же самое! Вот недавняя статья в их блоге "Learning Through Active Exploration". Естественно, они используют идею HTM, но движутся в том же направлении, что и DeepMind.

В общем, похоже, что появление дешевых вычислительных мощностей стимулировало новый всплеск интереса к этой области, и он в конце концов дает результат. "ОК Google" уже никого не удивляет, хотя лет 10 назад это бы казалось фантастикой. То ли еще будет.

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

А кто-нибудь из френдов (кроме Плахова, про которого я знаю) причастен? Чем занимаетесь?
kaipa: (Default)
Мой френд [livejournal.com profile] _darkus, автор нескольких книг по языку Хаскель и не только, а также организатор конкурсов по функциональному программированию, в одном из которых я даже как-то с удовольствием поучаствовал, попробовал использовать краудфандинг для финансирования двух своих общественно полезных проектов. Не ради прибыли, а просто чтобы минимально окупить расходы.

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

Месяц назад Роман анонсировал новый проект -- Систему Поддержки Принятия Решений для диагностике лечения судорожного синдрома (по простому -- эпилепсии). И под этот проект тоже был создан кошелек краудфандинга. За прошедший почти месяц на систему диагностики и лечения больных, которая может помочь спасти чьи-то жизни и здоровье, читатели его журнала пожертвовали денег в два раза меньше, чем за несколько дней на книгу по квантовым вычислениям!

Вам не кажется это странным? Есть ли этому какое-нибудь разумное объяснение тому, что айтишники ценят книгу по модной профессиональной теме выше, чем перспективный проект на стыке медицины и информационных технологий?
kaipa: (Default)
[livejournal.com profile] _darkus_ затеял разработку системы поддержки принятия решений (СППР) для диагностики определенного типа заболеваний, и публикует наброски статей по архитектуре. Поскольку я когда-то занимался математической теорией, стоящей за процессами принятия решений, тема для меня не чужая.

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

Для начала, довольно очевидные, но важные определения.

1. Решение -- это элемент конечного или бесконечного множества альтернатив или решений какой-то задачи.
2. Принятие решения -- акт выбора ЛПР решения из множества возможных.
3. Это важно. Акт выбора производится не случайно, а с целью удовлетворения некоторым субъективным для ЛПР или объективным критериям.
4. СППР -- средства и процесс, помогающие ЛПР принять решение.

Ключевой пункт здесь третий. Решения могут быть объективными и субъективными. Большинство систем, которые принято называть СППР, помогают именно с объективными решениями. Экспертные системы -- самый распространенный пример. Объективность в данном случае означает, что разные ЛПР при одних и тех же условиях при помощи СППР выберут одно и то же решение (или небольшой набор решений). Это полезно, но не очень интересно. Куда интереснее, во всяком случае на мой взгляд, СППР, которые помогают ЛПР выразить свои субъективные предпочтения и принять именно его, личное решение.

Все люди разные. Кто-то любит синее, кто-то красное. Большинство реальных ситуаций, когда требуется принимать решения, описываются набором характеристик, часто вступающих между собой в противоречие. Расхожая фраза -- "быстро, недорого, качественно -- выберете два из трех" -- типичный пример ситуации принятия решения. В такой постановке есть как минимум три оптимальных решения (быстро, недорого, некачественно; быстро, дорого, качественно; долго, недорого, качественно) -- и разные люди выбирают разные, в зависимости от своих желаний и возможностей. Можно усложнить задачу и оценить скорость во временных единицах, стоимость в деньгах, а качество -- в количестве брака или дефектов. Пространство решений в этом случае существенно расширяется, но множество достижимых решений ограничено либо моделью, которая связывает эти характеристики между собой, либо выборкой коммерческих предложений (тендеров и т.п.). Как выбрать наилучший вариант?

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

При первом подходе пытаются выяснить у ЛПР его отношения предпочтения между разными критериями, их ранг и т.д. Обычно человеку просто ответить, что более важно для него, А или Б. Не всегда. Эти отношения могут использоваться как в рамках интерактивной процедуры, которая сходится к оптимальному решению, так и для построения функции полезности, которая является скаляризацией критериев. Имея функцию полезности, можно найти ее пересечение с Парето-границей (границей множества решений оптимальных по Парето) -- это и будет оптимальным решением.

Другой подход состоит в визуализации Парето-границы и представлении средств (визуальных) изучения взаимовлияния критериев. Фактически, ЛПР дается полная информация о том, какие решения в принципе возможны, и предлагается самому найти устраивающий его компромисс. Это возможно не всегда, а только когда число критериев не более пяти-семи. При большем числе критериев объективные взаимосвязи донести до ЛПР не получится, особенно в нелинейных задачах. Однако, большинство реальных практических задач описываются небольшим числом критериев, даже если число параметров задачи велико (здесь я подразумеваю, что задача принятия решений описывается некоторой параметризованной моделью). Этот подход работает и в том случае, когда ЛПР много, или когда решение принимается в переговорах нескольких участников. Работает в том смысле, что между решениями разных ЛПР на Парето-границе можно провести аналог геодезической линии, и сущность переговоров сводится к поиску взаимоприемлемого компромисса на этой линии.

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

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

Вот тут один товарищ пишет, как в Фейсбуке (не соц.сети, а компании) с его, видимо, помощью сделали систему, загружающую в СУБД Вертика 35TB/час данных (или 10GB/сек). Это нижняя планка, SLA, а пиковая производительность должна быть в полтора-два раза выше, чтобы реагировать на колебания нагрузки, незначительные задержки и прочее. Необходимо заметить, что параллельно непрерывной загрузке система обслуживает запросы клиентов. В нашей компании мы загружаем данных меньше, но в расчете на узел кластера, думаю, примерно столько же. Я давно хочу написать статью на Хабре про оптимизацию скорости загрузки в Вертику, но чтобы не быть голословным, надо заново перепрогнать тесты в разных конфигурациях, нарисовать таблички и графики, а это время и лень. Тем не менее, базовые принципы, изложенные в статье выше, верные и могут быть применены к любой массивно-параллельной системе управления данными, не только к Вертике. Попробую их тут обобщить, по ходу дела комментируя некоторые моменты вышеуказанной статьи.

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

Скорость загрузки или правильнее говорить пропускная способность системы на запись, так как загрузка происходит во много потоков, определяется сочетанием трех основных факторов:

1. Скоростью обработки и загрузки одного файла на одном сервере.
2. Масштабируемостью по числу параллельных загрузок в пределах одного сервера.
3. Масштабируемостью по числу параллельных загрузок в пределах всего кластера.

Сверху скорость, очевидно, ограничена производительностью дисковой подсистемы.
Read more... )
kaipa: (Default)
Не секрет, что основную информацию о текущем мы (я имею ввиду тех, кто это сейчас читает) получаем из Интернета. То есть из множества статей, фото и видео-свидетельств, записей в социальных сетях. Не редки умышленные фальсификации и недостоверная информация. Решить, что из этого правда, а что нет, не всегда возможно по объективным признакам, и тогда в силу вступают политические или иные предпочтения. Верят "нашим", которые у каждого свои. Критическому анализу подвергается (если вообще подвергается, а не игнорируется) только то, что вызывает диссонанс с устоявшимся мировоззрением. В этой связи мне подумалось вот что.

Ашманов описал феномен мозговых вирусов, которые могут запускаться через сеть и формировать или модифицировать мнение "зараженных". Но возможно ли сейчас, при современном развитии технологий с одной стороны, и открытостью Интернета с другой, создать полностью виртуальное событие или цепь событий, сфальсифицировав видео, аудио, странички в фейсбуке, если надо и т.д. То есть что-то не на уровне полета на Луну американцами (на всякий случай -- это лишь абстрактный пример, обсуждать который не надо), но достаточно существенное. В кино такое бывает часто, а в жизни?

В до-интернетовскую пору фальсификации были реальными, достаточно вспомнить Таиру Сайтаферна, "Велесову книгу" или подделки Сулакадзева.

Вопрос, зачем, оставим в стороне. Информационные войны не обязательно ведутся диванными аналитиками. Должны быть соответствующие отделы и у спецслужб. Мне интересно мнение насчет технической возможности. Как думаете? И, может, кто-то вспомнит современные примеры такого рода фальсификаций, которые не были раскрыты в течении достаточно большого времени (недели, месяцы, годы).
kaipa: (Default)
На предстоящем этой осенью Хайлоаде анонсирован доклад Leif Walsh из Tokutek, где он будет рассказывать о том, как фрактальные деревья помогают масштабировать индексы на примере TokuMX (это MongoDB с индексакцией на фрактальных индексах от Tokutek). Это преподносится как супер-прорыв. С одной стороны, это так и есть, обычные бинарные индексы масштабируются хреново, а хэш индексы не везде можно использовать. С другой -- я два года назад рассказывал на том же Хайлоаде, как работают фрактальные индексы в TokuDB (это расширение MySQL от Tokutek), и упоминал об этом в  статье на Хабре, но никакого интереса это не вызвало. Разве что CEO Tokutek мне написал письмо с благодарностью за популяризацию (мы знакомы). Обидно, понимаешь. Вообще, доклад Лейфа Уолша, судя по аннотации, близок к моему прошлогоднему, где я рассказывал о распределенных базах данных для аналитики, только у него упор на горизонтальное масштабирование OLTP.

Для интересующихся, вкратце, проблемы с бинарными индексами следующие.
1) Скорость вставки (без балансировки) растет как log2N
2) Но без балансировки плохо, поэтому надо балансировать, что в худшем случае дорого (оценку не помню)
3) Удаление с балансировкой дорого
4) Поиск по дереву, если оно большое, плохо ложится на диск с последовательным чтением, то есть сегменты индекса могут быть раскиданы случайно. Из-за этого такие индексы приходится кэшировать целиком, иначе резко падает скорость. Для больших индексов плохо.

В целом, бинарные индексы нормально работают на не слишком большом объеме деревьев, но с ростом количества данных и размера индекса, производительность существенно падает. То есть индекс служит серьезным препятствием для масштабирования.

В компании Tokutek придумали и сделали так называемые индексы на фрактальных деревьев (фрактальные -- не от фракталов, а от fraction -- частей), которые свободны от перечисленных выше недостатков. Это несколько напоминает Log Structured Merge-Trees, но лучше. Как работает, можно понять из этой презентации.
kaipa: (Default)
Классический пример, но мне понравилось.

Time flies like an arrow. Fruit flies like a banana.

Google Translate: Время летит, как стрела. Плодовые мушки, как банан.
Яндекс-Переводчик, то же самое: Время летит, как стрела. Плодовые мушки, как банан.
Переводчик MacOS, некоторые вариации и без запятых: Время летит как стрелка. Фруктовые мухи как банан.
Translate.ru, пытается поразить эрудицией: Время летит как стрела. Дрозофилы как банан.
Webtran.ru, добавили запятые, но мушка стала мухом: Время летит, как стрела. Дрозофил, как банан.

Все, сдаюсь.

Интересно, что разницу между time flies и fruit flies понимают все, хотя я могу представить летающий фрукт, но что like может быть и союзом и глаголом -- никто. Почему?

Еще пара экспериментов, Гугл:
Fruit flies to the basket: Плодовые мушки к корзине
Fruit flies into the basket: Фрукты летят в корзину

Ага, все же может, если захочет.

Яндекс на оба варианта выдал обреченно: Плодовые мушки в корзину.

Мне не удалось из переводчиков "выжать" вариант, где like бы использовался в качестве глагола. Почему все так грустно? Мне казалось, что машинный перевод сильно продвинулся за последнее время.
kaipa: (Default)
Редкая хорошая новость.
http://www.rg.ru/2013/12/30/vznos-dok.html
http://biz.cnews.ru/news/2013/12/30/prezident_rossii_podpisal_zakon_o_lgotah_dlya_malyh_itkompaniy_555440

Вкратце, если раньше, чтобы платить 14% налогов в бюджет (фонды соц.страха) вместо 30.2%, ИТ-компаниям надо было иметь минимум 30 сотрудников, то теперь порог снижен до 7. Небольшие стартапы и просто небольшие компании теперь вполне могут воспользоваться льготами. Это все еще дороже, чем ИП, но имеет свои преимущества.

Зарплаты же в ИТ продолжают расти хорошими темпами, что необходимо доносить до руководства :)
http://www.eg-online.ru/news/234949/

HighLoad++

Oct. 30th, 2013 07:40 pm
kaipa: (Default)
Как и объявлял, выступил вчера на HighLoad++. Подготовка давалась тяжело, материал не ложился, и окончательную версию я закончил в 4 утра в день выступления. Но все прошло хорошо. Мой доклад стоял последним, никто не подпирал, и после выступления я минут 40, если не больше, отвечал на хорошие и интересные вопросы. Я встретил однокурсника, которого не видел лет 15, он сделал мне комплимент, что это один из лучших докладов. Заслужено или нет -- не знаю. Еще мне повезло с залом. Там всего три зала, выступления идут параллельно, мой зал был на 450 человек, но вытянутый поперек. То есть прямо передо мной сидело не более 100-120 человек, остальных я почти не видел, они смотрели презентацию через огромные мониторы и слушали трансляцию. Но вопросы потом тоже задавали.

Сама конференция стала еще лучше. В частности, гораздо лучше стал вайфай и обед :) Из интересного, поболтал с Сысоевым, он поделился, что он делает в nginx 2.0 (передавать не буду -- возможно, что это секрет). Очень понравилось выступления Monty. Да-да, того самого, автора MySQL. Сильно немолодой, с плохим английским произношением и плохими слайдами -- но как же он искренне болеет за MySQL и его нынешнюю дочку -- MariaDB! Он рассказывал про историю MySQL и MariaDB, про текущее состояние MariaDB и планы, про то, как они организовывают бизнес. Нелегко, на самом деле. Но они смогли собрать ключевых разработчиков и саппортеров из бывшей MySQL команды, поэтому не будет преувеличением сказать, что MariaDB -- это "настоящий" MySQL, а оракловская версия -- левый брэнч. А вовсе не наоборот :)

А вот Петя Зайцев разочаровал. Его выступление по уровню материала скорее подходило либо полным чайникам, либо IT-директорам, чем специалистам по высоким нагрузкам. Все очень правильно, но очень примитивно. Многие остались разочарованными. Я ничего особенного не ждал, поэтому не разочаровался. А еще у меня возникло некоторое дежавю -- он нас консультировал, когда Перкона только начиналась (где-то в 2007 году), и говорил те же самые слова, хотя и с меньшим апломбом. Мне даже кажется, что первый слайд (очень-очень правильный) он с тех пор не поменял. Хорошее, вечное.

Как всегда хорошо выступил [livejournal.com profile] levgem. Хотя, когда Максим отвечал на вопросы, то у него был странный вид: смесь некоторой нервной неуверенности с раздражением, типа достали уже своими дурацкими вопросами, подумайте хоть немного своей головой :)

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

Profile

kaipa: (Default)
kaipa

April 2017

S M T W T F S
       1
2345678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 04:44 pm
Powered by Dreamwidth Studios