Эх, раз, да ещё раз,
Да ещё yet another раз…
Не так давно завершилась конференция Яндекс YaC 2011 и теперь, когда стали доступны записи выступлений, я хочу представить вам технический отчёт о её посещении. В отчете я сосредоточился на той информации, которую вы можете получить, посмотрев запись того или иного доклада, и решить стоит ли тратить на это время. Для некоторых тем добавил дополнительные ссылки на ключевые ресурсы, а так же, по мотивам общения с авторами, описал устройства двух NoSQL технологий Яндекса: Elliptics Network и хранилища писем в Яндекс почте.
Итак, Yac 2011, как это было.
Лучи уходящего лета определили начало моего понедельника. Чудесное утро ранней осени, с каждым шагом, улучшало настроение, пока я шёл к зданию Центра Международной торговли, в котором 19 сентября 2011 года проходила уже вторая по счёту технологическая конференция, организованная компанией Яндекс.
Всего год назад Яндекс принял решение ежегодно проводить новую конференцию, скромно названную, Yet another Conference, и «ещё одна конференция» оказалось на голову выше подавляющего большинства тех, на которые можно попасть в окружающем нас пространстве. С одной стороны, качество ключевых докладов и их прямая направленность на состоявшихся технических специалистов установили очень высокую планку для остальных технических конференций, а с другой стороны, Яндекс создал особенную атмосферу тем, что выпустил в свет своих ключевых специалистов и отдал их на «растерзание толпе». Многих докладчиков после выступления окружали желающие пообщаться, и они часами отвечали на вопросы, называли вещи своими именами и выдавали многие секреты, о которых не принято говорить на сцене.
Не менее важно и то, что записи докладов YaC выложены в публичный доступ, и каждый может самостоятельно их посмотреть и оценить. Конечно, видео не позволит вам пообщаться с докладчиком напрямую и узнать всё самое интересное, но, тем не менее, оно предоставляет ценнейший ресурс для самообразования.
Целью данного отчёта не будет пересказ докладов, поскольку, вы сами сможете всё посмотреть. Вместо этого, будет полезнее, кратко рассказать о сути докладов, поделиться своими мыслями и впечатлениями и порекомендовать те доклады, на которые стоит потратить своё время и посмотреть запись. Впрочем в конце я немного отойду от этого правила для того чтобы поделиться тем, что не попало в запись.
Конференцию открыл доклад Андрея Плахова, который был посвящён новой системе, запущенной в конце 2010 года, оценки релевантности ответа на поисковый запрос. Андрей посвятил свой рассказ постановке проблемы неоднозначных запросов и описал её решение в общих принципах.
Яндекс обрабатывает 5 миллиардов запросов в месяц и многие из них составлены таким образом, что даже человеку нелегко понять, что именно хотел узнать пользователь. Например, по запросу Ягуар, варианты ответов могут касаться животного, автомобиля и напитка. Система на основании анализа потока запросов находит возможные расширения текущего запроса, например, «объём двигателя Ягуара» или «содержание спирта в Ягуаре». Среди всех возможных расширений выбираются те, которые соответствуют категории запроса (например, напиток, нечто вредное) и возможным расширениям назначаются веса, исходя из потенциальных потребностей категории. Система содержит ограниченное количество категорий, таких как фильмы, книги, люди, гаджеты и т.п., которые определяются вручную.
Запись доклада стоит посмотреть для общего понимания проблемы неоднозначных запросов и примерных подходов к её решению
Дмитрий Жестилевский, рассказывал о Platform Abstraction Layer (PAL), который разрабатывается в Яндексе. PAL позволяет, без дублирования кода, создавать Native C++ приложения под iOS, Android, Symbian и другие системы. PAL был основан на OpenKODE: наборе открытых стандартов, описывающих программную платформу мобильного устройства. В OpenKODE входят API для взаимодействия с операционной системой OpenKODE Core (во многом копирующие POSIX), OpenGL ES, OpenSL ES и др. В Яндексе реализовали часть стандартов OpenKODE для каждой платформы, другая часть уже была реализована на платформах изначально (например, OpenGL ES) и получили универсальную среду разработки приложений. PAL позволяет написать и отладить код под Windows и сразу скомпилировать его под iOS и Android. Набор стандартов OpenKODE предоставляет богатые возможности, но иногда появляются задачи, для оптимального решения которых, возможностей OpenKODE становиться недостаточно и тогда возникает необходимость в создании собственных расширений OpenKODE.
Стандарт OpenKODE использует язык C и, с одной стороны, логично писать расширения без использования C++, но с другой стороны, со временем, стало понятно то, что создавать интерфейс расширений на чистом C не слишком удобно, когда весь остальной код использует C++. Сейчас расширения представляют собой полноценные C++ объекты и не возникает дополнительная необходимость создания RAII оберток над C кодом.
PAL не уникальная технология Яндекса и другие компании предлагают не менее интересные аналоги. Например, Marmalade SDK, о котором было упомянуто в докладе, предоставляет вполне законченное и, с моей точки зрения, самое перспективное решение. Тем не менее, Яндекс начал писать свою систему, прежде всего потому, что это обеспечивало независимость от сторонних компаний и предоставило неограниченные возможности расширения.
Запись доклада стоит посмотреть для понимания проблем, с которыми столкнулась компания Яндекс, но для изучения подходов к организации PAL, рекомендую изучить сайты посвященные OpenKODE и Marmalade SDK.
Красивое название доклада не могло оставить меня равнодушным, и я, предвкушая, пробрался ближе к сцене. Рассказ был посвящён системе Nigma-Математика, отечественном аналоге Wolfram Alpha. Доклад был посвящён общему описанию структуры сервиса, которая оказалась достаточно типовой.
Доклад стоит смотреть для понимания общих принципов организации веб-сервисов, но если вас интересуют тонкости, то лучше обратитесь к другим ресурсам.
Юрий Береза, ещё один разработчик PAL, рассказывал о тонкостях разработки под Android: вызовах Java из C++ и вызовах C++ из Java, компиляции Boost, особенностях отладки, сборки и др. В итоге у него получился очень полезный с практической точки зрения доклад.
Запись, однозначно, стоит посмотреть тем, кто собирается или уже пишет на C++ под Андройд. Это было одно из самых практически полезных выступлений.
JavaScript не входит в число моих интересов и на данном докладе я коротал время, пока рассосётся первая волна желающих пообедать. Но, тем не менее, кое-что я всё же узнал.
Компания Cloud9 создала IDE для JavaScript, работающую прямо в браузере. Действительно, IDE умеет подсвечивать синтаксис, работать с системами контроля версий, полноценно отлаживаться: ставить точки останова, смотреть значение переменных, callstack и т.д.
Смотрел я, голодный, на всё это торжество HTML 5 и думал о будущем компьютерных технологий, повсеместном интернете, умных устройствах, автопилотах в автомобилях, о термоядерном синтезе для всего этого электронного счастья.
Впрочем, у данного IDE я нашёл один большой «недостаток»: полное отсутствие интеграции с Twitter’ом и Facebook’ом. Поэтому, кто знает, выберет ли программист IDE, разрываясь между такими замечательными сервисами?
Доклад мне показался в значительной степени маркетинговым и поэтому я рекомендую его смотреть только тем, кого действительно заинтересовали возможности проекта.
Это не доклад, это эпос, Одиссея с Рамаяной и Сон в красном тереме с Бхагавад-гитой.
Нет, правда, если бы на тему языков программирования нужно было бы создать что-то нетленное и рассказать за 40 минут, то выглядело бы это примерно так же.
Советую смотреть, обязательно перед сном, в хорошем расположении духа и в рассредоточенном сознании.
Путь стандарта был тернист и долог, но спустя 8 лет мы, наконец, можем сказать, что этот путь завершен. Все привыкли объяснять столь долгий срок сложностями языка, но может, дело совсем не в этом? Может дело во вмешательстве потусторонних сил? Судите сами, докладчика просто не пустили в Россию. И если мы, здесь, давно привыкли жить с нашими потусторонними силами, то, что могут они, члены комитета, супротив такой беды?
Доклад Дейва Абрамса проходил по Скайпу, что само по себе было забавно. Подручные технические ухищрения обеспечили двустороннюю видео связь: с показом слайдов, вопросами в конце и т.п. Дейву, наверное, было странно наблюдать огромную аудиторию снятую камерой небольшого ноутбука, а нам смотреть на человека, выступающего перед большим количеством людей в домашней обстановке.
Разговор шёл о новых возможностях C++, и смотреть видео, учитывая технические проблемы связи, думаю, не стоит. Лучше потратьте своё время на изучение статьи в Википедии, посвящённой C++11.
Юнит тесты будут действительно приносить пользу только в том случае, если они быстрые, надежные и точные. Но как написать юнит-тест системы, зависящий от базы данных, сети или тяжёлых вычислений? Один из ответов на этот вопрос состоит в том, чтобы тестировать только конкретный модуль, а работу всех зависимых модулей эмулировать при помощи Mock-объектов.
Mock – это объект, представляющий собой конкретную фиктивную реализацию интерфейса, предназначенную исключительно для тестирования.
Писать Mock-объект для каждого теста часто может быть достаточно накладно и поэтому возникает желание, каким либо образом автоматизировать данный процесс. Существует множество Mock библиотек для Java, для которой, в силу поддержки интроспекции, написать такие библиотеки значительно проще. И мне казалось, что для C++ никогда не появятся удобные Mock библиотеки, однако Google представил Google Mock.
Сразу после доклада библиотека показалась мне «кадавром, неудовлетворённым желудочно». Судите сами, при помощи шаблонного метапрограммирования был создан свой декларативный язык, на котором описывается поведение Mock-объекта. И возникает вопрос: не придётся ли дольше копаться в документации, в попытке объяснить, что именно должен делать Mock, вместо того чтобы быстро написать, как он должен это сделать?
Первое впечатление прошло после того, как я немного погрузился в документацию Google Mock. Библиотека организованна вполне разумно, проста в изучении и сейчас она мне кажется, по меньшей мере, интересной.
Сложно сказать стоит ли смотреть видео или нет. Мне показалось то, что к синтаксису нужно какое-то время привыкнуть, а докладчик сразу уходит в дебри и портит первое впечатление.
Компания Cloudera специализируется на технологиях, построенных вокруг Hadoop – свободного проекта Apache Software Foundation, предназначенного для хранения и обработки больших объёмов данных на кластерах, состоящих из тысяч отдельных узлов. Hadoop, фактически, является экосистемой, объединяющей несколько отдельных проектов: распределённую файловую систему HDFS, реализацию парадигмы MapReduce, нереляционную базу данных HBase и д.р.
В последнее время популярность Hadoop быстро растёт. Увеличивается количество компаний решающих при помощи Hadoop свои задачи, повышается качество внутренней реализации, и всё большие объемы данных обрабатывают Hadoop кластеры. Обычным делом сейчас становятся кластеры, хранящие до 80 петабайт данных.
Доклад мне показался в некоторой степени маркетинговым и направленным на специалистов, непосредственно работающих с Hadoop, поэтому, думаю, не стоит тратить на него свое время. Вместо этого, рекомендую выступление Константина Швачко из Yahoo, который на прошлой конференции очень интересно рассказал про Hadoop.
Темой доклада снова стал Hadoop, а точнее его модификация, направленная на повышение масштабируемости, которая была создана в компании Facebook. Дело в том, что Facebook использует fork старой версию Hadoop и в какой-то момент решил исправить некоторые проблемы масштабируемости своей системы, которые к тому времени уже были исправлены сообществом в основной ветке.
Доклад был посвящен тому, как именно Facebook исправлял свою систему и будет полезен Hadoop специалистам, но те, кто поверхностно знаком с технологией скорее всего не найдут в докладе ничего полезного.
Доклад лаборатории Касперского начался с элементов вузовского курса Операционные системы, но быстро перешёл к тонкостям устройства BIOS и процесса загрузки ОС. Причём с перечислением значений адресов их функциональности и хитростей, которые использует современное вредоносное ПО.
Весьма специфическая информация, на достаточно глубоком уровне, поэтому я рекомендую смотреть только истинным ценителям, которые знают толк в подобных вещах.
В течение дня в фойе конференции проходила технологическая выставка, где можно было попробовать написать приложение с использованием Yandex Mobile MapKit, посмотреть на новые смартфоны, 3D телевизоры, выиграть какие-то призы – в общем, классический красный уголок маркетинга. Однако среди всех стендов были два, которые меня действительно заинтересовали. Я расскажу о них немного подробнее так, как фактически, докладов, посвященных системам которые на них показывали, не проводилось. На стендах просто отвечали на вопросы проходящих мимо.
Оба стенда были посвящены хранению и обработки больших объёмов данные в NoSQL хранилищах (под термином NoSQL рассматривают не отказ от языка SQL, а хранение информации в базах данных, построенных по модели отличной от реляционной). Реляционные базы данных давно стали самым распространённым способом хранения и обработки значительных объёмов структурированных данных. Тем не менее, быстродействие, целостность, а также удобство разработки прикладных программ на современных SQL СУБД достигается за счёт компромисса с другими немаловажными факторами: масштабируемостью и доступностью. Говоря о SQL СУБД, часто употребляют термин вертикальная масштабируемость, суть которого сводится к тому, что с определенного момента развития проекта, стоимость оборудования при наращивании производительности на одну и ту же величину стремительно возрастает, и, постепенно, становятся непомерно высокой. Ещё хуже обстоят дела с доступностью: отказ одного узла может повлечь остановку сервера на продолжительное время и вылиться крупными финансовыми потерями. Для решения описанных проблем появились системы хранения данных, которые, принося в жертву функциональность, выигрывают в масштабируемости и доступности.
Одним из примеров хранилищ, альтернативных SQL, служит проект Elliptics Network, который в Яндексе используют для хранения фотографий в сервисе Яндекс.Фотки и тайлов в Яндекс.Картах. Elliptics Network относится к классу Распределённых хеш-таблиц (DHT), которые по сравнению с реляционными базами данных предоставляют достаточно скудный набор операций: сохранение и получение неструктурированных двоичных данных по уникальному ключу (такой класс хранилищ называют key-value storages), но при этом обладают рядом уникальных свойств. Кластер Elliptics Network организован по принципу одноранговой (P2P) сети, в которой все узлы выполняют одинаковые операции и ни один узел не выделается среди других. Ключом записи может быть произвольная сущность, по которой можно вычислить хеш-функцию (в данном случае, SHA512). Использование криптостойкой хеш-функции позволяет не рассматривать вероятность её коллизии и снять проблему неуникальных ключей. Кроме того, хранилище может ничего не знать об истинном типе ключа и методе его генерации, то есть выполнять все операции, используя только хеш. Каждый узел в кластере выбирает несколько сегментов из кольца значений хеш-функции, за которые он будет отвечать и модифицирует, глобально доступную (синхронизированную между узлами), таблицу маршрутизации запросов. Клиент, при доступе к данным, генерирует по ключу уникальное хеш-значение, по которому в таблице маршрутизации осуществляется поиск узла, отвечающего за диапазон в который попадает значение. После получения адреса, клиент может напрямую обращаться к узлу и запрашивать от него данные.
Отсутствие централизованных элементов позволяет пропорционально наращивать производительность, путём добавления новых узлов сходной конфигурации. Такой способ масштабируемости, называют горизонтальным. Он позволяет значительно экономить средства и создавать сервисы, функционирование которых было бы невозможным при использовании реляционных баз данных.
Каждый узел в кластере может в любой момент выйти из строя и когда узлов становится достаточно много постоянно возникают ситуация при которых часть узлов недоступна. Для того чтобы при отказе узла не останавливался весь кластер вводят систему репликации. Работа такой системы основана на том, что за один и тот же интервал пространства ключей отвечает сразу несколько узлов и запись происходит синхронно во все доступные реплики. Если все узлы, отвечающие за некоторый диапазон хеш-значений, отказывают, то чтение из этого диапазона становится невозможным, но запись продолжается в узлы, отвечающие за соседние диапазоны. Таким образом, отказ произвольного количества узлов может сделать недоступным для чтения только часть данных и то только тех, для которых вышли из строя все возможные копии (систему обычно настраивают на двойное или тройное резервирование), но при этом невозможность записи возникает только при отказе всех узлов кластера.
Год назад Elliptics Network поддерживала версионность данных, но сейчас её отрезали за ненадобностью. Кроме того, Elliptics Network позволяет использовать интервальные запросы, то есть получить все данные ключ которых лежит в диапазоне от X до Y. Такая функциональность, очевидно, выходит за рамки key-value storages и вмешивается в стройную архитектуру DHT. Реализована она следующим образом: от ключа SHA512 отбрасываются младшие байты и используются, как индекс сортировки. Каждый узел хранит в памяти красно-черное дерево хеш-ключей и, естественным образом, позволяет осуществлять интервальные запросы. Разработчики говорят о том, что они не рассматривают интервальные запросы, диапазон которых, может перекрыть несколько узлов, хотя с моей точки зрения — это может стать проблемой масштабирования, не говоря уже о том, что вмешательство в механизм генерации ключей препятствует равномерному распределению данных по узлам. И, гипотетически, достаточно большой и популярный интервал данных, полностью попадая на одну машину, может запросто затормозить её до полной остановки.
Вокруг Elliptics Network сосредоточено несколько технологий. Библиотека Eblob, которая «работает даже лучше, чем звучит», позволяет организовать на диске хранилище неструктурированных бинарных данных (BLOB’ов) и получить быстрый доступ к ним (обычные файловые системы плохо справляются с нагрузкой в ситуациях, когда количество файлов начинает измеряется в миллионах). Файловая система PohmelFS, созданная на базе Elliptics Network, в которой ключом служит имя файла и добавлены дополнительные механизмы для поддержания целостности, а также PohmelFS совместима со стандартом POSIX и может быть смонтирована, как стандартная файловая система Linux.
Тем не менее, моё отношение к Elliptics Network, хоть и с интересеом, но скорее скептическое. В сущности, о масштабируемости Elliptics Network говорить сложно, так как используется она в кластере, состоящем максимум из пары десятков достаточно высокопроизводительных узлов. Альтернативой проекту может служить уже упоминавшийся выше Hadoop, Apache Casandra (которую очень хвалил автор Elliptics, год назад, но сейчас на стенде говорили о недостаточной её производительности) и другие.
О Elliptics Network, живо, но поверхностно, рассказывал автор проекта Евгений Поляков на прошлом Yac. Видео доступно.
Скачать исходники Elliptics Network и почитать блог можно на сайте проекта:
www.ioremap.net
Слайды, которые крутились в фойе, на текущей конференции:
www.slideshare.net/AntonKortunov/yac-2011-elliptics-network
Кроме того, очень рекомендую статью о ещё одной реализации DHT от компании Amazon под названием Dynamo:
s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf
Вторым представителем key-value storages на конференции был проект Mulca, который представляет собой распределенную файловую систему, использующуюся для хранения писем в Яндекс.Почте. Кластер хранит 22 триллиона записей, общим объёмом 6.5 петабайт, на более чем тысячи узлах и постоянно растёт.
Система, также как и Elliptics Network, построена на хеш-таблицах, но использует совершенно другие принципы. Ключ записи хешируется двумя разными, некриптостойкими хеш-функциями и каждый узел в памяти реализует двойную хеш-таблицу. Первый уровень представляет собой массив, назовём его H1, указателей, размером равным нескольким миллионам элементов. Каждый указатель такого массива ссылается на список второго уровня H2 из десятка элементов, который в свою очередь ссылается на место на диске где лежат данные. При такой конструкции поиск осуществляется следующем образом: Значение первой хеш-функции (точнее его остаток от деления на размер H1) используется для получения смещения в массиве H1 и получения адреса списка H2. По списку H2 линейно осуществляется поиск элемента совпадающего со значением второй хеш-функции. После нахождения такого элемента, происходит чтение данных с диска и только после этого сравниваются настоящие ключи. Если ключи не совпадают, то продолжается поиск по списку H2 так далее. Список H2 отсортирован по времени и поэтому доступ к новым письмам происходит быстрее.
Благодаря тому, что ключи не хранятся в памяти, разработчикам удалось свести требования к памяти с 50 до 12 GB на узел. С другой стороны, такой подход не приводит к уменьшению производительности, так как сейчас в системе единицы двойных коллизий и нет ни одной тройной коллизии. Т.е. поиск подавляющего числа писем происходит за одно чтение с диска и только для нескольких писем требуется два чтения.
Каждое письмо хранится на двух узлах в разных дата центрах, а метаинформация по письмам хранится в кластере СУБД Oracle и ключ письма устроен таким образом, что в него добавлена информация об узлах, на которые записано письмо. Это позволяет, зная ключ письма, производить чтение напрямую с узла, который его хранит.
Записью управляют специальные узлы, называемые балансерами, которые следят за загруженностью остальных узлов и при генерации ключа нового письма, используют узлы, с наименьшей загруженностью.
Главное преимущество системы в Яндекс.Почте перед Elliptics Network в том, что добавление нового узла не приводит к перекачке данных между узлами. В Elliptics Network, напротив, добавлении узла приводит к тому, что перераспределяется ответственность за диапазоны кольца SHA512 между узлами, что, в свою очередь, приводит к массовой перекачке данных между узлами.
Дополнительных материалов посвящённых внутреннему устройству Яндекс.Почты я, к сожалению, не нашёл.
В этом году, по моему субъективному мнению, Яндекс немного не дотянул до того уровня, который он сам же и задал год назад: доклады были слабее, маркетинга стало больше, да и докладчики меньше стремились к общению. Но даже с такими оговорками YaC остаётся одной из лучших технических конференций в Москве, и её посещение обязательно будет полезно техническим специалистам, которые стараются расширить свой кругозор.
Записи докладов:
yac2011.yandex.ru/archive2011/video1
yac2011.yandex.ru/archive2011/video2
yac2011.yandex.ru/archive2011/video3
Записи докладов прошлого года:
yac2011.yandex.ru/archive2010/materials
Да ещё yet another раз…
Не так давно завершилась конференция Яндекс YaC 2011 и теперь, когда стали доступны записи выступлений, я хочу представить вам технический отчёт о её посещении. В отчете я сосредоточился на той информации, которую вы можете получить, посмотрев запись того или иного доклада, и решить стоит ли тратить на это время. Для некоторых тем добавил дополнительные ссылки на ключевые ресурсы, а так же, по мотивам общения с авторами, описал устройства двух NoSQL технологий Яндекса: Elliptics Network и хранилища писем в Яндекс почте.
Итак, Yac 2011, как это было.
Введение
Лучи уходящего лета определили начало моего понедельника. Чудесное утро ранней осени, с каждым шагом, улучшало настроение, пока я шёл к зданию Центра Международной торговли, в котором 19 сентября 2011 года проходила уже вторая по счёту технологическая конференция, организованная компанией Яндекс.
Всего год назад Яндекс принял решение ежегодно проводить новую конференцию, скромно названную, Yet another Conference, и «ещё одна конференция» оказалось на голову выше подавляющего большинства тех, на которые можно попасть в окружающем нас пространстве. С одной стороны, качество ключевых докладов и их прямая направленность на состоявшихся технических специалистов установили очень высокую планку для остальных технических конференций, а с другой стороны, Яндекс создал особенную атмосферу тем, что выпустил в свет своих ключевых специалистов и отдал их на «растерзание толпе». Многих докладчиков после выступления окружали желающие пообщаться, и они часами отвечали на вопросы, называли вещи своими именами и выдавали многие секреты, о которых не принято говорить на сцене.
Не менее важно и то, что записи докладов YaC выложены в публичный доступ, и каждый может самостоятельно их посмотреть и оценить. Конечно, видео не позволит вам пообщаться с докладчиком напрямую и узнать всё самое интересное, но, тем не менее, оно предоставляет ценнейший ресурс для самообразования.
Целью данного отчёта не будет пересказ докладов, поскольку, вы сами сможете всё посмотреть. Вместо этого, будет полезнее, кратко рассказать о сути докладов, поделиться своими мыслями и впечатлениями и порекомендовать те доклады, на которые стоит потратить своё время и посмотреть запись. Впрочем в конце я немного отойду от этого правила для того чтобы поделиться тем, что не попало в запись.
Поисковая технология «Спектр»
Конференцию открыл доклад Андрея Плахова, который был посвящён новой системе, запущенной в конце 2010 года, оценки релевантности ответа на поисковый запрос. Андрей посвятил свой рассказ постановке проблемы неоднозначных запросов и описал её решение в общих принципах.
Яндекс обрабатывает 5 миллиардов запросов в месяц и многие из них составлены таким образом, что даже человеку нелегко понять, что именно хотел узнать пользователь. Например, по запросу Ягуар, варианты ответов могут касаться животного, автомобиля и напитка. Система на основании анализа потока запросов находит возможные расширения текущего запроса, например, «объём двигателя Ягуара» или «содержание спирта в Ягуаре». Среди всех возможных расширений выбираются те, которые соответствуют категории запроса (например, напиток, нечто вредное) и возможным расширениям назначаются веса, исходя из потенциальных потребностей категории. Система содержит ограниченное количество категорий, таких как фильмы, книги, люди, гаджеты и т.п., которые определяются вручную.
Запись доклада стоит посмотреть для общего понимания проблемы неоднозначных запросов и примерных подходов к её решению
Кросс-платформенная разработка под мобильные устройства
Дмитрий Жестилевский, рассказывал о Platform Abstraction Layer (PAL), который разрабатывается в Яндексе. PAL позволяет, без дублирования кода, создавать Native C++ приложения под iOS, Android, Symbian и другие системы. PAL был основан на OpenKODE: наборе открытых стандартов, описывающих программную платформу мобильного устройства. В OpenKODE входят API для взаимодействия с операционной системой OpenKODE Core (во многом копирующие POSIX), OpenGL ES, OpenSL ES и др. В Яндексе реализовали часть стандартов OpenKODE для каждой платформы, другая часть уже была реализована на платформах изначально (например, OpenGL ES) и получили универсальную среду разработки приложений. PAL позволяет написать и отладить код под Windows и сразу скомпилировать его под iOS и Android. Набор стандартов OpenKODE предоставляет богатые возможности, но иногда появляются задачи, для оптимального решения которых, возможностей OpenKODE становиться недостаточно и тогда возникает необходимость в создании собственных расширений OpenKODE.
Стандарт OpenKODE использует язык C и, с одной стороны, логично писать расширения без использования C++, но с другой стороны, со временем, стало понятно то, что создавать интерфейс расширений на чистом C не слишком удобно, когда весь остальной код использует C++. Сейчас расширения представляют собой полноценные C++ объекты и не возникает дополнительная необходимость создания RAII оберток над C кодом.
PAL не уникальная технология Яндекса и другие компании предлагают не менее интересные аналоги. Например, Marmalade SDK, о котором было упомянуто в докладе, предоставляет вполне законченное и, с моей точки зрения, самое перспективное решение. Тем не менее, Яндекс начал писать свою систему, прежде всего потому, что это обеспечивало независимость от сторонних компаний и предоставило неограниченные возможности расширения.
Запись доклада стоит посмотреть для понимания проблем, с которыми столкнулась компания Яндекс, но для изучения подходов к организации PAL, рекомендую изучить сайты посвященные OpenKODE и Marmalade SDK.
В поисках математики
Красивое название доклада не могло оставить меня равнодушным, и я, предвкушая, пробрался ближе к сцене. Рассказ был посвящён системе Nigma-Математика, отечественном аналоге Wolfram Alpha. Доклад был посвящён общему описанию структуры сервиса, которая оказалась достаточно типовой.
Доклад стоит смотреть для понимания общих принципов организации веб-сервисов, но если вас интересуют тонкости, то лучше обратитесь к другим ресурсам.
Разработка приложений для Android на С++
Юрий Береза, ещё один разработчик PAL, рассказывал о тонкостях разработки под Android: вызовах Java из C++ и вызовах C++ из Java, компиляции Boost, особенностях отладки, сборки и др. В итоге у него получился очень полезный с практической точки зрения доклад.
Запись, однозначно, стоит посмотреть тем, кто собирается или уже пишет на C++ под Андройд. Это было одно из самых практически полезных выступлений.
How we Architected Cloud9 IDE for scale on NodeJS
JavaScript не входит в число моих интересов и на данном докладе я коротал время, пока рассосётся первая волна желающих пообедать. Но, тем не менее, кое-что я всё же узнал.
Компания Cloud9 создала IDE для JavaScript, работающую прямо в браузере. Действительно, IDE умеет подсвечивать синтаксис, работать с системами контроля версий, полноценно отлаживаться: ставить точки останова, смотреть значение переменных, callstack и т.д.
Смотрел я, голодный, на всё это торжество HTML 5 и думал о будущем компьютерных технологий, повсеместном интернете, умных устройствах, автопилотах в автомобилях, о термоядерном синтезе для всего этого электронного счастья.
Впрочем, у данного IDE я нашёл один большой «недостаток»: полное отсутствие интеграции с Twitter’ом и Facebook’ом. Поэтому, кто знает, выберет ли программист IDE, разрываясь между такими замечательными сервисами?
Доклад мне показался в значительной степени маркетинговым и поэтому я рекомендую его смотреть только тем, кого действительно заинтересовали возможности проекта.
Зачем обычному программисту знать языки, на которых почти никто не пишет
Это не доклад, это эпос, Одиссея с Рамаяной и Сон в красном тереме с Бхагавад-гитой.
Нет, правда, если бы на тему языков программирования нужно было бы создать что-то нетленное и рассказать за 40 минут, то выглядело бы это примерно так же.
Советую смотреть, обязательно перед сном, в хорошем расположении духа и в рассредоточенном сознании.
C++11 is the new C++ language standard
Путь стандарта был тернист и долог, но спустя 8 лет мы, наконец, можем сказать, что этот путь завершен. Все привыкли объяснять столь долгий срок сложностями языка, но может, дело совсем не в этом? Может дело во вмешательстве потусторонних сил? Судите сами, докладчика просто не пустили в Россию. И если мы, здесь, давно привыкли жить с нашими потусторонними силами, то, что могут они, члены комитета, супротив такой беды?
Доклад Дейва Абрамса проходил по Скайпу, что само по себе было забавно. Подручные технические ухищрения обеспечили двустороннюю видео связь: с показом слайдов, вопросами в конце и т.п. Дейву, наверное, было странно наблюдать огромную аудиторию снятую камерой небольшого ноутбука, а нам смотреть на человека, выступающего перед большим количеством людей в домашней обстановке.
Разговор шёл о новых возможностях C++, и смотреть видео, учитывая технические проблемы связи, думаю, не стоит. Лучше потратьте своё время на изучение статьи в Википедии, посвящённой C++11.
Юнит-тестирование и Google Mock
Юнит тесты будут действительно приносить пользу только в том случае, если они быстрые, надежные и точные. Но как написать юнит-тест системы, зависящий от базы данных, сети или тяжёлых вычислений? Один из ответов на этот вопрос состоит в том, чтобы тестировать только конкретный модуль, а работу всех зависимых модулей эмулировать при помощи Mock-объектов.
Mock – это объект, представляющий собой конкретную фиктивную реализацию интерфейса, предназначенную исключительно для тестирования.
Писать Mock-объект для каждого теста часто может быть достаточно накладно и поэтому возникает желание, каким либо образом автоматизировать данный процесс. Существует множество Mock библиотек для Java, для которой, в силу поддержки интроспекции, написать такие библиотеки значительно проще. И мне казалось, что для C++ никогда не появятся удобные Mock библиотеки, однако Google представил Google Mock.
Сразу после доклада библиотека показалась мне «кадавром, неудовлетворённым желудочно». Судите сами, при помощи шаблонного метапрограммирования был создан свой декларативный язык, на котором описывается поведение Mock-объекта. И возникает вопрос: не придётся ли дольше копаться в документации, в попытке объяснить, что именно должен делать Mock, вместо того чтобы быстро написать, как он должен это сделать?
Первое впечатление прошло после того, как я немного погрузился в документацию Google Mock. Библиотека организованна вполне разумно, проста в изучении и сейчас она мне кажется, по меньшей мере, интересной.
Сложно сказать стоит ли смотреть видео или нет. Мне показалось то, что к синтаксису нужно какое-то время привыкнуть, а докладчик сразу уходит в дебри и портит первое впечатление.
Контроль зверей: инструменты для управления и мониторинга распределенных систем от Cloudera
Компания Cloudera специализируется на технологиях, построенных вокруг Hadoop – свободного проекта Apache Software Foundation, предназначенного для хранения и обработки больших объёмов данных на кластерах, состоящих из тысяч отдельных узлов. Hadoop, фактически, является экосистемой, объединяющей несколько отдельных проектов: распределённую файловую систему HDFS, реализацию парадигмы MapReduce, нереляционную базу данных HBase и д.р.
В последнее время популярность Hadoop быстро растёт. Увеличивается количество компаний решающих при помощи Hadoop свои задачи, повышается качество внутренней реализации, и всё большие объемы данных обрабатывают Hadoop кластеры. Обычным делом сейчас становятся кластеры, хранящие до 80 петабайт данных.
Доклад мне показался в некоторой степени маркетинговым и направленным на специалистов, непосредственно работающих с Hadoop, поэтому, думаю, не стоит тратить на него свое время. Вместо этого, рекомендую выступление Константина Швачко из Yahoo, который на прошлой конференции очень интересно рассказал про Hadoop.
Масштабируемость Hadoop в Facebook
Темой доклада снова стал Hadoop, а точнее его модификация, направленная на повышение масштабируемости, которая была создана в компании Facebook. Дело в том, что Facebook использует fork старой версию Hadoop и в какой-то момент решил исправить некоторые проблемы масштабируемости своей системы, которые к тому времени уже были исправлены сообществом в основной ветке.
Доклад был посвящен тому, как именно Facebook исправлял свою систему и будет полезен Hadoop специалистам, но те, кто поверхностно знаком с технологией скорее всего не найдут в докладе ничего полезного.
Сложнейшие техники, применяемые буткитами и полиморфными вирусами
Доклад лаборатории Касперского начался с элементов вузовского курса Операционные системы, но быстро перешёл к тонкостям устройства BIOS и процесса загрузки ОС. Причём с перечислением значений адресов их функциональности и хитростей, которые использует современное вредоносное ПО.
Весьма специфическая информация, на достаточно глубоком уровне, поэтому я рекомендую смотреть только истинным ценителям, которые знают толк в подобных вещах.
Стенд Elliptics Network
В течение дня в фойе конференции проходила технологическая выставка, где можно было попробовать написать приложение с использованием Yandex Mobile MapKit, посмотреть на новые смартфоны, 3D телевизоры, выиграть какие-то призы – в общем, классический красный уголок маркетинга. Однако среди всех стендов были два, которые меня действительно заинтересовали. Я расскажу о них немного подробнее так, как фактически, докладов, посвященных системам которые на них показывали, не проводилось. На стендах просто отвечали на вопросы проходящих мимо.
Оба стенда были посвящены хранению и обработки больших объёмов данные в NoSQL хранилищах (под термином NoSQL рассматривают не отказ от языка SQL, а хранение информации в базах данных, построенных по модели отличной от реляционной). Реляционные базы данных давно стали самым распространённым способом хранения и обработки значительных объёмов структурированных данных. Тем не менее, быстродействие, целостность, а также удобство разработки прикладных программ на современных SQL СУБД достигается за счёт компромисса с другими немаловажными факторами: масштабируемостью и доступностью. Говоря о SQL СУБД, часто употребляют термин вертикальная масштабируемость, суть которого сводится к тому, что с определенного момента развития проекта, стоимость оборудования при наращивании производительности на одну и ту же величину стремительно возрастает, и, постепенно, становятся непомерно высокой. Ещё хуже обстоят дела с доступностью: отказ одного узла может повлечь остановку сервера на продолжительное время и вылиться крупными финансовыми потерями. Для решения описанных проблем появились системы хранения данных, которые, принося в жертву функциональность, выигрывают в масштабируемости и доступности.
Одним из примеров хранилищ, альтернативных SQL, служит проект Elliptics Network, который в Яндексе используют для хранения фотографий в сервисе Яндекс.Фотки и тайлов в Яндекс.Картах. Elliptics Network относится к классу Распределённых хеш-таблиц (DHT), которые по сравнению с реляционными базами данных предоставляют достаточно скудный набор операций: сохранение и получение неструктурированных двоичных данных по уникальному ключу (такой класс хранилищ называют key-value storages), но при этом обладают рядом уникальных свойств. Кластер Elliptics Network организован по принципу одноранговой (P2P) сети, в которой все узлы выполняют одинаковые операции и ни один узел не выделается среди других. Ключом записи может быть произвольная сущность, по которой можно вычислить хеш-функцию (в данном случае, SHA512). Использование криптостойкой хеш-функции позволяет не рассматривать вероятность её коллизии и снять проблему неуникальных ключей. Кроме того, хранилище может ничего не знать об истинном типе ключа и методе его генерации, то есть выполнять все операции, используя только хеш. Каждый узел в кластере выбирает несколько сегментов из кольца значений хеш-функции, за которые он будет отвечать и модифицирует, глобально доступную (синхронизированную между узлами), таблицу маршрутизации запросов. Клиент, при доступе к данным, генерирует по ключу уникальное хеш-значение, по которому в таблице маршрутизации осуществляется поиск узла, отвечающего за диапазон в который попадает значение. После получения адреса, клиент может напрямую обращаться к узлу и запрашивать от него данные.
Отсутствие централизованных элементов позволяет пропорционально наращивать производительность, путём добавления новых узлов сходной конфигурации. Такой способ масштабируемости, называют горизонтальным. Он позволяет значительно экономить средства и создавать сервисы, функционирование которых было бы невозможным при использовании реляционных баз данных.
Каждый узел в кластере может в любой момент выйти из строя и когда узлов становится достаточно много постоянно возникают ситуация при которых часть узлов недоступна. Для того чтобы при отказе узла не останавливался весь кластер вводят систему репликации. Работа такой системы основана на том, что за один и тот же интервал пространства ключей отвечает сразу несколько узлов и запись происходит синхронно во все доступные реплики. Если все узлы, отвечающие за некоторый диапазон хеш-значений, отказывают, то чтение из этого диапазона становится невозможным, но запись продолжается в узлы, отвечающие за соседние диапазоны. Таким образом, отказ произвольного количества узлов может сделать недоступным для чтения только часть данных и то только тех, для которых вышли из строя все возможные копии (систему обычно настраивают на двойное или тройное резервирование), но при этом невозможность записи возникает только при отказе всех узлов кластера.
Год назад Elliptics Network поддерживала версионность данных, но сейчас её отрезали за ненадобностью. Кроме того, Elliptics Network позволяет использовать интервальные запросы, то есть получить все данные ключ которых лежит в диапазоне от X до Y. Такая функциональность, очевидно, выходит за рамки key-value storages и вмешивается в стройную архитектуру DHT. Реализована она следующим образом: от ключа SHA512 отбрасываются младшие байты и используются, как индекс сортировки. Каждый узел хранит в памяти красно-черное дерево хеш-ключей и, естественным образом, позволяет осуществлять интервальные запросы. Разработчики говорят о том, что они не рассматривают интервальные запросы, диапазон которых, может перекрыть несколько узлов, хотя с моей точки зрения — это может стать проблемой масштабирования, не говоря уже о том, что вмешательство в механизм генерации ключей препятствует равномерному распределению данных по узлам. И, гипотетически, достаточно большой и популярный интервал данных, полностью попадая на одну машину, может запросто затормозить её до полной остановки.
Вокруг Elliptics Network сосредоточено несколько технологий. Библиотека Eblob, которая «работает даже лучше, чем звучит», позволяет организовать на диске хранилище неструктурированных бинарных данных (BLOB’ов) и получить быстрый доступ к ним (обычные файловые системы плохо справляются с нагрузкой в ситуациях, когда количество файлов начинает измеряется в миллионах). Файловая система PohmelFS, созданная на базе Elliptics Network, в которой ключом служит имя файла и добавлены дополнительные механизмы для поддержания целостности, а также PohmelFS совместима со стандартом POSIX и может быть смонтирована, как стандартная файловая система Linux.
Тем не менее, моё отношение к Elliptics Network, хоть и с интересеом, но скорее скептическое. В сущности, о масштабируемости Elliptics Network говорить сложно, так как используется она в кластере, состоящем максимум из пары десятков достаточно высокопроизводительных узлов. Альтернативой проекту может служить уже упоминавшийся выше Hadoop, Apache Casandra (которую очень хвалил автор Elliptics, год назад, но сейчас на стенде говорили о недостаточной её производительности) и другие.
О Elliptics Network, живо, но поверхностно, рассказывал автор проекта Евгений Поляков на прошлом Yac. Видео доступно.
Скачать исходники Elliptics Network и почитать блог можно на сайте проекта:
www.ioremap.net
Слайды, которые крутились в фойе, на текущей конференции:
www.slideshare.net/AntonKortunov/yac-2011-elliptics-network
Кроме того, очень рекомендую статью о ещё одной реализации DHT от компании Amazon под названием Dynamo:
s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf
Стенд Яндекс.Почта
Вторым представителем key-value storages на конференции был проект Mulca, который представляет собой распределенную файловую систему, использующуюся для хранения писем в Яндекс.Почте. Кластер хранит 22 триллиона записей, общим объёмом 6.5 петабайт, на более чем тысячи узлах и постоянно растёт.
Система, также как и Elliptics Network, построена на хеш-таблицах, но использует совершенно другие принципы. Ключ записи хешируется двумя разными, некриптостойкими хеш-функциями и каждый узел в памяти реализует двойную хеш-таблицу. Первый уровень представляет собой массив, назовём его H1, указателей, размером равным нескольким миллионам элементов. Каждый указатель такого массива ссылается на список второго уровня H2 из десятка элементов, который в свою очередь ссылается на место на диске где лежат данные. При такой конструкции поиск осуществляется следующем образом: Значение первой хеш-функции (точнее его остаток от деления на размер H1) используется для получения смещения в массиве H1 и получения адреса списка H2. По списку H2 линейно осуществляется поиск элемента совпадающего со значением второй хеш-функции. После нахождения такого элемента, происходит чтение данных с диска и только после этого сравниваются настоящие ключи. Если ключи не совпадают, то продолжается поиск по списку H2 так далее. Список H2 отсортирован по времени и поэтому доступ к новым письмам происходит быстрее.
Благодаря тому, что ключи не хранятся в памяти, разработчикам удалось свести требования к памяти с 50 до 12 GB на узел. С другой стороны, такой подход не приводит к уменьшению производительности, так как сейчас в системе единицы двойных коллизий и нет ни одной тройной коллизии. Т.е. поиск подавляющего числа писем происходит за одно чтение с диска и только для нескольких писем требуется два чтения.
Каждое письмо хранится на двух узлах в разных дата центрах, а метаинформация по письмам хранится в кластере СУБД Oracle и ключ письма устроен таким образом, что в него добавлена информация об узлах, на которые записано письмо. Это позволяет, зная ключ письма, производить чтение напрямую с узла, который его хранит.
Записью управляют специальные узлы, называемые балансерами, которые следят за загруженностью остальных узлов и при генерации ключа нового письма, используют узлы, с наименьшей загруженностью.
Главное преимущество системы в Яндекс.Почте перед Elliptics Network в том, что добавление нового узла не приводит к перекачке данных между узлами. В Elliptics Network, напротив, добавлении узла приводит к тому, что перераспределяется ответственность за диапазоны кольца SHA512 между узлами, что, в свою очередь, приводит к массовой перекачке данных между узлами.
Дополнительных материалов посвящённых внутреннему устройству Яндекс.Почты я, к сожалению, не нашёл.
Заключение
В этом году, по моему субъективному мнению, Яндекс немного не дотянул до того уровня, который он сам же и задал год назад: доклады были слабее, маркетинга стало больше, да и докладчики меньше стремились к общению. Но даже с такими оговорками YaC остаётся одной из лучших технических конференций в Москве, и её посещение обязательно будет полезно техническим специалистам, которые стараются расширить свой кругозор.
Ссылки
Записи докладов:
yac2011.yandex.ru/archive2011/video1
yac2011.yandex.ru/archive2011/video2
yac2011.yandex.ru/archive2011/video3
Записи докладов прошлого года:
yac2011.yandex.ru/archive2010/materials
