sas платформа что это
Интерфейс SAS: история, примеры организации хранения
В прошлый раз мы с вами рассмотрели все, что касается технологии SCSI в историческом контексте: кем она была изобретена, как развивалась, какие у нее есть разновидности и так далее. Закончили мы на том, что наиболее современным и актуальным стандартом является Serial Attached SCSI, он появился относительно недавно, но получил быстрое развитие. Первую реализацию «в кремнии» показала компания LSI в январе 2004 года, а в ноябре того же года SAS вошел в топ самых популярных запросов сайта storagesearch.com.
Начнем с основ. Как же работают устройства на технологи SCSI? В стандарте SCSI все построено на концепции клиент/сервер.
Клиент, называемый инициатором (англ. initiator), отправляет разные команды и дожидается их результатов. Чаще всего, разумеется, в роли клиента выступает SAS контроллер. Сегодня SAS контроллеры — это HBA и RAID-контроллеры, а также контроллеры СХД, стоящие внутри внешних систем хранения данных.
Сервер называется целевым устройством (англ. target), его задача — принять запрос инициатора, обработать его и вернуть данные или подтверждение выполнения команды обратно. В роли целевого устройства может выступать и отдельный диск, и целый дисковый массив. В этом случае SAS HBA внутри дискового массива (так называемая внешняя система хранения данных), предназначенный для подключения к нему серверов, работает в режиме Target. Каждому целевому устройству (“таргету”) присваивается отдельный идентификатор SCSI Target ID.
Для связи клиентов с сервером используется подсистема доставки данных (англ. Service Delivery Subsystem), в большинстве случаев, это хитрое название скрывает за собой просто кабели. Кабели бывают как для внешних подключений, так и для подключений внутри серверов. Кабели меняются от поколения к поколению SAS. На сегодня имеется три поколения SAS:
— SAS-1 или 3Gbit SAS
— SAS-2 или 6Gbit SAS
— SAS-3 или 12 Gbit SAS – готовится к выходу в середине 2013 года
Внутренние и внешние кабели SAS
Иногда в состав этой подсистемы могут входить расширители или экспандеры SAS. Под экспандерами (англ. Expanders, расширители, но в русском языке прижилось слово «экспандер») понимают устройства, помогающие доставке информации от инициаторов к целям и обратно, но прозрачные для целевых устройств. Одним из самых типичных примеров является экспандер, позволяющий подключить несколько целевых устройств к одному порту инициатора, например, микросхема экспандера в дисковой полке или на бэкплейне сервера. Благодаря такой организации, серверы могут иметь более 8 дисков (контроллеры, которые сегодня используются ведущими производителями серверов, обычно 8-портовые), а дисковые полки – любое необходимое количество.
Инициатор, соединенный с целевым устройством системой доставки данных, называют доменом. Любое SCSI устройство содержит как минимум один порт, который может быть портом инициатора, целевого устройства или совмещать обе функции. Портам могут присваиваться идентификаторы (PID).
Целевые устройства состоят из как минимум одного логического номера устройства (Logical Unit Number или LUN). Именно LUN и идентифицирует с каким из дисков или разделов данного целевого устройства будет работать инициатор. Иногда говорят, что target предоставляет инициатору LUN. Таким образом, для полной адресации к нужному хранилищу используется пара SCSI Target ID + LUN.
Как в известном анекдоте («Я не даю в долг, а Первый Национальный Банк не торгует семечками») — целевое устройство обычно не выступает в роли «посылающего команды», а инициатор — не предоставляет LUN. Хотя стоит отметить, что стандарт допускает тот факт, что одно устройство может быть одновременно и инициатором и целью, но на практике это используют мало.
Для «общения» устройств в SAS существует протокол, по «доброй традиции» и по рекомендации OSI, разделенный на несколько слоев (сверху вниз): Application, Transport, Link, PHY, Architecture и Physical.
SAS включает в себя три транспортных протокола. Serial SCSI Protocol (SSP) — используется для работы со SCSI устройствами. Serial ATA Tunneling Protocol (STP) — для взаимодействия с дисками SATA. Serial Management Protocol (SMP) — для управления SAS-фабрикой. Благодаря STP мы можем подключать диски SATA к контроллерам SAS. Благодаря SMP мы можем строить большие (до 1000 дисковых/SSD-устройств в одном домене) системы, а также использовать зонирование SAS (подробнее об этом в статье про SAS-коммутатор).
Уровень связей служит для управления соединениями и передачи фреймов. Уровень PHY — используется для таких вещей как установка скорости соединения и кодировки. На архитектурном уровне находятся вопросы расширителей и топологии. Физический уровень определяет напряжение, форму сигналов соединения и т.д.
Все взаимодействие в SCSI строится на основании команд, которые инициатор посылает целевому устройству и ожидает их результата. Команды эти посылаются в виде блоков описания команды (Command Description Block или CDB). Блок состоит из одного байта кода команды и ее параметров. Первым параметром почти всегда выступает LUN. CDB может иметь длину от 6 до 32 байт, хотя последние версии SCSI допускают CDB переменной длины.
После получения команды целевое устройство возвращает код подтверждения. 00h означает что команда принята успешно, 02h обозначает ошибку, 08h — занятое устройство.
Команды делятся на 4 большие категории. N, от английского «non-data», предназначены для операций, не относящихся к непосредственно обмену данными. W, от «write» — запись данных, полученных целевым устройством от инициатора. R, как не сложно догадаться от слова «read» используется для чтения. Наконец В — для двустороннего обмена данными.
Команд SCSI существует достаточно много, поэтому перечислим только наиболее часто используемые.
Test unit ready (00h) — проверить, готово ли устройство, есть ли в нем диск (если это ленточный накопитель), раскрутился ли диск и так далее. Стоит отметить, что в данном случае устройство не производит полной самодиагностики, для этого существуют другие команды.
Inquiry (12h) — получить основные характеристики устройства и его параметры
Send diagnostic (1Dh) — произвести самодиагностику устройства — результаты этой команды возвращаются после диагностики командой Receive Diagnostic Results (1Ch)
Request sense (03h) — команда позволяет получить статус выполнения предыдущей команды — результатом этой команды может стать как сообщение типа «нет ошибки», так и разные сбои, начиная с отсутствия диска в накопителе и заканчивая серьезными проблемами.
Read capacity (25h) — позволяет узнать объем целевого устройства
Format Unit (04h) — служит для деструктивного форматирования целевого устройства и подготовки его к хранению данных.
Read (4 варианта) — чтение данных; существует в виде 4 разных команд, отличающихся длиной CDB
Write (4 варианта) — запись. Так же как и для чтения в 4 вариантах
Write and verify (3 варианта) — запись данных и проверка
Mode select (2 варианта) — установка различных параметров устройства
Mode sense (2 варианта) — возвращает текущие параметры устройства
А теперь рассмотрим несколько типичных примеров организации хранения данных на SAS.
Пример первый, сервер хранения данных.
Что это такое и с чем его едят? Большие компании типа Amazon, Youtube, Facebook, Mail.ru и Yandex используют сервера этого типа для того, чтобы хранить контент. Под контентом понимается видео, аудио информация, картинки, результаты индексирования и обработки информации (например, так популярный в последнее время в США, Hadoop), почта, и.т.д. Для понимания задачи и грамотного выбора оборудования под нее нужно дополнительно знать несколько вводных, без которых никак нельзя. Первое и самое главное – чем больше дисков – тем лучше.
Дата-центр одной из российских Web 2.0-компаний
Процессоры и память в таких серверах задействуются не сильно. Второе – в мире Web 2.0, информация хранится географически распределено, несколько копий на различных серверах. Хранится 2-3 копии информации. Иногда, если она запрашивается часто, хранят больше копий для балансировки нагрузки. Ну и третье, исходя из первого и второго, чем дешевле – тем лучше. В большинстве случаев все вышесказанное приводит к тому, что используются Nearline SAS или SATA диски высокой емкости. Как правило, Enterprise-уровня. Это значит, что такие диски предназначены для работы 24×7 и стоят значительно дороже своих собратьев, использующихся в настольных PC. Корпус обычно выбирают такой, куда можно вставить побольше дисков. Если это 3.5’’, то 12 дисков в 2U.
Типичный 2U-сервер хранения данных
Или 24 x 2.5’’ в 2U. Или другие варианты в 3U, 4U и.т.д. Теперь, имея корпус, количество дисков и их тип, мы должны выбрать тип подключения. Вообще-то выбор не очень большой. А сводится он к использованию экспандерного или безэкспандерного бэкплейна. Если мы используем экспандерный бекплейн, то контроллер SAS может быть 8-портовым. Если безэкспандерный – то количество портов контроллера SAS должно равняться или превышать количество дисков. Ну и последнее, выбор контроллера. Мы знаем количество портов, 8, 16, 24, например и выбираем контроллер исходя из этих условий. Контроллеры бывают 2х типов, RAID- и HBA. Отличаются они тем, что RAID-контроллеры поддерживают уровни RAID 5,6,50,60 и имеют достаточно большой объем памяти (512MB-2ГБ сегодня) для кэширования. У HBA памяти или cовсем нет, или ее очень мало. Кроме этого, HBA либо не умеют делать RAID вообще, либо умеют олько простые, не требующие большого объема вычислений уровни. RAID 0/1/1E/10 – типичный набор для HBA. Здесь нам нужен HBA, они стоят значительно дешевле, так защита данных нам не нужна совсем и мы стремимся к минимизации стоимости сервера.
16-портовый SAS HBA
Пример второй, почтовый сервер Exchange. А также MDaemon, Notes и другие подобные сервера.
SSD- кэширующий RAID-контроллер Nytro MegaRAID
Пример третий, внешняя система хранения данных своими руками.
Итак, самое серьезное знание SAS, конечно же, требуется тем, кто производит системы хранения данных или хочет их сделать своими руками. Мы остановимся на достаточно простой СХД, программное обеспечение для которой производится компанией Open-E. Конечно же, можно делать СХД и на Windows Storage Server, и на Nexenta, и на AVRORAID, и на Open NAS, и на любом другом подходящем для этих целей софте. Я просто обозначил основные направления, а дальше вам помогут сайты производителей. Итак, если это внешняя система, то мы почти никогда не знаем, сколько же дисков потребуется конечному пользователю. Мы должны быть гибкими. Для этого есть так называемые JBOD – внешние полки для дисков. В их состав входит один или два экспандера, каждый из которых имеет вход (4-х портовый разъем SAS), выход на следующий экспандер, остальные порты разведены на разъемы, предназначенные для подключения дисков. Причем, в двухэкспандерных системах первый порт диска разведен на первый экспандер, второй порт – на второй экспандер. Это позволяет строить отказоустойчивые цепочки JBOD-ов. Головной сервер может иметь внутренние диски в своем составе, либо не иметь их совсем. В этом случае используются «внешние» контроллеры SAS. То есть контроллеры с портами «наружу». Выбор между SAS RAID-контроллером или SAS HBA зависит от управляющего ПО, которое вы выбираете. В случае Open-E, это RAID-контроллер. Можно позаботиться и об опции кэширования на SSD. Если ваша СХД будет иметь очень много дисков, то решение Daisy Chain (когда каждый последующий JBOD подключается к предыдущему, либо к головному серверу) в силу многих причин не подходит. В этом случае головной сервер либо оснащается несколькими контроллерами, либо используется устройство, которое называется SAS-коммутатор. Он позволяет подключать один или несколько серверов к одному или нескольким JBOD. Подробнее SAS-коммутаторы мы разберем в следующих статьях. Для внешних систем хранения данных настоятельно рекомендуется использовать диски только SAS (в том числе NearLine) в силу повышенных требований к отказоустойчивости. Дело в том, что протокол SAS имеет в своем составе гораздо больше функций, чем SATA. Например, контроль записываемых-считываемых данных на всем пути с помощью проверочных сумм (T.10 End-to-End protection). А путь, как мы уже знаем, бывает очень длинным.
Напоследок, хочется поделиться некоторыми сведениями о текущей адаптации SAS мировыми производителями оборудования. SAS сегодня – это стандарт де-факто для серверных систем и профессиональных рабочих станций. Серверные системы подавляющего большинства как A- так и B- брендов имеют в составе контроллеры SAS, как HBA, так и RAID. В области внешних систем хранения данных, основные производители оборудования (HP, EMC, NetApp, IBM) уже несколько лет как перевели внутренние архитектуры своих систем на SAS. Таким образом, диски Fibre Channel стали за последние пару лет настоящей экзотикой. Fibre Channel продолжает жить и развиваться, в основном, как способ подключения серверов к системам хранения данных, хотя в области Low-End, Mid-Range и профессиональных систем, SAS отвоевывает все большую долю.
На этом наш экскурс в мир истории и теории SCSI вообще и SAS в частности подошел к концу, и в следующий раз я расскажу вам более подробно о применении SAS в реальной жизни.
Цифровой маркетинг в режиме одного окна: разбираем облачные продукты SAS
Меня зовут Максим, и я работаю консультантом по клиентской аналитике в компании SAS (это не спецназ и не авиакомпания, а институт). Мы оцениваем применимость новых технологий в бизнес-процессах различных отраслей и на основе этого делаем проекты. В том числе в цифровом маркетинге. Самыми интересными результатами нашей работы я буду делиться с вами в этой и последующих публикациях.
Сегодняшний герой — облачный продукт для цифрового маркетинга SAS Customer Intelligence 360, который позволяет централизованно собирать и обрабатывать данные о клиентах. Разбор возможностей и примеры работы — под катом.
День D
«Диджитал» подкрался незаметно из социальных сетей, поисковых систем, экранов мобильных телефонов и различных носимых устройств.
К комфорту современного интернета быстро привыкаешь, некогда непривычно высокий уровень обслуживания становится делом обыденным и соответствующим минимальным «must have».
Для того чтобы безнадежно не отстать от потребностей своих клиентов, компании вынуждены рваться вперед в гонке цифровых клиентских сервисов.
С какими проблемами сталкиваются организации при работе с цифровыми каналами? Их много, но мы выделяем три наиболее острые:
Что делать?
Чтобы успешно решать эти и другие проблемы, мы разработали SAS Customer Intelligence 360. Это решение распространяется по модели SaaS и пока включает два модуля — для сбора данных о поведении пользователей (Discover) и для управления клиентскими путешествиями и персонификацией (Engage).
У нескольких заказчиков проходят закрытое тестирование еще два модуля — управления email-рассылками и маркетинговыми инициативами (MRM). Мы планируем регулярно обновлять существующие модули и добавлять новые. Все обновления происходят автоматически, без участия пользователей.
На данный момент SAS Customer Intelligence 360 состоит из двух модулей
В отличие от традиционных продуктов SAS, решение базируется в облаке. Это типичный подход для реализации SaaS-решений, который не требует от пользователя покупки дополнительного «железа», и мы не стали идти против трендов индустрии.
Облачная реализация имеет и дополнительные преимущества: гибкое управление потребляемыми услугами, автоматическое обновление и быстрый старт при начале работы (у меня уходит меньше 10 минут, чтобы подключить новый сайт).
«Облачность» требует повышенного внимания к аспектам безопасности и вопросам передачи данных, в том числе персональных. В Customer Intelligence 360 все соединения шифруются по протоколу https (TLS 1.2), а при сборе данных можно «обфускировать» значения.
На стороне браузера клиента происходит хеширование по алгоритму SHA-384. Если данные вдруг попадут в чужие руки, процесс восстановления значений из хеша окажется крайне сложным и нерентабельным (в отличие от шифрования данных, когда достаточно знать правильную парольную фразу для расшифровки). Когда захешированные данные попадают в облако, они подвергаются повторному хешированию с иными параметрами. Требования к хешированию предъявляются и при пакетной (например, из CRM) загрузке персональных данных в облако – SAS не допускает их хранение в открытом виде.
Данные собираются в специальном облачном хранилище – DataHub, где находятся обезличенные профили посетителей всех подключенных сайтов, мобильных устройств, информация об их поведении в подключенных онлайн- и оффлайн-каналах. DataHub можно расширить – достаточно подготовить таблицу и отправить ее в облако, определенным образом указав «ключи». Тогда DataHub свяжет новую таблицу с уже имеющимися данными. Привязка осуществляется в разрезе профилей посетителей.
Теперь подробнее остановимся на составляющих решения. Начнем с модуля Discover.
Все собирают данные о работе сайта, но не все обладают способностью формировать единый омниканальный профиль клиента и автоматически загружать собираемую информацию в нормализованную витрину данных, не прибегая к необходимости писать код или совершать какие-то сложные интеграции. А SAS 360 Discover это делать умеет. Сбор большей части действий клиента происходит автоматически сразу же после добавления тега на сайт. Для отслеживания более сложных событий или процессов используется мастер настройки, который позволяет гибко сконфигурировать систему. И, да, для этого не требуется писать код.
Настройки сбора правил задаются через интерфейс администратора – не нужно что-либо дополнительно дорабатывать на сайте
«Окей, — скажет кто-то, — у любого решения есть ограничения, не все события на сайте можно собрать. Что делать в таком случае?». Без паники, это также предусмотрели. Есть возможность передавать события напрямую в SAS 360 Discover простым вызовом RESTful сервиса по API. В самом простом виде тело запроса будет похоже на эти два примера:
Для сбора данных из мобильного имеется особый SDK, который несложно прикрутить к приложению под Android или iOS. Собираемые с разных устройств данные накапливаются в единой витрине и всегда доступны.
Теперь поговорим про вовлечение — модуль «Engage».
Имея под рукой столь ценные разведданные, было бы преступлением ими не пользоваться. Все, что известно о посетителе сайта, может быть использовано против него для более точного таргетинга.
И дело не ограничивается тривиальными механиками вроде «догони пользователя баннером любой ценой» (кстати, мы в SAS выступаем резко против подобного спама). Решение позволяет элегантно «отруливать» такие важные вопросы как контактная политика, тестирование, сегментация базы и анализ эффективности онлайн-кампаний. Можно загрузить список клиентов из CRM, выбрать контент для коммуникации, настроить правила и показатели эффективности проведения кампании и следить за ее успешностью — в рамках одного пользовательского интерфейса.
Встроенные аналитические помощники позволяют проводить различные А/B тестирования, оптимизировать коммуникации, профилировать клиентскую базу и подбирать товары или услуги для клиента.
Для примера разберем вариант реализации простой коммуникации в 360 Engage. Пока опустим создание баннера, настройку места вывода баннера, выбора аудитории и создание событий (об этом мы планируем рассказывать в новых публикациях) и ограничимся этапом постановки задачи.
Задачи бывают разных типов и для разных каналов. На сегодняшний день доступны web, mobile и email. Для примера выберем web – это самый простой из них. Откроется интерфейс настройки задачи Web. Указываем, в какой спот какой контент (креативы, баннеры) выводить.
Типы задач
Дополнительно указываем ограничения контактной политики. Можно задать максимальное количество показов баннера для конкретного пользователя за все время действия кампании или за определенный период (сессия или какой-то промежуток времени). Еще один параметр — срок актуальности задачи (например, время проведения кампании). Когда наступит «час Х», кампания автоматически завершится.
Контактная политика
Чтобы убедиться, что креативы (баннеры) будут корректно отображаться на сайте, можно воспользоваться превью.
Пример предпросмотра на сайте
360 Engage позволяет настроить тип аудитории, которая подходит для данной кампании — например, отобрать клиентов на основе их поведения в сети и/или данных, загруженных из внешних систем (например, из CRM). В нашем случае мы ограничим аудиторию задачи теми пользователями, которые заходили на страницу https://habrahabr.ru/hub/career/ и читали статьи, посвященные карьере в IT-индустрии. Еще можно настроить систему так, что пользователи не увидят баннер, если, например, видели аналогичный или уже выполнили некое целевое действие.
Выбор аудитории
Для реализации более сложных сценариев взаимодействия с клиентами можно настроить карту активностей – диаграмму, где отображается путь клиента в цифровых каналах. Каждый следующий шаг на карте активностей выбирается в зависимости от поведения пользователя на предыдущем шаге. Приятная особенность – можно проводить A/B тестирования целых процессов (нескольких объединенных шагов). Карты активностей — еще один предмет будущих публикаций.
Карты активностей позволяют строить многошаговые сценарии взаимодействия с клиентами
Что дальше?
Недавно я заглянул в дорожную карту SAS Customer Intelligence 360, и мне стало очевидно, что это уже не просто расширение digital-возможностей «классических» решений традиционного целевого маркетинга SAS. SAS Customer Intelligence 360 медленно, но верно превращается в самодостаточную Digital Marketing платформу. Дорабатываются интеграции (внешние DMP и традиционные каналы), шлифуются модели аналитических помощников (расширенная сегментация и продуктовый рекомендер), в имеющиеся инструменты добавляются новые «фичи» (мультистраничное A/B тестирование и online персонализация контента). C каждым релизом увеличивается встроенная функциональность MRM.
На все интересующие вопросы по SAS Customer Intelligence 360 я готов ответить в комментариях.
Вия, Уая, Вая, Вайя – “трудности перевода”, или что скрывается за новой платформой SAS Viya (Вайя)
В сети можно найти огромное количество разнообразных статей о методах использования алгоритмов математической статистики, о нейронных сетях и в целом о пользе машинного обучения. Данные направления способствуют существенному улучшению жизни человека и светлому будущему роботов. Например, заводы нового поколения, способные работать полностью или частично без вмешательства человека или машины с автопилотом.
Разработчики объединяют комбинации этих подходов и методов машинного обучения в различные направления. Эти направления впоследствии получают названия, оригинальные и не очень, например: IOT (Internet Of Things), WOT (Web Of Things), Индустрия 4.0 (Industry 4.0), Artificial Intelligence (AI) и другие. Данные концепции объединяет то, что их описание является верхнеуровневым, то есть не рассматриваются ни конкретные инструменты и технологии, ни уже готовые к внедрению системы, а основной целью является визуализация желаемого результата. Но технологии уже существуют, хотя часто не имеют единой платформы.
Решения предоставляют как крупные вендоры ПО: SAS, SAP, Oracle, IBM, так и маленькие стартапы, составляющие крупным игрокам сильную конкуренцию, а также решения с открытым исходным кодом — open source решения. Все это многообразие сильно осложняет быстрое и эффективное выполнение поставленной задачи, так как требует трудоемкой интеграции различных систем между собой, огромных трудов разработчиков по созданию хороших моделей машинного обучения и будущую имплементацию этих решений в продуктив. Но в то же время основной критерий успешности любого инновационного проекта, который меняет подход компании к ведению бизнеса часто требует быстрого доказательства успешности и состоятельности, а иначе никто не рискнет его запустить. А это невозможно без использования единой платформы, которая позволит выполнять быстро весь цикл подготовки (поиска, сбора, очистки, консолидации) данных и получать финальные результаты в виде качественной аналитики (в том числе с использованием алгоритмов машинного обучения), и, как следствие, прибыли для компании.
Про SAS
Трудности выбора
Мы уже выяснили, что сейчас на рынке существует огромное количество продуктов известных вендоров и игроков поменьше, а также open source, который позволяет решать различные аналитические задачи во всех сферах бизнеса. Какие же критерии, кроме цены, должны учитываться при принятии решения о выборе той или иной платформы?
Начнем с того, что сейчас бизнес пользователь становится все больше вовлечен в полный аналитический цикл и требует большей независимости от ИТ. На первый план выходят понятные этим пользователям критерии – удобство использования (единые интерфейсы), минимизация обучения новым системам (меньше кода, больше графики), производительность (в разрезе аналитики — это возможность быстрого получения результата на больших массивах данных), наличие готовых алгоритмов и моделей для работы. Время “черных” экранов уходит, терминальные окна, хотя и в другом виде, все еще доступны и позволяют писать и отлаживать код прямо на ходу, но большую часть функций уже давно можно реализовать в виде блоков в графическом интерфейсе, что открывает двери для пользователей любых уровней для работы с продвинутой аналитикой (хотя математику знать все же желательно).
Второй тренд, который неизбежно завоевывает рынки – это облачные технологии. С точки зрения компаний это возможность гибкого управления доступными ресурсами под любые проекты. Существует много исследований о времени полного вытеснения облачными технологиями классических решений. Но здесь важно понимать, что облачные вычисления — это не только железо, которое живет где-то далеко во внешних цодах, но и сам подход гибкого предоставления всевозможных услуг в виде сервисов, которые можно получить быстро и без необходимости выстраивания или перестраивания сложной IT инфраструктуры.
Еще один тренд – использование Big Data технологий. Да и использование всей Hadoop экосистемы в целом со своими языками и технологиями, а также других доступных open source систем, которые дают интерфейсы для работы с данными, такие как R, Python и другие. В этой области нет смысла конкурировать, но есть смысл иметь технологии для интеграции с этой экосистемой. Или не просто интегрироваться, а использовать возможности этой экосистемы как в случае с SAS Hadoop Embedded Process или использование Kafka для построения High Availability для систем ESP (SAS Event Stream Processing). А иногда даже улучшать и ускорять, как например возможность запускать код на R на движке CAS в SAS Viya.
Универсальная платформа
Спрос рождает предложение и SAS Viya не исключение из правил. Если обратиться к официальному определению SAS Viya, которое было дано Джимом Гуднайтом (очень сильно сокращено, но смысл сохранен) во время анонса в 2016 году на глобальном SAS форуме, то SAS Viya это: «Облачная система, которая использует подходы распределенных вычислений…и дает единую платформу для аналитики«
Ну а если коротко сформулировать идею и цели платформы SAS Viya – то это универсальная платформа для любого вида анализа на всех стадиях проекта от подготовки данных до применения сложных алгоритмов машинного обучения. Можно выделить 4 блока задач:
1. Подготовка данных
2. Визуализация и исследование данных
3. Прогнозная аналитика
4. Продвинутая аналитика в виде алгоритмов машинного обучения
Информация для читателей
Так как в рамках одной статьи все рассказать достаточно трудно без ущерба важным нюансам, то эти шаги будут рассмотрены в следующих статьях на примерах. В этой статье мы рассмотрим важную тему движка SAS Viya, который обеспечивает быструю работу аналитических инструментов. Статьи про современные и красивые интерфейсы следующие в очереди.
Основа платформы SAS Viya
Почему Cloud?
SAS при разработке платформы Viya и CAS в частности использовала преимущества концепции облачных вычислений. Их можно выделить в 4 группы:
1. Доступность через большой набор API разных клиентов. Для SAS это большой шаг вперед. Больше нет ограничений на использование только языка SAS Base для аналитики. Можно использовать Python (Например, из Jupiter Notebook), R, Lua и др., выполнение которых будет происходить в CAS на платформе SAS Viya.
2. Эластичность. Можно легко масштабировать систему, подключая/отключая узлы кластера CAS. Приложения доступны через web и организованы в виде микросервисов. Они независимы друг от друга в вопросах установки, обновления и работы.
3. Высокая доступность. В CAS используется система зеркалирования данных между узлами кластера. Один набор данных хранится на нескольких узлах, что уменьшает риск потери данных. Переключение в случае отказа одного из узлов происходит автоматически с сохранением состояния выполнения задания, что часто бывает критично для тяжелых аналитических расчетов.
4. Повышенная безопасность. Так как облако может быть получено от публичного провайдера, то реализация должна соответствовать более жестким требованиям к надежности каналов передачи данных.
Развернуть платформу Viya можно где угодно — в облаке, на выделенной машине в своем цоде, в кластере из любого количества машин. Автоматически обеспечивается отказоустойчивость решения.
Как же CAS работает?
Я буду разбирать работу CAS на примере MPP установки. SMP упрощает, но сохраняет принципы работы CAS. В реальной жизни SMP можно использовать в качестве тестовых локальных сред для отработки моделей с последующим переносом разработки на MPP платформу для лучшей производительности.
Давайте еще раз посморим на верхнеуровневую архитектуру CAS на SAS Viya:
Если говорить про CAS, то он состоит из контроллера, по-другому, мастер ноды (плюс есть возможность выделить еще один узел для резервной ноды контроллера) и рабочих узлов. Мастер нода хранит метаинформацию о данных, расположенных на узлах кластера, и отвечает за распределение запросов на эти узлы (CAS Workers), выполняющие обработку и хранение данных. Отдельно выделен сервер, на котором находятся аналитические сервисы и дополнительные модули, необходимые для работы платформы. Их тоже может быть несколько в зависимости от задач. Например, можно использовать на отдельной машине в рамках инсталляции Viya сервер для SPRE (SAS Programming Runtime Environment), который позволит запускать классические задачи SAS 9 на платформе Viya как с использованием CAS, так и SPRE.
Есть интересная конфигурация, которая расширяет возможности использования CAS на платформе Viya, и оправдывает первую букву своего названия Cloud:
Мультиарендность (multitenancy) дает возможность разделить ресурсы и данные между департаментами. При этом “арендаторам” дается единый интерфейс доступа к платформе и обеспечивается логическое разделение различных функций платформы Viya. Вариантов достаточно много. Возможно, этот вопрос будет рассмотрен в отдельной статье.
Как же быть с надежностью оперативной памяти и как загрузить данные в CAS?
Любая in-memory система для надежности требует бэкапирования данных, которые находятся в RAM. RAM не умеет сохранять состояние при отключении питания плюс все данные могут не поместиться в область оперативной памяти, и необходим механизм для быстрой перезагрузки данных в RAM. Поэтому для таблиц, которые загружаются в CAS для аналитики, создаются копии в области постоянной памяти специального формата SASHDAT. Для обеспечения высокой доступности эти файлы зеркалируются на нескольких узлах кластера. Этот параметр можно настроить. Идея в том, что при потере узла данные будут автоматически загружены в оперативную память на соседнем узле из копии файла SASHDAT. Область хранения этих копий в структуре CAS называется CAS_DISK_CACHE.
CAS_DISK_CACHE это важная часть в составе CAS, которая нужна не только для обеспечения отказоустойчивости, но и оптимизации использования памяти. На схеме ниже отображены разные способы хранения SASHDAT и принцип загрузки данных в RAM. Например, датасет A получен из БД Oracle и хранится на одном узле CAS в RAM и на диске. Плюс этот датасет A дублируется на другом узле только на жесткий диск. Вариантов много (некоторые из них не требуют дополнительного резервирования – это будет рассмотрено ниже), но основная идея в том, чтобы всегда иметь копию для быстрого восстановления ранее загруженных данных в оперативную память. Кстати, в случае установки двух параметров: MAXTABLEMEM=0 и COPIES=0 на уровне сессии, данные будут жить только в оперативной памяти.
Отдельно хочется рассмотреть интересную конфигурацию CAS с Hadoop. Для использования этой конфигурации CAS вместе с Hadoop системой нужна установка SAS Plugins for Hadoop. Основная идея подхода в том, что узлы кластера Hadoop становятся также рабочими узлами CAS. Данные затягиваются в оперативную память напрямую из файлов в hdfs без сетевой нагрузки. Это лучший вариант с точки зрения производительности. Можно использовать Hadoop либо только для хранения SASHDAT файлов (HDFS на кластере будет выполнять роль CAS_DISK_CACHE –резервирование на уровне HDFS), либо вместе с другими данными. Распределение ресурсов на кластере Hadoop выполняется через YARN. Схема установки CAS на кластер Hadoop:
Загрузка
С загрузкой данных все просто. Мы можем указать различные источники на вход CAS. Их можно загружать или в один поток или параллельно. Так как реляционные базы данных используются гораздо чаще в качестве источников, мы рассмотрим тему загрузки данных в CAS из RDBMS. Для оптимизации загрузки данных в кластер CAS желательно установить клиентское ПО базы данных источника на каждый узел кластера. В этом случае каждый узел CAS кластера будет получать свою порцию данных в параллельном режиме. При установке клиента только на контроллер все данные будут передаваться через CAS контроллер.
Например, при установке параметра numreadnodes=3 таблица будет автоматически разбиваться на 3 порции данных для загрузки на разные узлы CAS – в этом случае распределение данных будет основано на группировке по первому числовому столбцу с применением операции mod 3.
Если же в качестве источника используются Hadoop или Teradata, то с использованием Embedded Process для Hadoop или Teradata загрузка будет выполняться напрямую с каждого узла кластера Hadoop или Teradata. Обратите внимание, что в случае с отдельной инсталляцией кластера Hadoop (CAS установлен не на узлах Hadoop) область CAS_DISK_CACHE будет создана на кластере CAS.
С чего начать работу с CAS?
Важными терминами в работе CAS являются библиотеки и сессии. При начале работы с CAS первое, что создается – это сессия. Ее можно определить вручную при работе через SAS Studio, или она автоматически создается через доступные графические интерфейсы на SAS Viya при подключении к CAS. Внутри сессии все данные и преобразования, которые определяются в новых библиотеках, по умолчанию создаются с локальной областью видимости. Данные (определенные в caslib) и результаты шагов локальной сессии видны только в этой сессии. В случае, если нам нужно сделать результаты общедоступными, то мы можем переопределить caslib параметром global и оператором promote, и данные будут доступны из других сессий. Библиотеки, которые уже определены с параметром global, будут доступны из любых сессий. Сделано это для оптимального разделения ресурсов и управления правами доступа к данным. После отключения от локальной сессии удаляются все временные данные, если caslib не был переопределен в global. Мы можем настроить параметр TIMEOUT для удаления данных при отключении от сессии, чтобы избежать возможных потерь при кратковременных сетевых сбоях или чтобы вернуться к этой сессии для дальнейшего анализа (например, можно выставить параметр TIMEOUT на 3600 секунд, что даст нам 60 минут времени для возврата к сессии). Плюс данные можно сохранить на любом шаге преобразований в специальный формат SASHDAT или в доступную БД, к которой настроено подключение простым оператором SAVE.
Библиотеки caslibs описывают наборы данных, которые будут доступны в CAS. При создании caslib указывается тип подключения и параметры подключения. В определении caslib мы указываем сразу на источник данных и на целевую область в in-memory. Также на уровне caslib удобно задавать права доступа группам пользователей к данным, которые описаны в caslib. Делается это в графическом интерфейсе.
Пример описания caslib для разных типов источников:
После определения caslib мы можем загружать данные в оперативную память для дальнейшей обработки. Пример загрузки данных caslib hivelib:
Внутри каждой сессии запросы (actions) выполняются последовательно. Это важно при написании кода вручную, но при использовании графических интерфейсов, доступных на Viya, об этом можно не думать. Клиентские приложения с GUI сами создают раздельные сессии для выполнения шагов в параллельном режиме.
Полноценно графические интерфейсы и подходы работы через них мы рассмотрим в следующих статьях. Здесь добавлю скриншоты шагов по созданию caslib DM_ORAHR и загрузки данных в RAM через GUI:
Это только начало
На этом я заканчиваю часть про CAS и возвращаюсь к платформе Viya. Так как Viya создана для бизнес-пользователей, то в процессе работы не нужно будет глубоко понимать специфику работы CAS. Для всех операций есть удобные графические интерфейсы, а CAS будет обеспечивать быструю работу всех аналитических шагов за счет in-memory и распределенных вычислений.
Теперь можно переходить к пользовательским интерфейсам, которые доступны на Viya. На текущий момент их достаточно много, и количество продуктов постоянно увеличивается. В начале статьи они были выделены в 4 группы, которые нужны для полного аналитического цикла. Возвращаясь к основной идее, Viya – это единая платформа для исследования данных и продвинутой аналитики. А начинается работа с подготовки и поиска этих данных. И в следующей части цикла статей про Viya я расскажу про инструменты подготовки данных, которые доступны аналитикам.
Вместо заключения, название Viya происходит от слова Via (от англ. “посредством” или “через”). Основная идея этого названия в простом переходе от классического решения SAS 9 к новой платформе, которая создана, чтобы перевести аналитику на новый уровень.