[Обсуждение] Azure наиболее подходящая архитектура для совместного использования и использования больших данных - PullRequest
0 голосов
/ 28 марта 2020

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

  1. Собранные данные будут разделены по отделам (НИОКР, продажи, HR, Производство и т. д.). ). в принципе, отдел мог бы иметь полное разрешение только на чтение и запись пространства и данных своего отдела, но в некоторых случаях он также мог бы иметь право доступа к указанным c данным из другого пространства отдела после получения разрешения от администратора отдела.
  2. собранные уровни доступа к данным будут изменены правилами после самой последней даты обращения к ним, но пользователь также может изменить его вручную
  3. озера данных для этой системы будет достаточно безопасность секретных данных и личной информации.

поэтому, прочитав книгу и информацию о azure, я подумал об архитектуре, которая выглядит следующим образом:

enter image description here

в этой архитектуре, я думаю, для службы доступно 3 шага:

  1. ввод данных: будут собираться данные из другой службы или локального сервера в azure. если размер данных большой, а моей клиентской сети недостаточно, чтобы справиться с этим, я думаю использовать Data Box для загрузки данных. в то время как если моя клиентская сеть будет способна загружать все имеющиеся у них данные, я буду использовать фабрику данных. в то время как для данных небольшого размера они могли загружать их непосредственно из Storage Explorer. и, конечно, миграция базы данных для переноса их БД в azure.
  2. хранилище данных: я использую Azure хранилище для нереляционных данных с файлом, в основном CSV и журналом, и SQL База данных для их реляционной БД. с Azure хранилищем я также мог установить правила автоматического изменения уровней доступа к своим файлам.
  3. доступ к данным: мой клиент будет обращаться к этой системе через свои P C, а веб-приложения, размещенные на App Sevices, являются их UI. чтобы получить доступ к этому пользовательскому интерфейсу, они сначала выполнят процесс аутентификации со своим ADID, и оттуда моя система получит пользовательский отдел и покажет только каждому пользователю доступное пространство и файлы. вот где будет достигнута первая целевая функция. Пользователь также будет иметь некоторую функцию запроса доступа в этом пользовательском интерфейсе, чтобы запросить разрешение для другого пространства или файлов. и пользователь с правами администратора сможет принять или отклонить этот запрос. не только это, но администратор также будет иметь право изменять каждый уровень доступа к файлам вручную.

Теперь вот вопросы, которые я хочу обсудить:

  1. эта архитектура подходит для обслуживания и использования больших данных - если нет, то что мне не хватает?
  2. для большей части доступа к данным, я в основном думаю создать приложение с нуля. но есть ли в Azure какой-либо сервис или который может быть интегрирован в Azure для выполнения такого рода функций?
  3. какой тип защиты вы обычно устанавливаете для этого типа сервиса с высокой степенью конфиденциальности и личной информационные данные?
  4. Можно ли azure рассчитать доступ каждого сотрудника департамента, чтобы мы могли знать, какой отдел активно использует услуги?

бест,

...