SAS connect to Hadoop. Способ подсоединения через Filename. Part1
Всем добрый день.
Сегодня рассмотрим пример, как можно создавать файлы в hadoop, а также делать записи в эти файлы и после забирать данные.
Визуально схема взаимодействия SAS и Hadoop выглядит следующим образом:
Итак самое главное, что Вам нужно сделать, это написать следующий конфигурационный xml файлик:
Где сервер hadoop_main_node, нужно заменить на Ваш сервер, а точнее на гловной Node hadoop.
После этого пишем обычный filename с указанием access method - HADOOP, обязательно в опциях нужно указать путь к конфигурационному xml файлу.
В приведенном примере мы созадли файл test.txt и записали туда одну записть "TEST test Test1"
Теперь убедимся в том, что данный файл появился в файловой структуре Hadoop:
Первая команда была выполнена до запуска sas кода, вторая уже после. Сравнив, мы видим, что появился наш файлик test.txt.
Теперь давайте попробуем забрать эти данные. Делается это также просто:
Мы видим, что в work появился файлик Test, в котором есть как раз одна наша запись.
В дальнейших уроках мы рассмотрим другой метод соединения с Hadoop, а именно через SAS/Access.
Вкратце обо всех трех способах взаимодействия SAS и Hadoop писал в прошлой статье.
До скорых встеч.
С уважением,
Тимаков Николай.
Сегодня рассмотрим пример, как можно создавать файлы в hadoop, а также делать записи в эти файлы и после забирать данные.
Визуально схема взаимодействия SAS и Hadoop выглядит следующим образом:
Итак самое главное, что Вам нужно сделать, это написать следующий конфигурационный xml файлик:
Где сервер hadoop_main_node, нужно заменить на Ваш сервер, а точнее на гловной Node hadoop.
После этого пишем обычный filename с указанием access method - HADOOP, обязательно в опциях нужно указать путь к конфигурационному xml файлу.
В приведенном примере мы созадли файл test.txt и записали туда одну записть "TEST test Test1"
Теперь убедимся в том, что данный файл появился в файловой структуре Hadoop:
Первая команда была выполнена до запуска sas кода, вторая уже после. Сравнив, мы видим, что появился наш файлик test.txt.
Теперь давайте попробуем забрать эти данные. Делается это также просто:
Мы видим, что в work появился файлик Test, в котором есть как раз одна наша запись.
В дальнейших уроках мы рассмотрим другой метод соединения с Hadoop, а именно через SAS/Access.
Вкратце обо всех трех способах взаимодействия SAS и Hadoop писал в прошлой статье.
До скорых встеч.
С уважением,
Тимаков Николай.
Ну да. Только ее загрузка будет за 90% в среднем. Звучит красиво, если не задумываться, что в худшем случае, который будет случаться не так уж и редко (попробуйте добиться идеальной синхронизации и идеальной работы всех процессов), ETL - процессы в очереди стоять будут. А весь смысл акселераторов в том, что они используют СВОБОДНЫЕ ресурсы MPP системы. Которых при таком раскладе не будет вовсе. И закупать дорогое железо, чтобы был резерв мощности на случай, когда Вам приспичит скоринг погонять, никто не будет. В России я ни от одного конечного пользователя в адрес связки акселератор+MPP цензурных слов не слышал, за исключением, единственного, по-моему, исключения, когда этот MPP изначально внедряли для быстрого обсчета моделей в операционном контуре, а не в рамках проекта общекорпоративного DWH, где этот обсчет - дело десятой степени важности.
Ну и по мелочи: в один момент времени у Вас может быть только одна версия акселератора и одна версия SAS. Если в организации два проекта, то первый проект сможет перейти но новую версию SAS только вместе со вторым, иначе один из этих проектов останется без акселератора. Проекты же в больших организациях редко меньше года длятся. И в середине проекта версию ПО менять в здравом уме никто не будет. В итоге на новую версию Вы перейдете через пару лет в лучшем случае, потому что пока второй проект доделают, откроется третий или вторая фаза первого. А ведь проекты могут быть еще и в разных подразделениях, что согласования отнюдь не упрощает.
Кроме того, у этих самых акселераторов есть неприятная особенность, что запускать в них более-менее удобно можно лишь модели, которые сделаны в Miner. Если Вы выпилили что-то в Guide, для запуска модели на стороне MPP системы придется попрыгать с бубном и поработать напильником. Положим, модели текущего кредитования (для рисков) или модели отклика (для CRM) в Miner делаются удобно. Но вот уже с LGD моделями не все так радужно, а лабать в Miner NII и EaR - это разновидность мазохизма. С другой стороны, эти модели и на жутко больших объемах гонять обычно не надо. Но тогда возникает один неприятный вопрос: а где их вообще гонять, если мы изначально ставку на обсчет на стороне хранилища сделали. Понятно, что если припрет, можно и на личной персоналке обсчитать, но, спрашивается, если очереди на "он-лайн" скоринг для одной задачи надо ждать пару дней, а вторую приходится считать, где получится, зачем вся эта возня с акселераторами вообще нужна? Дешевле просто вывести в штат человека, который модели реализовывать в Java, PL\SQL или Teradata SQL или предложить подчиненным освоить нужный язык, благо научиться кодировать конструкции вида "если- то, иначе" много ума и усилий не требуется. Обойдется на порядок дешевле затрат на проект и стоимости лицензии и работать будет лучше.
> благо научиться кодировать конструкции вида "если-то, иначе" много ума и усилий не требуется
,то это конечно не верно. (Хотя верно, но только до той степени что к if-else + циклам можно свести любую самую сложную программу). В Miner-е реализованы сложные методы и, думаю, оттестированы. Может быть за основу взяты Open source продукты, это не известно. Но самому реализовывать всё что есть в майнере совсем не обязательно, потому что все равно придется писать тесты и сравнивать с уже существующими имплементациями. Проще сразу взять уже готовые библиотеки в которых код "revisited and tested". Если, нужна Java, то можно взять Weka (там есть GUI интерфейс, но можно использовать довольно легко и jar файлы прямо в своем исходном коде).
Во-первых хотел поблагодарить за интереснейший комментарий, в котором вы затронули достаточно мого пробем, с которыми приходиться встречаться при внедрении подобного рода систем.
Где-то я разделяю вашу точку зрения, где-то нет.
Прежде всего везде нужно подходить с умом и понимать еще до внедрения какие задачи будет решать данная система.
Часто бывает так, что уже существуют рабочие модели, которые отрабатывают по расписанию. Такие модели действительно надо оборачивать в ETL и ставить на расписание.
Что косается online скоринга, то здесь нужно думать. В данном случае, пологаю, модели могут быть не сложные и общет может идти на сервере SAS (тем более если "проваленные процессы" в MPP систему будут висеть в очереди).
Конечно всего не предусмотришь и многое начинаешь понимать лишь при внедрении.
Что касается новых версий - здесь я с Вами соглашусь. Не так просто заказчику перейти на новую версию, да и делают они это с большой неохотой, т.к. на старой написано уже много кода и нужно платить дополнительные деньги просто за перенос этого кода на новую версию и чтобы все работало. До сих пор есть те, кто использует SAS 9.1.3.
По поводу того кого взять в штат, здесь какждый решает задачу сам. Порой грамотного специалиста по SAS найти труднее и дороже, чем тоже по Java или PL/SQL.
В самом Miner, хочу обратить внимание, нет почти ничего, чего бы не было в SAS BASE+STAT+...(или в Guide, который есть ничто иное как просто графическая оболочка над ядром), зато ряд процедур, которые удобно вызываются в Guide (там есть вполне удобный редактор), в Miner можно вызвать только через ублюдочный нод SAS Сode, в котором писать что-то длиннее пары строк, мягко говоря, неудобно. Зато за отдельные деньги к Miner докупаются допноды Ctredit Scoring, в которых есть, например, IG. Этот нод действительно экономит массу времени при разработке типовых моделей и реализовывать его самостоятельно, как это пытались делать в одной из дочек европейского банка, здравомыслящие люди точно не будут, в этом я с Вами соглашусь. Miner, повторюсь еще раз, хорош там, где надо быстро клепать типовые модели определенного вида, или где молспецу, который глубоко не разбирается в работе процедур, нужно без надрыва сделать модель, или если надо быстро что-то сделать, и принципиально время, а качество - достаточно вполне себе среднее (ложка к обеду бывает иногда очень дорога). Здесь Miner - вне конкуренции.
Но речь в моем посте была про другое: передача модели из SAS в MPP cопряжена с рядом сложностей, если Вы разрабатываете модель не в Miner, а в Guide. Иногда эту модель (набор весов при атрибутах, а не алгоритм, еще раз повторюсь) дешевле тупо самому руками реализовать в этой MPP cистеме, пользуясь инструментами MPP системы, а не пытаться сделать то, что рекомендует вендор. И опять-таки, как бы Вы туда (в MPP) модель не передавали, средствами SAS Score Accelerator или ручками, никакого "вау-эффекта" в большинстве случаев Вы не получите. Просто потому, что в MPP-системе будет острый дефицит машинных мощностей. Или потому, что настройки уровня изоляции транзакций хранилища рассчитана изначально лишь на подготовку сводов, а не на обработку он-лайн событий. Или потому, что Ваша MPP относится к классу блочных со всеми их достоинствами и недостатками.
Бывают в жизни огорчения.
А деньги организации приносят, вообще говоря, не модели сами по себе (это просто отчет, грубо говоря), а только лишь работа этой модели в операционном контуре. Нет этого - нет денег. Нет денег - аналитики будут лишь сервсным подразделением, которое плодит никому ненужные презентации с красивыми графиками, и рассуждают о кораблях, бороздящих просторы театра.
Не совсем с Вами соглашусь. 70-80% тратить на подготовку данных можно лишь в начале проекта. Когда же подразделение по моделированию работает не один год, то процесс подготовки данных уже должен быть давно выстроен. И тратить на это более 30% процентов времени уже непозволительно. Тем более должны быть специализации. Подготовку данных лучше отдавать отвечающим за это подразделениям, а те кто строят модели должны строить модели, тестировать их, переобучать и смотреть, что бы они не устаревали.
Что косается документации, тоже вопрос. Обычно когда подразделение внутреннее, то не особо следят за документацией. К тому же сейчас IT средства позволяют сделать автоматическую документацию в виде word или pdf документа не тратя на это время.
Соглашусь с Вами в том, что очень важно, чтобы на входе был порядок.
Известная тема!) Если данные подготовлены "хорошо", то и самый простой алгоритм выдаст хорошие результаты. Ведь в подготовку данных можно включить и features selection процесс, аппроксимацию missing data и много чего еще. Да, это наверное и есть основная проблема в моделировании в индустрии - подготовка данных, а запустить на них нод в майнере любой сможет) Интерпретировать и tuning тоже конечно надо, но это интересная работа, в отличии от подготовки )
А есть открытые данные? Интересно было бы посмотреть) Или они только акционерам доступны?
После того, как эта БД превращается в настоящую аналитическую БД, где есть не только исходные данные в форме, в которой их можно непосредственно в стат.пакет засунуть, но и предрассчитанные поведеческие агрегаты, а на 3 специалистов по моделированию выводится 1 специалист по работе с данными, который в разы быстрее может посчитать сложные атрибуты, загрузить в БД данные из нового источника во время пилота, автоматизировать аналитическую отчетность и.т.д, время разработки моделей снижается в разы.
Опять-таки, если из операционного модуля в аналитическую БД передаются ID моделей, которые были применены к текущей заявке, это не только 1/N testing позволяет сделать удобным при прогоне champion challenger. Это же дает возможность легко автоматизировать верификацию моделей, даже когда этих моделей будут сотни. Собственно IV посчитать, KS, Gini, SSI и статистику Хосмера-Лемешоу (или какую-то ее вариацию) для контроля стабильности калибровки - задача не бог какой сложности.
Принципиальна организация процесса. Самая совершенная кредитная фабрика или аналитический CRM не даст Вам нормально осуществлять эксперименты в рамках champion challenger, если у Вас в BRMS модуле изначально не задаются iD моделей при внедрении и.т.д.
Таких тонких мест в процессе зарабатывания денег на аналитике - сотни.
К сожалению просто иметь толковых специалистов по SAS, Java или Oracle, иметь грамотных аналитиков, бюджеты и проектных менеджеров и.т.д.для достижения успеха (в денежных единицах) недостаточно. Очень многое упирается в менеджмент и организацию взаимодействия между подразделениями.
Например, если при проектировании фронт-системы изначально не подразумевается, что эти данные будут использоваться в анализе, и вместо заполнения из справочников допускается ввод данных в свободных текстовых полях, а при заполнении идентификаторов типа ИНН не проверяются контрольные суммы и.т.д., то на входе у аналитиков будет такой трэш, что мама не горюй.
А ведь это, как и наличие "сквозных" ID для клиентов, - из уровня прописных истин.
При этом, не выстроив процессы даже на базовом уровне, набольшие крупнейших компаний сейчас ломятся за новой серебряной пулей в виде Big Data, In-Memory-Analytic и.т.д., не понимая, что добиться проставления в кредитной системе признака, который бы указывал на судьбу кредита (реструктуризация, списание, мировое соглашение и.т.д.), намного дешевле, надежнее и эффективнее, чем попытка установить эту информацию путем сопоставления неструктурированной информации из различных ИС организации. Особенно, когда у клиента даже идентификатора нет и предлагается искать информацию по ключам типа ФИО+ДР.
Сколько я уже этих серебряных пуль на своем веку перевидал. Кейс-инструменты, описание и оптимизация бизнес-процессов на пару с UML, гриды, облачные технологии, виртуализация, DWH с MPP и целевые модели данных, аналитика/скоринг - на-стороне - хранилища, аналитика/скоринг - в-оперативке...
А на практике...Ну пользовали 3NF - стали Data Vault. Щастя нет, а DWH как пилили годами, так и пилят. Да..надо вместо DWH поиметь еще и ODS, и прочие хранилища для он-лайн аналитики. Мда...треш как был, так и остался трешем. Нет, мы поняли - нам надо Map Reduce и свертки - и наступит Щасте. Неа, не наступит.
Уже гонялись за MDM системами - количество мусора в хранилищах не уменьшилось. Идея грамотно проектировать фронтовые системы и органично развивать ИТ-ландшафт выглядит все еще менее привлекательной, чем покупка и внедрение SAS Data Quality или HF Labs за много-много денег, которые - фокус-покус и решат все проблемы.
Не решат. Но веру в Поле Чудес в Стране Дураков истребит только конкуренция, если ей когда-то будет суждено возникнуть в нашей стране.
Во многом с Вами согласен. Действительно, порой для значимых улучшений достаточно более качественно и внимательно отнестись к настройкам фрон офисных систем. Это сэкономит много сил в дальнешем при анализе данных.
Если же из источников мы льем в хранилище Г., то какие бы системы мы не закупали и не вычищали это Г., все равно нормальные модели не построить. Точнее что-то мы построим, но вряд ли они будут точными и приносить желаемый value.
А так надоже вендорам денежку зарабатывать, вот и пишут в маркетинговых статьях о плюсах своих продуктов и о счастье которое наступит когда вы эти продукты внедрить ).
https://plus.google.com/+sassoftware/posts/ZyRb9eJVq3o