С наступлением эры больших данных все больше и больше предприятий осознали ценность активов данных. В отрасли принято считать данные важным активом предприятия.Предприятия также быстро изучают сценарии приложений и бизнес-модели и начинают создавать технологические платформы.
Однако здесь следует подчеркнуть, что если управление данными забыто в «головоломке» больших данных, может оказаться бесполезным вкладывать дополнительные средства в технологии. Из-за отсутствия связи управления данными последствия часто таковы: несогласованные данные повсюду, качество данных, которое трудно улучшить, сортировку моделей, которую трудно выполнить, безопасность данных, которую трудно обеспечить, и т. д. построению данных трудно действительно реализовать свою коммерческую ценность.
Поэтому особенно важно устранить несогласованность данных, установить стандартизированные стандарты данных, улучшить возможности управления данными, обеспечить совместное использование безопасности данных и иметь возможность использовать данные как ценный актив предприятия в бизнесе, управлении и принятии стратегических решений. и в полной мере использовать ценность активов данных Срочно и важно, управление данными уже не за горами. В этой статье будут представлены некоторые исследования и практики технической команды доставки Meituan в области управления данными, которые надеются вдохновить и помочь всем.
1. Как понять управление данными
Управление данными, строго определена, является институциональной основой для управления, оценки, направления и мониторинга больших данных организации, используя ее. Путем формулирования стратегической политики, создание организационных структур и разъяснение подразделения обязанностей предприятия могут добиться контроля рисков данных, соответствия безопасности, повышению безопасности и созданию ценностей и обеспечения инновационных услуг. С точки зрения личной практики управление данными является процессом управления и контроля данных акций и дополнительных данных. Данные акций преобразуются из хаоса в управление, правила и правила, а дополнительные данные строго контролируются и не могут быть превышены. Момент ограничения.
2. Цели, которые необходимо достичь
Управление данными не является самоцелью, это всего лишь средство для достижения стратегических целей организации. С точки зрения организационных функций и размера цели управления данными в разных типах организаций совершенно разные.Основываясь на организационных функциях и этапах развития текущей группы данных распределения Meituan, мы надеемся решить проблемы производства данных, производства данных и развитие посредством управления данными Проблемы, возникающие в процессе управления и использования, улучшают существующие спецификации процесса управления производством, обеспечивают безопасность и согласованность данных, чтобы способствовать беспрепятственному обмену данными внутри организации.
3. Когда внедрять управление данными
Определение точки входа в управление данными является ключом к успеху или неудаче управления данными. Многие студенты спросят, если создание хранилища данных разделено на стадию создания прототипа хранилища данных, стадию итерации хранилища данных и стадию подготовки возможностей, на какой стадии следует включить управление данными? На самом деле мы не должны рассматривать управление данными как поэтапный проект, это должен быть долгосрочный проект, который реализует различные этапы построения данных, но на разных этапах объем охвата и преследуемые цели различаются в зависимости от бизнеса и технических аспектов. характеристики.Просто разные.
На начальном этапе цифрового хранилища, то есть, когда дистрибьюторский бизнес Meituan только создавался, на этом этапе бизнес имел две характеристики: во-первых, большие масштабы и быстрое расширение; во-вторых, бизнес быстро менялся и требовал больше данных. Чтобы быстро реагировать на потребности бизнеса и обеспечивать точность результатов доставки данных, мы в основном осуществляем управление техническими спецификациями и показателями.Что касается стандартного управления, мы формулируем ряд спецификаций НИОКР для обеспечения качества НИОКР и фактический процесс моделирования Мы продолжаем повторять и улучшать качество наших НИОКР. Что касается управления индикаторами, мы отсортировали калибры фондовых индикаторов, чтобы обеспечить последовательный внешний вывод калибров индексов.
На этапе итерации хранилища данных мы надеемся изменить модель «дымохода», разработанную на раннем этапе, за счет управления архитектурой, устранения избыточности и улучшения согласованности данных. И по мере того, как все больше данных обрабатывается в хранилищах данных, вопросы безопасности данных и затрат становятся все более важными. Поэтому на данном этапе мы постепенно осуществляем управление архитектурой, управление ресурсами и управление безопасностью на уровне производства и исследований. Что касается управления архитектурой, мы уточнили обязанности и границы каждого уровня и темы в хранилище данных, построили согласованную базовую модель ядра данных и сформулировали ряд спецификаций определения индикаторов, чтобы обеспечить четкое определение индикаторов и постоянно основываться на них. бизнес-итерации Уточнение и итерация соответствующих моделей и спецификаций. Что касается управления ресурсами, мы применяем различные стратегии управления жизненным циклом данных на разных уровнях, чтобы обеспечить удовлетворение самых больших потребностей бизнеса с наименьшими затратами на хранение. Что касается управления безопасностью, мы обеспечиваем безопасность использования данных, формулируя ряд спецификаций безопасности данных.
На этапе выделения мощностей, основываясь на развитии бизнеса и технологий на предыдущих двух этапах, мы сформировали ряд спецификаций на ранней стадии в стандарты, от бизнеса до производства и исследований, чтобы способствовать управлению данными сверху донизу и через создание соответствующих организаций, процессов и системы для обеспечения полной реализации стандарта на данном этапе и содействия внедрению стандарта с более высоким качеством путем создания платформы управления данными.
4. Как осуществлять управление данными
С точки зрения большой стадии управление данными в основном делится на стадию «от хаоса к управлению» складскими данными и операционную стадию добавочных данных, строго реализуемую в соответствии с правилами и положениями, чтобы гарантировать «не нарушайте правила». ". В процессе «от хаоса к управлению» нам необходимо внедрять правила и положения, стандарты, инструменты и организации, дополняющие внедрение правил, положений и стандартов. На этапе эксплуатации дополнительных данных мы в основном полагаемся на соответствующую организацию для обеспечения выполнения правил и положений, регулярно проверяем эффект внедрения посредством аудитов и постоянно совершенствуем правила и положения в долгосрочной перспективе. На этапе реализации «от хаоса к управлению» данными о запасах мы в основном приняли «двухэтапную» стратегию, и конкретная стратегия реализации выглядит следующим образом.
4.1 Установите стандарты и улучшите качество
На первом этапе основное внимание уделяется бизнес-стандартам, техническим стандартам, стандартам безопасности данных и стандартам управления ресурсами. С помощью бизнес-стандартов направьте передовую команду для завершения нормативного определения показателей и, наконец, достижения цели бизнес-когнитивной согласованности показателей; затем используйте технические стандарты, чтобы помочь студентам, занимающимся исследованиями и разработками, стандартизировать моделирование и решить проблему плохой масштабируемости модели. и избыточность на техническом уровне. проблемы и обеспечение согласованности данных; направлять нас к усилению управления безопасностью данных и контроля с помощью стандартов безопасности, чтобы гарантировать, что данные не могут быть изъяты или изъяты, а пользователи не могут понять конфиденциальные данные; посредством формулировки управления ресурсами стандарты, помогают нам делать все заранее Хороший бюджет ресурсов, хорошее управление ресурсами во время мероприятия и хорошее управление счетами после мероприятия.
4.1.1 Бизнес-критерии
Бизнес-стандарты - это в основном стандарты управления и эксплуатации индикаторов.Мы в основном решаем три проблемы: кто определяет индикаторы, как определять индикаторы и как работать с индикаторами. Исходя из этих трех вопросов, мы предлагаем одновременно три принципа:
- Бизнес-группа отвечает за определение метрик.
- Производственное, исследовательское и коммерческое подразделение отвечает за предоставление стандартов определения индикаторов и вспомогательных инструментов, помогая бизнес-группе завершить нормативное определение индикаторов и достичь цели когнитивной согласованности индикаторов.
- Наконец, комитет по управлению индикаторами отвечает за управление индикаторами и их работу, обеспечивая работу всего жизненного цикла индикаторов от создания, проверки, запуска и окончательной ликвидации.
Чтобы унифицировать определение индикаторов, мы делим индикаторы на атомарные индикаторы, производные индикаторы и производные индикаторы.Атомарные индикаторы генерируют производные индикаторы путем ограничения условий и времени. «Четыре смешанные операции» среди производных индикаторов составляют производные индикаторы. Мы не только сформулировали стандартное определение показателей, но и сделали точную атрибуцию активов.Показатель исходит из конкретного бизнес-процесса, а бизнес-процесс принадлежит к разным предметным областям.Несколько предметных областей составляют бизнес офлайн-доставки Meituan.Сценарий анализа показано на следующем рисунке:
4.1.2 Технические стандарты
Упомянутые здесь технические стандарты в основном относятся к стандартам моделирования и спецификациям производства данных, предложенным Data RD. Через стандарты моделирования определяется иерархическая структура хранилища данных, а также четко определяются границы и обязанности каждого уровня. принята концепция дизайна. Вся наша архитектура хранилища разделена на четыре уровня: уровень операций, уровень основных фактов, средний уровень и уровень приложений, и соответствующие спецификации моделирования формулируются синхронно на каждом уровне, как показано на следующем рисунке:
В дополнение к стандартам моделирования мы также сформулировали производственные спецификации, охватывающие этапы от производства до эксплуатации и обслуживания, чтобы обеспечить качество модели, в основном включая проверку модели перед запуском в эксплуатацию, полную настройку метаданных во время производства, DQC, SLA и настройки жизненного цикла. механизм ежедневной эксплуатации и обслуживания после выхода в интернет и т. д. Специально для управления метаданными и управления жизненным циклом мы разработали отдельно спецификации обслуживания метаданных и спецификации управления жизненным циклом для каждого уровня хранилища.Спецификации управления метаданными основаны на стандартах моделирования различных типов таблиц на каждом уровне хранилища. Чтобы сформулировать, необходимо стандартизировать именование, уточнить атрибуцию данных и открыть связь между бизнес-метаданными и техническими метаданными. Спецификация управления жизненным циклом сформулирована в соответствии с характеристиками дистрибьюторского бизнеса и статусом-кво каждого уровня склада, как показано в следующей таблице:
4.1.3 Стандарты безопасности
Сосредоточив внимание на стандартах безопасности данных, прежде всего, должны быть классификация данных и стандарты классификации, чтобы гарантировать, что данные имеют точный уровень безопасности, прежде чем они попадут в сеть. Во-вторых, для пользователей данных должны существовать четкие стандарты авторизации ролей, а посредством классификации и авторизации ролей важные данные не могут быть украдены. В-третьих, для конфиденциальных данных должны существовать стандарты управления конфиденциальностью, чтобы обеспечить безопасное хранение конфиденциальных данных.Даже если неавторизованные пользователи обходят управление полномочиями для получения конфиденциальных данных, они должны гарантировать, что они не смогут их понять. В-четвертых, формулируя стандарты аудита, он обеспечивает основу для последующих аудитов, чтобы гарантировать, что данные не могут ускользнуть.
4.1.4 Стандарты управления ресурсами
Что касается управления ресурсами, то инженерно-технический отдел распределительных технологий дал разумное абстрактное и точное определение содержания, связанного с управлением ресурсами, абстрагировав такие понятия, как арендаторы, ресурсы и проектные группы. Будь то последующий бюджет ресурсов или управление ресурсами, нам всем нужно работать на основе арендаторов и проектных групп, поэтому для бизнес-команды нам нужно только четко разделить конкретные функции арендаторов и проектных групп, а затем назначить их нам в соответствии с различными функциями актива и выделять ресурсы, необходимые для производства этого актива. Для облегчения последующих операций мы назначили ответственного за каждого арендатора и проектную команду, ответственное лицо несет ответственность за результаты работы.
Для бизнес-подразделений ключом к управлению ресурсами является четкая классификация активов данных, разделение различных арендаторов и групп проектов на основе классификации данных и последовательное сопоставление данных с арендаторами и группами проектов. Поскольку и у арендатора, и у проектной группы есть конкретные ответственные лица, благодаря этим отношениям сопоставления мы не только достигаем изоляции активов, но и реализуем право собственности на активы (руководитель проектной группы одновременно несет ответственность за активы и управляет ими). . Мы разделяем данные на две категории в целом.Одна из них – необработанные данные, включая данные, поступающие в центр обработки данных, и данные центра регистрации данных.Для данных, поступающих в центр обработки данных, они далее делятся на бизнес-данные и трафик в соответствии с тем, как он генерируется. Второй — обработка данных, которая соответствует построению хранилища командой данных и построению рынка другими командами. Основываясь на приведенном выше описании, для управления ресурсами мы разделили и подтвердили права следующим образом:
4.2 Повторная реализация для обеспечения реализации
Второй шаг — внедрить стандарты первого шага, выполнить цели первого этапа управления данными, реализовать «от хаоса к управлению» биржевыми данными и завершить создание соответствующих организаций и инструментов, чтобы достижение второго этапа «не превышать норму» Эта цель предусматривает инструменты и организационные возможности. В этом процессе работа по управлению в основном делится на три аспекта: во-первых, управление архитектурной моделью от хаоса к управлению, устранение избыточности модели, межуровневых ссылок и чрезмерно длинных ссылок, а также обеспечение целостности модели в архитектуре. непротиворечивость данных; во-вторых, управление метаданными от хаоса к управлению, реализация стандартного определения показателей, полный сбор технических метаданных и установление взаимосвязи между показателями, таблицами и полями, а также полное решение проблемы непротиворечивости понимания показателей. усилить управление безопасностью данных и контроль над безопасностью конфиденциальности и безопасностью обмена, чтобы понять, что данные нельзя забрать, нельзя забрать и личные данные нельзя понять.
4.2.1 Управление архитектурой
Подводя итог, можно сказать, что управление архитектурой в основном решает две проблемы: во-первых, гибкость модели, позволяющая избежать влияния изменений спроса и бизнес-итераций на базовую модель, так что RD оказывается в ловушке бесконечных итераций спроса; во-вторых, согласованность данных. устраняет проблемы согласованности данных, вызванные избыточностью модели и межуровневыми ссылками.
Гибкость модели
Распределение решает вопрос о балансе между эффективностью, стоимостью и опытом, то есть как повысить эффективность распространения райдеров, обслуживать больше продавцов и как контролировать райдеров и снизить затраты на дистрибуцию при условии удовлетворения определенного пользовательского опыта. Если абстрагироваться от уровня данных, он в основном отражает изменения в исходных источниках пакетов, изменения в службах доставки, предоставляемых внешнему миру, и изменения во внутреннем управлении бизнесом. Чтобы оградить влияние бизнес-итерации на базовую модель, мы абстрагируем источник пакета, предоставление услуг, бизнес-архитектуру и другие согласованные измерения, инкапсулируя атрибуты пакета извне и атрибуты накладной внутри.Любая бизнес-итерация включает измерения только на уровне данных. Корректировка значительно уменьшила влияние на базовую модель и проблему построения данных в стиле дымохода (когда приходит новый бизнес, просто поднимите ветку для построения).
Одним из ключевых моментов построения системы индексов распределения является вывод показателей масштаба, опыта и эффективности каждого уровня организации для достижения эффективного управления и контроля пропускной способности.Иерархическая взаимосвязь организации, к которой принадлежит пропускная способность будет продолжать меняться с итерацией бизнеса. Чтобы адаптироваться к этому изменению и избежать повторного построения данных на среднем уровне, вызванного добавлением измерений, мы скорректировали таблицу измерений организационного уровня с метода фиксированного иерархического моделирования на промежуточную таблицу, чтобы адаптироваться к изменениям на организационном уровне, таким образом реализация среднего уровня Модель может автоматически адаптироваться к изменениям на организационном уровне и может автоматически генерировать индикаторы новых измерений. Как показано ниже:
В сценарии уточненного анализа у бизнеса будут потребности в анализе данных по периоду времени, сегменту расстояния и ценовому сегменту. Возьмем в качестве примера время, основанное на времени. Существуют разные периоды времени, такие как вечерний пик, дневной пик и полдник. Разные деловые стороны определяют один и тот же период времени по-разному, то есть разные деловые стороны будут иметь разное время. стратегии на основе. Чтобы выполнить требования анализа в этом сценарии, мы удаляем вырожденное измерение в таблице фактов, переносим логику периода времени, изначально инкапсулированную в таблице фактов, в таблицу измерений и масштабируем время в таблице фактов через определенные интервалы как измерение Первичный ключ в таблице, который используется в качестве внешнего ключа к таблице фактов. Таким образом, мы можем настроить таблицу измерений для различных потребностей бизнеса в временной стратегии, избегая проблемы повторной корректировки таблицы фактов и повторных подсчетов. То есть за счет масштабирования фактов времени, цены и расстояния реализуется гибкий размерный анализ. Как показано ниже:
согласованность данных
Одна из фундаментальных причин, по которой согласованность данных не может быть гарантирована, заключается в том, что в процессе моделирования не реализуется маркировка бизнес-калибра, а бизнес-калибр опускается на тематический уровень. Когда многие студенты развиваются на основе потребностей, для удобства реализации новый калибр индикатора упаковывается и разрабатывается на прикладном уровне и среднем уровне с помощью метода «Case When». Итерация бизнеса, и RD находится в процессе разработки.Снимок таблицы хранилища будет непосредственно ссылаться на промежуточный уровень или уровень приложений для завершения разработки требований. Со временем это приведет к снижению возможности повторного использования данных. Калибр одного и того же показателя инкапсулируется в разные таблицы приложений для удовлетворения потребностей разных отчетов. Однако с увеличением количества приложений трудно обеспечить согласованность одних и тех же показателей. без логики упаковки таблиц приложения Трудно обеспечить согласованность данных, и этот метод также влечет за собой два серьезных последствия: во-первых, увеличение межуровневых ссылок, низкая возможность повторного использования данных, что приводит к потерям затрат на вычисления и хранение; во-вторых, когда индикатор изменения калибра были бы «катастрофой», проблема заключается не только в оценке воздействия, но и в настройке логики прикладного уровня с использованием этой метрики, что также является огромной проблемой для RD.
Таким образом, в процессе управления «от хаоса к управлению» мы реализуем маркировку бизнес-калибров, извлекая факты, опуская бизнес-логику на тематический уровень, устраняя такие проблемы, как межуровневые ссылки и избыточность моделей, и гарантируя от технических уровень Согласованность данных находится в центре внимания управления архитектурой на этом этапе. С точки зрения бизнеса, мы разделили строгие предметные области и бизнес-процессы.На уровне построения темы мы берем предметную область, разделенную на бизнес, в качестве нашей темы и проводим многомерное моделирование на основе бизнес-процессов, чтобы инкапсулировать показатели, которые принадлежат бизнесу. в производных фактах по соответствующему бизнес-процессу.
4.2.2 Управление метаданными
Управление метаданными в основном решает три проблемы: во-первых, путем создания соответствующих организаций, процессов и инструментов для содействия внедрению бизнес-стандартов, стандартизации определения показателей и устранения неоднозначности понимания показателей; во-вторых, на основе текущего состояния бизнеса и будущего развития. метод, абстрагируйте бизнес-модель, сформулируйте четкую тему, бизнес-процесс и направление анализа, создайте полные технические метаданные, точно и полностью опишите физическую модель, а также раскройте взаимосвязь между техническими метаданными и бизнес-метаданными и проанализируйте физическую модель. из полной характеристики, в-третьих, за счет построения метаданных, повысить эффективность использования данных, а также решить проблемы «поиска чисел, понимания чисел и оценки» и «принимая числа, визуализация данных» и другие проблемы.
Во-первых, для обеспечения беспрепятственного внедрения бизнес-стандартов и достижения цели согласованности в бизнес-восприятии показателей. Мы сотрудничали с производством и исследованиями, коммерческими подразделениями и бизнес-отделами, чтобы способствовать созданию Комитета мер и весов, а также создали механизм работы с индикаторами для реализации операций с индикаторами в соответствии со стандартными стандартами и процедурами посредством организационных гарантий. Как показано ниже:
Во-вторых, исходя из текущей ситуации и будущего развития дистрибьюторского бизнеса, мы выполнили высокую степень абстракции бизнеса и завершили построение содержания метаданных, таких как темы, бизнес-процессы и направления анализа. Дистрибуция — это логистика С помощью онлайн-систем и офлайн-операций мы эффективно распределяем ресурсы в соответствии с потребностями пользователей в дистрибуции и возможностями Meituan для достижения высокого качества обслуживания и недорогих услуг по дистрибуции. Внешне мы предоставляем услуги распространения пользователям, продавцам и платформам электронной коммерции с помощью платформенного подхода для удовлетворения потребностей в распространении различных пользователей в различных бизнес-сценариях. Внутренне мы отправляем накладную в пуле накладных соответствующему гонщику через различные режимы планирования для выполнения контракта, балансируя соотношение между масштабом, стоимостью и опытом. Как показано ниже:
Основываясь на приведенной выше бизнес-модели, мы разделили тему накладной (построение данных в домене данных о производительности для поддержки требований к анализу данных масштаба и опыта), тему диспетчеризации (данные, созданные в домене данных диспетчеризации, используемые для поддержки анализа стратегии диспетчеризации) ), урегулирование, оценка, жалобы, темы отмены (используемые для поддержки опыта, потребностей в анализе данных о затратах), а также темы управления и контроля (используемые для поддержки поощрений и наказаний, нарушений и потребностей в анализе найма) и другие темы, и разделены на соответствующие темы по каждой теме. На прикладном уровне формулируется метка анализа направления анализа, а абстракция бизнеса завершается путем создания содержимого метаданных, а основные данные готовятся для характеристики физическая модель.
В-третьих, построение службы метаданных, мы открыли всю связь метаданных от сбора до построения и приложения, чтобы повысить эффективность использования данных, решить проблемы «поиска, понимания и оценки» и «получения чисел, визуализации данных». ""проблема. Во всем процессе построения мы фокусируемся на сборе метаданных, построении модели метаданных, службе метаданных и приложении конечного продукта.Общая архитектура показана на следующем рисунке:
Сбор метаданных
Сбор метаданных делится на ручной ввод и автоматическое извлечение.Точная атрибуция физических таблиц (в том числе, какой уровень хранилища, соответствующие темы, бизнес-процессы, отношения звездной модели и т. д.) и сбор показателей реализуются посредством ручного ввода. Таким образом, сбор технических метаданных и бизнес-метаданных завершается, а сбор производственных метаданных и метаданных об использовании завершается посредством автоматического извлечения, в основном включая: зависимости физической модели, занятость хранилища, тепло и другую информацию.
здание метамодели
Он разделен на базовую конструкцию метамодели, основанную на физических таблицах, и метамодели, связанные с кровью, сосредоточенные на крови. Построение базовой метамодели сосредоточено на физической таблице, и реализована связь между ней и техническими метаданными (темой, бизнес-процессом, схемой), реализована четкая принадлежность физической таблицы, связь между физической таблицей и производственные метаданные открываются, и к ним добавляется физическая таблица.Открывается информация о производстве и использовании, такая как тепловая нагрузка запроса таблицы, потребление ресурсов и уровень плотности запросов, и устанавливается соответствующая связь с индикаторами, измерениями и приложениями, и полные метаданные устанавливаются для приложения извлечения данных верхнего уровня. Метамодель родословной сосредоточена на родословной.Она не только строит физическую родословную от вышестоящей бизнес-таблицы до автономной таблицы хранилища, но также открывает родословную от автономной таблицы склада до соответствующего отчета нижестоящего уровня и создает полные метаданные. основу для последующей оценки воздействия.
служба метаданных
Унифицированная служба метаданных (OneService) в основном предоставляет два типа служб метаданных, предоставляя базовые службы метаданных для запроса базовой информации о таблицах, показателях и измерениях, а также службы родословных для запроса кровных родств на уровне таблиц и кровных родств на уровне полей.
приложение метаданных
Были созданы три продукта: карта данных (Wherehows) со сценариями приложений «поиск чисел, понимание чисел и оценка воздействия», визуализация данных (QuickSight) со «поиском чисел, визуализацией данных» в качестве сценариев приложений и управление Управление аудиторские отчеты для целей аудита.
4.2.3 Управление безопасностью
Управление безопасностью в основном укрепляет управление безопасностью конфиденциальных данных и управление безопасностью каналов обмена данными. Благодаря управлению безопасностью личных данных необходимо не только обеспечить их невидимость в процессе хранения, но и обеспечить двойную аутентификацию пользователей в процессе их использования, аутентификацию полей на уровне шифрования и аутентификацию ключа дешифрования; Для управления безопасностью совместного использования данных мы расширяем управление разрешениями данных с управления разрешениями на уровне таблиц до управления разрешениями на уровне строк на основе классификации и классификации данных.
Управление безопасностью конфиденциальных данных
Конфиденциальные данные подлежат безопасности, в основном для решения проблемы безопасности хранения и использования конфиденциальных данных. В автономном режиме безопасность хранения конфиденциальных данных должна решать две задачи:
- Убедитесь, что план обработки на стороне склада не только защищает влияние изменений в вышестоящей бизнес-системе, но и защищает влияние собственной стратегии на нижестоящую систему BI.
- Чтобы избежать распространения конфиденциальных данных по всей цепочке обработки.
Таким образом, чтобы решить проблему отделения решения для складской обработки от вышестоящей бизнес-системы и нижестоящей системы BI, мы гарантируем, что конфиденциальные данные, попадающие на уровень ODS, должны быть в виде открытого текста, когда конфиденциальные данные выше по течению попадают в канал ODS. , Все данные сети зашифрованы, но на уровне использования нисходящий канал прозрачно гарантированно работает нормально в производстве, а разрешения данных уровня ODS ограничены. Данные уровня ODS используются только для безопасного производства.Это решение не только защищает хранилище от вышестоящего решения по обработке, но и решает проблему безопасности конфиденциальных данных. Когда данные покидают хранилище, конфиденциальные данные обратимо обрабатываются в канале передачи, а конфиденциальные данные передаются в библиотеку бизнес-аналитики в виде открытого текста для реализации отделения от нижестоящей системы бизнес-аналитики. Чтобы решить проблему распространения конфиденциальных данных во всей производственной цепочке, мы снижаем чувствительность конфиденциальных данных на уровне моментальных снимков и удаляем конфиденциальные данные со уровня моментальных снимков.Чтобы обеспечить обратимость конфиденциальных данных, конфиденциальные данные на уровне ODS удаляются. извлекаются в репозиторий безопасности и зашифрованное хранилище для обеспечения безопасного и независимого управления. Конкретная реализация показана на следующем рисунке:
При использовании конфиденциальных данных мы достигаем цели безопасного использования конфиденциальных данных, контролируя разрешения конфиденциальных полей и ключей дешифрования. Для отдельно извлеченных конфиденциальных данных, в дополнение к установке соответствующего уровня шифрования для конфиденциальных данных, чтобы обеспечить контроль разрешений на конфиденциальные данные, мы также назначаем идентичный ключ для каждой группы проектов на основе метода шифрования «крипто» и использовать ключ. Он хранится в KMS, интегрированном с кластером Hadoop, для управления (для обеспечения высокого уровня параллелизма автономных вычислений) и для обеспечения контроля доступа к ключам во время расшифровки.
Управление безопасностью общих ссылок
Для управления безопасностью ссылки для обмена мы в основном завершаем иерархическую классификацию и подтверждение прав на данные для данных в ссылке для создания данных, а также завершаем контроль разрешений на уровне таблицы и контроль разрешений на уровне строк для данных в ссылке на использование данных. . Убедитесь, что данные утверждены и распространены стандартизированным образом по ссылке использования, а также проверьте безопасность после открытия центра, чтобы гарантировать, что данные не могут ускользнуть.
Во-первых, мы логически делятся на данные слоя темы или объекта C в соответствии с данными уровня темы или объекта C, в соответствии с данными темы или объекта C, и устанавливают уровень ресурсов и полномочий. В частности, можно контролировать эту цель (то есть аутентификацию уровня строки) в соответствии с бизнес-линией для данных B3, и мы отмечаем контроль разрешений на уровне данных, отметьте использование поля, необходимое для аутентификации, и значение перечисления, соответствующему поле.
Во-вторых, в ссылке на использование мы завершаем утверждение и распространение данных в соответствии с уровнем безопасности активов и ролью пользователя, а также реализуем безопасный обмен данными.
В-третьих, для данных уровня B3 проверьте, установлен ли контроль разрешений на уровне строк. Есть ли несанкционированное использование данных, когда данные открываются, и усилить аудит использования данных для сотрудников, которые собираются уйти, чтобы гарантировать, что данные не могут ускользнуть.
В процессе управления данными «от хаоса к управлению» мы не только реализовали «от хаоса к управлению» биржевыми данными, но также ускорили ряд методологий и инструментов моделирования в процессе, а также создали соответствующие группы безопасности и оперативные показатели. Организации. В то же время мы предоставляем надежные организационные гарантии, стабильные вспомогательные инструменты и строгие стандарты реализации для последующего инкрементного управления данными, чтобы гарантировать, что построение данных «не превышает нормы». На втором этапе управления данными, в процессе реализации «соответствия» дополнительных данных, мы в основном фокусируемся на аудите архитектуры больших данных, аудите управления безопасностью и конфиденциальностью больших данных, аудите управления качеством больших данных и аудите управления жизненным циклом больших данных. Работа из этих четырех аспектов было выполнено для обеспечения непрерывного прогресса в работе по управлению и постоянного повышения уровня управления в организации.
5. Введение в инструмент
5.1 Карта данных (где как)
Как продукт приложения метаданных, карта данных ориентирована на сценарий «нахождения числа» пользователей данных и реализует требования «нахождения числа» для извлечения данных и понимания данных. Благодаря описанию метаданных автономных наборов данных и онлайн-наборов данных мы удовлетворяем потребности пользователей в поиске и понимании чисел.Благодаря карте кровных родств мы можем завершить построение кровных родств от физических таблиц до продуктов и устранить боль пользователя. оценка.
Автономные сценарии данных
1. Поиск ключевых слов и запрос мастера совместно решают проблему «поиска данных»: в большинстве сценариев поиска данных пользователи данных могут получить совпадающие результаты с помощью поиска ключевых слов. По оставшемуся небольшому количеству сценариев, например, как новички понимают всю систему хранилищ данных и показателей после прихода в компанию (хранилища данных разбиты на несколько слоев, и какие модели штрихуются для решения каждого слоя проблема; как работает вся система индикаторов и измерений? классификация, какие индикаторы и измерения есть), эта часть сцены может использовать функцию запроса мастера. Запрос мастера эквивалентен классификационному запросу, таблицы и индикаторы классифицируются в соответствии с бизнес-процессом, и пользователь может постепенно найти нужную таблицу или индикатор в соответствии с классификацией.
2. Мы открыли взаимосвязь между бизнес-метаданными и техническими метаданными, а также улучшили возможность «найти данные»: после нахождения индикатора через «Где как» невозможно просмотреть не только бизнес-определение индикатора, но и техническое Также можно просмотреть реализацию индикатора Логика, в каких измерениях или комбинациях измерений реализованы показатели, и в какой таблице можно найти данные индикатора этих измерений или комбинаций измерений. И наоборот, также можно узнать, какие индикаторы были реализованы в рамках определенного измерения и в каких таблицах расположены соответствующие индикаторы. Эти функции облегчают пользователям поиск нужных данных.
3. Мы предоставляем относительно полную информацию о данных, чтобы помочь пользователям лучше понять данные: для информации о таблицах «Wherehows» не только предоставляет основную информацию, такую как китайские и английские названия и информацию описания таблиц и полей, чтобы помочь пользователям лучше понять. идеи построения таблицы, мы также предоставляем звездную модель таблицы (согласованные размеры, которые могут быть связаны, и соответствующую таблицу размеров), кровное родство таблицы и другую информацию.
4. Мы помогаем пользователям быстро получить обратную связь с помощью функции комментариев и вопросов и ответов: если пользователь все еще чувствует проблему после прочтения информации, «Где как» предоставляет функцию комментариев и вопросов и ответов. Пользователи могут задавать вопросы с помощью этой функции, и будет соответствующее ответственное лицо, чтобы ответить. На повторяющиеся вопросы пользователи могут найти ответы, просматривая вопросы и ответы других людей. А ответственное лицо будет регулярно вносить информацию о вопросах и ответах в соответствующие метаданные и постоянно дополнять и улучшать метаданные.
сценарии бизнес-данных
Проблема, которую пытаются решить основные сценарии бизнес-данных, заключается в том, как узнать, что бизнес-таблица (таблицы MySQL) не синхронизирована с количеством позиций. Без синхронизации можно обратиться к для синхронизации. Как было открыто, "Бизнес-таблица -> Таблица количество позиций -> продуктов" родственной связи между тремя, мы можем легко решить проблему сценариев бизнес-данных.
Сценарий оценки производства
В повседневной работе по производству данных нам часто приходится выполнять такие работы, как оценка воздействия, устранение неполадок и анализ ссылок в таблицах.Если эти задачи выполняются исключительно вручную, это отнимает много времени и сил. Но теперь, когда мы открыли кровную связь между «бизнес-таблицей/полем -> таблицей/полем хранилища данных -> продуктом», мы можем завершить оценку в течение 10 минут. Для разных сценариев ссылка на родословную предоставляет две удобные функции: фильтрацию и обрезку. Например, необходимо изменить логику таблицы, какие последующие таблицы или продукты необходимо изменить? Какие RD и PM должны быть уведомлены? В этом случае инструмент происхождения визуально показывает, какие принципалы и продукты были затронуты, а также нисходящие ссылки этой таблицы.
Ссылки некоторых таблиц очень длинные, а весь график кровных родств очень большой, что может привести к информации о позиционировании пользователя или проблемам. Таким образом, инструмент родословной предоставляет функцию обрезки, и ветви, которые бесполезны и не хотят быть видны, могут быть удалены, что делает всю ссылку более интуитивной.
5.2 Визуализация данных (QuickSight)
Сосредоточив внимание на сценарии «выборки» данных пользователем с помощью QuickSight, пользователи больше не могут заботиться об источнике данных, больше не беспокоиться о согласованности данных и больше не полагаться на разработку планирования RD. Благодаря методу выбора того, что вы получаете, он удовлетворяет потребности пользователей во вторичной обработке, составлении отчетов и получении основных бизнес-показателей. Во-первых, мы логически изолируем автономные производственные индикаторы с помощью таких концепций, как пулы индикаторов и наборы данных, и разрабатываем разные наборы данных для разных пользователей для достижения цели контроля разрешений, как показано на следующем рисунке:
Во-вторых, мы предоставляем пользователям ряд компонентов, которые помогают пользователям реализовать функции вторичной обработки и визуализации данных индикаторов на основе их открытых наборов данных, чтобы удовлетворить их приложения для поиска и визуализации данных в различных бизнес-сценариях. Как показано ниже:
6. Резюме и перспективы
После трех этапов работы по управлению мы добились хороших результатов по всем аспектам:
- Что касается стандартов данных, мы сформулировали бизнес-стандарты, технические стандарты, стандарты безопасности и стандарты управления ресурсами, чтобы обеспечить соответствие процессам производства, управления и использования данных.
- Что касается архитектуры данных, мы повышаем гибкость модели за счет объединения таблиц, масштабирования по времени и снижения уровня бизнес-калибра, а также обеспечиваем согласованность данных, устраняя такие проблемы, как межуровневые ссылки и избыточность модели.
- Что касается безопасности данных, мы усилили управление безопасностью конфиденциальных данных и ссылок для обмена данными, чтобы гарантировать, что данные не могут быть изъяты или украдены, а личные данные не могут быть поняты.
- Что касается построения метаданных, мы открыли всю связь от сбора до построения и приложения и предоставили пользователям данных продукты для приложений метаданных, такие как карты данных и визуализация данных, помогая им решить проблему «нахождения чисел» и «получения чисел». «количество» и «оценка воздействия».
В будущем мы продолжим управлять безопасностью данных, использованием ресурсов, качеством данных и другими аспектами с помощью организации, норм, процессов и других средств, а также усердно работать над простотой использования данных, чтобы продолжать снижать стоимость использования данных для пользователи.
- С точки зрения архитектуры данных, с быстрым развитием технологии баз данных уже существует множество баз данных, которые могут поддерживать немедленное использование десятков миллионов или даже сотен миллионов данных.Мы также пытаемся использовать эти базы данных для улучшения разработки данных. эффективность и улучшить анализ хранилища данных Управление слоями и эффективность поддержки приложений.
- Что касается продуктов данных, мы продолжим улучшать продукты приложений данных, такие как карты данных и визуализация данных, чтобы помочь пользователям быстро исследовать и эффективно анализировать и по-настоящему использовать ценность данных для бизнеса.
об авторе
- Ван Пэн, который присоединился к Meituan-Dianping в 2016 году, в настоящее время отвечает за создание краудсорсинговых бизнес-данных, управление данными и систематизацию в группе данных отдела распределения.
- Цзяхао, присоединившийся к Meituan-Dianping в 2018 году, в настоящее время отвечает за создание краудсорсинговых бизнес-данных, управление данными и их систематизацию в группе данных отдела распределения.
Чтобы прочитать больше технических статей, подпишитесь на общедоступный аккаунт WeChat «Техническая команда Meituan».