[Перевод] Как сделать многослойную Parallax иллюстрацию на CSS & JavaScript

Мнение: Почему стоит изучать и использовать Clojure

Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы в «Латере» развиваем биллинг для операторов связи «Гидра» и тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.

Итак, почему стоит изучать Clojure и использовать его в реальных проектах?

Не только Ruby и RoR

По словам Джеффа Лэйна, написавшего пост в блоге Gaslight, с помощью Clojure его команде удается решать задачи, которые не по плечу Ruby. Он иллюстрирует этот тезис словами одного из основателей Gaslight Дуга Алкорна:

«Я уверен, что нельзя держаться за один язык программирования вечно. Придет время, когда Ruby уступит место новому языку. Потому что изменится сама среда. Я лишь надеюсь, что тот, кто займет этот трон, будет лучше и милосерднее».

Лэйн говорит, что в компании все еще трепетно относятся к Ruby. Здесь все еще считают Rails лучшим решением для написания веб-приложений. Но, как и у любого инструмента, у него есть свои ограничения:

• Ruby — не лучший выбор для многопоточного программировании, несмотря на существование JRuby и наличие библиотек вроде Celluloid.
• Ruby и Rails почти всегда достаточно быстры. Почти, но не всегда.
• Объектно-реляционное отображение (ORM) может не подходить для решения конкретных задач.
• Объектно-ориентированные языки — это в принципе не всегда лучшее решение.

Функциональное программирование как альтернатива

В свою очередь, функциональное программирование — это совершенно иной образ мышления. Заглянем в Википедию:

«Функциональное программирование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних».

Функциональные языки в отличие от объектно-ориентированных Ruby и JavaScript предлагают совершенно иной подход к решению задач. Изучение этого подхода позволяет приобрести новые знания, которые будут недоступны, если постоянно находиться в комфортных условиях уже знакомых языков программирования, убежден Лэйн.

Clojure работает на сервере
Возьмем описание работы языка с сайта Clojure.org:

«Clojure достигает своих целей, четко следуя стандартам индустрии и используя открытую платформу JVM. Это модернизация хорошо знакомого Lisp. Он обеспечивает функциональное программирование стабильными и устойчивыми структурами данных. Предоставляет встроенную поддержку многопоточного программирования с помощью софта для транзакционной памяти и асинхронных агентов. Clojure — это быстрые и надежные решения ваших задач».

Итак, Clojure работает на виртуальной машине Java (JVM), а значит, обладает несомненными преимуществами, которые предлагает этот инструмент:

• высококачественный сборщик мусора;
• высокопроизводительные встроенные потоки;
• портативность.

Clojure можно использовать везде, где необходимы современные эффективные стабильные структуры данных. Он также вводит новую модель многопоточного программирования с core.async. И потом, сейчас разработаны многие другие полезные библиотеки для логического программирования, сопоставления по образцу, option-типов и многое другое, в чем не лишне было бы попрактиковаться.

Clojure работает в браузере
Еще одна цитата. Вот как описывает преимущества языка ClojureScript Wiki:

«Платформа для разработки с хорошей портативностью, широким охватом и мульти-вендорной поддержкой. Проработанный инструментарий для создания более качественных и надежных приложений, совместимый со всеми новыми устройствами».

ClojureScript легко компилируется в JavaScript и запускается в браузере. Все это обеспечивает совершенно новый подход к созданию клиентских приложений. В сообществе разработчиков JavaScript по многим причинам недолюбливают. Clojure же можно назвать вполне самостоятельным отпрыском Lisp, удобным, лаконичным языком с отличной асинхронной поддержкой, пишет Лэйн. Он может взаимодействовать с другими библиотеками JavaScript. Это позволяет использовать один и тот же язык для клиентской и серверной части, избегая ненужных жертв и потери времени.

Обеспечение полного сохранения текущих состояний (statefullness) в приложениях для клиентов – штука непростая. И пока JavaScript-фреймворки (например, React или Ember) только подступаются к этой проблеме, стоит задаться вопросом – а не сменить ли кардинально сам подход? Возможно, найдется язык в пару к одному из этих фреймворков, способный научить нас лучше управляться с подобными сложностями.

Безусловно, не существует универсального инструмента, который бы подходил для решения всех типов задач. Однако тот факт, что Clojure можно использовать «по обе стороны баррикад» клиент-серверного взаимодействия — его несомненное преимущество.

Игра на опережение

Лэйн цитирует также великого хоккеиста Уэйна Гретцки:

«Как у меня это получается? Я просто всегда стараюсь быть там, где в следующее мгновение окажется шайба, а не там, где она уже побывала».

Clojure позволяет заполнить некоторые пробелы в процессе создания специфических типов приложений. Тех из них, которые нуждаются в высокой скорости обработки больших объемов информации. Эра многоядерных процессоров уже давно началась, но большинство традиционных языков программирования до сих пор не приспособлено к такой архитектуре, убежден Лэйн. Функциональное программирование способно снять эту проблему при написании софта. Clojure обладает всем необходимым инструментарием, для того чтобы позволить программистам эффективно работать с большими массивами данных. Фактически, упорядочивать и преобразовывать данные можно в режиме реального времени.

Без лишней инновационности

В мире технологий иногда возникают вещи настолько передовые и новые, что польза от них не очевидна — хоть когда-то в будущем и может быть существенной — а применение несет в себе большие риски. Для обозначения таких технологий придумали специальный термин — «bleeding edge». Работать с ними комфортно только любителям всего нового.

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

Фундамент Clojure — хорошо знакомые технологии, например та же JVM, работа над которой ведется более 15 лет. Поэтому, работая с Clojure, можно использовать и все высококачественные библиотеки Java, существующие на данный момент.

Любопытство — двигатель прогресса

Ну, и самый последний аргумент «за» изучение Clojure — это любопытство и желание узнавать нечто новое. Всегда есть желание быть на передовой, владеть и уметь обращаться с лучшими технологиями на рынке. Clojure идеально подходит для этих целей. Всегда интересно ставить перед собой новые задачи. А находить для них решения – ни с чем не сравнимое удовольствие.

Сейчас в Латере мы используем Clojure выполнения команд по управлению оборудованием. Специфика задачи заключается в требованиях к одновременности при исполнении команд и гибких ограничениях. С одной стороны нельзя «завалить» одно устройство командами, с другой стороны — исполнять все команды последовательно неэффективно, потому что они могут параллельно исполняться на различном оборудовании. Эта задача с легкостью решается библиотекой core.async, которая добавляет поддержку go-блоков и каналов, знакомых по языку Go, где с помощью них реализованы взаимодействующие последовательные процессы (термин, больше известный как CSP).

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

Даже если вы на дух не переносите Lisp, вам стоит ознакомиться с концепциями, которые заложены в язык, многие из них заставляют по-новому взглянуть на программирование.

Let's block ads! (Why?)

Релиз Lazarus 1.6

[recovery mode] Защита платежной инфраструктуры банка

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

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

В целях минимизации рисков возникновения ущерба от реализации различных киберугроз, кредитным организациям, а также платежным клиринговым и операционным центрам платежных систем необходимо усилить контроль за применением организационных мер и технических средств защиты информации, обусловленным требованиями по информационной безопасности, разработанных и утвержденных Банком России, в частности, Положения №382-П. В частности Банк России рекомендует при эксплуатации объектов информационной инфраструктуры, используемых при взаимодействии с платежными системами, включая платежные системы, в рамках которых осуществляются переводы денежных средств с использованием платежных карт, обеспечивать:

• контроль доступа к объектам платежной инфраструктуры лиц, осуществляющих их эксплуатацию и обслуживание, а также предоставление прав доступа к объектам исключительно для выполнения должностных обязанностей;
• сегментацию ЛВС и размещение объектов платежной инфраструктуры в выделенных сегментах ЛВС;
• контроль сетевой активности, в том числе обращения к прокси-серверу, контроль конфигурации межсетевых экранов, а также, в случае наличия, применение средств обнаружения и предотвращения вторжений;
• мониторинг появления признаков нештатного функционирования платежной инфраструктуры, проявляемой как на прикладном, так и на сетевом уровне;
• контроль функционирования и регулярного обновления программного обеспечения, предназначенного для защиты информации, в том числе средств защиты от воздействия вредоносного кода.

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

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

Однако внедрение механизмов защиты на уровне сетевой инфраструктуры всегда было сопряжено с рядом трудностей, заключающихся в необходимости вручную настраивать десятки и сотни списков контроля доступа (Access Control List, ACL) на каждом сетевом устройстве, которое могло еще и отличаться (пусть и незначительно) по своим командам. При увеличении числа устройств и динамичности защищаемой среды, это превращалось в ночной кошмар специалистов, отвечающих за обслуживание сетевой инфраструктуры.

Технология Cisco TrustSec и система мониторинга и управления ею — Cisco Identity Service Engine (ISE) сняли всю остроту проблему, полностью автоматизировав все рутинные задачи по настройке безопасности инфраструктуры. В частности с помощью Cisco ISE задается ролевая матрица доступа работников банка (или групп работников) к объектам и группам объектов платежной инфраструктуры, которая сама, без участия ручного труда, транслируется в настройки конкретной модели коммутатора или маршрутизатора. При этом Cisco ISE еще и следит за актуальностью текущих настроек сетевого оборудования и их соответствием принятой политики безопасности.

Но сегментировать сеть, локализовав инциденты ИБ, а также управлять доступом к объектам платежной инфраструктуры недостаточно. Необходимо в реальном времени мониторить все в ней происходящее и оперативно реагировать на любые нештатные ситуации и явные проявления действий злоумышленников. Однако применить традиционные подходы в виде установки систем предотвращения вторжения или антивирусов на объекты инфраструктуры внутри нее получается не всегда. Либо сегмент в принципе не допускает установки системы обнаружения вторжений, либо SPAN-порт на коммутаторе уже занят, либо сервер уже загружен платежным приложением и на него нельзя поставить антивирус. В конце концов нельзя забывать и про принцип экономической целесообразности — хоть банк и владеет крупными денежными суммами, это еще не значит, что он может их не глядя тратить на обеспечение безопасности своей и своих клиентов. Нужен здоровый баланс между безопасностью и ее стоимостью.

Cisco предлагает такое сбалансированное решение в виде Cyber Threat Defense, которое позволяет мониторить аномалии внутри сети банка путем анализа NetFlow, собираемого с сетевого оборудования. Изначально разработанный для обнаружения проблем в сети, протокол NetFlow может быть использовать и для целей безопасности, что и было применено в Cisco Cyber Threat Defense. Используя каждый коммутатор или маршрутизатор в качестве сенсора системы обнаружения вторжений, мы можем сэкономить на системе защиты, внедрив только систему сбора и анализа данных с точки зрения безопасности. По сути, мы превращаем всю сеть в систему мониторинга аномальной активности.

Но что делать с банкоматами, компьютерами операционистов, серверами, которые не поддерживают NetFlow? Для решения этой задачи компания Cisco разработала новый протокол zFlow, который предназначен именно для мониторинга аномалий на уровне оконечных устройств. Будучи реализованным в защитном агенте Cisco AnyConnect, данный протокол может собирать информацию о происходящем на прикладном уровне платежной инфраструктуры и передавать эту информацию в решение Cyber Threat Defense для корреляции с аномалии на сетевом уровне, собираемых с помощью NetFlow.

