Приветствую всех вОблако Tencent + сообщество, получить больше крупной технической практики Tencent по галантерее~
Эта статья была впервые опубликована в сообществе cloud+ и не может быть воспроизведена без разрешения.
Привет всем, я хотел бы кратко представить. Меня зовут Рао Джун. Я один из соучредителей Confluent, начинающей компании в Силиконовой долине. Все трое основателей нашей компании в начале были разработчиками kafka. Наша компания была основана в 2014 году. Цель создания — сделать компанию бизнесом, который помогает различным предприятиям выполнять поток данных на основе kafka.
Прежде чем начать, я хотел бы провести простой опрос, кто использовал Kafka в этой комнате. Его используют около 80% людей. Хорошо, спасибо. Делясь с вами сегодня, я хочу поделиться нашим проектом, развитием Кафки, тем, как он был создан, и некоторыми из его опытов. Говоря о Кафке, мы должны вернуться в 2010. В этой области я присоединился к LinkedIn в 2010. Многие люди могут быть знакомы с ней, это социальная платформа, которая предоставляет таланты и возможности. В 2010 году LinkedIn начал формироваться, что также является этапом быстрого роста LinkedIn. Когда я присоединился к LinkedIn в 2010 году, я, вероятно, был сотрудником № 600. Я ушел из LinkedIn в 2014 году. Когда я ушел, я вырос до сотрудника № 6000. Всего за четыре года организация быстро развивалась. В процессе быстрого развития LinkedIn причина, по которой он может иметь такое быстрое развитие, неотделима от данных. Как и многие интернет-компании, ядром LinkedIn являются данные. Пользователи могут прямо или косвенно предоставлять LinkedIn свои собственные данные. исследований или анализа, LinkedIn может извлечь много новых идей и знаний, и эта информация будет возвращена нам. Что касается продукта, этот продукт будет более эффективным и может привлечь больше пользователей на нашу платформу, поэтому, если данные будут сделаны ну, это может сформировать очень хороший круг благоприятных действий, пользователи могут получить больше данных, могут сделать Лучшая аналитика может производить лучшие продукты и привлекать больше пользователей.
Разнообразие источников данных
С точки зрения данных, данные LinkedIn очень разнообразны. Наиболее распространенные данные могут быть известны как один тип — данные транзакций. Эти данные обычно хранятся в базе данных. очень просто.Вы предоставляете резюме работы или несколько резюме вашей школы, в том числе связь между вами и участниками в ней, которые все являются транзакционными данными, но есть еще много нетранзакционных данных. , некоторые поведенческие данные многих пользователей, например, по какой ссылке вы щелкаете как пользователь, какие ключевые слова для поиска вводите, это на самом деле очень ценная информация. Из наших внутренних операций есть много показателей оперативного обслуживания, некоторые журналы приложений и, наконец, некоторая информация о многих наших смартфонах, что также очень ценно. Поэтому с точки зрения стоимости ценность этих нетранзакционных данных не меньше стоимости этих транзакционных данных. Но с точки зрения трафика, трафик этих нетранзакционных данных может быть в 100 или даже 10 миллионов раз больше источника данных этих транзакционных данных. Давайте возьмем небольшой пример, чтобы увидеть, как LinkedIn использует идею этих данных для предоставления этой услуги.
Это называется люди, которых вы можете знать на английском языке, сокращенно PYMK. Эта организация занимается предоставлением некоторых рекомендаций пользователям LinkedIn. Он хочет порекомендовать некоторых других пользователей LinkedIn. Он еще не подключен к вам. Какова его рекомендация? Это? Он использует от 30 до 40 видов внутренней информации и суммирует их, чтобы дать вам окончательную рекомендацию. Чтобы привести несколько простых примеров, скажем, мы двое учились в одной школе или работали в одной компании, это сильное сообщение, может быть, нам просто нужно быть на связи, но есть такая косвенная информация, например, два человека, А и Б, не имеют каких-то явных общих родственных связей, но если многие люди видят резюме этих двух людей одновременно за короткий промежуток времени, это означает, что у них все же могут быть какие-то скрытые информацию, которая делает их достойными объединения. Так что в первые дни существования LinkedIn, если вы воспользуетесь этим сервисом, вы обнаружите множество удивительных рекомендаций. На первый взгляд можно подумать, что он порекомендовал бы мне такого человека, но если подумать, то обнаружится, что на это есть много веских причин, и действительно есть некоторые истины, и подобных сервисов в это, так что он может использовать различные данные в реальном времени. Но в 2010 году у нас была большая проблема с LinkedIn, то есть интеграция данных была на самом деле очень несовершенным процессом. Эта картинка примерно представляет состояние в то время, поэтому я вижу, что выше есть различные источники данных. LinkedIn была старой интернет-компанией в начале. Все данные хранятся в базе данных. С концепцией развития у меня есть система, которая собирает все данные о поведении пользователя, много данных хранится в локальных файлах, а некоторая другая информация хранится в рабочем журнале, выполняя некоторые данные мониторинга идентификации.
Ниже по течению мы видим, что это различные конечные потребители. LinkedIn изначально имел такое хранилище данных. Со временем у нас появляется все больше и больше микросервисов в реальном времени, которые похожи на эти пакетные обработки. Также захватывают более или менее то же самое информацию из этих различных источников данных. Как и механизм рекомендаций, который мы только что упомянули, это один из микросервисов. У нас их много, а также некоторая обработка социальных графов. Он может анализировать отношения между двумя узлами, например двумя участниками LinkedIn. Как они связаны, какие соединение является самым сильным, и есть некоторые поиски в реальном времени, поэтому эти числа постепенно увеличиваются, и многие из их применений более в реальном времени, от генерации данных до обновленной системы, большую часть времени это несколько секунд, или даже более короткие задержки.
интеграция данных точка-точка
Итак, что мы делали в то время, так это то, что если мы хотели отправить эти данные из источника данных потребителю, подход был тем, что мы называли интеграцией данных точка-точка, Мы знали некоторые данные, и мы хотели отправить данные потребителю.В хранилище данных наш подход заключается в написании скриптов или написании некоторых программ. Через несколько дней мы обнаружили, что многим системам также необходимо считывать данные, мы проделаем аналогичную работу и напишем скрипты и некоторые программы, поэтому мы занимаемся подобными вещами в течение длительного времени, но после написания пяти или шести подобные потоки данных, я обнаружил, что это очень неэффективная практика. В чем основная проблема? Первая проблема, которую мы хотим решить, — это проблема перекрестного умножения, которая представляет собой проблему перекрестного умножения с персоналом данных и потребителями данных. Поэтому при каждом добавлении источника данных источник данных должен быть подключен ко всем потребителям.Если также добавляется потребитель, потребитель должен быть напрямую подключен ко всем источникам данных. Вторая проблема заключается в том, что когда мы выполняем поток данных такого типа, нам приходится повторять много одной и той же работы каждый раз, когда мы делаем поток данных, и у нас нет достаточно времени, чтобы сделать это за все время. каждый источник данных. До 100% совершенства, поэтому мы считаем, что эта архитектура не очень идеальна.
идеальная архитектура
Итак, если вы хотите улучшить, что следует улучшить? Мы подумали, что если будет такая архитектура, предполагая, что у нас есть централизованная система логирования посередине, мы можем сначала кэшировать информацию всех источников данных.Если мы сможем это сделать, мы сильно упростим фреймворк. Поэтому, если вы являетесь источником данных, вам не нужно знать всех потребителей, единственное, что вам нужно сделать, это отправить свои данные в центральную систему регистрации. Точно так же, если вы являетесь потребителем, вам не нужно знать все источники данных, все, что вам нужно сделать, это подписаться на сообщения, которые вы хотите, как в этой центральной системе журналов, поэтому мы упростим задачу перекрестного умножения прямо сейчас до одной. реальная проблема, ключ в архитектуре, какую систему можно использовать в качестве центральной лог-системы, так это то, что мы обсуждали в то время, мы не хотели перестраивать новую систему в начале, это кажется быть очень распространенной проблемой на уровне предприятия, должно быть аналогичное решение на этом предприятии. Если внимательно присмотреться и подумать, центральная система ведения журналов похожа на традиционную систему обмена сообщениями с точки зрения интерфейса. Наша система сообщений, как правило, разделяет этот тип производства и потребителя, а затем это система очень реального времени, поэтому мы подумали, почему бы не попробовать некоторые существующие системы сообщений, в то время были некоторые системы сообщений с открытым исходным кодом, и некоторые предприятия продвинутая система обмена сообщениями, но мы обнаружили, что она очень неэффективна. Есть много конкретных причин, но самая важная причина заключается в том, что эти традиционные системы сообщений не предназначены для такого использования, особенно самая большая проблема - их пропускная способность.
Kafka First Edition: система обмена сообщениями публикации и подписки с высокой пропускной способностью
Много такого рода ранних новостей, его дизайнер дал данные по этим базам данных, такого рода транзакционные данные потребления для проектирования, но вам может быть трудно представить себе множество нетранзакционных данных, таких как журналы поведения пользователей, и некоторые данные такого рода мониторинга распространяются через эти традиционные новости. Так вот в этом случае мы чувствуем, что у нас нет возможности решить эту проблему, а готового результата нет, тогда мы говорим, что делаем что-то сами. Примерно в 2010 году мы сделали первую версию, которая начала делать kafka. Позиционирование первой версии также очень простое, мы просто хотим сделать ее системой сообщений с высокой пропускной способностью, а большой объем памяти — наша самая важная цель.
Распределенная архитектура
В следующих словах мы поговорим о том, как мы добиваемся высокой пропускной способности. Первое, что мы сделали с высокой пропускной способностью, это то, что в первой версии coffee мы сделали распределенную структуру. Многие люди, знакомые с Kafka, знают, что в Kafka есть три уровня: средний уровень плюс сервисный уровень — это производственная сторона, а ниже — потребительская сторона. Сервер обычно имеет один или несколько узлов.Основная концепция называется перетиранием сообщений.Этот источник сообщений может быть разделен, и каждый раздел может быть размещен на определенном жестком диске определенного узла, поэтому, если вы хотите увеличить пропускную способность, самый простой Способ заключается в том, чтобы увеличить количество машин в кластере, чтобы иметь больше ресурсов. Будь то с точки зрения хранилища или пропускной способности, у вас может быть больше ресурсов для получения большого количества данных. Точно так же, что мы делаем на стороне производства и на стороне потребителя. также представляет собой этот многопоточный дизайн. В любом случае у вас могут быть тысячи таких потоков-производителей и потоков-потребителей, записывающих или считывающих данные из карстового кластера. Таким образом, этот дизайн означает, что в нашем первом классе есть много вещей, некоторые старомодные системы обмена сообщениями.
Простое и практичное хранилище журналов
Второй момент, который мы делаем, — это использование структуры хранения журнала, которая также очень проста, но является очень эффективной структурой хранения, поэтому, вероятно, некоторые из ее структур являются разделами каждого источника сообщений, и будет соответствующий журнал. к такой структуре журнала, и вся структура журнала и жесткий диск связаны вместе, будут храниться через жесткий диск. В этой структуре каждый маленький квадратик соответствует сообщению, у каждого сообщения есть код, и код постоянно увеличивается.Если вы продюсер, то, что вы делаете, это записываете сообщение, которое хотите записать в журнал.В конце , вы получите новый и больший журнал кода сообщения, а затем отправите его потребителю по порядку. В каком порядке вы его запишете, в каком порядке он будет отправлен потребителю. Преимущество этого в том, что, начиная с со стороны потребителя ваши накладные расходы очень малы, потому что вам не нужно запоминать все сообщения на стороне потребителя, вам нужно только помнить кодовое имя последнего сообщения, которое он потребил. Затем помните об этом, он может продолжать потребление с этого места, потому что мы знаем, что все сообщения отправляются по порядку, поэтому все сообщения до этого сообщения должны были быть использованы.
две оптимизации
Эта конструкция имеет ряд преимуществ.Первым преимуществом является то, что ее режим доступа очень способствует оптимизации, так как не только с точки зрения записи, но и с точки зрения чтения это линейная запись, и чтение также начинается с определенной позиции Линейное чтение. Так что с этой точки зрения операционной системе и файловой системе выгодно оптимизировать свою производительность. Второй момент заключается в том, что наша система может поддерживать множественное потребление одновременно.В любой момент времени у вас может быть один или несколько потребителей.Потребитель может начать потребление с этого места, а другой потребитель может начать потребление с другого места.Потребление, но независимо от того, сколько у вас потребителей, эти данные сохраняются только один раз, поэтому с точки зрения хранения их производительность не имеет ничего общего с тем, сколько раз вы их потребляете. Еще один момент не очень очевиден: поскольку наши журналы хранятся на жестком диске, мы можем одновременно получать потребителей в реальном времени, а также можем принимать некоторых не в реальном времени пакетных потребителей. Но поскольку все данные находятся на жестком диске, у нас может быть очень большой кеш, так что независимо от того, работаете ли вы в режиме реального времени или нет, метод обслуживания со стороны потребителя является набором, ему не нужно выполнять различные оптимизации, Только проблема в том, что мы полагаемся на операционную систему, чтобы решить, какие данные доступны потребителям из памяти, а какие нужно считывать с жесткого диска. Но конструкция этой рамы такая же. Наконец, мы сделали такую высокую пропускную способность. Мы сделали две небольшие оптимизации. Эти две оптимизации связаны между собой. Первая оптимизация — это пакетная обработка. Все три уровня находятся на стороне сервера. Мы только что упомянули об этом. Сообщение должно храниться в журнал на жестком диске, но у него есть определенные накладные расходы для записи на жесткий диск, поэтому мы не записываем каждое сообщение на жесткий диск немедленно, а обычно ждем некоторое время, когда мы накопим достаточное количество. После отправки сообщения, он будет записываться на жесткий диск партиями, поэтому, хотя у вас все те же накладные расходы, ваши накладные расходы распределяются на множество сообщений, и то же самое верно на производственной стороне.Если вы хотите отправить сообщение, мы обычно также вместо этого отправки этого сообщения в качестве удаленного запроса на сервер сразу, мы также немного подождем, надеясь дождаться еще нескольких сообщений, чтобы упаковать их вместе и отправить на сервер. Сжатие данных связано с пакетной обработкой. Наше сжатие также выполняется для пакета данных, и это сквозное сжатие. Если вы включите функцию сжатия, мы будем ждать пакет данных на производственной стороне. Подождите пока пакет данных не будет завершен.После этого мы будем сжимать этот пакет данных вместе, и сжимать пакет данных, и часто получаем лучшую степень сжатия, чем это сжатие для каждого сообщения. В разных сообщениях часто бывает несколько таких повторов, и тогда сжатые данные будут отправляться от производителя на сервер, а сервер будет хранить сжатые данные в логе и отправлять их потребителю в сжатом формате до момента потребления. потребляет сообщение, мы распаковываем сообщение. Таким образом, если вы включите сжатие, мы не только сократим накладные расходы на сеть, но и на ресурсы хранения, поэтому оба эти способа являются очень эффективными способами достижения такой высокой пропускной способности. Итак, наша первая версия kafka заняла около полугода, но нам потребовалось чуть больше времени, чтобы применить ее к линии данных LinkedIn, потому что в LinkedIn много микросервисов, вероятно, в нашем Это было сделано в конце 2011 года, и это были некоторые основные количества в то время.
На производственной стороне у нас были сотни тысяч созданных сообщений, а затем были потреблены миллионы сообщений.В то время эти данные все еще были очень значительными, а у LinkedIn в то время были сотни микросервисов и десятки тысяч микросервисов. и, что более важно, после того, как мы сделали это, мы добились демократизации данных в этой области. До kafka, если вы были инженером или менеджером по продукту в LinkedIn, или аналитиком данных, и хотели сделать какой-то новый дизайн или новые приложения такого рода, самая трудная проблема заключалась в том, что вы не знали, как это сделать. интерфейса используется для его чтения, и я не знаю, полны ли данные. После создания kafka мы значительно упростили эту проблему и значительно освободили способность инженеров к инновациям. Итак, получив успешный опыт и почувствовав, что эта система kafka очень полезна, мы сделали еще несколько разработок в будущем.Разработка второй части в основном предназначена для некоторой поддержки такого рода высокой доступности.
Kafka Version 2: высокая доступность
В первой версии каждое сообщение хранится только на одном узле, и если этот узел отключится, данные не будут получены. Если машина будет повреждена навсегда, ваши данные также будут потеряны. Поэтому, когда мы делали вторую версию, мы добавили часть этой высокой доступности, и метод реализации заключался в добавлении этого механизма множественного копирования. Если в группе несколько узлов, то мы можем избыточно хранить сообщение на нескольких копиях, и один и тот же маленький цвет — это несколько разных копий. В той же ситуации, если одна из ваших машин выходит из строя, другой знак, если есть такие же копии, он может продолжать предоставлять услуги с теми же данными. Таким образом, во второй версии мы можем расширить объем данных, которые она может включать, не только для этих нетранзакционных данных, но и для некоторых транзакционных данных, которые необходимо собрать.
В 2000 году мы тоже сделали одну вещь.В том году проект kafka был передан в дар Apache Foundation.Когда мы это делали,мы думали,что построенная нами система как минимум очень полезна внутри поля.Потом посмотрим Посмотрите, будет ли это полезно для других компаний, и другие интернет-компании также могут счесть это полезным, но я не осознавал, что после открытого исходного кода у него очень широкий спектр использования, поэтому часто это сетевое расположение, а не только ограниченное к такого рода интернет-компаний, но и всей отрасли. Пока у вашей компании есть некоторые из этих данных в режиме реального времени, вы можете использовать все, что вам нужно для их сбора. Основная причина заключается в том, что различные традиционные предприятия также проходят этот процесс оцифровки программного обеспечения. Есть некоторые традиционные отрасли, сила которых в прошлом могла быть в этих традиционных производственных отраслях или в некоторых розничных торговых точках, но теперь они должны быть относительно сильны в программном обеспечении или данных. Затем Kafka обеспечивает очень эффективный канал для многих предприятий от интеграции данных в реальном времени. На следующем этапе мы испытали разработку kafka в течение нескольких лет, зная, что она все более и более широко используется, поэтому мы хотим сделать что-то, посвященное kafka, потому что это работа на полный рабочий день, поэтому мы ушли в 2014 году. LinkedIn основал Confluent. В этой компании мы хотим обеспечить удобство для всех видов предприятий, и его можно использовать более широко.Сейчас в нашей компании работает более 200 человек.
Развитие Кафки
Давайте поговорим о разработках, которые мы сделали за 14 лет. После этого мы в основном делали две вещи в kafka, первая была связана с функциями уровня предприятия, а эта в основном была связана с интеграцией данных. Второй блок связан с обработкой потоков данных. Тогда мы будем говорить немного о двух аспектах. Это пропускается. В мире предприятия, мы сделали большую часть, которая связана с интеграцией данных вещи о которой мы говорили в самом начале. Для многих таких компаний, если у вашей компании долгое время, вы обнаружите , что ваши источники данных разбросаны во многих системах. То , что мы только что сказали, что это очень удобно иметь Кафки. Вы можете извлечь эти данные, но разные Если вы являются компании, вы не хотите , каждая компания читать вещи , чтобы сделать свой собственный набор вещей, так что есть две части в нашем проекте. Первая часть является то , что она имеет платформу часть, которая извлекает много общего. Выйди и сделать модуль. Например, вам нужно сделать некоторое распределение данных, что вам нужно сделать некоторую параллельную обработку, и вы также должны сделать некоторые такие обнаружения неисправностей. После обнаружения, вы можете сделать некоторые данные балансировки, поэтому эти общие вещи все в этом модуле, есть открытый интерфейс в этом модуле, который может быть использован для разработки и реализовать подключение различных различных источников данных. На передающей стороне данных, мы можем сделать что-то подобное, если мы хотим, чтобы искать какую-то реплику, так что это первая часть мы делаем.
Второй блок выполняет аспект, связанный с потоком данных. Если у вас есть такая система, как Kafka, которая может собирать много данных в режиме реального времени, первоначальное использование будет платформой для передачи данных. Но мы думаем, что со временем кафка может быть не только ограничена платформой передачи, но также может стать платформой для обмена и сотрудничества.После того, как данные в реальном времени доступны, вы часто делаете некоторые вещи, например, вы хотите сделать что-то такие потоки данных. , например, для передачи данных из одного формата в другой формат, вы также можете захотеть сделать некоторое расширение данных, например, у вас есть поток данных, который содержит некоторую информацию о данных, но только кодовое имя пользователя , пользователи не имеют конкретной информации о данных, но у вас может быть много более подробной информации о пользователях в базе данных.Если вы можете объединить эти две информации вместе, поток данных будет богаче, что позволит вам делать все более и более эффективные операции. Кроме того, вы также можете захотеть выполнить некоторую агрегацию данных в реальном времени.В приложении мы хотим упростить эту часть.
Будущее Кафки.
Я думаю, что в будущем система kafka станет не только платформой для сбора и передачи данных в реальном времени, но также может стать платформой для обработки большего количества потоков данных, обмена и совместного использования, если она будет развиваться с течением времени, поэтому мы будем делать больше. в этом направлении. В будущем, когда многие приложения станут шире, мы думаем, что многие приложения будут становиться все более и более приложениями реального времени. Таким образом, на этой основе у нас может быть сильная экосистема на kafka.
Наконец, позвольте мне поделиться с вами небольшой историей. Эта история об одном из наших пользователей в Северной Америке.Этот банк является относительно традиционным старым банком и был историческим банком на протяжении десятилетий.Проблема, которая существовала в течение длительного времени, заключается в том, что его данные очень разбросаны. Итак, если вы являетесь клиентом этого банка, у вас может быть счет в банке, у вас может быть кредит, у вас может быть страховка, у вас может быть кредитная карта, вся предыдущая информация об этом клиенте, потому что она отличается. коммерческий сектор, это все совершенно отдельно. Если вы продавец банка, ваша беда в том, что вы не можете знать всю информацию об этом клиенте. Эта компания разработала проект, связанный с Kafka. Проект состоит в том, чтобы собирать всю информацию из различных источников данных о клиентах в режиме реального времени, а затем передавать эту информацию десяткам тысяч своих продавцов. При совершении продаж будет более эффективная информация в режиме реального времени, чтобы давать более целевые рекомендации клиентам, поэтому этот проект очень успешен.
Для получения дополнительной информации о совместном использовании щелкните ссылку ниже:
спросите.autobots.com/draft/11844…
вопросы и ответы
Как использовать apache kafka против apache storm?
Связанное Чтение
Chen Xinyu: применение CKafka в системе распознавания лиц PASS
Ян Юань: Практика автоматизированных операций Tencent Cloud Kafka
Бай Юйцин: знание дизайна и реализации платформы kafka на основе Kubernetes.
Эта статья была разрешена автором для публикации сообщества Tencent Cloud +, исходная ссылка: https://cloud.tencent.com/developer/article/1114675?fromSource=waitui.