Бэкенд Twitter перешёл на Protocol Buffers

    Хотя основные копии пользовательских твитов хранятся в базах данных MySQL и Cassandra, компания также разворачивает дополнительное хранилище на Hadoop, которое можно будет использовать для аналитики и дополнительных программных приложений.

    Информацию из этой системы можно запрашивать с помощью Java MapReduce или Pig, собственного SQL-подобного языка запросов Hadoop. В данный момент на этот бэкенд уже переведена система поиска, а в будущем появятся и другие приложения.

    Отвергнув популярные технологии вроде XML, CSV и JSON, программисты Twitter выбрали в качестве формата для хранения данных бэкенда относительно неизвестный формат Protocol Buffers, разработанный в Google (он уже обсуждался на Хабре). Технические подробности реализации были оглашены представителями Twitter на конференции HadoopWorld во вторник.

    Каждый день в базу Twitter добавляется 12 ТБ новых данных. С такими объёмами выбор правильного формата приобретает критическое значение. Комбинация Protocol Buffers, Hadoop и смежных технологий призвана решить эту проблему.

    Каждый твит состоит из 17 полей в базе данных, шесть из которых имеют как минимум одно подполе. В будущем Twitter планирует добавить и другие подполя. В перспективе система хранения должна выдерживать и эффективно работать с триллионом твитов от миллиарда юзеров.

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

    Преимущество Protocol Buffers перед XML становится очевидным на больших объёмах данных. По словам разработчиков Twitter, база в триллион твитов на XML может занимать примерно десять петабайт вместо одного. В JSON тоже хранится много лишней информации. На другом полюсе — CSV, где данные разделяются всего лишь запятыми. Здесь ничего лишнего, но трудно структурировать подполя.

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

    Похожие публикации

    Комментарии 43

      +13
      Вообще у гугла очень много мощных инструментов, о которых знают лишь единицы.
        +1
        Кому надо, те следят за новостями и анонсами :)
        +5
        Завидую программистам из Twitter. Ребята решают интереснейшие задачи, работают с огромными объемами данных, используют передовые непопулярные технологии. При этом результатом их работы пользуются миллионы людей.
        Блин, был бы я на их месте — с работы бы не вылазил и был счастлив.
          +1
          Еще не все потерянно :)
            +4
            Protocol Buffers — не такая уж непопулярная технология. Просто пользуются ей в основном разработчики баз данных (из недавних — в Riak появилась их поддержка). Даже на Хабре, по моему, проскакивали статьи о Protocol Buffers.
              +1
              Я не говорил что она не популярная. Я говорю про то что гугл создает столько технологий что о них о всех сложно знать.
              +2
              Ха, плавали — знаем.

              А теперь представь, что миллион людей пользуется твоей программой каждый день и самый мелкий баг — повод для 50 страниц флейма на форуме. Вставать ночью по звонку сервера что управляющая программа зависла и ее надо срочно чинить… Нафиг-нафиг… :-)
                +6
                Я больше завидую ребятам из гугла :) Все тоже только умноженное на 1000
                  0
                  На РИТе следующей весной к нам будут в гости именно эти ребята. К сожалению, на этот Highload они не успели.
                    +4
                    А вы работали с объемами хотя бы в сотни/тысячи раз меньшими? Меня порой мандраж берет когда я читаю строки «ежедневно добавляется 12 Тб данных».
                    Это далеко не рай, это самый настоящий ад! Когда все имеющиеся на данный момент стандартные решения перестают справляться, распределение не решает задач и приходится буквально в считанные дни делать то, на разработку чего у многих уходят просто годы.
                    А это и прощай личная жизнь и покой…
                    +5
                    Дрочу на их терабайты.
                      0
                      И обязательно сразу писать на хабр?
                        +9
                        Может он окном ошибся? =)
                      +2
                      Protocol Buffers очень много используется гуглом в Android.
                        –3
                        Гугл — не единица ;)
                        Гугл — много.
                          0
                          Для синхронизации с гугл.акком в хроме также используется PB.
                            +1
                            Protocol Buffers много используется гуглом практически в каждом проекта гугла :-)

                            И это не шутка.
                              0
                              В android очень много используется binder, который кстати не ахти. Protocol buffers там не встречал.
                              +4
                              Забавно, но я такую штуку писал еще в студенческие годы. Конечно, называлась она по-другому и конечно не была «very heavily optimized», но я просто уверен, что в мире таких «технологий» на сегодня разработано и отлажно сотни. Разница в чем? В том — что это сделал гугл, скажете Вы и будете правы. Так отчего же то, что сделал гугл для нас воспринимается как Библия, а то что сделали мы сами (или Ваши коллеги) — мы считаем за фуфло?
                              Сдается мне у ребят из твиттера логика та же…
                                0
                                Самых распространенных две: google protobuf и apache thrift (по сути, разработка Фейсбука). Сравнение производительности и функциональности можно посмотреть на thrift-protobuf-compare/.
                                  +1
                                  Несколько бесит то, что среди возможных альтернатив гугл показывает только три самых тупых:
                                  code.google.com/apis/protocolbuffers/docs/cpptutorial.html


                                  There are a few ways to solve this problem…
                                  * The raw in-memory…
                                  * You can invent an ad-hoc way to encode the data…
                                  * Serialize the data to XML…

                                  И все… Уж если Вы делаете заявку на мировое господство — будьте добры докажите. :)
                                  Спасибо за упоминание про thrift!
                                  +2
                                  +1.
                                  Основанная часть этих данных агрегируется с помощью свободной технологии Scribe (разработка Facebook).

                                  Яндекс до сих пор tail'ит логи каким-то своим продвинутым скриптом. Эффективнее tail/grep ничего еще не придумано.
                                    +2
                                    awk
                                      0
                                      Scribe больше похож на продвинутый syslogd
                                      +2
                                      Еще есть yaml c возможностью компиляции в байт-код.
                                        +8
                                        Очень просто, если штуту выпустил google, то ею пользуются десятки тысяч программистов, если мой коллега, то всего несколько людей, следовательно, первая тщательнее протестирована и содержит меньше ошибок)
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          –1
                                          Как по мне — так ASN.1 рулил, рулит и будет рулить. :)
                                            0
                                            Эх, рано сдались =) На первых порах тоже с этис столкнулся, но потос привык. Все равно достоинств больше, чем недостатков. Особенно понравилось: возможность расширения, скажем цепляешь к сообщению optional поле и таскаешь, потрясающая скорость создания dto-ек. Дописал описание, скомпилировал, все можно уже использовать новую сущность в коде — и все это с очень удобным API. Про скорость и компактный размер я вообще молчу.
                                              0
                                              Я тоже столкнулся с этим, пришлось дописать своё расширение — всего навсего добавил обязательное строковое поле alias находящееся всегда первым.(тут подробнее)
                                              есть реализации на as3/с++/java — компиляторы классов из .proto переписывать не пришлось, только базовые классы — вернее методы де/сериализации
                                                0
                                                Причём «расширенный» протокол нормально работает с «обычным» если использовать стандартный RPC.
                                                0
                                                А мы прикрутили успешно ;)
                                                У нас так приложение на айфоне с backend общается.
                                                Все довольны.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Вы совершенно правы, однако в mainstream языках его поддержки мало.
                                                  0
                                                  Странно что не Thrift ибо он как и Hadoop от апачи.

                                                  Как активный пользователь Thrift могу сказать — это действительно великолепная библиотека которая упрощает хранение/обработку логов. Кроме того Thrift идеально подходит для RPC, межпроцессорного взаимодействия.

                                                  Вот пример использования Thrift mikecvet.wordpress.com/2010/05/13/apache-thrift-tutorial-the-sequel/
                                                    +2
                                                    Мне тоже было интересно. Как раз подумал, почему ProtoBuffers, а не Thrift, потому как недавно анализировал варианты бинарных протоколов для одного из проектов. Потом пошёл покурить и подумал. Видимо потому что от Гугла :( Похоже Апачей больше не любят.

                                                    И ещё. Недавно Твиттер сообщил, что переписал часть своей инфраструктуры на Scala. С 60-процентной вероятностью могу утверждать, что в качестве основы обмена сообщениями был выбран проект Akka, который очень хорошо дружит с Netty, который в свою очередь из коробки поддерживает Google Protocol Buffers. Я пробовал и знаю. Так то.
                                                      0
                                                      У Thrift есть недостатки работы с большими пакетами данных — они должны полностью помещаться в память. В силу этого проект Cassandra собирается перейти к использованию Apache Avro.
                                                    +4
                                                    Каждый день в базу Twitter добавляется 12 ТБ новых данных...

                                                    Точно 12 терабайт? Насколько я понимаю, речь идет только о тексте — какая-то невероятная цифра получается.
                                                      0
                                                      Таки да (слайд 6)
                                                        +2
                                                        Хотя небольшое уточнение: это не только твиты, это вообще вся информация включая системные логи итд
                                                      +1
                                                      Следует также упомянуть, что Protocol Buffers поддерживает версионность интерфейсов «из коробки». Это очень важно в тех случаях, когда вы не можете просто взять и остановить всю систему, чтобы обновить каждый компонент для работы с новым протоколом или общим интерфейсом.
                                                        0
                                                        Т.е. не придется перекраивать все данные, чтобы добавить одно поле совершенно нового типа?
                                                        0
                                                        Каждый день в базу Twitter добавляется 12 ТБ новых данных.
                                                        На этой строчке я понял, что новость от alizar

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое