«Золотые записи» в MDM-системе: что это и как настроить их построение

7 мая 2019
Понятие «золотая запись» в MDM-системе подробно объясняет Дженнифер Вэйланд, ведущий руководитель целого ряда решений в Informatica. Также эксперт рассказывает, как эффективно наладить процессы создания таких записей. Пока не знакомы с терминами мастер-данные и MDM-система? Читайте подробное объяснение в статье Управление данными IoT с помощью MDM-систем. Больше реальных результатов управления данными с помощью MDM-систем ищите в статье: Мастер-данные в цифрах: 12 реальных результатов внедрения MDM-системы по ссылке.

Что такое золотая запись в MDM-системе?

Понятие «золотая запись» играет важнейшее значение в мире мастер-данных. Если организовать данные в формате таких записей, это позволит постоянно иметь доступ к очищенной, подтверждённой, полной информации в важнейших для компании доменах. Домен данных в контексте MDM-систем – предметная область, тип мастер-данных. Чаще всего компании, которые работают с клиентами, начинают с управления доменом клиентских мастер-данных. «Золотая запись – это единая, точно определённая версия всех объектов данных в экосистеме организации. В таком контексте золотую запись можно также назвать «единой версией правды». Под «правдой» подразумеваются те факты, к которым пользователи данных могут обратиться, когда хотят быть уверенными, что используют правильную информацию. Золотая запись охватывает все релевантные данные во всех системах внутри организации».

Настройка построения золотых записей в MDM-системе

При применении MDM-системы основную сложность создаёт именно настройка автоматического потока операций по созданию золотых записей. Основная загвоздка – правильное сопоставление дубликатов информации об одном и том же объекте и объединение этих дубликатов. Например, имя клиента у вас могут фиксировать сразу две системы: система регистрации клиентов и система подачи жалоб. Не всегда легко понять, в какой из них информация об имени клиента будет наиболее достоверной. А может существовать ещё третья система, которая надёжно фиксирует адрес, но имя клиента в ней отсутствует. Что важно для настройки сопоставления и объединения?
  • MDM-система охватывает все источники релевантной информации в компании.
  • правильно определено, какие из этих источников более надежны для заполнения конкретного поля в таблице MDM-системы.
  • определены критерии, на которые нужно ориентироваться при выборе той системы, информация из которой попадёт в MDM-систему.

С чем сталкивается MDM-система

Пример двух дубликатов ниже:
ФамилияИмяИдентификационный номер клиентаТелефонный номерНомер домаУлицаШтат
ВэйландДженифер2012157065842123Мэйн стритМэн
ВэйландДженн2012112078675309123Мэйн стритМэн
В дубликатах часть информации совпадает, часть – нет. Это значит, что автоматически без предварительных настроек MDM-система их не объединит.

Автоматизация работы благодаря MDM-системе

Давайте представим, что мы знаем, что первая информация для первого дубликата была получена из очень надёжного источника в том, что касается имени и адреса. А на источник данных для второго дубликата можно положиться в плане точности идентификационных номеров клиентов и их номеров телефона. В качественной MDM-системе обязательно будет набор инструментов, который позволит получать информацию для создания одной золотой записи из нескольких источников. А также – возможность самостоятельно задавать критерии сопоставления и слияния дубликатов. Применимо к нашему примеру, имя и адрес MDM-система возьмёт из первого дубликата, идентификационный и телефонный номер – из второго. Результат – ниже.
ФамилияИмяИдентификационный номер клиентаТелефонный номерНомер домаУлицаШтат
ВэйландДженифер2012112078675309123Мэйн стритМэн
Процессы сопоставления и слияния становятся особенно интересными, когда нет понимания, какой из источников информации для конкретного поля более надёжный. Поэтому иногда потребуется вручную определять, данные их какой записи должны попасть в золотую. Поэтому важно, чтобы в MDM-системе были инструменты для управления потоком операций. Эти инструменты должны распределять спорные дубликаты среди data stewards (кураторы данных). Кураторы решают, основываясь на своём опыте и знаниях, информация из какого дубликата должна попасть в конкретное поле. Также в MDM-системе должен быть механизм согласования перед тем, как слияние записей полностью осуществится и будет создана золотая.

Чек-лист для создания золотых записей в MDM-системе

Для того, чтобы настроить процессы максимально эффективно, проанализируйте ситуацию в своей компании по чек-листу ниже:
  • Какую информацию вам нужно фиксировать для золотой записи?
  • В связи с этим – есть ли у вас информация, которая не очень важна для этого конкретного домена, но может быть интересной, если установить связи между записями?
  • Какие у вас есть источники данных для создания золотых записей?
  • Все ли источники данных интегрированы на текущий момент? Как быстро появляется доступ к новым или отредактированным записям?
  • Какие источники самые надёжные и для каких полей?
  • Какого порога точности достаточно вашей компании при автоматических слияниях дубликатов?
  • Какой процесс согласования нужен вам перед слиянием дубликатов? Кто должен посмотреть на дубликаты и рекомендации по их слиянию перед завершение процесса слияния и создания единой версии правды?
Ответив себе на эти вопросы, вы сможете оптимально настроить MDM-систему. Остались вопросы? Задайте их ведущим специалистам по управлению мастер-данными и MDM-системам по почте info@dis-group.ru

Рекомендуем также

Интеграция данных: нужно понять ее ценность для бизнеса

18 апреля 2019
В отличие от интернета вещей или Big Data интеграция данных сейчас не пользуется большим интересом. Однако она помогает решать конкретные бизнес-задачи. Интересным примером делится Дэвид Линтикум – старший партнёр в Cloud Technology Partners, международный эксперт и автор книг по ИТ. Также читайте статью Дэвида о важности стратегического подхода к интеграции данных.

Компании игнорируют интеграцию данных, потому что не понимают её ценность

Я работаю консультантом. Среди моих клиентов – совершенно разные комании. С большинством мы начинаем общение с того, что определяем ценность применения той или иной технологии. Несложно заметить, что особенной популярностью сейчас пользуются вычисления в облаке, включая технологии Big Data и IoT. Именно в сторону их внедрения сейчас движется большинство компаний. Нужно понимать, что без эффективной интеграции данных такое движение не принесёт плодов. А именно о ценности интеграции данных чаще всего компании забывают. А зря, потому что эту ценность очень легко понять и измерить.

Интеграция данных для точного планирования

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

Выгода от интеграции данных

Что дала моему клиенту интеграция данных? Во-первых, она позволило ему повысить качество клиентского опыта. Оптовые закупщики и дистрибуторы могут быть уверены, что все их заказы будут выполнены, товара будет достаточно. Во-вторых, у моего клиента нет необходимости хранить дополнительную партию товара на складе. Это уменьшает его расходы. При правильном использовании такой метод позволяет идеально соотносить запасы товара на складе и спрос на этот товар. Это значит, что на предприятии не будет невостребованного сырья, а рабочее время сотрудников будет оптимально спланировано. Кроме того, такое предприятие сможет предлагать своим клиентам дополнительные возможности по кастомизации отдельных партий, о чём раньше не могло быть и речи. Когда мой клиент подсчитал всю выгоду от интеграции данных, оказалось, что он экономит 5 000 000 долларов в месяц. А его годовая прибыль после внедрения инструмента для интеграции данных выросла на 5 миллиардов долларов. Предложенный мной пример не универсальный. В других компаниях ценность интеграции данных может быть другой. Но точно не вызывает сомнений, что эта ценность есть и она может быть очень значительной. Иногда, чтобы её понять, нужно только оглянуться вокруг себя.

Рекомендуем также

Зачем нужна потоковая обработка данных, как ее сочетать с пакетной, почему не обойтись без Apache Spark

12 апреля 2019
Что такое потоковая обработка данных? Это – когда решение в реальном времени обрабатывает данные, которые поступают также в реальном времени, в формате потока, генерируются непрерывно. В потоке сложно определить полный и целостный набор данных. Обычно компании не имеют возможности хранить такие данные в полном объёме, произвольный доступ к ним есть не всегда. Только знакомитесь с потоковой обработкой данных? Чтобы не запутаться в понятиях, прочитайте статью, 6 фактов об Apache Spark, которые нужно знать каждому. О значении потоковой обработки данных, необходимости сочетать её с пакетной и о том, как использовать для этого Apache Spark, размышляет Вамши Сриперумбудур. В Informatica Вашми занимается маркетингом решений Big Data и аналитики.

Задачи для потоковой обработки данных

Потоковая обработка данных применяется не только для данных, собранных через интернет вещей. Вот несколько примеров задач, для которых она будет полезна:
  • Бороться с финансовыми мошенничествами (фродом) в реальном времени;
  • Быстро сделать интересное предложение клиенту, который собирается перестать пользоваться вашими услугами или покупать у вас товары;
  • Ввести динамическое ценообразование, в некоторых случая оперативно снижать цену для клиентов;
  • Привлечь потенциального клиента в магазин, рядом с которым он находятся;
  • В реальном времени мониторить данные пациентов.
Существует множество других примеров использования потоковой обработки данных в финансовом секторе, телекоме, рознице, здравоохранении, энергетике и государственном секторе.

Управляем одновременно потоковой обработкой данных и пакетной

Зачастую потоковая обработка данных не приносит пользы без привлечения пакетной. Давайте представим, то мы определили клиента для маркетинговых коммуникаций. Он входит в магазин? Мы его идентифицируем (например, с помощью видеокамеры) и сразу в реальном времени делаем ему персонализированное предложение. Для этого мы можем использовать его поисковую историю в браузере или историю его покупок в нашем магазине. Данные с видеокамеры будут поступать в потоке, потребуют потоковой обработки данных. Пакетная используется системами, в которых хранится информации о клиенте, на основе которой мы будем делать наше предложение. Например, это может быть MDM-система. Данные в первом и втором случае будут значительно различаться. Они поступают на разных скоростях, с разной латентностью, задержкой. Эти различия нужно будет преодолеть, чтобы в реальном времени сделать клиенту персональное предложение. Данные нужно будет интегрировать.

Потоковая обработка данных с Apache Spark: разбить поток на фрагменты

Раньше потоковую обработку данных можно было осуществлять только отдельно от пакетной. Это подразумевало, что традиционные ETL-решения не могли работать с данными в потоке (обрабатывать данные и вносить их в базы). Для таких задач нужно было внедрять отдельное решение. Некоторые вендоры, которые предлагают решения, которые ориентированы только на потоковую обработку данных, даже заявляли, что пакетная не нужна совсем. Они доходили до того, что называли её видом потоковой обработки данных. Например, среди решений, которые успешно применялись для потоковой обработки данных – Apache Spark. Он разделяет информацию на устойчивые распределенные наборы данных (RDD). По сути, Apache Spark разбивает поток данных на RDD – фрагменты данных, которые распределяются по разным узлам кластера. Несколько таких фрагментов соединяются вместе в микро-пакет – DStream (Discretized Stream). Несколько DStream могут обрабатываться параллельно. Проблема с механизмом DStream как раз была в том, при его применении приходилось разделять потоковую обработку данных и пакетную, а это усложняло весь механизм работы с данными и делало её дороже.

Потоковая обработка данных с Apache Spark: превратить поток в бесконечную таблицу для SQL

Со второй версии в Apache Spark доступен Structured Streaming, который помог преодолеть недостаток DStream. Structured Streaming – это масштабируемый и отказоустойчивый фреймворк для потоковой обработки данных, в основе его Spark SQL. Structured Streaming представляет поток данных в виде бесконечной таблицы. Решение позволяет и проводить потоковую обработку данных, и интеграцию их с данными, которые обрабатываются пакетной. Другими словами, Structured Streaming для решений Big Data пытается унифицировать потоковые, итеративные и пакетные запросы с помощью абстрактного структурирования данных.

Рекомендуем также

Интеграция данных

О том, какие факторы влияют на интеграцию больших данных и как правильно выбирать для неё инструменты, рассказывает Дэвид Линтикум – старший партнёр в Cloud Technology Partners, международный эксперт и автор книг по ИТ.

5 апреля 2019

Forrester: технологии Big Data распространяются

Не знаете, что такое Big Data? Читайте об этом в другой статье блога. Аналитики исследовательской компании Forrester указывают на то, что сейчас технологии Big Data распространяются взрывными темпами. Эксперты также предсказывают, что доля технологий NoSQL и Hadoop на рынке в ближайшие 5 лет значительно вырастет. При этом рынок для первых будет увеличиваться на 25% в год, а для второго – на 32,9%. Весь рынок Big Data будет расти в три раза быстрее рынка всех технологий. Кроме того, Forrester предлагает разделить все технологии Big Data на 6 важных частей: корпоративное хранилище, NoSQL, Hadoop, интеграция больших данных, виртуализация данных и in-memory фабрика данных (in-memory – это технология, которая позволяет проводить все вычисления в оперативной памяти).

Что такое интеграция больших данных?

Интеграция больших данных – это любая технология для перемещения данных из систем Big Data, включая NoSQL-системы хранения данных и Hadoop. А также – для постоянного обновления данных по мере их изменения в этих системах хранения.

Что влияет на развитие технологий интеграции больших данных

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

Как выбрать инструмент интеграции больших данных

Принимая все перечисленные тренды во внимание, интеграция больших данных оказывается не такой простой, как могло показаться на первый взгляд. При выборе инструментов я советую сконцентрироваться в первую очередь на следующих требованиях: производительность, пригодность для решения вашей конкретной задачи и для Data Governance. Давайте рассмотрим производительность и пригодность для Data Governance. Для того, чтобы понять, какой инструмент лучше всего подойдёт для вашей задачи, напишите на почту info@dis-group.ru

Пригодность для решения задач и для Data Governance

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

Производительность

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

Рекомендуем также

Интеграция данных: нужен стратегический подход

О том, почему интеграция данных должна стать стратегическим направлением, размышляет Дэвид Линтикум – старший партнёр в Cloud Technology Partners, международный эксперт и автор книг по ИТ.

5 апреля 2019

Интеграции данных не место в тактических задачах

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

Идеальные данные – в основе ваших решений

К данным всегда нужно относиться стратегически, и к тем, которые у вас есть, и к тем, которых нет. Способность сводить данные вместе в нужное время даёт бизнесу возможность принимать решения на основе практически идеальных данных. Например, на основе данных производственное предприятие может эффективно определять, какое количество продукции ему необходимо изготовить. Какие это могут быть данные? Внутренняя информация о продажах за последние 5 лет и внешняя информация, например, закономерности в погодных условиях, которые могут повлиять на продажи. Кроме того, такое предприятие сможет отслеживать спрос на свою продукцию почти в реальном времени. А это – залог оптимального управления загрузкой склада, которое помогает избежать избытка или недостатка товара. Я привел самый простой пример. Но его можно развить до более сложного уровня, на котором он будет приносить ещё больше выгоды. Например, банк может создать автоматическую систему проведения операций с ценными бумагами. Система сможет работать на основе сотен потоков данных, которые поступают из внутренних и внешних систем. Также компании могут извлекать пользу от анализа данных с помощью систем машинного обучения или предиктивной аналитики. Всё это – часть современного data science, который без интеграции данных эффективно приносить пользу не сможет.

Интеграция данных внутри и снаружи

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

«Естественный отбор» на основе эффективности интеграции данных

Конечным результатом станет «естественный отбор» компаний. Выиграют в нём те, кто понимает стратегическую ценность интеграции данных и эффективно встроят её в общую ИТ-стратегию. Это требует времени, денег и технологий. Но это того стоит. ROI (return on investment, возврат на инвестицию) от этих усилий в среднем достигает более 200%, учитывая всю выгоду для бизнеса. От интеграции данных не уйдёт ни одна компания. Рано или поздно, случайно или нет всем придётся столкнуться с ценностью интеграции данных. Чаще всего эта ценность становится очевидной на этапе проекта по проверке концепции, когда оказывается, что интеграция данных приносит значительную выгоду. Только внедряете интеграцию данных в своей компании? Избегайте этих трёх ошибок! Также читайте об интеграции данных, собранных через интернет вещей, а также истории успеха в этой области.

Рекомендуем также

Интеграция данных: избегайте этих трех ошибок!

О том, какие ошибки компании чаще всего допускают при интеграции данных и как их избежать, рассказывает Дэвид Линтикум – старший партнёр в Cloud Technology Partners, международный эксперт и автор книг по ИТ.

22 марта 2019

Компании допускают похожие ошибки при интеграции данных

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

Первая ошибка интеграции данных: вопросы безопасности не принимаются во внимание

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

Вторая ошибка интеграции данных: проблемы метаданных заранее не определены

Интеграция данных будет намного проще, если вы будете понимать, какие данные вы интегрируете. Лучше понять данные могут помочь их метаданные. Именно поэтому так важно их контролировать. Вам понадобятся не только самые очевидные метаданные (формат данных, их владелец, целостность и другое). Нужны ещё и метаданные о соответствии требованиям регуляторов, Data Governance, безопасности и более сложных концептах, с которыми приходится сейчас иметь дело. Контроль всех метаданных повысит шансы того, что проект по интеграции данных будет успешным. По сути, благодаря метаданным вы избежите неправильной интеграции данных и сможете обеспечить необходимый уровень безопасности информации.

Третья ошибка интеграции данных: неправильный выбор технологий

Не нужно ориентироваться на моду при выборе технологии для интеграции данных. Это очень распространённая ошибка. Руководители проектов очень склонны выбирать для себя технологии на основе своего понимания того, что сейчас популярно. В итоге в компании внедряется одновременно несколько разнородных инструментов интеграции данных. В такой ситуации всё очень усложнится, затраты и риски возрастут. Кроме того, вам придётся содержать широкий штат сотрудников с разными компетенциями для работы с этими разнородными технологиями. Недостатки такого сценария очевидны. Ошибки возникают почти во всех проектах по интеграции данных. Многих из них очень сложно избежать. Но тех, которые я перечисляю, избежать можно сравнительно легко.

Рекомендуем также

Почему для успешной стратегии IoT нужна интеграция данных?

О значении интеграции данных для интернета вещей (IoT), размышляет Дэвид Линтикум – старший партнёр в Cloud Technology Partners, международный эксперт и автор книг по информационным технологиям.

5 марта 2019

У интернета вещей большое будущее

Интерес к IoT растёт по мере того, как с устройств собирается всё больше данных. Для меня поворотным пунктом стало исследование Всемирного института McKinsey. В нём указывается, что «к 2025 году влияние интернета вещей на международную экономику может достигнуть 6,2 триллиона долларов».

Компании не знают, как применять данные

Чтобы привлечь внимание, этой оценки достаточно. Но, чтобы прогноз реализовался, нужно будет ещё многое сделать. В отчёте указывается: «В то же самое время опрошенные руководители компаний признают, что им не хватает точного видения конкретных бизнес-возможностей IoT. И это при том, что у приложений, которые сейчас разрабатываются, широкие возможности, потенциальное влияние на рынки (потребительский, индустриальный сегменты и здравоохранение) может быть очень большое, а тренд использования технологии только зарождается». То, что мы можем собирать огромные объёмы данные с тысяч устройств, само по себе поразительно. Однако многим компаниям сейчас сложно понять, что с этой информацией делать. При этом у данных IoT может быть очень широкая сфера применения. Например, на их основе можно в реальном времени следить за работой оборудования, автоматически планировать ремонт и техобслуживание, искать лучшие маршруты для грузового транспорта и многое другое. Правильное применение таких данных может сэкономить миллионы долларов в год.

Интеграция данных – часть IoT-стратегии

Но, чтобы начать данные применять, нужно наладить их правильную обработку. Недостаточно выбрасывать информацию в больших объёмах во внутренние системы компании. Нужна полноценная интеграция данных. Данные нужно собрать и переместить в некую систему хранения или в приложение. Там они оцениваются в контексте бизнес-процесса или контексте использования для принятия решений. По сути, интеграция данных – это то, что по-настоящему позволяет интернету вещей приносить пользу. Но те, кто использует IoT, знают о ней очень мало. Несомненно, планирование внедрения интернета вещей нужно начинать с бизнес-задач, но двигаться стоит в сторону данных. В процессе планирования нужно установить, какие основные данные нужно собрать и как их эффективно использовать. Очень часто оказывается, что способность перемещать и обрабатывать данные – главная проблема, которую нужно решить. Интеграция данных – это основа и центр большинства стратегий интернета вещей, которые мне приходилось разрабатывать. Мой совет – сфокусироваться на интеграции данных как основной части стратегии использования интернета вещей в компании. Не важно, с каких устройств вы собрали эти данные: с носимых устройств или с сенсоров на турбинах самолётов. Качество данных также имеет большое значение для IoT. Подробнее об этом читайте в другой статье блога. Об интеграции данных в контексте технологий Big Data читайте в статье ETL-процессы VS анархия. Что выбрать? Истории успеха в области интеграции данных: ФГК, ФК «Уралсиб», «Ренессанс Кредит».

Рекомендуем также

Apache Spark для текстового поиска: найти все, что скрыто

4 февраля 2019
Никогда не сталкивались с Apache Spark? Читайте статью «6 фактов об Apache Spark, которые нужно знать каждому». О том, почему приложения для работы с Big Data не могут обойтись без текстового поиска с использованием Apache Spark, рассказывает Пракаш Дас. Пракаш работает архитектором в Informatica.

Текстовый поиск для логов

Приложения могут использовать текстовый поиск для работы с большими объёмами лог-файлов. Лог-файлы или логи – файлы с хронологическим описанием работы устройства или программы. Логи можно использовать не только, чтобы искать и устранять неполадки. Они помогут понять, как программа или устройство работает в нормальных условиях, определить параметры этой работы и другое. Например, приложение может использовать текстовый поиск для логов, которые генерируются демонами sshd. Это позволит проанализировать причины неудачных попыток входа в систему, выяснить, кто из пользователей и с какого IP пытался осуществить вход. А также – мониторить неудачные попытки почти в реальном времени с регулярными интервалами, чтобы отличить нетипичное поведение от типичного.

Текстовый поиск в озёрах

Приложения могут использовать текстовый поиск и для работы с озером данных в системе Hadoop (в HDFS). Например, аналитики выгрузили базу продуктов с браком в озеро. Они ищут в этих данных инсайты или составляют на их основе прогнозы. Им понадобилось выгрузить перечень всех дефектов? Эти данные можно найти на основе нескольких ключевых слов, таких как сообщение об ошибке или ошибке в коде. Эта информация в текстовом формате обычно хранится в реляционной базе приложения.

Чем ещё искать текстовую информацию, кроме Apache Spark

Кроме Apache Spark, для логов и данных, сгенерированных с помощью программного обеспечения, можно использовать коммерческие инструменты Splunk, Sumo Logic, и другие. В open source можно найти библиотеку для высокопроизводительного полнотекстового поиска – Lucene. Она позволяет хранить и индексировать данные только на локальной системе файлов. Для инфраструктуры распределённого текстового поиска, приложение должно использовать Elasticsearch или Solr. Оба поисковых инструмента основаны на Lucene и используют её для индексации и поиска в каждом отдельном ноде (узле кластера). После этого они агрегируют поисковые результаты в одной ноде, в той, которая получила первоначальный запрос из приложения. В ней результаты обобщаются отправляются в приложение, которое делало запрос. Для анализа логов особенно популярен такой инструмент из мира open source, как ELK (Elasticsearch и Kibana). В этой связке Kibana через браузер обеспечивает графический интерфейс для Elasticsearch. Elasticsearch переводит данные в собственную базу в формате JSON. В ней он осуществляет поиск. Через Elasticsearch можно осуществлять и аналитические запросы, которые требуют агрегирования информации.

Недостатки Elasticsearch

  • Для загрузки в свой свою базу Elasticsearch сжимает данные. В них остаётся максимум смысла при минимуме знаков. Прямой доступ к этим данным оказывается затруднённым для других видов анализа. Например, для машинного обучения. Такая схема исключает использование готовых алгоритмов машинного обучения, которые понимают данные в открытом, чётко определённом формате.
  • SQL-операции соединения (используются для сопоставления строк в реляционных базах) в Elasticsearch плохо масштабируются для больших объёмов данных. А такое масштабирование необходимо для некоторых типов аналитических запросов.
  • Elasticsearch – это не универсальная платформа для распределённой обработки данных. Набор его возможностей ограничен. Поэтому при работе с ним часто приходится использовать дополнительные инструменты, например, тот же Apache Spark. Проблема может возникнуть, если ваше приложение Big Data захочет получить единый взгляд на данные из базы Elasticsearch и данные из реляционной базы. Это потребует привлечения дополнительных инструментов.

Apache Spark: и поиск, и аналитика

Что же делать в такой ситуации? Последний озвученный недостаток сам предлагает решение проблемы. Для текстового поиска приложений Big Data нужно использовать универсальную вычислительную платформу. Apache Spark – прекрасный пример платформы такого типа в open source. Эта платформа уже достигла популярности и продолжает набирать её: с каждой новой версией Apache Spark расширяет свою функциональность. Apache Spark работает с данными напрямую в HDFS. Решение обеспечивает возможности работы с SQL с помощью Apache Spark SQL и с библиотекой алгоритмов машинного обучения анализа больших данных. Однако сам по себе Apache Spark в своём стандартном виде нельзя использовать как основу текстового поиска для приложений Big Data. Решение придётся доработать. Как? Это уже предмет другой статьи.

Рекомендуем также

Кто такой CDO? «Chief Data Officer» или «Chief Digital Officer»?

О том, кто такой CDO, чем отличается директор по данным (Chief Data Officer) от директора по цифровым технологиям (Chief Digital Officer) размышляет Джо Маккендрик, независимый аналитик и внештатный автор целого ряда зарубежных IT-изданий.

24 января 2019

CDO – это не только Chief Data Officer

Недавно я принимал участие в «Саммите CDO», который проводил клуб CDO и Capgemini Consulting. В этом клубе «CDO» – это директор по цифровым технологиям. Но я заметил, что у многих спикеров саммита в названиях должностей встречалось и слово «данные». А это намекает на то, что обязанности этих спикеров тесно связаны с обязанностями Chief Data Officer. Сама программа конференции была переполнена дискуссиями и презентациями на тему того, как анализ данных меняет положение дел во многих организациях. Не так давно я спросил нескольких экспертов, в чём разница между Chief Data Officer и Chief Digital Officer. Как правило, ожидается, что первый будет подчиняться второму. Это обусловлено тем, что данные – это всё-таки компонент более широкой инициативы – цифровизации организации. Подразумевается, что роль Chief Digital Officer включает в себя различные аспекты развития контента, продаж и маркетинга, операционной деятельности, производства, финансов и развития продукта. Но ведь и Chief Data Officer погружён во все эти области бизнеса. Пересечения в обязанностях и сходство определений обоих CDO возникают из-за того, что происходит сейчас во многих компаниях. Цифровые каналы и интеллектуальные функции товаров и услуг открывают перед бизнесом новые возможности. Это понимают все. Но также понятно и то, что достигнуть эффективного внедрения цифровых технологий нельзя без эффективного сбора, анализа и монетизации данных. Это и приводит к сближению обязанностей, требований к компетенции и возможностей для целого ряда сотрудников, а не только для двух разных CDO.

Каждый CDO смотрит со своей колокольни

Однако каждый CDO будет смотреть на многие вещи по-своему. Бэкграунд у Chief Digital Officer и Chief Data Officer обычно разный. Первый скорее всего пришёл из маркетинга или ИТ. Второй – занимался статистическим анализом и сделал карьеру как scientist. Больше вероятности, что Chief Data Officer будет больше заботиться о данных, о том, как они создаются, обрабатываются, хорошо ли они защищены. А директор по цифровым технологиям будет фокусироваться на общей картине цифровизации в компании.

Обязанности Chief Data Officer

Доктор Энн Мари Смит, главный консультант в Alabama Yankee Systems, LLC, в отчёте Cutter Consortium очерчивает следующий набор обязанностей директора по цифровым технологиям:
  • чётко сформулировать концепцию развития корпоративных данных;
  • быть «лидером масштабного управления данными, Data Governance, обеспечения качества данных и отношений с вендорами инструментов для этого во всей организации»;
  • работать с «руководством компании, владельцами данных, стюардами (кураторы данных), чтобы достичь точности данных и других целей, связанных с процессами в организации, как для внутренних, так и для внешних клиентов».
  • контролировать мониторинг активностей для обеспечения качества данных во всей организации;
  • управлять образованием сотрудников в организации «в области управления данными, оптимального использования данных, корпоративного управления мастер-данными и обеспечения качества данных, корпоративной поддержки принятия решений, возможностей инструментов различных вендоров, создания правил доступа к данным и в других областях, связанных с данными».

Обязанности директора по цифровым технологиям

Обязанности этого CDO не сильно отличаются от обязанностей Chief Data Office. По сути, они также подразумевают лидерство в том, что касается данных. Об обязанностях директора по цифровой трансформации рассказывает Сэм Рамжи, вице-президент по стратегии в компании Apigee. Вот перечень этих обязанностей:
  • чётко сформулировать цифровую стратегию предприятия; определить, как цифровая трансформация поможет организации «соответствовать вызовам мира, где главные роли будут играть мобильные сервисы, цифровые партнёрства и новые формы конкуренции», а также «построить целостный клиентский опыт во всех линиях бизнеса, который как сеть покроет всю организацию».
  • убедить сотрудников во всей компании взять на себя обязательства по цифровой стратегии. При этом придётся выступать «как посредник в корпоративной культуре, который определяет концепцию развития организации. Эта концепция должна объединять бизнес и технологии. Также Chief Data Office должен быть лидером, который вовлекает всех остальных в воплощение этой концепции».
  • экспериментировать на основе данных: развивать способность компании постоянно экспериментировать в цифровой сфере. При этом важно понимание, что неудача – это самая важная часть инновации.
  • стремиться к наглядным результатам, которые можно измерить.
  • поддерживать связь с экспертами внутри компании и внешними экспертами в индустрии. разговаривать на разных бизнес-языках: языке информационных технологий, языке маркетинга, языке стратегии и языке финансов.

Рекомендуем также

Хотите извлекать пользу из Apache Hadoop? Грузите в него подготовленные данные

О том, почему нужно готовить данные для загрузки в Apache Hadoop и как это сделать, рассказывает Мёрти Матипракасам. Мёрти – главный менеджер по маркетингу продуктов Big Data. Эксперт обладает более 15 годами опыта работы в области ИТ, включая такие компании как Mercury Interactive, Google, eBay, VMware и Oracle.

21 ноября 2018

Хранилище останется, в дополнение к нему – Apache Hadoop

Традиционная система хранилища и реляционные базы данных по-прежнему широко используются. Компании не спешат отказываться от них. Особенно когда речь идёт о формировании отчётности и применении Business Intelligence. В этой области сейчас ничто не предвещает перемен. При этом экосистема Apache Hadoop активно развивается. Вычислительные ресурсы работают всё быстрее. Хранение данных становится дешевле. Появляются новые методы поиска, обработки и анализа данных. Все эти инновации организации активно применяют, чтобы стать эффективнее, более конкурентоспособными и быстрее реагировать на нужды клиентов. Такое развитие мотивирует всё новые компании внедрять у себя Apache Hadoop.

Анализ важнее экономии

По моему мнению, у Apache Hadoop есть два основных преимущества. Он даёт возможность снизить затраты. Хранение и обработка данных в нём дешевле, чем в хранилище. Хотите знать почему? Читайте статью «Как окупаются инвестиции в Apache Hadoop». Кроме того, он позволяет обрабатывать совершенно новые источники данных. В том числе те, которые собираются с сенсоров IoT. Для этого организуются озёра данных на Apache Hadoop – вспомогательная для хранилища данных среда. Давайте честно посмотрим на вещи. Представим, стоит выбор между экономией на хранении и обработке и возможностью начать анализировать новые источники данных. Несомненно, второе звучит заманчивее. Именно вторая возможность и мотивировала появление новых ролей, таких как data scientists и новых инструментов визуализации для самообслуживания. В мире вездесущей аналитики главное преимущество Apache Hadoop в том, что он – дешёвая временная песочница для data scientists. Они выгружают в него исторические данные из различных систем-источников и проводят их исследовательский анализ. По мере сбора новые данные могут постоянно подгружаться в Apache Hadoop. Он не проверяет их схему, структуру при загрузке (Apache Hadoop – платформа «schema-on-read»). При необходимости SQL-технологии в среде Apache Hadoop, такие как Cloudera Impala, Hortonworks Stinger, Apache Drill и Pivotal HAWQ обеспечивают гибкий и повторяющиеся SQL-подобные запросы дата-сетов. А Tableu визуализирует данные и позволяет с ними самостоятельно работать.

Apache Hadoop не проверяет схему при загрузке, но не освобождает от подготовки данных

Революционные возможности Apache Hadoop безусловно выглядят воодушевляющими. Тем не менее такая среда данных нуждается в модернизации. Организации не могут полагаться на методологию многократного неконтролируемого сброса данных в озеро. Это превращает озёра в болота. Неуправляемые «болота» данных не имеют практического значения для бизнеса. Чтобы обрабатывать данные как на конвейере и обеспечивать работу аналитических систем, среда Apache Hadoop должна быть чистой, целостной и гибкой. Загрузка корпоративных данных в Apache Hadoop вместо традиционного хранилища не освобождает от подготовки данных.

Все готовят данные для загрузки в Apache Hadoop

Открою секрет: почти каждая компания, которая использует Apache Hadoop, имеет процессы, стандарты, инструменты и сотрудников для профайлинга данных, их очищения, обогащения и валидации. В мире корпоративных Big Data схемы данных и метаданные всё ещё имеют большое значение. Поделюсь несколькими примерами. На конференции Strata+HadoopWorld выступал сотрудник большой компании, которая занимается программным обеспечением. Его команда отвечает за подготовку данных. Он описал, как его организация собирает данные из различных источников с использованием стандартной схемы для всех данных, которые поступают в озеро Apache Hadoop. Когда данные собраны, его команда профилирует, очищает, обогащает и валидирует их. Это нужно, чтобы у аналитиков был доступ к данным высокого качества. Ещё один специалист описал, как внутренние команды по работе с данными должны были конвертировать данные в формат Avro перед загрузкой в озеро данных. Формат Avro – новый формат данных, который используется наряду с ORC, Parquet и JSON). Один из data engineer (инженер по данным) из крупной компании рассказал о создании специального комитета по управлению изменениями в схемах и структурах данных. Ещё один участник конференции – корпоративный архитектор одного из крупнейших операторов связи. Он объяснил, что схема данных имеет большое значение для соответствия требованиям конфиденциальности. Поэтому данные маскируются перед тем, как поступают аналитикам. Отмечу, что эти компании не просто переносят CRM и ERP в Apache Hadoop. Они собирают данные с сенсоров, которые носят пациенты, файлы логов, данные типа «событие», сведения о посещениях. И для каждого из этих типов информации подготовка данных – главная задача.

Много маленьких озёр данных впадают в озеро информации

Недавно я общался с представителем клиента Informatica – крупного финансового сервиса. Он недавно предложил внутри компании уникальную архитектуру использования Apache Hadoop. Несколько бизнесов компании построили для себя отдельные озёра в качестве песочниц на Apache Hadoop. В них могут работать небольшие команды data scientists. После этого, когда данные профилированы, очищены, обогащены и валидированы, они загружаются в более крупную структуру Apache Hadoop – корпоративное озеро информации. А в отличие от озёр данных озёра информации чистые, целостные и гибкие. Data Stewards (стюарды знаний, сотрудники, ответственные за данные на местах) озёр информации могут управлять метаданными и обеспечивать мониторинг линеджа данных из источника до песочницы, озера данных, финальной системы. Озёра информации обладают таким же высоким качеством данных, как хранилище. Но в отличие от него, они обладают экономической эффективностью и масштабируемостью Apache Hadoop. Построить корпоративные озёра информации из озёр данных можно легко и быстро. Для этого нужны инструменты, которые перенесут маппинги данных из традиционной системы в Apache Hadoop. У них должны быть визуальные интерфейсы для разработки и нативные механизмы работы в Apache Hadoop. Лучше всего возможности корпоративного озера информации были описаны на конференции Strata+Hadoop World сотрудник крупной медицинской компании. «Большие данные кажутся привлекательными, но не менее привлекательны полные данные. Сейчас у нас много данных и мало информации». Схемы, структуры данных и метаданные сейчас играют большее значение, чем когда-либо. А с помощью инструментов по интеграции, подготовки данных и озёр информации компании могут открыть для себя путь к информационным богатствам.

Рекомендуем также