Уже упомянутые Cisco ISE и Cisco AnyConnect позволяют реализовать и еще одну задачу, рекомендованную Банком России в своем обзоре для повышения защищенности платежной инфраструктуры. Речь идет о контроле функционирования средств защиты, в том числе и средств противодействия вредоносному коду. Нередка ситуация, когда компьютеры, подключающиеся к сети банка, либо не имеют средств защиты вовсе, либо эти средства не работают, либо на них устаревшая конфигурация или неактуальная антивирусная база. Что делать в этом случае? Пускать такие устройств в сеть или блокировать им доступ? Если пускать, то кто возьмет на себя ответственность, если инцидент начнется именно по причине несоответствия настроек подключаемого узла требованиям политики безопасности? У Cisco есть технология, которая поможет и в этом случае — речь идет о Network Admission Control или NAC, которая и позволяет контролировать доступ устройств, опираясь на их оценку соответствия установленным в конкретной организации правилам. При первом подключении (а также через заданные интервалы) компьютера, банкомата, PoS-терминала, сервера или даже IP-телефона, камеры видеонаблюдения или турникета СКУД к сетевой инфраструктуре, система Cisco ISE проверяет наличие установленных патчей, длины используемых паролей, включения шифрования жесткого диска, актуальной версии базы антивируса, наличие VPN-клиента или иного защитного агента и после прохождения всех проверок разрешает им подключение к платежной инфраструктуре. В случае невыполнения какого-либо из “тестов” устройство может быть помещено в карантин, где в автоматическом или автоматизированном режиме оно будет приведено в полное соответствие с требованиями политик, после чего его доступ будет разрешен. Такой механизм NAC позволяет обеспечивать не просто регулярное обновление средств защиты, в т.ч. и противодействия вредоносному коду, но и контролировать текущее состояние этих средств.

Последней актуальной задачей, определенной Банком России в своем обзоре, является мониторинг признаков нештатного функционирования платежной инфраструктуры. Помимо уже названного Cisco Cyber Threat Defense данная задача может быть решена с помощью других технологий и решений Cisco, позволяющих мониторить различные аномалии:

• Cisco OpenDNS обнаруживает аномалии в DNS-трафике, в котором вредоносный код часто скрывает получаемые извне команды, а также отправляемые наружу данные из скомпрометированного узла или сегмента.
• Cisco Cognitive Threat Analytics обнаруживает признаки нештатного поведения в логах прокси-серверов.
• Cisco Advanced Malware Protection обнаруживает вредоносную активность в файлах, попадающих внутрь платежной инфраструктуры по различным каналам — электронная почта, Web-трафик, FTP-трафик, передача через расшаренные ресурсы и т.п.
• Cisco FirePOWER Services обнаруживает вредоносную активность “на лету” в сетевом трафике, проходящем через маршрутизаторы, межсетевые экраны или системы предотвращения вторжения.

К сожалению, мы вынуждены признать, что серебрянной пули в области информационной безопасности не существует и одним решением, даже самым лучшим, проблему не решить. И это не от желания производителя продать побольше своих решений. Просто угрозы сегодня настолько разноплановы, а сети настолько динамичны и построены на разных принципах, что единого решения просто не может существовать. Еще в 98-м году, когда я занимался решениями ISS, в их презентациях в качестве будущей и желаемой многими безопасниками системы защиты рисовалась одна кнопка “Вкл” (без возможности “Выкл”). С тех пор прошло почти 20 лет, а этой кнопки так и не появилось. Поэтому и приходится использоваться разные подходы, разные технологии, разные решения для защиты от современных угроз и выполнения всех нормативных требований. И одним межсетевым экраном и антивирусом, как это было раньше, уже не обойтись…

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

Let's block ads! (Why?)

[Из песочницы] Автоматизация кадровых изменений на PowerShell

Сказ царя Салтана о потенциале лапласиана

«Три девицы под окном пряли поздно вечерком.»

Ну как пряли. Не пряли, конечно, а лайкали друг на друга. По условиям конкурса «мисс Салтан» девицы должны были выбрать меж собой лучшую.

«Какой-то странный конкурс», — беспокоились девицы. И это было правдой. По правилам конкурса вес лайка участника зависел от того, сколько лайков он получает от других. Что это значит, — никто из девиц до конца не понимал.
«Как все сложно», — тосковали девушки и подбадривали себя песней «Кабы я была царицей».

Вскоре «в светлицу вошел царь — стороны той государь» (показан на рисунке). «Во все время разговора...», — ну понятно в общем.
«Собираем лайки нежности — формируем матрицу смежности», — бодро срифмовал он.
Девицы-красавицы с именами Алена, Варвара и Софья засмущались, но лайки (из балалайки) передали.

Вот что там было:

• Алена получила 1 лайк от Софьи и 2 лайка от Варвары.
• Варвара получила по лайку от Алены и Софьи.
• А Софья получила 2 лайка от Алены и 1 от Варвары.

Царь взял лайки, покрутил гайки, постучал по колесам, пошмыгал носом, причмокнул губами, поскрипел зубами, сгонял в палаты и объявил результаты.

Наибольший вес лайков (7 баллов) получила Софья, но титул «мисс Салтан» достался Алене (15 баллов).

Подробнее о матрице лайков

Для матрицы

вектор потенциалов равен (5, 4, 7), а вектор потоков — (15, 12, 14).

После объявления результатов девицы бросились обратились к царю с просьбой рассказать,- откуда взялись эти странные цифры?

