• Сложно подобрать и удержать квалифицированных специалистов, которые умеют работать с экосистемой Apache Hadoop.
• Требуется много времени на реализацию проекта от пилотной версии до продуктовой среды.
• Технологии Big Data эволюционируют очень быстро, что затрудняет их внедрение.
• Проекты не приносят той пользы, которую от них ожидают.
• Сложно добиться того, чтобы данные в Apache Hadoop подходили для выполнения поставленных целей, были доступными и надёжными, хранились в безопасности.

Самая большая проблема в работе с Big Data сейчас – найти хороших специалистов. Их требуется всё больше. Один из крупнейших международных банков начал свой проект по большим данным с командой из 5 Java-разработчиков. Но инициатива быстро развилась и в этом году им понадобилось нанять ещё 25 специалистов. Масштабировать свою инфраструктуру, чтобы хранить и обрабатывать большие объёмы данных, банк смог быстро. А увеличить число квалифицированных кадров – нет. Но, если детально разобраться с функциями специалистов по работе с большими данными, то окажется, что они выполняют много монотонных задач, которые могут быть автоматизированы. Согласно консалтинговой фирме Booz Allen Hamilton, «в некоторых организациях, аналитики тратят до 80% своего времени на подготовку данных. На проведение самого анализа у них остаётся всего 20%». Автоматизировать выполнение задач по подготовке данных к аналитике (их интеграцию, каталогизацию, обеспечение их качества, обезличивание и так далее) помогают промышленные инструменты. В частности, решения компании Informatica, которые эффективно работают в среде Apache Hadoop. Для платформы Informatica вы легко найдёте специалиста на рынке. И он заменит армию программистов, которые вручную пишут код на Java и других языках программирования, которые подходят для Apache Hadoop. Проведённые тесты показали, что специалисты Informatica в среднем в 5 раз продуктивнее работают с данными на Apache Hadoop, чем программисты, которые работают вручную. И это при том, что первым не нужно осваивать написание кода на многочисленных языках программирования. Сейчас ситуация на рынке такая, что только каждой из топ-100 компаний мира необходимо нанять по 40 data scientists. Хотите ли вы тратить время таких востребованных специалистов на подготовку данных к анализу, а не на сам анализ? Или автоматизируете 80% их задач?

Один из клиентов Informatica из области медиа и развлечений перед покупкой Informatica Big Data Management рассказал мне, что его предыдущий проект в области больших данных уже потерпел неудачу. Он так объяснил мне причину этой неудачи: «Мы наняли опытных Java-разработчиков. Они придумали идею решения и даже доказали её жизнеспособность в песочнице. Но потом пришло время выводить это решение в продуктовую среду. И тогда им пришлось переработать большую часть кода, чтобы оно заработало, легко масштабировалось, было доступно 24х7 и интегрировалось с остальной продуктовой инфраструктурой. Кроме того, созданное решение было сложно поддерживать, когда что-то менялось. Всё вместе привело к задержкам в реализации всего проекта и перерасходу средств». Сложно представить себе, что такая ситуация произойдёт с промышленной платформой. Благодаря ей всё, что вы разрабатываете в песочнице, может быть мгновенно и автоматически использоваться для продуктовой среды. Производительность, масштабируемость и надёжность платформы обеспечиваются благодаря параметрам конфигурации. При этом нет необходимости перестраивать или перерабатывать разработки, как это приходится делать при работе с решениями, которые вы напишите сами. Также промышленная платформа упрощает повторное использование существующих разработок и поддержку проектов Big Data даже тогда, когда что-то меняется. Informatica BDM включает в себя технологию Vibe, которая обеспечивает универсальную совместимость систем и ускоряет загрузку новых типов данных в любых объёмах и на любой скорости.

Технологии Big Data появляются и развиваются очень быстро. Многие организации не успевают внедрить предыдущую разработку до того, как появится новая. Что, если вы сделаете ставку не на ту технологию, и узнаете, что она вышла из употребления ещё до того, как вы начали её использовать? Apache Hadoop сейчас широко внедряется. Но он постоянно меняется и развивается вместе с другими решениями в области. Сейчас в сфере больших данных буквально сотни open-source и коммерческих решений. Informatica смогла эффективно решить проблему взрывного развития технологий. В платформу Big Data Management (BDM) встроена технология Vibe, которая позволяет использовать виртуальную машину. Благодаря этому практически любой процесс, который работает на традиционном оборудовании, может быть запущен без каких-либо дополнительных усилий на кластере Apache Hadoop. Другими словами, инфраструктура, которую вы выстроили для корпоративных данных среднего размера, может использоваться и для Big Data. Текущие клиенты Informatica могут взять маппинги PowerCenter, которые они создали много лет назад, импортировать их в BDM и использовать в Apache Hadoop. В большинстве случаев это можно сделать без дополнительных усилий и не внося никаких изменений. Сегодня существуют платформы Apache Hadoop с пятью различными приправами. Завтра будет Apache Hadoop и пять совершенно других технологических платформ. Решения Informatica уже готовы к такой ситуации и смогут эффективно работать и с ними. Как решить оставшиеся две проблемы Big Data и среды Apache Hadoop, читайте во второй части статьи по ссылке Решаем 5 главных проблем Big Data и среды Apache Hadoop. Часть 2.

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

Самый простой способ перемещения данных в облако – подход “lift-and-shift” (копирование в облако без изменения архитектуры). Он заключается в том, что вы перемещаете содержимое своего хранилища (ХД) в облако в том же самом виде, в котором оно было размещено на серверах компании. Это касается не только данных, но и маппингов, процессов и кода, который помогает определить, обработать и переместить эти данные. Но такая схема предполагает, что в облачное хранилище данных вы экспортируете и неэффективный код, неоптимальные сокращения и устаревшие практики. Они копились в течение многих лет и тихо сжигали большую часть ваших затрат на операционную деятельность. Но зачем закреплять старые ошибки на новой платформе? (Читайте о том, как правильно перемещать информацию в облачное хранилище данных, читайте в статье Хранилище данных никуда не уйдёт, оно улетит в облако) Вместо этого можно использовать миграцию в облачное хранилище данных для поиска и исправления слабых мест в коде. При перемещении данных в облако, вам придётся всё протестировать заново в любом случае. Тестирование скорее всего займёт много времени и ресурсов. А если вы их тратите в любом случае, оптимально использовать их так, чтобы повысить эффективность системы, связанной с данными?

Каждый ИТ-отдел пытается держать баланс внедрения инноваций и поддержания существующей системы. Традиционно 70% ИТ-бюджета идёт на поддержку действующей инфраструктуры. 30% на то, чтобы внедрять что-то новое. И это не простая статистика. С течением времени неэффективность множится, и задача поддержки поглощает всё больше ресурсов. Начинается всё с малого. Немного ИТ-организаций строго подходит к улучшению стандартов написания кода. Поэтому с течением времени десяток разных девелоперов используют сокращения кода по своему усмотрению для того, чтобы справиться с десятками различных ошибок. Это приводит к тому, что, когда где-то возникает неполадка, для её исправления специалисту приходится самостоятельно изобретать её решение. Он не сможет ориентироваться на чужой опыт, потому что система и код в организации будут уникальными. Каждое последующее исправление будет требовать больше времени и бюджетных трат. И я имею ввиду реальные деньги. Когда я руководил большим корпоративным ХД в Pfizer, я сократил расходы на поддержку системы на 20% ежегодно благодаря перестройке существующей инфраструктуры. Каждый сэкономленный цент был потрачен на внедрение инноваций. Это жизненно необходимо сегодня. Всё больше руководство настаивает на необходимости внедрения самых передовых решений в ИТ. А бюджет, который выделяется этому отделу, редко соответствует масштабу амбиций компании. Невозможно добиться успеха в таких условиях без сокращения затрат на поддержку существующих решений и инфраструктуры.

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

Безусловно, если вы используете миграцию в облако для полной проверки кода, связанного с данными, вы увеличите время всего процесса и траты на неё. Но в конечном итоге вы останетесь в плюсе. Периодически я слышу от руководителей ИТ-отделов примерно следующее: «Да, мы инвестировали на 20% больше во фронтенд, чтобы улучшить наши ETL-процессы во время перемещения информации в облачное хранилище данных. Но теперь ежегодно мы сможем экономить. И эта экономия окупит затраты меньше, чем за 18 месяцев. А средства от неё можно потратить на инновации и инициативы по цифровой трансформации». Если в компании есть теневые ИТ-команды, ИТ-директор организации должен их также убедить в выгодности совместного перемещения информации в облачное хранилище данных. (Теневая ИТ-команда создаётся внутри отдельного юнита или подразделения для обслуживания его собственных нужд). Бизнес-подразделения используют свои бюджеты, чтобы поддерживать собственные теневые ИТ-сервисы по ситуации. ИТ-директор может пойти в такое бизнес-подразделение и сказать: “Выделите моей команде свой бюджет и моя команда улучшит ваш код и решит ваши проблемы. Мы проведём миграцию данных, обеспечим поддержку этого сервиса. А всё, что сможем сэкономить таким образом поделим пополам между вашим и нашим отделом». У указанного бизнес-подразделения будет на одну головную боль меньше и больше бюджетных средств на то, чтобы потратить их на что-то более важное. Общекорпоративный ИТ-отдел получает лучший контроль инфраструктуры компании, лучшее качество данных и потратит меньше денег на инновации. Кроме того, всегда разговаривайте со своими внутренними клиентами и никогда не упускайте возможностей. Вместо того, чтобы привязываться только к ИТ-составляющей проектов, потрудитесь выяснить, как пользователи на самом деле используют программное обеспечение, которое вы предоставляете им. Сколько лицензий скорее всего не будет использоваться? Какие функции никому не нужны? Что можно вы могли бы добавить к своему проекту, чтобы сделать его успешнее? Ответы на все эти вопросы помогут вам и добиться лучшей эффективности, и внедрить инновации. А зачастую первое поможет оплатить второе.

Что такое Apache Hadoop и как он работает, вы можете узнать в статье Что такое Big Data? Азбука больших данных от А до Я. О том, что делать, чтобы внедрение Apache Hadoop окупилась, рассказывает Питер Ку. В корпорации Informatica Питер отвечает за консалтинг в области решений для финансовой индустрии. Эксперт помогает компаниям банковского и финансового рынка эффективно применять данные и решения управления ими для выполнения различных бизнес-задач. Среди этих задач – соответствие требованиям регуляторов и улучшение клиентского опыта.

Теперь всё реже можно услышать вопрос «Что такое Big Data?» и всё чаще – «Как мы можем с максимальной эффективностью использовать Big Data для решения конкретных бизнес-задач?». Кажется, что с большими данными сейчас работают все. Одни компании предлагают программное обеспечение для предиктивной аналитики «нового поколения» в традиционных базах данных. Другие — для обеспечения качества данных, для их интеграции, для Business Intelligence. Каждая организация считает, что именно она играет ключевую роль в работе с Big Data. Правда же в том, что важные роли играет каждая из них. Но самое восторженное отношение сейчас – к Apache Hadoop и его экосистеме. Обусловлено это тем, что первопроходцы, которые экспериментировали с версиями этого решения в open source, быстро выросли до масштаба внедрения промышленных решений уровня организации. Apache Hadoop сейчас предлагают Cloudera™, HortonWorks™, MapR™ и Amazon’s RedShift™.

Apache Hadoop быстро и дешево обрабатывает большие объёмы данных за счёт распределённой архитектуры. Все операции в нём осуществляются на отдельных недорогих серверах. В самом Apache Hadoop нет нативных инструментов для аналитики или Business Intelligence. Модели для них запускаются аналитиками и data scientists с помощью специальных приложений, которые могут работать в среде Apache Hadoop. Только результаты анализа извлекаются в отдельное хранилище для использования решениями Business Intelligence, управления кампаниями, систем отчётности. Такой механизм ускоряет предоставление данных и сокращает затраты на вычисления и работу моделей по сравнению с традиционной архитектурой хранилища.

Apache Hadoop позволяет компаниям решать целый ряд реальных бизнес-задач, выполнить которые было бы сложно с помощью традиционных инструментов. На основе больших данных в Apache Hadoop можно выявлять фрод (мошенничество в области информационных технологий) в финансовом секторе и электронной торговле. Для этого анализируется информация из журнала регистрации вызовов, социальные данные, данные по оплатам и транзакциям за всё время. Анализ клиентских настроений в телекоме и здравоохранении позволяет определить клиентов, которые с большой вероятностью перейдут к конкуренту. Это можно сделать с помощью интеграции транзакционных данных и информации о взаимодействии компании и клиента в реальном времени. Также с помощью больших данных можно повысить качество риск-менеджмента во всей организации. Для этого нужно консолидировать данные о рисках по кредитам, на рынке и в операционной деятельности и анализировать их.

Безусловно, Apache Hadoop открывает перед бизнесом широкие возможности. Но реализовать их можно, только если у компании есть эффективные и масштабируемые инструменты для интеграции Big Data и обеспечения их качества. Инструменты должны подходить для всех трёх главных признаков больших данных: больших объёмов, скорости и многообразия. Давайте начнём с того, как переместить Big Data на Apache Hadoop. При том, что сейчас увеличиваются не только объёмы данных, но и число систем-источников, которые эти данные генерируют. Данные в разных форматах, с разной структурой и типами должны быть трансформированы, форматированы и валидированы перед загрузкой в Apache Hadoop. Интеграция данных с использованием нативных языков программирования Hadoop (PIG, MapReduce и другие) требует привлечения разработчиков, которые владеют такими языками. Может быть непросто найти подобных специалистов из-за их высокой стоимости и долгого цикла проектов. Помочь в такой ситуации смогут промышленные инструменты, которые автоматизируют интеграцию данных. Кроме того, качество и достоверность данных играет большое значение и тогда, когда data scientists и аналитики начинают запускать на них свои модели. Как говорится в одной известной пословице, «что посеешь, то и пожнёшь». Можете спросить любого data scientist или аналитика, на что они тратят большую часть своего времени. Скорее всего, они ответят, что на то, чтобы обеспечить качество данных для своих моделей и аналитики. Исследование Elder Research показало, что аналитики и data scientists тратят от 60% до 80% процентов рабочего времени на очищение и подготовку тех данных, которые предоставили им ИТ-специалисты. В течение многих лет обеспечение качества данных остаётся одним из главных приоритетов бизнеса. Но несмотря на это, многие и большим, и маленьким компаниям не хватает отлаженных процессов и технологий для того, чтобы автоматизировать обнаружение, фиксацию и мониторинг процессов обеспечения качества данных из систем-источников, которые генерируют данные для аналитики, BI, применения для бизнес-целей. Пока эта проблема не решена, сложно добиться и окупаемости Apache Hadoop. Сейчас большие данные используют все шире, всё шире используется и Apache Hadoop. Для того, чтобы эта технология работала эффективно и приносила реальную прибыль, необходимы решения по интеграции данных и обеспечению их качества.

Apache Spark – это технология, которая работает с Big Data. Если вы никогда не слышали об особенностях хранения и обработки больших данных, читайте сначала статью «Что такое Big Data? Азбука больших данных от А до Я».

MapReduce – компонент Hadoop для обработки данных (есть ещё HDFS для их хранения). Он проводит вычисления в два этапа. На первом этапе (Map) главный узел кластера Hadoop распределяет задачи по другим узлам (нодам). На втором – данные сворачиваются, передаются обратно на главный узел и формируется окончательный результат вычисления. Такая сложная схема приводит к задержкам в работе. Пока все процессы этапа Map не закончатся, процессы Reduce не начнутся. Замедляет работу технологии и то, что обрабатывает она в основном информацию на жёстких дисках. MapReduce прекрасно справляется с пакетной обработкой, но, когда требуется высокая скорость – низкая латентность – такая технология не подходит. В промежутке между 2007 и 20015 появилось множество независимых проектов по разработке решения, которое могло бы проводить вычисления на Hadoop, но с высокой латентностью. В частности, появились Apache Storm, GarphLab, Apache Tez, Giraph. Они и сейчас остаются полноценными частями экосистемы Hadoop. Наибольшую популярность приобрёл Apache Spark. Он сохранил главные преимущества MapReduce. В частности – неограниченную горизонтальную масштабируемость и способность восстанавливаться даже после серьезных ошибок системы. При этом Apache Spark проводит вычисления в оперативной памяти. Благодаря технологии RDD (resilient distributed dataset) Apache Spark не проводит всех вычислений сразу, а только тогда, когда требуется вывести готовый результат. Всё это позволяет ему в 10-100 раз работать быстрее своего старшего товарища.

Apache Spark – отдельное решение, которое теоретически может использоваться и для другой платформы хранения данных: для Apache Cassandra или Amazaon S3.

Apache Spark создавался для случаев, когда объёмы данных сравнительно небольшие, а латентность требуется высокая. Если у вас нет очень больших объёмов оперативной памяти, Spark не сможет обрабатывать очень большие данные.

Apache Spark был разработан так, что подходит и для пакетной и для итеративной обработки. Итеративная обработка нужна для машинного обучения (библиотека MLib), работы с графами (оптимально применять библиотеку GraphX) и обработки данных в потоковом режиме (SparkStreaming), оно активно применяется для IoT и кибербезопасности.

Вести разработку на Apache Spark можно с помощью множества языков, например, с помощью Java, Scala, Python и R. Писать код в Apache Spark намного проще, чем на MapReduce, а сам код получается короче и компактнее.

Решения Informatica для Big Data прекрасно работают с технологией Apache Spark. Кейсы успешной совместной работы есть уже и на международном, и на российском рынках. «Продукты Informatica работают с графами с помощью Apache Spark, — объясняет Сумиит Агравал, главный менеджер по продукту Informatica. — Потому что мы всегда стараемся использовать инновации open-source». При этом, Apache Spark не может составить конкуренцию Informatica Big Data Management в области пакетной обработки данных при ETL. Исследования показали, что собственная технология Informatica на основе технологии YARN – Blaze – работает в 2-3 раза быстрее при осуществлении ETL-процессов. Он также позволяет эффективнее использовать ресурсы при проведении нескольких операций и имеет целый ряд других преимуществ.

Организации должны аккуратно опускать свои руки в озёра данных. Предосторожности нужны не потому, что у компаний нет возможности технически поддерживать свои водоёмы информации. Дело скорее в том, что к работе с этим решением не готовы сотрудники, а бизнес-процессы к ней не приспособлены. На форуме Data Summit, который проходил в Нью-Йорке, обсуждались сложности озёр данных и возможности, которые открывает эта технология. Среди участников – Энн Бафф, менеджер по бизнес-решениям для передового опыта в Институте SAS; Абхик Рой, инженер базы данных Experian и Тассос Сарбейнс, математик и data scientist в области инвестиционно-банковского дела Credit Suisse.

В том, что касается технологий, большинство организаций легко могли бы применять озёра данных, считают участники дискуссии. «Мы движемся в верном направлении, – считает Сарбейнс. – Для эффективной работы достаточно интеграции сервисов, процессов и наборов инструментов, которые есть у компаний. Кроме того, мы каждый день слышим от сообщества open source о новых инструментах, которые раздвинут границы возможного ещё шире. Ограничений никаких нет. Сообщество open source постоянно создаёт всё новые и новые решения». Бафф давно выступает против самой концепции озера данных. Но она согласна с тем, что проблема не в технологии, а в людях, которые используют её. «Для меня данные – это как банка с шурупами, болтами и гвоздями. Такие многие держат у себя в гаражах. Шурупы, болты, гвозди и данные хранятся на случай, если они когда-нибудь понадобятся, на всякий случай. Но доступ к такой банке должны иметь только те, кто понимает, когда именно что можно применить». Бафф утверждает, что новые технологии, такие как озеро данных, могут появляться и исчезать. Важно, чтобы организация выращивала или нанимала сотрудников, которые смогут развиваться вместе с новыми требованиями бизнеса. Она считает, что не стоит искать специалистов с определённым набором навыков и умений. При найме нужно задавать соискателям один вопрос – «какая ваша главная задача в компании». Сотрудников нужно нанимать с условием, что они действительно понимают, чего пытаются достичь для компании. Также важно, чтобы работник был готов меняться вместе с технологией, когда она изменится».

Озёра данных – «это только точка на радаре» развития технологий, считает Бафф. Также она перечисляет новые решения, которые сейчас разрабатываются. Например, будут такие, которые смогут применять структуру ДНК для хранения данных. Модель ДНК потребует небольшую часть того места, которое занимают данные сейчас. Большие хранилища в таких условиях будут не нужны. Вопрос в том, будет ли озеро данных иметь такую же ценность для бизнеса через несколько лет? Особенно, когда активнее будет использоваться интернет и семантическая паутина для хранения данных онлайн, а также новые аналитические ресурсы. Скорее всего, да. Потому что некоторые данные, например, информация с сенсоров, настолько быстро меняется, что нужен специальный инструмент, который сможет поймать её и удержать. Сарбейнс считает, что озеро данных будет необходимо всегда, потому что «организациям нужно своё собственное место, где они могут в безопасности хранить свои данные», – говорит Сарбейнс. «Сейчас на рынке нет места банкам или финансовым организациям, которые бы хранили данные в интернете. Им пришлось бы уйти с рынка на следующий день после того, как они начали это делать». Бафф признаёт, что архитектуры с озёрами данных довольно эффективны. «Тревогу вызывают только организации, которые просто перемещают данные из разных источников в озеро и всё. Но идея, что связанные данные обязательно являются интегрированными, в корне неверная», – объясняет Бафф. Она добавляет, что озеро данных приносить пользу, если в нём работают «хорошо знающие данные и хорошо обученные люди». Однако «это не значит, что, если у вас есть озеро данных, доступ к нему можно давать всем. Специалисты без достаточной квалификации могут стать причиной нарушения работы всего решения». Рой считает, что нужно в первую очередь принимать во внимание бизнес-процессы, а не технические аспекты работы с данными. «Сначала нам нужно спросить себя, какую ценность озеро данных представляет для организации. Нашли ответ на этот вопрос? Вас подстерегает следующая проблема. Вам может быть сложно переместить слабо моделированные данные в среду озера. Нужно будет решить, как это сделать или научиться недорого создавать модели данных для каждого кейса». Вместе с настроенными процессами работы с данными и экспертизой сотрудников большую роль играет наличие онтологии (состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила и так далее). Она является ключевым требованием при работе в среде озера данных, считает Сарбейнс. «Онтология будет играть ведущую роль в вашем озере или озёрах. Сотрудник, который заходит в озеро данных, чтобы найти что-то и выполнить необходимый анализ, должен будет посмотреть в «словарь данных». Хотите узнать, какие ошибки чаще всего компании допускают при использовании озёр данных? Читайте об этом в другой статье в нашем блоге – Только начинаете работать с Big Data? Избегайте этих 5 ошибок!

Традиционное хранилище данных по-прежнему имеет большое значение во многих крупных организациях со сложной корпоративной структурой. Традиционные ХД позволяют решать проблемы отчетности и аналитики. Они обеспечивают сотрудников хорошо-интегрированными, систематически очищающимися, доступными релятивными данными. А при внедрении озёр данных и инструментов по управлению мастер-данными, ХД можно адаптировать под новые архитектуры. Давид Лошин и Аби Рейфер, эксперты исследовательской компании Eckerson Group, объясняют в своей недавней статье: «Традиционное хранилище данных стягивает нужные данные в отдельную среду. Оно организует их в формат, который удобен для их обобщения, агрегирования, других типов запросов. Благодаря этому аналитики могут делать свою работу, в реальном времени, не мешая работе приложения, из которого поступили данные». Другие модели сбора и хранения данных для анализа могут казаться более эффективными, чем обычное ХД. Но нужно дважды подумать, прежде чем заменять чем-то уже существующее в компании хранилище данных. «Действительно ли MapReduce обрабатывает запросы быстрее, чем SQL? Иногда это так, иногда нет. Всё зависит от конфигурации данных, их структуры и частоты изменения этой структуры», – замечают специалисты Eckerson Group. Новые платформы, которые приходят на смену традиционным ХД, обещают лучшую гибкость. Но часто оказывается, что они «собирают данные о транзакциях в отдельные среды. Они трансформируют данные таким образом, чтобы они были организованы для лучшей доступности и более быстрой обработки. Но не в этом ли основной принцип, по которому работает традиционное хранилище данных?», – задаются вопросом Давид Лошин и Аби Рейфер. «Да, продуктивность у новых платформ лучше. Они позволяют работать с большими объёмами данных и более широким кругом источников. Но мы всё равно должны внимательно подумать о том, насколько они удобнее для обеспечения данными их конечного пользователя: аналитика, data scientists и других».

«Традиционное хранилище данных, конечно, живо. Но всё-таки оно недостаточно хорошо себя чувствует», – указывает в своей статье другой эксперт Eckerson Group, Дейв Уэллс. «Частота использования ХД постоянно растёт. Список источников данных и их типов постоянно расширяется. Объёмы, в которых информация собирается, увеличиваются. В таких условиях традиционное хранилище данных сталкивается с всё большими проблемами. Оно несомненно живо, но требует обязательной модернизации – перехода в облако», – объясняет он. Облака обеспечивают высокий уровень масштабирования. «Гибкость облаков лечит главную боль – управление загрузкой данных», – объясняет Уэллс. К тому же «облака обладают преимуществами управляемой инфраструктуры и сокращает затраты». Кроме того, «RDBMS (система управления реляционной базой данных) в облаке упрощает управление, не требуя при этом перестройки и использования NoSQL-подхода».

Однако переместить хранилище данных в облако – это не в парке прогуляться. Тем, кто решился на это, Веллс даёт следующие рекомендации:

• Обеспечьте ясность. «Начните планирование с составления списка причин, почему вам нужно переместить хранилище данных в облако, — советует Уэллс. — Определите свою стартовую позицию, свою конечную цель, разработайте маршрут движения к ней от начала до конца. На протяжении всего проекта придерживайтесь выбранного курса».
• Оцените текущую архитектуру, которую имеет хранилище данных. «Текущая архитектура может иметь недостатки и с трудом соответствовать требованиям команды аналитики. В этом случае запланируйте её перестройку, когда будете перемещать данные в облако».
• Определите стратегию миграции. Избегайте подхода “lift-and-shift” (копирование в облако без изменения архитектуры). «Изменения обычно нужны для того, чтобы адаптировать структуры данных, улучшить обработку, гарантировать совместимость с выбранной облачной платформой. Такая поступательная миграция распространена шире и обычно более успешна».
• Выберете технологию. «Определите облачную платформу, на которую вы хотите перейти. После этого можно выбирать инструмент для миграции».
• Перемещайте данные и вводите ХД в эксплуатацию. «Составьте план по тому, как вы будете тестировать успешность миграции. После этого начинайте перемещать структуру, данные и обработку. Протестируйте успешность их перемещения. Если тестирование пройдёт успешно, вводите облачное хранилище данных в эксплуатацию и перемещайте пользователей и приложения».

Подходит ли блокчейн, или, по-другому, распределённый реестр, для работы с большими данными? Этот вопрос подняли в свой недавней статье эксперты исследовательской компании Eckerson Group. Они советуют: не спешите с этой идеей. «Пока неясно, сможет ли блокчейн встроиться в архитектуры, которые используют организации для обработки и хранения больших данных», – считают специалисты.

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

«Блокчейн был разработан для решения узкого набора проблем, где требуется децентрализация и неизменяемость. Эти параметры технологии сужают круг задач, для которых его можно использовать», – объясняет Джулиан Эрес, эксперт в области BI и анализа данных. Недавний отчёт Международного экономического форума также советует с осторожностью относиться к блокчейну. Авторы отчёта: Кэти Маллиган, ДжП Гуруджи, Шейла Уоррен и Дженнифер Чжу Скотт. Они объясняют: «Руководители компании не должны соблазняться хайпом. Вместо этого они обязаны честно ответить себе на вопрос: будет ли блокчейн здравым бизнес-решением несмотря на ясно очерченные проблемы». По мнению авторов отчёта, те, кто рассматривает для себя применение блокчейна, должны понять бизнес-контекст, в котором оно планируется. По сути необходимо задать себе один вопрос: «Нужно ли для решения конкретной бизнес-проблемы устранить посредника?». «Может быть дешевле без посредника сотрудничать с поставщиками, чем работать через расчётно-клиринговую компанию. Так, блокчейн-платформа CORDA в банковской индустрии для управления денежными переводами позволяет предоставлять услуги быстрее, безопаснее и дешевле. То же касается устранения любых других посредников: технологического брокера или страхового агента».

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

Скорость – ещё одна проблема блокчейна. «Когда требуется обрабатывать транзакции за миллисекунды, распределённый реестр пока не может справиться с этим эффективно. Поэтому рекомендуется или работать с существующей технологией, или подождать, пока блокчейн научится работать транзакциями на таких скоростях. Сейчас этой технологии может потребоваться от 2 до 10 минут на обработку данных». Блокчейн – многообещающая технология, в будущем она будет применяться для решения многих задач, включающих в себя и большие данные. Однако, как и другие многообещающие технологии, распределённый реестр требует дальнейшего исследования и оценки выгод, которые он предоставляет бизнесу.