Databook: с помощью метаданных Uber превращает большие данные в знания

Архитектура рептилия Программа перевода самородков Uber

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

Благодаря сложности системы и объему данных Uber выводит управление данными на новый уровень: обработка триллионов сообщений Kafka в день в нескольких центрах обработки данных.HDFSХраните сотни петабайт данных и выполняйте миллионы аналитических запросов в неделю.

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

Экспоненциальный рост бизнеса (и данных)

С 2016 года на платформу Uber было добавлено несколько новых предприятий, в том числеUber Eats,Uber Freight,а такжеJump Bikes. Сегодня мы совершаем не менее 15 миллионов поездок в день и ежемесячно обслуживаем более 75 миллионов активных пассажиров. За последние восемь лет Uber вырос из небольшого стартапа до 18 000 сотрудников по всему миру.

С этим ростом приходит сложность систем данных и инженерных архитектур. Например, существуют десятки тысяч таблиц, разбросанных по нескольким активным механизмам анализа, включаяHive,PrestoиVertica. Эта фрагментация привела к острой необходимости в полной картине информации, особенно в связи с тем, что мы продолжаем добавлять новые предприятия и новых сотрудников. В 2015 году Uber начал вручную поддерживать некоторые статические HTML-файлы для индексации таблиц.

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

Рисунок 1. Databook — это внутренняя платформа Uber, которая предоставляет метаданные о внутренних местоположениях и владельцах и управляет ими.

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

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

  • Расширяемость:Легко добавлять новые метаданные, хранилища и записи.
  • Доступность:Все метаданные могут быть получены сервисом программно.
  • Расширяемость:Поддерживается чтение с высокой пропускной способностью.
  • Особенность:Чтение и запись в центрах обработки данных.

Databook предоставляет широкий спектр метаданных из Hive, Vertica,MySQL,Postgres,Cassandraи несколько других внутренних систем хранения, в том числе:

  • схема таблицы
  • Описание таблицы/столбца
  • образец
  • Статистические данные
  • Восходящие и нисходящие отношения
  • Свежесть, SLA и владелец стола
  • Классификация персональных данных

Все метаданные доступны через централизованный пользовательский интерфейс иRESTful APIпосещать. Пользовательский интерфейс делает метаданные легко доступными для пользователей, а API позволяет использовать метаданные в Databook другими сервисами и вариантами использования Uber.

Хотя уже былиWhereHowsЭто решение с открытым исходным кодом, которое Uber не принял во время разработки Databook.Игровая структураиGradle(Примечание переводчика: оба являются зависимостями WhereHows). А в WhereHows отсутствовала поддержка чтения и записи между центрами обработки данных, что было критически важно для наших потребностей в производительности. Итак, используя мощь и развитую экосистему самой Java, мы создали собственное решение.

Далее мы познакомим вас с нашим процессом создания Датабука и проблемами, с которыми мы столкнулись на этом пути.

Архитектура датабука

Архитектуру Databook можно разделить на три части: сбор метаданных, хранение метаданных и отображение метаданных. На рисунке 2 ниже показана общая архитектура инструмента:

Рис. 2. Архитектура Databook. Метаданные извлекаются из Vertica, Hive и других систем хранения, хранятся во внутренней базе данных и экспортируются через RESTful API.

Databook принимает в качестве входных данных несколько источников данных, сохраняет соответствующие метаданные и выводит их через RESTful API (которые используются пользовательским интерфейсом Databook).

