Не для кого не секрет, что объем данных, с которыми мы работаем постоянно растет.
И анализировать возрастающий объем становиться все сложнее. Скорость работы ваших программ постоянно увеличивается и долего не всегда она увеличивается пропорционально объему поступаемых данных.
Так вот сейчас все большую популярность набирают MPP системы.
И речь уже не стоит в том «будут ли компании внедрять подобные системы или нет ?», а стоит лишь вопрос «когда ?»
Причем зачастую решение принимается, когда уже нет больше сил терперь, то что работает сейчас.
Так вернемся к нашему заголовку.
Одно и применений связки SAS + Hadoop — это просто хранение данных, как в решение SAS Visual Analytics. Там Hadoop используется как источник для LASR Server и позволяет быстро подгружать в оперативную память необходимые для анализа данные.
Скорость увеливается в десятки раз, по сравнению с тем, как если бы грузились бы данные просто с внешненго источника.
Другое применение связки SAS + Hadoop — это проваливание вычислений в Hadoop (или другую MPP платформу, как например Teradata, Greenplum и другие).
Примером может служить решение «SAS Scoring Accelerator» для различных платформ.
В данном случае скоринговые модели считаются на сторонее MPP платформы, что дает значительный выигрыш во времени потраченное на скоринг.
О SAS Scoring Accelerator много говорят. На практике это, к сожалению, работает очень, очень плохо. Дело заключается в том, что MPP решения обычно внедряют в проектах DWH и это подразумевает наличие ETL-процессов, которые запускаются по времени. При этом в MPP системах данные "размазываются" по разным нодам (в идеале равномерно), и каждая задача нагружает всю систему целиком. Вполне очевидно, что регламентные ETL — процессы имеют высший приоритет. Он-лайн скоринг, как говорится, это интересно, но поддержку ключевых бизнес-процессов никто не отменял. Как следствие, в некоторые моменты времени производительность этих акселераторов сильно проседает. Дальше интереснее. В сколь-либо крупной организации (а другие либо не могут себе позволить закупку MPP решений, либо не испытывают в них нужды) в ЦХД живут десятки витрин и ETL -процессов, а уровень утилизации либо высокий либо очень высокий. Хотя бы потому, что проекты ЦХД обычно презентуются высокому руководству как способ экономии на закупке железа, в духе, что раньше у нас было 10 отдельных систем, каждая мощностью X и стоимостью Y, которые работали на 40% своей мощности в среднем, в теперь будет одна, мощностью 4,4X и стоимостью 5Y, мощности которой будут использоваться рационально.
Ну да. Только ее загрузка будет за 90% в среднем. Звучит красиво, если не задумываться, что в худшем случае, который будет случаться не так уж и редко (попробуйте добиться идеальной синхронизации и идеальной работы всех процессов), ETL — процессы в очереди стоять будут. А весь смысл акселераторов в том, что они используют СВОБОДНЫЕ ресурсы MPP системы. Которых при таком раскладе не будет вовсе. И закупать дорогое железо, чтобы был резерв мощности на случай, когда Вам приспичит скоринг погонять, никто не будет. В России я ни от одного конечного пользователя в адрес связки акселератор+MPP цензурных слов не слышал, за исключением, единственного, по-моему, исключения, когда этот MPP изначально внедряли для быстрого обсчета моделей в операционном контуре, а не в рамках проекта общекорпоративного DWH, где этот обсчет — дело десятой степени важности.
Ну и по мелочи: в один момент времени у Вас может быть только одна версия акселератора и одна версия SAS. Если в организации два проекта, то первый проект сможет перейти но новую версию SAS только вместе со вторым, иначе один из этих проектов останется без акселератора. Проекты же в больших организациях редко меньше года длятся. И в середине проекта версию ПО менять в здравом уме никто не будет. В итоге на новую версию Вы перейдете через пару лет в лучшем случае, потому что пока второй проект доделают, откроется третий или вторая фаза первого. А ведь проекты могут быть еще и в разных подразделениях, что согласования отнюдь не упрощает.
Кроме того, у этих самых акселераторов есть неприятная особенность, что запускать в них более-менее удобно можно лишь модели, которые сделаны в Miner. Если Вы выпилили что-то в Guide, для запуска модели на стороне MPP системы придется попрыгать с бубном и поработать напильником. Положим, модели текущего кредитования (для рисков) или модели отклика (для CRM) в Miner делаются удобно. Но вот уже с LGD моделями не все так радужно, а лабать в Miner NII и EaR — это разновидность мазохизма. С другой стороны, эти модели и на жутко больших объемах гонять обычно не надо. Но тогда возникает один неприятный вопрос: а где их вообще гонять, если мы изначально ставку на обсчет на стороне хранилища сделали. Понятно, что если припрет, можно и на личной персоналке обсчитать, но, спрашивается, если очереди на "он-лайн" скоринг для одной задачи надо ждать пару дней, а вторую приходится считать, где получится, зачем вся эта возня с акселераторами вообще нужна? Дешевле просто вывести в штат человека, который модели реализовывать в Java, PLSQL или Teradata SQL или предложить подчиненным освоить нужный язык, благо научиться кодировать конструкции вида "если- то, иначе" много ума и усилий не требуется. Обойдется на порядок дешевле затрат на проект и стоимости лицензии и работать будет лучше.
Про все остальное не знаю, но прокомментирую последний абзац. Если это написано про алгоритмы реализованные в Miner:
> благо научиться кодировать конструкции вида "если-то, иначе" много ума и усилий не требуется
,то это конечно не верно. (Хотя верно, но только до той степени что к if-else + циклам можно свести любую самую сложную программу). В Miner-е реализованы сложные методы и, думаю, оттестированы. Может быть за основу взяты Open source продукты, это не известно. Но самому реализовывать всё что есть в майнере совсем не обязательно, потому что все равно придется писать тесты и сравнивать с уже существующими имплементациями. Проще сразу взять уже готовые библиотеки в которых код "revisited and tested". Если, нужна Java, то можно взять Weka (там есть GUI интерфейс, но можно использовать довольно легко и jar файлы прямо в своем исходном коде).
Иван, здравствуйте.
Во-первых хотел поблагодарить за интереснейший комментарий, в котором вы затронули достаточно мого пробем, с которыми приходиться встречаться при внедрении подобного рода систем.
Где-то я разделяю вашу точку зрения, где-то нет.
Прежде всего везде нужно подходить с умом и понимать еще до внедрения какие задачи будет решать данная система.
Часто бывает так, что уже существуют рабочие модели, которые отрабатывают по расписанию. Такие модели действительно надо оборачивать в ETL и ставить на расписание.
Что косается online скоринга, то здесь нужно думать. В данном случае, пологаю, модели могут быть не сложные и общет может идти на сервере SAS (тем более если "проваленные процессы" в MPP систему будут висеть в очереди).
Конечно всего не предусмотришь и многое начинаешь понимать лишь при внедрении.
Что касается новых версий — здесь я с Вами соглашусь. Не так просто заказчику перейти на новую версию, да и делают они это с большой неохотой, т.к. на старой написано уже много кода и нужно платить дополнительные деньги просто за перенос этого кода на новую версию и чтобы все работало. До сих пор есть те, кто использует SAS 9.1.3.
По поводу того кого взять в штат, здесь какждый решает задачу сам. Порой грамотного специалиста по SAS найти труднее и дороже, чем тоже по Java или PL/SQL.
Аlexander, абзац "if-then-else" относился к решающим правилам, которые получаются на выходе Miner, и процедуре внедрения этих правил в операционный контур посредством, например, BRMS приложения (от FICO, Experian или CRIF) или непосредственно в ETL-машине, а не к процедурам/алгоритмам, с помощью которых Вы это решающее правило (скоринговую карту, если угодно, или модель и.т.д.) получаете.
В самом 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 относится к классу блочных со всеми их достоинствами и недостатками.
Бывают в жизни огорчения.
А деньги организации приносят, вообще говоря, не модели сами по себе (это просто отчет, грубо говоря), а только лишь работа этой модели в операционном контуре. Нет этого — нет денег. Нет денег — аналитики будут лишь сервсным подразделением, которое плодит никому ненужные презентации с красивыми графиками, и рассуждают о кораблях, бороздящих просторы театра.
Этот комментарий был удален автором.
Понятно Иван, значит неправильно понял. Я на все это как раз смотрю с точки зрения чисто аналитика ) Да, очень интересно, не знал о таких проблемах. После прочтения появилось ощущение что всё-таки некоторые проблемы созданы SAS искуственно, так чтобы люди пользовлись не только Base/Guide, но и Miner не обходили стороной!)
Я последние годы смотрю на все это с точки зрения миноритарного акционера, и меня интересует не столько Gini, KS или SSI, сколько ROI и NPV от инвестиций в ту или иную инициативу в целом. Просто для справки: при создании подразделения по моделированию, у людей до 70-80% времени при этом самом моделировании уходит на подготовку данных. А ведь собственно моделирование — это ведь еще не все. Документирование, внедрение в операционный контур или, как минимум, участие в тестировании этого внедрения (даже если есть BRMS надо убедиться, что при внесении модели нигде не ошиблись с знаком, цифрой, ряазрядностью, именованием переменных), отчетность, мониторинг эффективности, what-if анализ, управление требованиями к информационным системам, бизнес-анализ и.т.д. В итоге, при внимательном изучении вопроса, собственно моделированием люди не так уж много и занимаются. Это я не к тому, что моделирование — бесполезная трата времени, а к тому, что ключ к повышению эффективности лежит вовсе не в выборе самого крутого алгоритма, а завязан на подходы к проектированию фронт-систем, организации бизнес-процессов, зрелости ИТ-инфраструктуры, качество данных (которое ни один MDM проект сам по себе не обеспечит, если на входе полный трэш).
Иван,
Не совсем с Вами соглашусь. 70-80% тратить на подготовку данных можно лишь в начале проекта. Когда же подразделение по моделированию работает не один год, то процесс подготовки данных уже должен быть давно выстроен. И тратить на это более 30% процентов времени уже непозволительно. Тем более должны быть специализации. Подготовку данных лучше отдавать отвечающим за это подразделениям, а те кто строят модели должны строить модели, тестировать их, переобучать и смотреть, что бы они не устаревали.
Что косается документации, тоже вопрос. Обычно когда подразделение внутреннее, то не особо следят за документацией. К тому же сейчас IT средства позволяют сделать автоматическую документацию в виде word или pdf документа не тратя на это время.
Соглашусь с Вами в том, что очень важно, чтобы на входе был порядок.
> у людей до 70-80% времени при этом самом моделировании уходит на подготовку данных
Известная тема!) Если данные подготовлены "хорошо", то и самый простой алгоритм выдаст хорошие результаты. Ведь в подготовку данных можно включить и features selection процесс, аппроксимацию missing data и много чего еще. Да, это наверное и есть основная проблема в моделировании в индустрии — подготовка данных, а запустить на них нод в майнере любой сможет) Интерпретировать и tuning тоже конечно надо, но это интересная работа, в отличии от подготовки )
Этот комментарий был удален автором.
> Я последние годы смотрю на все это с точки зрения миноритарного акционера, и меня интересует не столько Gini, KS или SSI, сколько ROI и NPV от инвестиций в ту или иную инициативу в целом.
А есть открытые данные? Интересно было бы посмотреть) Или они только акционерам доступны?
Я про самое начало и говорил. Простое создание БД масштаба отдела (в простейшем случае реплики фронта и кредитной системы, например), позволяет повысить эффективность процесса разработки моделей намного сильнее, чем закупка самого продвинутого инструмента для моделирования.
После того, как эта БД превращается в настоящую аналитическую БД, где есть не только исходные данные в форме, в которой их можно непосредственно в стат.пакет засунуть, но и предрассчитанные поведеческие агрегаты, а на 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.
А так надоже вендорам денежку зарабатывать, вот и пишут в маркетинговых статьях о плюсах своих продуктов и о счастье которое наступит когда вы эти продукты внедрить ).
webinar по теме:
https://plus.google.com/+sassoftware/posts/ZyRb9eJVq3o