1. Уравнение баланса

В основе нашего мира лежит баланс. Это означает, что если в одном месте что-то прибыло, то в другом месте столько же убыло.

Физики демонстрируют данный баланс уравнением непрерывности для сплошных и непрерывных сред. Но в современном мире рулят танковые клинья дискретные системы — графы.

У графа есть узлы, через которые течет поток (ну как течет — толчками и нерегулярно). Принцип баланса прост — в узле графа остается разница между тем, сколько из него вытекло и сколько в него втекло. А куда течет поток из узла? Правильно — в другие узлы, соответственно втекает поток в узел тоже из других узлов.

Запишем это множество слов формулой:

Здесь обозначает количество входящего потока в i-й узел, — количество исходящего из узла потока, — изменение остатка в узле.

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

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

В многих ситуациях (в частности с нашим конкурсом оценок) учет остатка в узле не нужен. То есть он всегда нулевой — сколько втекло — столько и вытекло. Игра с нулевой стоимостью нулевым остатком. Для таких систем уравнение упрощается:

Круто. Но пока малополезно.

Баланс потенциалов

Когда мы говорили о том, что поток может течь из узла i в узел j, мы подразумевали, что есть некая связь между данными узлами. Иначе потоку просто не по чему течь. Связность узлов графа обычно называют матрицей смежности (связности), ее элементы обозначают через . Применительно к потокам матрицу смежности также называют матрицей проводимости. Ее элементы отражают пропускную способность ребер графа.

Есть связь — есть поток, нет связи — нет потока. Логично предположить, что чем сильнее связь — тем больше поток.
Итак, поток между узлами пропорционален величине связи узлов. Но чему равен коэффициент пропорциональности?

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

Связь потока с потенциалами и проводимостью выражается простой формулой:

Подставляя (1.3) в уравнение баланса (1.2) получаем систему уравнений для расчета потенциалов узлов:

В данном уравнении известными являются проводимости, а неизвестными — потенциалы.
Количество уравнений в системе равно количеству узлов графа. Решение системы балансовых уравнений является прямой задачей расчета потенциалов (и потоков) графа.

В уравнении (1.4) мы использовали понятие общей проводимости исходящих из узла связей — степень узла:

Рейтинги и самооценки

«Все это здорово,» — сказали девушки, зевая. — «Но причем тут лайки?»

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

Связываем с потоками. Когда i-й участник с весом голоса оценивает j-го участника с оценкой (количеством лайков) то он делится с ним своим потоком . Копить остатки тут ни к чему, поэтому каждый участник делится с остальными всем, что получил.

Вес голоса участника — это потенциал , матрица лайков — это матрица смежности (связности), а итоговая оценка — суммарный полученный (он же отданный) поток .

Для ранжирования участников (определения лучших) нам надо решить уравнение баланса (1.4), то есть определить веса участников, которые сбалансируют систему.

2. Лапласианы

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

Помню «вау-эффект», когда я узнал о том, что есть и другой способ расчета потенциалов, о котором, видимо, знали еще наши деды Лаплас и Кирхгоф. Способ основывается на свойствах матриц-лапласианов. Тут уже недавно вспоминали лапласианы в непрерывных средах. Дискретные лапласианы не менее интересны и важны.

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

Тут можно посмотреть лапласиан от наших лайков

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

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

Лапласианы могут быть симметричными — в них потенциалы всех узлов равны между собой — для нашей задачи они пока неинтересны.

Матрица Кирхгофа относится к классу лапласианов.

Потенциалы лапласианов

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

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

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

Итак, если обозначить через дополнительный минор матрицы, то определение потенциала лапласиана можно записать как

Так вот эти потенциалы 1-го порядка от матрицы Кирхгофа и являются искомым решением уравнения (1.4).
Удивительно. Не нужны никакие циклы, начальные присваивания, произведение матриц и пр. Удалил строку/колонку, посчитал определитель — получил ответ.

Свойства потенциалов 1-го порядка

• Потенциал узла представляет собой сумму произведений (кортежей) проводимостей ребер графа по всем возможным путям в данный узел, исключая контуры (циклы).
• Количество множителей в произведении на 1 меньше размерности (количества узлов) графа.
• Потенциал узла не зависит от проводимостей исходящих из него дуг.
• Каждый кортеж (путь) в выражении для потенциала узла состоит из дуг, которые исходят из всех узлов, кроме данного. В одном кортеже нет двух дуг, исходящих из одного узла, но могут быть дуги, входящие в один узел.
• В каждом кортеже (пути) обязательно присутствует дуга, входящая в узел (замкнутость).
• В выражении для потенциала отсутствуют кортежи, содержащие циклы (контуры).
• Количество кортежей в выражении для потенциала определяется известной формулой Кэли , и быстро растет с ростом узлов графа. Для 4-х узлов имеем 4^2 = 16 слагаемых, для пяти — 5^3 = 125 и т. д.
• В симметричном графе потенциалы всех узлов равны – следствие того, что структура выражения для потенциалов всех узлов одна и та же (разница лишь в направлении).

Графическая структура потенциала графа из 4-х узлов

Демонстрирует комбинаторную сущность выражения для потенциала.
http://ift.tt/1X3gDql

Для определения потока через узел достаточно умножить потенциал узла на его степень:

Мы получили, что хотели.

Считаем лайки

Для расчета веса голоса (потенциала) участника вычеркиваем соответствующую строку и столбец и считаем определитель. Получаем 3 потенциала:

Это вес голоса каждого участника. Теперь считаем потоки и определяем, кто сколько голосов набрал:

Алена набрала больше всех голосов.

Как считать потенциалы больших графов

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

• В матрице лапласиана заменяем первую строку на вектор (1, 0, 0, ...).
• Считаем обратную матрицу от полученной и находим ее детерминант.
• Делим значения первой колонки полученной обратной матрицы на ее детерминант. Это и есть искомый вектор потенциалов. В первой строке — потенциал первого узла, во второй — второй и т. д.
• Если абсолютное значение потенциала неважно, то считать и делить на детерминант необязательно.

Ранжирование объектов на основе потенциалов и потоков

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

Что именно должно служить основанием для ранжирования, — потенциалы или потоки,- требует отдельного рассмотрения в каждой задаче, поскольку определяется прикладным аспектом.

Результаты турниров

Рассмотрим применение системы ранжирования применительно к определениям итогов шахматного турнира. Справедлива ли нынешняя система определения победителя простой суммой очков? На наш взгляд, она имеет лишь одно достоинство — простота. Но в век смартфонов кого волнует простота?
Несправедливо то, что выигрыш сильного по сути приравнивается в «простой системе» выигрышу у слабого.

Современный и правильный подход — считать взвешенные очки, то есть использовать расчет потенциалов и потоков. Еще один плюс — при данной системе практически исключена дележка мест — не надо думать о том, что делать при равенстве очков.

Как раз недавно в Москве закончился турнир претендентов (поздравляем Сергея Карякина с победой!), по итогам которого большое количество участников поделило места (2-3, 4-7). Используя метод потенциалов, попробуем разобраться, кто же какое место занял на самом деле.

Результаты турнира — это матрица смежности графа. В терминах лайков проигрыш участника — это проставление лайка победителю (хотя и звучит немного непривычно). От проигравшего к победителю идет поток взвешенных очков.

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

Для интересующихся подробностями

Мы нормировали потенциалы и потоки так, чтобы их сумма была равна 100.

	Сергей Карякин	Хикару Накамура	Аниш Гири	Виши Ананд	Веселин Топалов	Левон Аронян	Фабиано Каруана	Петр Свидлер
U	17,8	11,4	12,5	13,7	6,4	12,0	13,8	12,4
J	14,5	11,8	13,0	13,2	9,0	12,4	13,3	12,8
М	1	7	4	3	8	6	2	5

Каруана все-таки второй, а Гири — 4-й.

Потенциалы пьяницы

Последний пример, который мы рассмотрим в данной статье — это расчет ценности карт в народной игре «Пьяница».
Спасибо за данный пример astgtciv. Без его статьи, возможно, не было бы и этой.

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

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

Ключевая особенность — в правом нижнем углу — «шестерка бьет туза».
Тогда матрица Кирхгофа будет иметь вид:

Теперь наглядно видно, почему потенциал «шестерки» равен (n-2)! Потому что вычеркнув колонку и столбец шестерки, мы получаем треугольную матрицу, определитель которой считается простым умножением элементов главной диагонали.
То же самое справедливо и для туза с той лишь разницей, что у него в составе множителей два раза встречается элемент (n-2). Поэтому сразу видно, что потенциал туза всегда в (n-2) раза больше потенциала шестерки.

Сводка формул

Выражения для потенциалов от туза до шестерки:

Интересно, что сумма потенциалов всех карт (кроме шестерки и туза) равна потенциалу туза:

Заключение

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

Пришла и нам пора закругляться. Используйте потенциалы!

Let's block ads! (Why?)

Облачный сервис для мониторинга массивов HPE 3PAR StoreServ

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

HPE предоставляет своим заказчикам и партнерам такую возможность. Фактически вам достаточно зайти на портал http://ift.tt/1VfU1UM, зарегистрироваться, зарегистрировать свои массивы (если вы владелец СХД) и, при желании, предоставить доступ к определенной информации о массиве своему сервисному партнеру. И все. Вы получаете в свое распоряжение удобный и мощный инструмент для мониторинга и анализа работы массива, и заметьте, совершенно безвозмездно.

Посмотрим, что же реально дает этот сервис. При входе вы видите основную панель управления со следующей информацией:

— Ёмкость массива и наличие свободной емкости;
— Эффективность использования дисковых ресурсов (учитывается экономия дисковых ресурсов за счет применения таких технологий, как Thin Provisioning и дедупликация);
— Типы накопителей, их кол-во и утилизация по емкости;
— Информацию о состоянии массива (наличие различного рода (Serious, Normal, Warning, Unknown) предупреждений);
— Модель массива;
— Версия микрокода.

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

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

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

• Анализ тенденции изменения емкости массива. Согласитесь, при использовании технологии Thin Provisioning очень важно знать, когда примерно аллокированная дисковая емкость сравняется с физической емкостью массива.

  

  Или тоже самое, но с разбивкой по различным уровням хранения: SSD, NL, FC (First Class – т.е. диски 10k и 15k rpm).

  

• Анализ изменения производительности массива со временем и определение периодов пиковых нагрузок. На данном графике показано только время отклика, аналогичные графики могут быть получены и для таких показателей производительности, как IOPs, MB/s, глубина очереди, размер блока ввода/вывода.

  

• Анализ нагрузки на различные типы накопителей – можно посмотреть не являются ли какие-то накопители чрезмерно нагружены.

  
  

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

Может возникнуть законный вопрос: какие массивы можно мониторить с помощью данного сервиса? Требований всего два: массив должен находиться на поддержке и должен быть подключен к системе call-home, которая позволяет передавать информацию о массиве (system health information, configuration data, performance data, system events) в HPE 3PAR Central.

В заключение хочу добавить, что этот сервис можно использовать и для мониторинга дисковых библиотек HPE StoreOnce. Поддержка различных СХД облачным сервисом НРЕ StorefrontRemote будет расширяться.

Let's block ads! (Why?)

Немного о сокетах, redis и битых яйцах

Big Data от А до Я. Часть 4: Hbase

Привет, Хабр! Наконец-то долгожданная четвёртая статья нашего цикла о больших данных. В этой статье мы поговорим про такой замечательный инструмент как Hbase, который в последнее время завоевал большую популярность: например Facebook использует его в качестве основы своей системы обмена сообщений, а мы в data-centric alliance используем hbase в качестве основного хранилища сырых данных для нашей платформы управления данными Facetz.DCA

В статье будет рассказано про концепцию Big Table и её свободную реализацию, особенности работы и отличие как от классических реляционных баз данных (таких как MySQL и Oracle), так и key-value хранилищ, таких как Redis, Aerospike и memcached.
Заинтересовало? Добро пожаловать под кат.

Кто и зачем придумал Hbase

Как обычно — начнём с истории вопроса. Как и многие другие проекты из области BigData, Hbase зародилась из концепции которая была разработана в компании Google. Принципы лежащие в основе Hbase, были описаны в статье «Bigtable: A Distributed Storage System for Structured Data».

Как мы рассматривали в прошлых статьях — обычные файлы довольно неплохо подходят для пакетной обработки данных, с использованием парадигмы MapReduce.

С другой стороны информацию хранящуюся в файлах довольно неудобно обновлять; Файлы также лишены возможности произвольного доступа. Для быстрой и удобной работы с произвольным доступом есть класс nosql-систем типа key-value storage, таких как Aerospike, Redis, Couchbase, Memcached. Однако в обычно в этих системах очень неудобна пакетная обработка данных. Hbase представляет из себя попытку объединения удобства пакетной обработки и удобства обновления и произвольного доступа.

Модель данных

Hbase — это распределенная, колоночно-ориентированная, мультиверсионная база типа «ключ-значение».
Данные организованы в таблицы, проиндексированные первичным ключом, который в Hbase называется RowKey.
Для каждого RowKey ключа может храниться неограниченны набор атрибутов (или колонок).

Колонки организованны в группы колонок, называемые Column Family. Как правило в одну Column Family объединяют колонки, для которых одинаковы паттерн использования и хранения.

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

Записи физически хранятся в отсортированном по RowKey порядке. При этом данные соответствующие разным Column Family хранятся отдельно, что позволяет при необходимости читать данные только из нужного семейства колонок.

При удалении определённого атрибута физически он сразу не удаляется, а лишь маркируется специальным флажком tombstone. Физическое удаление данных произойдет позже, при выполнении операции Major Compaction.

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

Список и названия групп колонок фиксирован и имеет четкую схему. На уровне группы колонок задаются такие параметры как time to live (TTL) и максимальное количество хранимых версий. Если разница между timestamp для определенно версии и текущим временем больше TTL — запись помечается к удалению. Если количество версий для определённого атрибута превысило максимальное количество версий — запись также помечается к удалению.

Модель данных Hbase можно запомнить как соответствие ключ значение:

<table, RowKey, Column Family, Column, timestamp> -> Value

Поддерживаемые операции

Список поддерживаемых операций в hbase весьма прост. Поддерживаются 4 основные операции:

— Put: добавить новую запись в hbase. Timestamp этой записи может быть задан руками, в противном случае он будет установлен автоматически как текущее время.

— Get: получить данные по определенному RowKey. Можно указать Column Family, из которой будем брать данные и количество версий которые хотим прочитать.

— Scan: читать записи по очереди. Можно указать запись с которой начинаем читать, запись до которой читать, количество записей которые необходимо считать, Column Family из которой будет производиться чтение и максимальное количество версий для каждой записи.

— Delete: пометить определенную версию к удалению. Физического удаления при этом не произойдет, оно будет отложено до следующего Major Compaction (см. ниже).

Архитектура

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

Hbase для своей работы использует два основных процесса:

1. Region Server — обслуживает один или несколько регионов. Регион — это диапазон записей соответствующих определенному диапазону подряд идущих RowKey. Каждый регион содержит:

• Persistent Storage — основное хранилище данных в Hbase. Данные физически хранятся на HDFS, в специальном формате HFile. Данные в HFile хранятся в отсортированном по RowKey порядке. Одной паре (регион, column family) соответствует как минимум один HFIle.
• MemStore — буфер на запись. Так как данные хранятся в HFile d отсортированном порядке — обновлять HFile на каждую запись довольно дорого. Вместо этого данные при записи попадают в специальную область памяти MemStore, где накапливаются некоторое время. При наполнении MemStore до некоторого критического значения данные записываются в новый HFile.
• BlockCache — кэш на чтение. Позволяет существенно экономить время на данных которые читаются часто.
• Write Ahead Log(WAL). Так как данные при записи попадают в memstore, существует некоторый риск потери данных из-за сбоя. Для того чтобы этого не произошло все операции перед собственно осуществление манипуляций попадают в специальный лог-файл. Это позволяет восстановить данные после любого сбоя.

2. Master Server — главный сервер в кластере hbase. Master управляет распределением регионов по Region Server’ам, ведет реестр регионов, управляет запусками регулярных задач и делает другую полезную работу.

Для координации действий между сервисами Hbase использует Apache ZooKeeper, специальный сервис предназначенный для управления конфигурациями и синхронизацией сервисов.

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

Так как данные по одному региону могут храниться в нескольких HFile, для ускорения работы Hbase периодически их сливает воедино. Эта операция в Hbase называется compaction. Compaction’ы бывают двух видов:

• Minor Compaction. Запускается автоматически, выполняется в фоновом режиме. Имеет низкий приоритет по сравнению с другими операциями Hbase.
• Major Compaction. Запускается руками или по наступлению срабатыванию определенных триггеров(например по таймеру). Имеет высокий приоритет и может существенно замедлить работу кластера. Major Compaction’ы лучше делать во время когда нагрузка на кластер небольшая. Во время Major Compaction также происходит физическое удаление данных, ране помеченных меткой tombstone.
  

Способы работы с Hbase

Hbase Shell

Самый простой способ начать работу с Hbase — воспользоваться утилитой hbase shell. Она доступна сразу после установки hbase на любой ноде кластера hbase.

Hbase shell представляет из себя jruby-консоль c встроенной поддержкой всех основных операций по работе с Hbase. Ниже приведён пример создания таблицы users с двумя column family, выполнения некоторых манипуляций с ней и удаление таблицы в конце на языке hbase shell:

Простыня кода

create 'users', {NAME => 'user_profile', VERSIONS => 5}, {NAME => 'user_posts', VERSIONS => 1231231231}
put 'users', 'id1', 'user_profile:name', 'alexander'
put 'users', 'id1', 'user_profile:second_name', 'alexander'
get 'users', 'id1'
put 'users', 'id1', 'user_profile:second_name', 'kuznetsov'
get 'users', 'id1'
get 'users', 'id1', {COLUMN => 'user_profile:second_name', VERSIONS => 5}
put 'users', 'id2', 'user_profile:name', 'vasiliy'
put 'users', 'id2', 'user_profile:second_name', 'ivanov'
scan 'users', {COLUMN => 'user_profile:second_name', VERSIONS => 5}
delete 'users', 'id1', 'user_profile:second_name'
get 'users', 'id1'
disable 'users'
drop 'users'

Native Api

Как и большинство других hadoop-related проектов hbase реализован на языке java, поэтому и нативный api доступен для языке java. Native API довольно неплохо задокументирован на официальном сайте. Вот пример использования Hbase API взятый оттуда же:

Простыня кода

import java.io.IOException;

import org.apache.hadoop.hbase.HBaseConfiguration;
import org.apache.hadoop.hbase.TableName;
import org.apache.hadoop.hbase.client.Connection;
import org.apache.hadoop.hbase.client.ConnectionFactory;
import org.apache.hadoop.hbase.client.Get;
import org.apache.hadoop.hbase.client.Table;
import org.apache.hadoop.hbase.client.Put;
import org.apache.hadoop.hbase.client.Result;
import org.apache.hadoop.hbase.client.ResultScanner;
import org.apache.hadoop.hbase.client.Scan;
import org.apache.hadoop.hbase.util.Bytes;

// Class that has nothing but a main.
// Does a Put, Get and a Scan against an hbase table.
// The API described here is since HBase 1.0.
public class MyLittleHBaseClient {
  public static void main(String[] args) throws IOException {
    // You need a configuration object to tell the client where to connect.
    // When you create a HBaseConfiguration, it reads in whatever you've set
    // into your hbase-site.xml and in hbase-default.xml, as long as these can
    // be found on the CLASSPATH
    Configuration config = HBaseConfiguration.create();

    // Next you need a Connection to the cluster. Create one. When done with it,
    // close it. A try/finally is a good way to ensure it gets closed or use
    // the jdk7 idiom, try-with-resources: see
    // http://ift.tt/1GLvdMB
    //
    // Connections are heavyweight. Create one once and keep it around. From a Connection
    // you get a Table instance to access Tables, an Admin instance to administer the cluster,
    // and RegionLocator to find where regions are out on the cluster. As opposed to Connections,
    // Table, Admin and RegionLocator instances are lightweight; create as you need them and then
    // close when done.
    //
    Connection connection = ConnectionFactory.createConnection(config);
    try {

      // The below instantiates a Table object that connects you to the "myLittleHBaseTable" table
      // (TableName.valueOf turns String into a TableName instance).
      // When done with it, close it (Should start a try/finally after this creation so it gets
      // closed for sure the jdk7 idiom, try-with-resources: see
      // http://ift.tt/1GLvdMB)
      Table table = connection.getTable(TableName.valueOf("myLittleHBaseTable"));
      try {

        // To add to a row, use Put. A Put constructor takes the name of the row
        // you want to insert into as a byte array. In HBase, the Bytes class has
        // utility for converting all kinds of java types to byte arrays.  In the
        // below, we are converting the String "myLittleRow" into a byte array to
        // use as a row key for our update. Once you have a Put instance, you can
        // adorn it by setting the names of columns you want to update on the row,
        // the timestamp to use in your update, etc. If no timestamp, the server
        // applies current time to the edits.
        Put p = new Put(Bytes.toBytes("myLittleRow"));

        // To set the value you'd like to update in the row 'myLittleRow', specify
        // the column family, column qualifier, and value of the table cell you'd
        // like to update. The column family must already exist in your table
        // schema. The qualifier can be anything. All must be specified as byte
        // arrays as hbase is all about byte arrays. Lets pretend the table
        // 'myLittleHBaseTable' was created with a family 'myLittleFamily'.
        p.add(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"),
        Bytes.toBytes("Some Value"));

        // Once you've adorned your Put instance with all the updates you want to
        // make, to commit it do the following (The HTable#put method takes the
        // Put instance you've been building and pushes the changes you made into
        // hbase)
        table.put(p);

        // Now, to retrieve the data we just wrote. The values that come back are
        // Result instances. Generally, a Result is an object that will package up
        // the hbase return into the form you find most palatable.
        Get g = new Get(Bytes.toBytes("myLittleRow"));
        Result r = table.get(g);
        byte [] value = r.getValue(Bytes.toBytes("myLittleFamily"),
          Bytes.toBytes("someQualifier"));

        // If we convert the value bytes, we should get back 'Some Value', the
        // value we inserted at this location.
        String valueStr = Bytes.toString(value);
        System.out.println("GET: " + valueStr);

        // Sometimes, you won't know the row you're looking for. In this case, you
        // use a Scanner. This will give you cursor-like interface to the contents
        // of the table. To set up a Scanner, do like you did above making a Put
        // and a Get, create a Scan. Adorn it with column names, etc.
        Scan s = new Scan();
        s.addColumn(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"));
        ResultScanner scanner = table.getScanner(s);
        try {
           // Scanners return Result instances.
           // Now, for the actual iteration. One way is to use a while loop like so:
           for (Result rr = scanner.next(); rr != null; rr = scanner.next()) {
             // print out the row we found and the columns we were looking for
             System.out.println("Found row: " + rr);
           }

           // The other approach is to use a foreach loop. Scanners are iterable!
           // for (Result rr : scanner) {
           // System.out.println("Found row: " + rr);
           // }
         } finally {
           // Make sure you close your scanners when you are done!
           // Thats why we have it inside a try/finally clause
           scanner.close();
         }

         // Close your table and cluster connection.
       } finally {
         if (table != null) table.close();
       }
     } finally {
       connection.close();
     }
  }
}

Thrift, REST и поддержка других языков программирования.

Для работы из других языков программирования Hbase предоставляет Thrift API и Rest API. На базе них построены клиенты для всех основных языков программирования: python, PHP, Java Script и тд.

Некоторые особенности работы с HBase

1. Hbase «из коробки» интегрируется с MapReduce, и может быть использована в качестве входных и выходных данных с помощью специальных TableInputFormat и TableOutputFormat.

2. Очень важно правильно выбрать RowKey. RowKey должен обеспечивать хорошее равномерное распределение по регионам, в противном случае есть риск возникновения так называемых «горячих регионов» — регионов которые используются гораздо чаще остальных, что приводит к неэффективному использованию ресурсов системы.

3. Если данные заливаются не единично, а сразу большими пачками — Hbase поддерживает специальный механизм BulkLoad, который позволяет заливать данные намного быстрее чем используя единичные Put’ы. BulkLoad по сути представляет из себя двухшаговую операцию:

— Формирование HFile без участия put’ов при помощи специального MapReduce job’a

— Подкладывание этих файликов напрямую в Hbase.

4. Hbase поддерживает вывод своих метрик в сервер мониторинга Ganglia. Это может быть очень полезно при администрировании Hbase для понимания сути происходящих с hbase проблем.

Пример

В качестве примера можем рассмотреть основную таблицу с данными, которая у нас в Data-Centric Aliance используется для хранения информации о поведении пользователей в интернете.

RowKey

В качестве RowKey используется идентификатор пользователя, в качестве которого используется GUUID, строчка специально генерируемая таким образом, чтобы быть уникальной во всем мире. GUUID’ы распределены равномерно, что дает хорошее распределение данных по серверам.

Column Family

В нашем хранилище используются две column family:

— Data. В этой группе колонок хранятся данные, которые теряют свою актуальность для рекламных целей, такие как факты посещения пользователем определенных URL. TTL на эту Column Family установлен в размере 2 месяца, ограничение по количеству версий — 2000.

— LongData. В этой группе колонок хранятся данные, которые не теряют свою актуальность в течение долгого времени, такие как пол, дата рождения и другие «вечные» характеристики пользователя

Колонки

Каждый тип фактов о пользователе хранится в отдельной колонке. Например в колонке Data:_v хранятся URL, посещенные пользователем, а в колонке LongData:gender — пол пользователя.

В качестве timestamp хранится время регистрации этого факта. Например в колонке Data:_v — в качестве timestamp используется время захода пользователем на определенный URL.

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

Альтернативы

Hbase довольно сложна в администрировании и использовании, поэтому прежде чем использовать hbase есть смысл обратить внимание на альтернативы:

• Реляционные базы данных. Очень неплохая альтернатива, особенно в случае когда данные влезают на одну машину. Также в первую очередь о реляционных базах данных стоит подумать в случае когда важны транзакции индексы отличные от первичного.
• Key-Value хранилища. Такие хранилища как Redis и Aerospike лучше подходят когда необходима минимизация latency и менее важна пакетная обработка данных.
• Файлы и их обработка при помощи MapReduce. Если данные только добавляются, и редко обновляются/изменяются, то лучше не использовать Hbase, а просто хранить данные в файлах. Для упрощения работы с файлами можно воспользоваться такими инструментами как Hive, Pig и Impala, о которых речь пойдет в следующих статьях.

Checklist по использованию Hbase

Использование Hbase оправдано когда:

— Данных много и они не влезают на один компьютер
— Данные часто обновляются и удаляются
— В данных присутствует явный «ключ» по к которому удобно привязывать все остальное
— Нужна пакетная обработка данных
— Нужен произвольный доступ к данным по определенным ключам

Заключение

В данной статье мы рассмотрели Hbase — мощное средство для хранения и обновления данных в экосистеме hadoop, показали модель данных Hbase, её архитектуру и особенности работы с ней.

В следующих статьях речь пойдет о средствах, упрощающих работу с MapReduce, таких как Apache Hive и Apache Pig.

Ссылки на другие статьи цикла

» Big Data от А до Я. Часть 1: Принципы работы с большими данными, парадигма MapReduce
» Big Data от А до Я. Часть 2: Hadoop
» Big Data от А до Я. Часть 3: Приемы и стратегии разработки MapReduce-приложений

Let's block ads! (Why?)