При разработке Databook в первый раз нам пришлось принять важное решение: следует ли нам заранее собирать метаданные и хранить их или ждать, пока они нам понадобятся? Наша служба должна поддерживать чтение с высокой пропускной способностью и малой задержкой, и если мы возлагаем это требование на источники метаданных, все источники метаданных должны поддерживать чтение с высокой пропускной способностью и малой задержкой, что создает сложность и риск. Например, запрос Vertica на получение схемы таблицы обычно обрабатывается несколько секунд, что не подходит для визуализации. Точно так же наше хранилище метаданных Hive управляет всеми метаданными Hive, что делает рискованной поддержку запросов на чтение с высокой пропускной способностью. Поскольку Databook поддерживает множество различных источников метаданных, мы решили хранить метаданные в собственной схеме Databook. Кроме того, в большинстве случаев использования, хотя и требуются свежие метаданные, не требуется наблюдение за изменениями метаданных в режиме реального времени, поэтому возможен периодический сбор данных.

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

Рис. 3. Databook состоит из двух отдельных прикладных уровней: сканера сбора данных и уровня службы запросов.

Два слоя изоляции уменьшают побочные эффекты. Например, задание обходчика сбора данных может занимать много системных ресурсов, и если оно не изолировано, это повлияет на SLA API на уровне службы запросов. Кроме того, по сравнению с сервисным уровнем запросов Databook, уровень сбора данных менее чувствителен к прерываниям.Если уровень сбора данных зависает, он может гарантировать, что предыдущие метаданные все еще доступны, тем самым сводя к минимуму влияние на пользователей.

Приобретение, управляемое событиями, против сбора по времени

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

Сначала мы создали сканеры для периодического сбора метаданных о наборах данных, созданных различными источниками данных и микросервисами, таких как статистика использования таблиц, которая используется нашим мощным инструментом с открытым исходным кодом для разбора и анализа SQL.Queryparserгенерировать.(Кстати: Queryparser также был создан нашей командой Data Knowledge Platform).

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

Тем не менее, мы все же решили использовать Quartz, чтобы воспользоваться его мощными возможностями планирования в памяти, чтобы упростить и повысить эффективность размещения задач в нашей очереди задач. Для очереди задач Databook мы используем среду выполнения задач Uber с открытым исходным кодом.Cherami. Этот инструмент с открытым исходным кодом позволяет нам разделить потребительские программы в распределенной системе, позволяя им асинхронно взаимодействовать между несколькими потребительскими группами. С Cherami мы развернули сканеры в контейнерах Docker на разных хостах и ​​в нескольких центрах обработки данных. Использование Cherami позволяет получать различные метаданные из нескольких разных источников, не блокируя какие-либо задачи, сохраняя при этом потребление ЦП и памяти на идеальном уровне и ограничивая его одним хостом.

Хотя наш поисковый робот работает с большинством типов метаданных, некоторые метаданные необходимо обрабатывать практически в режиме реального времени, поэтому мы решили перейти на архитектуру, управляемую событиями, на основе Kafka. Благодаря этому мы можем своевременно обнаруживать и устранять сбои данных. Наша система также может фиксировать существенные изменения в метаданных, таких как взаимосвязь восходящего и нисходящего потоков данных и актуальность, как показано на рис. 4 ниже:

Рис. 4. В Databook для каждой таблицы собираются метаданные восходящей и нисходящей связи/актуальности.

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

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

Как мы храним метаданные

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

Ассоциативный при записи

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

Рис. 5. Databook сохраняет метаданные, не зависящие от кластера, во всех таблицах.

Эта схема гарантирует, что постоянные данные останутся чистыми. Например, на рисунке 5, если «столбец 1» не существует, кластер отклонит запрос. Но у этого есть важная проблема: чтобы связать метаданные, не зависящие от кластера, с метаданными, относящимися к кластеру, во время записи, все метаданные, связанные с кластером, должны уже существовать, что является единственным шансом во времени. Например, если изменить описание столбца таблицы на рисунке 5, только кластер 1 будет иметь этот «столбец 1», а запись кластера 2 завершится ошибкой. После этого схема для той же таблицы в кластере 2 обновляется, но возможность упускается, и это описание никогда не будет доступно, если мы не будем периодически повторять попытку записи, усложняя систему. На Рисунке 6 ниже показана эта ситуация:

Рис. 6. Databook сохраняет метаданные, не зависящие от кластера, во всех таблицах.

ассоциация времени чтения

Еще один способ достичь цели — сопоставить метаданные, не зависящие от кластера, и метаданные, зависящие от кластера, во время чтения. Поскольку эти два вида метаданных пытаются связать при чтении, не имеет значения, существуют ли временно метаданные, связанные с кластером, поэтому это решение может решить проблему потери метаданных в ассоциации при записи. Когда схема таблицы обновляется для отображения «столбца 1», его описание будет объединено, когда пользователь его прочитает, как показано на рис. 7 ниже:

Рис. 7. Databook сопоставляет метаданные, зависящие от кластера, и метаданные, не зависящие от кластера, при чтении.

варианты хранения

Серверная часть Databook изначально использовала MySQL из-за его быстрой скорости разработки и автоматической настройки через инфраструктуру Uber. Однако когда дело доходит до поддержки нескольких центров обработки данных, общий кластер MySQL не идеален по трем причинам:

  • Один главный узел: во-первых, Uber поддерживает только один главный узел, что приводит к замедлению времени записи в других центрах обработки данных (в нашем случае увеличение примерно на 70 мс на одну запись).
  • Повышение привилегий вручную. Во-вторых, в то время автоматическое повышение привилегий не поддерживалось. Поэтому, если главный узел умирает, продвижение нового главного узла может занять несколько часов.
  • Объем данных. Еще одной причиной, по которой мы отказались от MySQL, был объем данных, генерируемых Uber. Мы намерены сохранить все исторические изменения и хотим, чтобы наша система поддерживала расширение в будущем, не тратя слишком много времени на обслуживание кластера.

По этим причинам мы выбрали Cassandra, а не MySQL, потому что он имеет мощную поддержку репликации XDC, что позволяет нам записывать данные из нескольких центров обработки данных без увеличения задержки. А поскольку Cassandra линейно масштабируется, нам больше не нужно беспокоиться об адаптации к растущему объему данных Uber.

Как мы представляем данные

Databook предоставляет два основных способа доступа к метаданным: RESTful API и визуальный пользовательский интерфейс. RESTful API DatabookDropwizard(фреймворк Java для высокопроизводительных веб-сервисов RESTful), разработанный и развернутый на нескольких компьютерах с балансировкой нагрузки внутренней службой переадресации запросов Uber.

В Uber Databooks в основном используются другими сервисами для программного доступа к данным. Например, наша внутренняя служба синтаксического анализа/перезаписи запросов использует информацию о схеме таблицы в Databook. API может поддерживать чтение с высокой пропускной способностью и может масштабироваться по горизонтали, в настоящее время достигая максимальной скорости около 1500 запросов в секунду. Визуальный пользовательский интерфейс написан на React.js, Redux и D3.js и в основном используется инженерами, специалистами по данным, аналитиками данных и операционными группами по всей компании для сортировки проблем с качеством данных, а также выявления и изучения соответствующих наборов данных.

поиск

Поиск — важная функция пользовательского интерфейса Databook, которая позволяет пользователям легко получать доступ к метаданным таблицы и перемещаться по ним. Мы используем Elasticsearch в качестве нашей полностью индексируемой поисковой системы, которая синхронизирует данные с Cassandra. Как показано на рисунке 8 ниже, с помощью Databook пользователи могут комбинировать поиск по нескольким измерениям, таким как имя, владелец, столбцы и вложенные столбцы, для более своевременного и точного анализа данных:

Рисунок 8: Databook позволяет пользователям выполнять поиск по различным измерениям, включая имя, владельца и столбцы.

Новая глава в Датабуке

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

Если вам нравится создание масштабируемых интеллектуальных сервисов и разработка инновационных и сложных технологий, сочетающих собственные решения и решения с открытым исходным кодом, свяжитесь с Зоей Абрамс (za@uber.com) или подать заявку на нашу командуДолжность!

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории