Управляемое чтение
В этой статье представлены некоторые мысли и методы подробного доступа к информации о точках интереса в AutoNavi Maps в процессе платформизации.От первоначального отдельного приложения, с проблемами развития бизнеса, предлагаются идеи и решения для решения проблем с точки зрения бизнеса, и затем она превращается в процесс технического проектирования и реализации.
задний план
POI — это аббревиатура Point of Interest, то есть информация о местоположении, которую мы обычно понимаем. Для обычных пользователей,В дополнение к основной информации, такой как имя и координаты, данные POI также будут отображать изображения, комментарии, деловую информацию и т. д., которые мы в совокупности называем подробной информацией.. Являясь прямым отражением реального онлайн-мира, его богатство, точность и свежесть играют решающую роль в решениях пользователей о путешествиях, а также являются основой AutoNavi для обслуживания населения в различных аспектах, таких как жизненные услуги.
Чтобы обогатить информацию о глубине, мы соединяем собранные данные различными способами. Каждый источник доступа к данным называется CP (Content Provider). Когда сначала было всего несколько CP, каждый CP создавал приложение с полностью независимым хранилищем, независимым кодом и даже совершенно другим стеком технологий.
Однако по мере того, как масштаб доступа продолжает увеличиваться, эта модель единого ответа постепенно перестает поддерживаться, а невозможность массового производства, обновления, эксплуатации и обслуживания, мониторинга и других проблем стала камнем преткновения на пути бизнес-итераций. и все тратят энергию на базовое обслуживание и другие вопросы, пропорция даже превышает бизнес-итерацию.
Набор данных используется для иллюстрации скорости развития глубокого бизнеса: около 130 рабочих дней в квартале, количество новых обращений к задачам достигло более 120. На сегодняшний день общее количество доступных задач более чем в 100 раз превышает количество сотрудников отдела исследований и разработок, а объем данных, обрабатываемых за один день, составляет один миллиард. Основываясь на предварительном суждении об этой тенденции, команда Deepin заранее начала изучение платформизации.
Практика платформы
Идея платформизации понятна, но существует множество различных вариантов конкретного дизайна и реализации платформизации.
Цели проектирования большинства систем доступа к данным относительно чисты: в качестве системы доступа, пока данные получены и введены в бизнес-систему, остальные, такие как анализ данных и бизнес-обработка, снова обрабатываются другими нижестоящими системами. Только тогда можно формируются реальные бизнес-данные, то есть система доступа не имеет состояния с самого начала проектирования, а понимание самих данных в принципе не имеет отношения к бизнесу.
Однако, учитывая специфику бизнеса AutoNavi по доступу к информации, мы не использовали это решение при создании платформы, а приняли более интенсивный образ мышления.Платформа доступа сама по себе должна иметь полное представление о данных, а не только ответственность. для доступа к данным, но также отвечает за анализ данных, выравнивание измерений, отображение спецификаций и обслуживание жизненного цикла и другой связанный контент, платформа напрямую построила всю логику управления процессом глубокой обработки информации.
Кроме того, в отличие от системы общего доступа, в дополнение к исследованиям и разработкам (RD), продукт (PM) также является первым пользователем системы Платформа должна иметь возможность позволить PM самостоятельно завершить весь процесс доступа к данным при условии понимания ограниченных технических ограничений, анализа и отладки, что выдвигает чрезвычайно высокие требования к возможностям отладки проекта WYSIWYG в реальном времени платформы. С точки зрения конструкции платформы необходимо решить следующие трудности:
-
Неравномерный масштаб данных: объем данных и объем данных разных CP сильно различаются.Некоторые источники содержат сотни миллионов единиц данных, а наименьшая CP даже имеет только одну часть данных. В частности, размер каждых данных также очень разный, например, некоторые данные могут достигать 7,5М, а некоторые имеют только одно поле, всего несколько байт.
-
Бизнес-сценарии не сходятся: существует множество сложных источников подробных данных: в экономике есть интерфейсы трехстороннего сотрудничества, автономные файлы, OSS, ODPS, MetaQ и т. д., а также структура данных CP и правила сопоставления ассоциаций. разнообразны и непредсказуемы, требуя, чтобы платформа могла проектировать Поддерживает выравнивание размеров в различных сценариях.
-
Логика сопоставления и очистки сложна: есть еще один момент, отличающий его от обычного бизнеса: глубинные данные AutoNavi организованы в JSON с относительно свободной схемой, с несколькими слоями вложенных объектов и полей массивов, а спецификации разных отраслей разные.Необходимо организовать данные почти в сотню наборов данных с различными спецификациями.Обработка данных этой рыхлой, неплоской двумерной таблицы также является одной из проблем, особенно в сценарии контекста массива.
Наконец, мы разработали архитектуру платформы, как показано на рисунке Платформа объединяет четыре модуля: фундамент, преобразование, отправка и планирование задач, а также взаимодействует для выполнения всей работы по углубленному доступу к информации.
Платформа разделена на несколько модулей:
базовый модуль: Отвечает за размещение в Интернете базовой информации, такой как CP, отрасль, спецификации и разрешения для достижения единого управления.
модуль преобразования: Отвечает за сбор данных, согласование размеров, отображение спецификаций и т. д.
толкающий модуль: Отвечает за отправку преобразованных данных спецификации в нижестоящую службу доступа.
модуль задач: отвечает за управление задачами, такими как типы задач, политики невыполненных работ и различия в данных.
Конструкция двигателя преобразования
Модуль преобразования состоит из четырех частей: механизма преобразования, менеджера преобразования, дизайнера и отладчика.
Чтобы уменьшить сложность проектирования системы, все настраиваемые части бизнес-правил поддерживаются модулями преобразования. Будучи модулем с наивысшей степенью свободы бизнеса, модуль преобразования использует тот же нижний уровень для поддержки трех сценариев предварительного преобразования, преобразования и анализа данных бизнеса верхнего уровня.Это основная часть системы, которая может поддерживать различные сложные бизнес-сценарии Механизм преобразования должен поддерживать сбор данных, наиболее сложную и изменчивую часть функций конфигурации и отладки, таких как выравнивание размеров и очистка сопоставления спецификаций.
Сбор данных
Возможность сбора данных должна не только поддерживать общие сервисы HTTP, OSS, ODPS, MTOP, MetaQ и Push, но также поддерживать комбинацию и наложение. Например, сначала загрузите файл из OSS, проанализируйте строку файла, а затем вызовите службу HTTP в соответствии с проанализированными данными.
Чтобы поддерживать почти бесконечные возможности бизнес-наложения и эффект дизайна WYSIWYG, мы исследовали различные решения внутри и за пределами экономики Ali, такие как платформы Blink и Stream, и не нашли компонентов, которые могли бы напрямую удовлетворить наши бизнес-потребности. основная проблема для:
-
Организации, основанные на технических аспектах, требуют большого количества кодирования или понимания технической семантики и не могут обеспечить бизнес-перспективу.Существуют большие препятствия для понимания и использования данных PM.
-
Пошаговое представление данных представляет собой плоскую двумерную таблицу, которую нельзя передать и обработать в свободной структуре. Слишком сложно настраивать бизнес-ограничения и протоколы между этапами.
-
Отладка в режиме реального времени без побочных эффектов не может поддерживаться, и данные запущенного процесса и процесса отладки будут загрязнять друг друга.
Основываясь на приведенном выше анализе, мы решили не проводить вторичную разработку на вышеуказанных платформах, а настроить набор движков непосредственно на основе текущего бизнес-сценария.Хотя эти движки нельзя использовать напрямую, пошаговая организация и метод вождения PDI соответствуют нашим бизнес-сценариям.Учитывая степень свободы, выразительности и интуитивности, механизм преобразования отказывается от DAG, которая представляет собой относительно простую техническую модель, основанную на вычислениях и параллельном планировании, и использует модель ориентированного графа, аналогичную PDI для организации.
Выравнивание размеров
Выравнивание измерений относится к интеграции данных из различных источников данных и измерений в данные определенного измерения посредством заданной ассоциации бизнес-правил.Например, подробный информационный бизнес обычно необходимо интегрировать в данные измерения POI. Теоретически, с предоставленным механизмом возможность интуитивного выражения и объединения сервисов может удовлетворить требования размерного выравнивания. Тем не менее, все еще существует проблема, которую необходимо решить для получения подробной информации, то есть перед лицом необходимости отладки данных PM в реальном времени, независимо от того, сложное или простое преобразование, необходимо иметь возможность отладки на в любое время, а результаты могут отображаться интуитивно, что удобно для быстрого анализа данных и устранения неполадок.
Обычный ETL будет включать в себя проблему выравнивания измерений, но поскольку обычный бизнес, как правило, представляет собой ассоциацию и интеграцию двумерных таблиц данных, такие решения, как PDI, в основном обрабатываются с помощью решения SQL + временной таблицы, которое связывается во время проектирования. , Учитывая ввод и вывод, нет существенной разницы между отладкой и запуском, или конфигурацию необходимо изменить во время отладки, чтобы принудительно вывести вывод во временное хранилище, а это означает, что механизм преобразования должен полагаться на определенную внешнюю среду ( например, конкретная таблица базы данных), вызывая отладку и запуск.Данные будут загрязнять друг друга.
Наши данные, естественно, не являются двумерной структурой и не могут быть выложены в таблицу, поэтому, естественно, эту схему использовать нельзя. Мы полагаемся только на локальную память + диск для обработки данных.Например, требования фрагментации данных flatten напрямую реализуются в памяти, без необходимости хранения; например, объединение слиянием и другие возможные операции перекрестного перехода полных данных напрямую использовать локальные диски В качестве помощника все функции реализованы без поддержки внешней специальной среды.Придерживаясь этой идеи, мы наконец реализовали движок конвертации со следующими возможностями:
чистый двигатель
- Данные не записываются и записи выполнения не создаются.
- Независимость от задач и специальных сред выполнения.
- Может быть инициализирован и выполнен в любое время.
утечка данных
Конфигурация преобразования не требует указания вывода, шаг вывода данных динамически перехватывается.
Различные менеджеры сцен: сцена задачи будет записана в БД, а сцена отладки будет отправлена обратно на страницу внешнего интерфейса через WebSocket.
С таким движком, учитывая требования сцены отладки, при преобразовании больше не нужно указывать цель вывода во время проектирования, и цель вывода будет динамически связываться менеджером сцены в соответствии со сценой отладки и сценой нормальной работы во время выполнения. во избежание загрязнения данных. Платформа поддерживает почти все уровни функций отладки и анализа WYSIWYG на стороне Интернета, охватывая почти все ссылки, такие как предварительное преобразование, преобразование, очистка и отправка.
Очистка сопоставления спецификаций
Чтобы поддерживать свободное сопоставление схемы и прозрачное расширение, преобразованная модель строки (RowSchema) по-новому разработана как структура с двумя контейнерами.
-
Основные данные: содержат прямые данные о результатах предшествующих шагов.
-
Панель данных: содержит параметры преобразования, пошаговые переменные, результаты сопоставления и т. д.
Этап сопоставления поддерживает интеграцию сопоставления и очистки с помощью типов сопоставления, правил сопоставления и параметров очистки.
-
Прямое сопоставление: извлечение данных выполняется сверху вниз, в основном путем расширения выражений JSONPath (расширение контекстной семантики, например, основные данные, панель данных, элемент цикла массива и т. д.), дополненное различными типами сопоставления.
-
Обратная очистка: очистка слой за слоем снизу вверх, стратегии могут накладываться произвольно.
Модуль преобразования обрабатывает данные через три уровня шагов, сопоставление и очистку поля.При использовании PM вам нужно только перетащить соответствующие компоненты через веб-интерфейс и просто заполнить некоторые бизнес-параметры для завершения настройки.
Чтобы избежать проблемы «черного ящика» бизнеса, дизайн системы отличается от платформы Stream тем, что компоненты системы обратно совместимы, и не существует понятия версии для подключаемых модулей шага, подключаемых модулей сопоставления и подключаемых модулей очистки. Пользовательские сервисы, которые не поддерживаются системой, могут быть реализованы путем написания скриптов (Groovy) в каждом системном модуле, но загрузка бинарных пакетов не допускается.Код должен быть напрямую отражен в форме конфигурации, чтобы избежать проблем с обслуживанием в дальнейшем.
управление жизненным циклом
Жизненный цикл означает, что система должна инициировать операцию добавления, обновления и удаления данных в соответствующее время. С точки зрения доступа к данным удаление — относительно сложный процесс, который в бизнес-терминах называется автономным. Чтобы прояснить офлайн-проблему, мы должны сначала поговорить о задачной модели глубокой информации.
В настоящее время мы поддерживаем как модели пакетной обработки, так и модели потоковой обработки.Как вы интуитивно понимаете, номер пакета будет увеличиваться каждый раз, когда выполняется пакетное задание, например обычные типы запланированных задач. Потоковая модель означает, что после открытия задачи она всегда будет выполняться, а данные обычно получают пассивно через MetaQ, службы Push и т. д., без концепции пакетов.
Чтобы удовлетворить потребности бизнеса, мы поддерживаем три стратегии: истечение пакета, истечение времени и условное отключение, а также поддерживаем использование нескольких стратегий. У этих стратегий также есть свои собственные соображения при разработке, например, как избежать сканирования записей истории всего пакета, и проблемы общего увеличения номеров пакетов в истории и сценариях повторных попыток, когда срок действия пакета истекает; как избежать привязки времени к каждая запись по истечении времени Количество таймеров, вызванных взрывом устройства, и так далее.
Управление жизненным циклом включает в себя разработку большого количества модулей задач, таких как модель планирования задач и разработка механизма разделения на несколько машин, логическая разработка автоматического выключателя с предупреждением о задаче, разработка таблицы хранения и т. д. Из-за требований интеграции подробных информационных служб, Платформа доступа не выбрана.Открытый исходный код или экономика Али имеют существующую структуру планирования задач, но разработали ее самостоятельно.Из-за ограниченного места я не буду обсуждать это здесь.
Сводная перспектива
Платформа углубленного доступа к информации стала свидетелем быстрого развития углубленного доступа AutoNavi в течение нескольких лет.Он поддерживает глубокое культивирование AutoNavi в различных вертикальных областях с чрезвычайно низким участием человека и обеспечивает расширение AutoNavi до высокочастотных приложений жизненных услуг. Поддерживается базовыми данными. В будущем мы продолжим углубляться и развиваться в области полнофункциональной отладки, усовершенствованной поддержки сценариев работы, нестандартной обработки данных и бесплатной платформы оркестрации сервисов.