После 20 лет работы с бизнес-аналитикой и базами данных в последние два года
я сосредоточился на «облачных» решениях. Я отобрал пять основных задач, которые встают
перед нами каждый день при переходе к «облаку» и неизбежно сопутствуют
планированию «облачной» бизнес-аналитики.
Построение решений бизнес-аналитики — хорошо документированный процесс, и вы можете почерпнуть много полезного из множества примеров успешных и неудачных проектов. Традиционная модель бизнес-аналитики и хранилища данных (BI/DW) всегда вызывала большие трудности, но за долгие годы накопился богатый опыт и найдены методы работы, которыми могут воспользоваться специалисты по бизнес-аналитике.
При внедрении решений бизнес-аналитики иной природы или переносе существующего локального решения в «облако» возникает незнакомый набор задач. Я попытался составить список из самых важных проблем, чтобы помочь в планировании «облачного» проекта бизнес-аналитики.
1. Загрузка данных в «облако»
По моему опыту именно эта операция занимает больше всего времени. Получение доступа к источникам данных и загрузка больших начальных наборов данных в «облако», не говоря уже о построении «облачной» инфраструктуры ETL, трудная задача. Вам придется решать проблемы подключения для гибридной среды, перемещать большие объемы данных в «облако» и разработать стратегию архивации в «облачном» хранилище. Эти задачи отличаются от классического подхода с использованием локальных устройств SAN. Если вы строите решение в области бизнес-аналитики на основе SQL Server в виртуальных машинах Azure IaaS, используйте такие инструменты, как AZCopy (https://docs.microsoft.com/en-us/azure/ storage/storage-use-azcopy) или Azure Data Factory, чтобы загрузить начальные наборы данных в службу хранилища Azure. Разностные загрузки данных будут предпочтительным подходом после начальной загрузки данных, и для этой цели вы можете задействовать Azure Data Factory, SSIS, Attunity, Informatica и другие инструменты. Для архивации данных и хранения резервных копий используйте менее дорогостоящее хранилище Azure, например обычное хранилище, и обратите внимание на такие инструменты DraaS, как Azure Site Recovery (ASR) (https://azure. microsoft.com/en-us/services/site-recovery/). Рекомендуется применять диски типа Premium для выполнения прикладных приложений в виртуальных машинах в Azure, но вы можете использовать и диски типа Standard для резервных копий, а также для георепликации резервных копий в целях защиты данных. Если в Azure применяются управляемые общедоступные службы, такие как SQL DB, SQL DW, Azure Analysis Services, Power BI и другие, то вы обнаружите встроенные «облачные» адаптеры и функции для подключения к данным в Azure Storage, Azure Data Lake, HD Insight и других «облачных» источниках. Но в большинстве случаев, если вы не работаете с совершенно новым приложением, вам потребуется развернуть гибридную архитектуру, в которую необходимо включить данные из локальных источников.
В этом случае вам потребуется установить локальные прокси-шлюзы управления данными для перемещения данных (https://docs.microsoft.com/en-us/azure/data-factory/datafactory-data-managcment-gateway) и для Power BI (https://powerbi.microsoft.com/en-us/gateway/).
Это очень сложная тема, требующая различных инструментов для разных архитектурных подходов в Azure.
2. Подключение
Прежде чем планировать развертывание решения для бизнес-аналитики, необходимо понять требования пользователей к задержкам, времени отклика и географическому положению. При подключении к общедоступному «облаку» имейте в виду, что обычные «облачные» службы подключаются через общедоступные IPадреса, которые во многих случаях должны быть внесены в список разрешений брандмауэра для управления доступом. Вы также можете настраивать виртуальные сети и подключения VPN для соединения вашей корпоративной сети со многими, но не со всеми службами в Azure. Если вам требуется подключение к Azure с малыми задержками и высоким уровнем доступности, то подумайте о приобретении решения Express Route (https://docs.microsoft.com/enus/azure/expressroute/expressrouteintroduction) для прямых подключений. Просто отведите на ранних этапах проектирования время для выяснения требований к подключениям.
По прежнему необходимо настраивать общедоступные IPадреса, брандмауэры, балансировщики нагрузки, виртуальные сети и подключения VPN, даже если используется общая «облачная» платформа. Если вы намерены задействовать Power BI (общедоступную «облачную» службу Office 365), то вам подойдет новая версия Power BI Premium, с помощью которой вы сможете предоставить выделенные ресурсы для масштабных реализаций Power BI. Более подробную информацию о PBI Premium можно найти в техническим документации.
3. Управление данными
Управление данными — важный аспект любого аналитического проекта. При запуске решения бизнес-аналитики в «облаке» необходимо уделить еще больше внимания взаимозависимости данных, обеспечению их целостности и качеству. Дело в том, что вам с очень большой вероятностью придется объединять разнообразные источники в «облаке» бизнес-аналитики, особенно если вы уже располагаете локальным решением бизнес-аналитики. В «облаке» чрезвычайно много внимания обычно уделяется взаимозависимости данных и обеспечению их целостности вследствие нормативных требований, гибридности среды и перемещений данных между различными регионами и центрами обработки данных «облачных» поставщиков. Например, в Azure можно использовать Azure Data Lake Store для необработанных данных в Восточном регионе США, но хранить данные Office 365 в Центральном регионе и располагать серверы SQL Server с виртуальными машинами или базы данных Azure SQL в Западном регионе США. В этом случае сложнее работать с взаимозависимыми данными изза возможных деловых и технических требований к трассировке данных и аудиту, и ваши данные перемешаются между центрами обработки данных в различных географических регионах.
Обратите внимание на это обстоятельство, а также на необходимость оплачивать стоимость исходящих данных при перемещении данных из регионов Azure. Упростить управление данными можно с помощью такого инструмента, как Azure Data Catalog (https://azure.microsoft.com/enus/services/datacatalog/), используемого для каталогизации, индексации и обнаружения корпоративных данных.
4. Эксплуатация и обслуживание
«Облачные» инструменты для мониторинга нового «облачного» решения бизнес-аналитики во многих случаях отличаются от традиционных локальных инструментов мониторинга. Но любой хороший администратор баз данных или группа эксплуатации располагают набором инструментов для мониторинга и управления, в который входят базовые показатели производительности, мониторинг изменений и функции для определения отклонений в этих изменениях во времени, средства удаленного применения исправлений и обслуживания виртуальных машин и серверов. Если используются службы PaaS в Azure, то можно получить преимущества полностью или частично управляемых служб, которые исключают отдельные этапы цикла эксплуатации и обслуживания, однако вам по прежнему придется следить за предупреждениями и производительностью. К этим ориентированным в первую очередь на «облако» службам данных в Azure относятся SQL DB, SQL DW, HS Insight, Power BI, ADF и другие. Для успешной эксплуатации «облачного» решения бизнес-аналитики критически важно отслеживать и назначать предупреждения в таких «облачных» приложениях, как Operations Management Suite, дополнительном средстве мониторинга на основе виртуальной машины или локальном продукте.
Operations Management Suite (OMS) — предпочтительный инструмент для мониторинга служб Azure (https://docs. microsoft.com/enus/azure/loganalytics/loganalyticsomagents). В Power BI предусмотрены пакеты содержимого для аудита и мониторинга данных телеметрии службы Azure (https://powerbi.microsoft.com/enus/documentation/powerbicontentpackazureentcrprise/).
5. Затраты
Стоймостные модели «облачного» решения по бизнес-аналитике различаются в широких пределах и будут гораздо более гибкими, чем у привычных традиционных локальных решений бизнес-аналитики. Но учитывая «облачные» затраты, следует рассматривать ваше решение как потребителя общедоступных услуг, например электричества или услуг от оператора телефонной связи. В Azure вам потребуется отслеживать, сколько часов вы потребили и сколько данных сохранили. Эта модель позволяет быстро и без лишних затрат создавать и удалять среды для проектирования и промежуточного хранения в «облаке». Но вам необходимы бюджетное планирование и стратегия, отличные от традиционных бессрочных лицензий с авансовыми годовыми платежами за обслуживание. Новая модель требует регулярного контроля потребления. Многие службы Azure, в том числе виртуальные машины и ADW, позволяют приостановить услугу, и вы платите за вычислительные ресурсы, только когда действительно работаете со своими данными. «Облачные» базы данных, такие как Azure SQL DB и Cosmos DB, позволяют корректировать потребление в течение суток, чтобы получить максимальную отдачу. Например, увеличить ресурсы во время пересылки больших объемов данных в ночные часы и при подготовке отчетов рано утром. Затем вы можете уменьшить ресурсы, регулируя затраты, по выходным и по окончании рабочегодня. Если входе процессов ELT вы работаете с Большими Данными в хранилищах данных, обратите внимание на преимущества службы Azure Data Lake Analytics, плата за которую взимается только на основе параллелизма при обработке данных в хранилище. Служба ADLA предоставляется с оплатой по мере использования или пакетами по пониженной цене (https://azure. microsoft, com/enus/pricing/details/datalakeanalytics/). Этот механизм оплаты широко применяется в «облаке» и решениях Azure.
Миграция в облако — от проектирования до поддержки, обращайтесь [email protected]