скользящая перекрестная проверка на k-частях. Разбейте набор данных на k случайных равнове ликих выборок. Проведите курс обучения модели на k–1 выборке из k, значения прогнозируемых переменных в которых, естественно, сильно коррелированы. Наконец, протестируйте модель на последней, k-й выборке, а затем определите ошибку обобщения по всем k-частям. Для получения численной оценки пригодности модели для использования в анализируемом контексте можно применить к полученным результатам различные статистические критерии.

4.2 Моделирование больших данных

Моделирование больших данных — задача технически крайне сложная, но решать ее необходи мо, если организация действительно нацелена на описание имеющихся в ее распоряжении дан ных с целью их постановки под контроль. Традиционные принципы архитектуры данных предприятия в равной мере применимы и к большим данным: они требуют интеграции, специфика ции и управления.

Главный стимул к разработке физической модели хранилища данных — обеспечить их на копление и возможность быстрой обработки запросов. На большие данные этот стимул не рас пространяется. Но это не повод отказываться от моделирования или отдавать его на откуп перво му попавшемуся стороннему разработчику. Ведь ценность моделирования данных заключается еще и в том, что в его процессе люди учатся понимать данные и разбираться в их содержании

исмысле. Так что применяйте проверенные методы моделирования данных, но только отдавая себе отчет в множественности и разнообразии источников. Разработайте модель предметной об ласти — хотя бы обобщенную, — чтобы ее можно было использовать для определения объектов

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

Выработайте понимание связей между различными данными и наборами. В случае данных различного уровня детализации внимательно следите за тем, чтобы какие-либо элементы или значения данных не были учтены два и более раз на разных уровнях. К примеру, категорически не рекомендуется сочетать наборы атомарных и сводных данных.

5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ

Многие общие принципы управления хранилищами данных автоматически переносятся

ина управление большими данными, включая: обеспечение надлежащей проверки надежности источников и достоверности данных; наличие метаданных в объеме, достаточном для понимания

ивозможности использования данных; управление качеством данных; изыскание способов инте грации данных из различных источников; обеспечение информационной безопасности и защиты данных (см. главы 6–8). Основные отличия при реализации среды больших данных обусловлены

тем, что приходится, по сути, решать систему уравнений со многими неизвестными: как и для чего будут использоваться данные? Какие данные будут считаться особо ценными? Каковы будут сроки хранения данных?

Скорость и объемы поступлений больших данных способны зародить мысль о том, что их можно пустить на самотек, тем более что времени на реализацию механизмов управления такими потоками, по сути, не остается. Это крайне опасное заблуждение. Чем больше массивы накоплен ных данных, тем важнее управлять их своевременной обработкой и инвентаризацией. В против ном случае озеро данных быстро превращается в гнилое болото.

Освоение больших данных далеко не всегда требует от организации получения законных прав на обладание ими или принятия на себя обязательств по их непременному изучению. Воз можны варианты периодической аренды платформы больших данных на срок, требующийся для исследования и предварительной оценки заинтересовавших вас данных. По результатам таких изысканий вы быстро определите области потенциального интереса. Да, и проводить подобную предварительную оценку нужно всегда и в любых ситуациях, прежде чем скачивать какие бы то ни было массивы данных в ИТ-среду организации, будь то озеро, хранилище данных или даже буферный накопитель.

5.1 Согласование со стратегией организации

Любая программа в области сбора и изучения больших данных должна выстраиваться сообразно стратегическим целям, планам и задачам организации. Утвержденная стратегия больших данных сразу же должна приниматься во внимание и включаться в стратегические планы управления до ступом пользователей, защиты данных, управления метаданными, включая генеалогию, и управ ления качеством данных.

В стратегии должны быть задокументированы цели, подход и руководящие принципы. Для извлечения максимума из больших данных организации как таковой нужно наработать опреде ленные навыки и способности. Используйте стандартные приемы управления возможностями и потенциалом для согласования бизнес-инициатив и ИТ-проектов в рамках дорожной карты программы. Обязательными документами являются стратегии управления:

жизненный цикл информации;

метаданные;

качество данных;

сбор данных;

доступ к данным и защита данных;

руководство данными;

конфиденциальность данных;

обучение и восприятие;

текущая работа.

Как и любой проект развития, инициатива в области больших данных или науки о данных долж на соответствовать реальным потребностям бизнеса. Прежде чем ее выдвигать, оцените готов ность организации к адекватному восприятию подобного проекта по следующим критическим параметрам успеха.

Польза для бизнеса. Насколько хорошо инициативы в области больших данных / науки о дан ных соответствуют потребностям и вписываются в канву деятельности компании? Для успеха они должны сулить перспективы качественного скачка в плане усиления бизнес-функций или развития бизнес-процессов.

Готовность бизнеса. Готовы ли бизнес-партнеры к долгосрочной, поэтапной поставке продукта? Согласны ли создать центры повышения квалификации для устойчивой поддержки новых вер сий? Не слишком ли расплывчаты в целевом сообществе общие представления, или не слишком ли скудны практические навыки, чтобы эту пропасть можно было перепрыгнуть одним махом?

Экономическая целесообразность. Проводилась ли консервативная оценка материальных и не материальных выгод от реализации проекта? Были ли учтены на стадии экономического обо снования варианты покупки/аренды готовых решений вместо построения собственных с нуля?

Прототипирование. Нельзя ли оперативно построить прототип предлагаемого решения для какой-то подгруппы целевой пользовательской аудитории, чтобы наглядно продемонстриро вать ценность модели? Масштабные реализации методом «Большого взрыва» — идея эффект ная, но многим она представляется чересчур рискованной, поскольку на кону стоят слишком большие деньги. Поэтому маломасштабная, но надежная реализация сбора в меру больших, но очень полезных и прибыльных данных — хороший способ побороть настороженность.

Однако самые трудные решения, вероятно, придутся на стадию согласования выделения средств на приобретение данных, разработку платформы и обеспечение программы прочими необходи мыми ресурсами.

Существует множество источников цифровых данных, и все их не подключишь, не купишь и не скачаешь. Какие данные реально нужны? Как это обосновать? Какие данные нужно приобрести в постоянное пользование, а какие достаточно взять во временную аренду или полу чить по подписке?

На рынке имеется множество программных средств и методологий. Какие из них лучше всего подойдут для общих нужд? В каком сочетании?

Как вовремя привлечь специалистов, обладающих всеми необходимыми на данном этапе на выками? Как удержать таланты на стадии реализации проекта? Какие альтернативы имеются в плане аутсорсинга, сетевого и облачного сотрудничества?

Воспитание собственных талантов — дело стоящее, но не в тех случаях, когда сроки сдачи работы поджимают.