Прорыв в системах обработки данных
Никитин М.В.
(по материалам citcity.ru, С. Кузнецов Беседа Марго Зельцер с Майклом Стоунбрейкером)
Сергей Кузнецов в очередной раз порадовал замечательной переводной статьей Майкла Стоунбрейкера о новых веяниях в индустрии информационных технолоогий. Стоунбрейкер – уникальный человек в сообществе баз данных. Он не просто высококлассный профессионал в своей области, он еще и талантливый предприниматель, что в научной среде встречается достаточно редко. Как известно, способность к предпринимательской деятельности основывается на грамотном построении прогнозов. Раньше других заметить перспективное направление и предугадать его коммерческий успех – этим навыком Стоунбрейкер владеет очень хорошо, о чем свидетельствует успешность всех его научных и коммерческих начинаний.
Исходя из этого следует с пристальным вниманием отнестись к его высказываниям по поводу дальнейших перспектив развития индустрии хранения и обработки данных, некоторые из которых и приведены в его беседе с Марго Зельцер.
Являясь одним из непосредственных создателей технологии реляционных баз данных, которые благодаря продуктам компаний Oracle, IBM, Microsoft (в беседе Майкл называет их «слонами») являются абсолютными монополистами на рынке промышленных СУБД, в настоящее время Стоунбрейкер считает ее явно устаревшей. За 30 лет, прошедших с момента появления первых реляционных баз данных в мире произошли огромные изменения, образовались новые рынки с новыми задачами, о которых в те времена не имели ни малейшего представления и для решения которых традиционные СУБД однозначно не годятся. В частности, задачи подобного рода возникают при создании хранилищ данных и систем потоковой обработки данных. Главной особенностью подобных систем является вычисление «скрытой изюминки» в огромных потоках неоднородных данных.
Как говорит Стоунбрейкер: «Данные поступают со скоростью воды в пожарном шланге. Объемы данных превосходят все пределы. Это та же бизнес-аналитика, с которой мы встречаемся в базах данных. Однако нужно производить вычисления во временном окне в небольшое число миллисекунд. И на этом рынке специализированная архитектура может победить реляционных «слонов».
Еще одним рынком с подобными задачами являются системы для работы с текстом и научной информацией. Как известно, крупнейшие поисковые системы, такие как Google и Yahoo не используют обычные базы данных для быстрого поиска в текстовых массивах (а там объемы данных поистине огромны), «реляционные базы для них слишком медленны».
Так что же за специализированная технология, которая, по мнению Стоунбрейкера, может пошатнуть устоявшуюся годами монополию «слонов» реляционных СУБД?
Основными требованиями к подобной технологии является скорость работы и возможность быстро вносить изменения в механизмы обработки данных. Почему на наиболее критических участках современного бизнеса (логистика, операции с ценными бумагами) предпочтение отдается «доморощенным» системам, а традиционные системы не подходят? Есть два очень простых ответа:
«Первый ответ состоит в том, что объемы данных превосходят все пределы, и с ними вот-вот перестанут справляться существующие унаследованные инфраструктуры».
«Вторая причина кроется в том, что в электронной торговле ценными бумагами «скрытая изюминка» срабатывает только в течение некоторого времени – а потом она перестает работать, и нужно искать ее заново. Народ с Уолл-стрит страдает от неустойчивой инфраструктуры и невозможности быстрого изменения ее жестко закодированных интерфейсов в соответствии с потребностями бизнеса».
Стоунбрейкер считает, что одной из основных проблем в доступе к базам данных является отсутствие простых и доступных интерфейсов: «Сейчас мы общаемся с базами данных, используя ODBC и JDBC, встроенные в языки программирования. Это наихудшие интерфейсы на нашей планете. Я имею в виду, что они настолько ужасны, что их не пожелаешь даже злейшему врагу.
C++ и C# – это очень большие и трудные языки, содержащие массу разных языковых средств. Я большой поклонник небольших языков, таких как PHP и Python».
При этом сам он не собирается заниматься языками и инструментальными средствами, предпочитая сконцентрироваться над созданием систем обработки данных в реальном времени, хотя и понимает важность создания более простых и доступных средств работы с базами данных, отличных от традиционного SQL.
Конечно, нужны более простые интерфейсы, при помощи которых пользователи данных могли бы самостоятельно настраивать необходимые им операции по извлечению данных. Полагаю, именно на решении подобных задач следовало бы сконцентрировать основное внимание разработчиков, но, к сожалению, еще слишком мало людей в сообществе СУБД понимают тот факт, что только сам пользователь досконально знающий свою предметную область сможет создать ее эффективную модель с помощью баз данных.
Итак, объемы данных нарастают лавинообразно, и при этом для поиска «скрытой изюминки» постоянно приходится менять технологию ее вычисления. Очевидно, что статическая реляционная структура к подобным динамическим операциям не приспособлена. При этом дальнейшее развитие мировой экономики с повсеместной интеграцией всевозможных потоков данных приводит к тому, что все больше сфер деятельности предъявляют аналогичные требования к информационным системам.
При таких объемах критическим становится время реакции. А реально сократить его возможно только путем распараллеливания потоков. И проблема здесь не столько в оборудовании. Сейчас процессоры состоят уже из нескольких ядер и являются достаточно быстрыми. Проблема в программном обеспечении, которое обрабатывает потоки данных. Как бы не росла скорость вычислений, проблема не будет решена, пока используется алгоритмическое программирование, где команды не могут исполняться иначе как последовательно.
И ведь существуют другие способы решения проблемы. Например, наш мозг способен обрабатывать огромные объемы данных, поступающие одновременно из различных источников именно за счет параллельности. Для этого используются рецепторы, настроенные на определенные признаки. Нам не нужен весь поток, он огромен. Нам нужно найти только то, что нужно. И для этого есть две операции: сравнить и переключить. При появлении во входном потоке нужного признака срабатывает переключатель, генерируется сигнал, который обрабатывается другим рецептором и так далее по цепочке. Благодаря тому, что рецепторов огромное количество, выстраиваются всевозможные комбинации прохождения сигнала, которые и позволяют нам ощущать объективную реальность во всем ее многообразии
Точно так же, как работают наши глаза и уши, должны работать информационные системы. Возможность отследить в потоке данных необходимый признак и настроить соответствующую реакцию. И компьютер в данном случае играет роль дополнительного рецептора, с помощью которого человек может обмениваться сигналами с внешним миром.
Вывод: распараллеливать потоки должен сам пользователь. Только он может решить, что для него является наиболее важным в тот или иной период времени. Для этого он должен иметь возможность самостоятельно настраивать чувствительность рецепторов и определять переключатели сигналов. Только вот как это сделать? Возможно, разработчикам информационных систем стоит позаимствовать ряд решений у природы, которая великолепно справляется с задачей объединения разнородных систем в единое целое, вырабатывая универсальные интерфейсы и языки общения между ее составными частями.
Ведь проблема состоит в том, что существующие системы все еще слишком сложны для того, чтобы с ними напрямую мог взаимодействовать рядовой пользователь – приходится использовать посредников – разработчиков, программистов. И для того, чтобы состыковать предметную область с ИТ затрачивается большое число усилий и времени. А как отмечалось выше, время становится критическим параметром в реальных «живых» системах. Когда сценарии принятия решений меняются «на лету» и нет времени на привлечение посредников для внесения изменений в ту или иную операцию. Пока такую проблему удается решить только созданием «доморощенных» систем, когда их разработчики начинают вплотную работать в той предметной области, для которой необходимо создать информационную систему, становятся частью команды, ответственной за принятие решений. Понятно, что это не самый эффективный путь решения проблемы, но пока не будет создано простых и доступных интерфейсов, позволяющих любому пользователю объединять свои знания и опыт с возможностями компьютерных технологий, она вряд ли когда-то будет решена.
Самое интересное, что многие это понимают, и Стоунбрейкер в том числе. Семантика существующих языков программирования «ужасна», а возможность научить компьютер понимать естественные языки очень туманна и неопределенна, несмотря на все усилия, предпринимаемые в этом направлении разработчиками «искусственного интеллекта».
Полагаю, что основная причина в том, что все используемые языки программирования (SQL в том числе) в реальный мир пришли из идеального мира математики. Математический мир объектов, отношений и уравнений использует упрощенные модели реальности, где большинство данных известны, выполняются строгие условия и равенства. В реальных моделях подобного никогда не бывает. Об окружающей нас среде мы всегда знаем значительно меньше, чем не знаем, и точно описать мир никто не в состоянии. Поэтому в реальной модели мира нет ни объектов, ни точных равенств и все решения приближенные, хотя математики и бьются уже в течение нескольких веков над выведением «точной формулы» мироздания.
И что в итоге получается: вся индустрия информационных технологий, начиная с микропроцессоров и заканчивая программными продуктами, основана на формальных математических моделях. При этом достаточно сложно нематематическое представление о мире втиснуть в «прокрустово ложе» мира объектов и уравнений, а именно так пытаются описывать реальность все существующие математические языки, в том числе и языки программирования.
Современный мир все больше напоминает единый большой организм, в котором интегрировано огромное число «клеток», объединенных в различные системы «органов». И роль нервной системы в нем выполняет единая информационная сеть планеты, стремительно развивающаяся с появлением Интернета. В этом ключе появление новых, неалгоритмических языков общения между людьми, расширяющих возможности по обмену сигналами с помощью компьютерной техники, кажется неизбежным, хотят этого или не хотят «слоны» ИТ-индустрии.
Что же все-таки станет главной «прорывной» технологией? Стоунбрейкер занимается созданием OLTP-процессоров, другие исследователи разрабатывают новые OLAP-системы, и возможно что-то из этого действительно будет прорывом в системах обработки данных. Тем не менее, без разработки новых «естественных» интерфейсов и языков программирования, доступных каждому пользователю всемирной сети, настоящего прорыва не случится, без этого сеть не сможет замкнуть в единое целое все «клетки» создающегося глобального организма.
Прорыв в системах обработки данных
Re: Прорыв в системах обработки данных
Использование динамических информационных технологий в транспортной логистике
(статья на конференции ТРАНСТЕК 2003)
Автор: Кречмер А.Э.
Проблема, с которой на сегодня сталкивается система управления транспортными, грузовыми, складскими и аналогичными потоками, заключается прежде всего в значительное увеличении количества людей участвующих в сборе, обработке и передачи данных, то есть занимающихся информационными технологиями. Огромная армия менеджеров, аналитиков и других специалистов организуются лишь для того, что бы принять решение. Но, так как интересы у каждого в этой группе свои, часто несовпадающие между собой, то возникают противоречия, выход из которого на первый взгляд, могло бы быть выработка единого языка, типа Esperanto или единого документа для всей системы, но исторический опыт человечества говорит, что это не реально. А вот выработать единые правила, то есть организовать соответствующую информационную технологию для обмена данными между участниками управления транспортным потоком, это вполне приемлемо. Весь вопрос только в инструменте, который бы позволил работать разным специалистам одновременно, с учетом собственных интересов.
Как и любая технология, информационная требует соответствия между способами, методами, методологией ее использования и объектом управления. Начиная с элементарных учетных систем и заканчивая сложными многофакторными системами статистической обработки, проблемы возникали практически только на уровне мощности «железа», то есть мощности процессора, объема памяти и т.д. Сами алгоритмы работы с данными особых изменений не претерпели. И пока количество людей участвующих в управлении информационными технологиями не превышал определенного уровня, своевременность ответной реакции информационных систем удовлетворяла лиц принимающих решение (ЛПР). Но, пришла логистика, которая потребовала от таких систем соответствия изменения и измерения, то есть события, которые происходят, допустим, в транспортном потоке должны быть отслежены, проанализированы, оценены и одобрены ЛПР в приемлемое время. И оказалось, что соответствующих алгоритмов отвечающих этим требованиям, практически нет. То есть, кое-что есть, но стоимость используемых ресурсов необходимых для решения таких задач, не удовлетворял возможности управленцев. Даже появление систем с красивым названием OLAP, к сожалению, положения в управлении информационными потоками существенно не изменил. Ошибка, которую делают проектировщики таких систем, заключается в том, что они пытаются превратить «живую» динамичную систему в жестко фиксированную систему объектов и их отношений, часто не понимая, что один и тот же объект для различных управленцев (отправитель груза, таможенник, экспедитор, заказчик) транспортного потока будет иметь разные свойства и характеристики. А это значит, что информационная система отражающая ситуации в транспортном потоке должна быть прежде всего динамичной и предоставлять данные и их обработку в соответствии виденья управленцев, отсюда, требования к информационным технологиям логистика должны быть следующими:
- анализировать ситуацию и поведение взаимодействующих элементов системы в реальном масштабе времени;
- в динамическом режиме обеспечивать мониторинг и диагностику управленческих процессов;
- моделировать реальные действия и события;
- прогнозировать и предупреждать критические ситуации.
При этом, хочется отметить, что наиболее существенным для ЛПР являются два последних требования. Прогноз – это значит предвидеть будущий результат, а что бы предвидеть, необходимо построить модель.
И так, для решения проблемы управления системами различных потоков необходимо учесть интересы всех участников в их виденье на объекты в потоке с оценкой конечного результата. Исходя из этого, при организации информационной технологии нового типа прежде всего откажемся от идеи, что все можно описать и проклассифицировать. Кроме того, определим, что все участники управления потоком общаются только через документы (устный, электронный, бумажный). Документом в данном случае является формализованным средством общения между логистиками и отношением их к объекту управления. При этом количество документов может быть любое, каждый из участников может изменять уже существующие или добавлять новые документы. «Выживаемость» этих документов будет зависеть от всех участников, если документ будут ими востребован он «выживет», в противном случае – нет. Согласованность между документами будет происходить через индивидуальные или групповые определения, то есть будут формироваться динамически словари для каждого из участника. И самое главное, если проследить за работой логистика, то можно обнаружить некий конечный набор действий, совершаемых ими над данными. Этот набор может выразить в общую процедуру: Ситуация – Анализ – Модель (Сценарий) – Прогноз – Ожидание изменения ситуации. Именно разнообразие этих процедур и определяет квалификации логистика и его опыт. Поэтому новая информационная технология должна иметь возможность накапливать эти процедуры и автоматически, и своевременно предлагать логистику наиболее подходящую для конкретной ситуации, то есть обладать некоторым интеллектом. Ниже представлена приблизительная схема работы такой системы.
Взаимодействие отдельных служб, обеспечивающих управление транспортным потоком, определяется различным набором документов, которые несут в себе различные данные о состоянии этого транспортного потока. Поэтому мы можем представить любые данные, которыми пользуется логистик, в виде потока документов. Все документы принадлежат к набору доступных хранилищ данных (множественные БД как на бумажных так и на электронных носителях). Из этого потока с определенным периодом или по запросу идентифицируются необходимые документы на предмет появления в них изменений, и по шаблонам подготовленными логистиками создаются локальные, групповые и индивидуальные БД и словари, тем самым формируется представление о ситуациях (анализ), которые происходят в системе транспортного потока. Следующий этап работы логистика заключается в построении логистических цепочек из полученных данных и создании модели конкретной ситуации и ее оценка. Тем самым дается прогноз развития конкретной ситуации. Если прогноз удачен, то последовательность событий и действий записывается в базу процедур (БДП). Чем больше сформированных решений как процедуры, тем большим знанием обладает система логистик + технология, а значит вероятность принятия правильного решения у ЛПР возрастает.
Словарь используемых терминов:
Взаимодействие – связь между системами и/или объектами, повлекшая за собой изменения в этих объектах
Данные – набор дифференцирующих признаков и их значений об объекте , или внешней среде
Знания - вербализированные, субъективно выделенные отношения между явлениями, предметами и процессами
Изменение – субъективная оценка приращение или убывания свойств системы
Измерение – количественная оценка изменения
Интеллект – свойство системы предвидеть будущий результат (моделировать последствия)
Информация – свойство системы отражать свои структурные изменения
Модель – отражение одной системы в другой
Объект – выделенный субъектом элемент или система
Отражение - структурное изменение в системе после взаимодействия
Процедура – субъективно выделенная последовательность взаимодействий между предметами, явлениями и процессами
Связь - субъективно выделенные отношения между предметами, явлениями и процессами
Связь внутренняя - субъективно выделенные отношения между элементами системы (или суть формирующая структуру системы)
Система – субъективно выделенные предметы, явления и процессы, которые по мнению субъекта объединены для достижения одной цели
Структура – вся совокупность внутренних связей в системе
Субъект – моделирующая система
Элемент – неделимая часть системы
(статья на конференции ТРАНСТЕК 2003)
Автор: Кречмер А.Э.
Проблема, с которой на сегодня сталкивается система управления транспортными, грузовыми, складскими и аналогичными потоками, заключается прежде всего в значительное увеличении количества людей участвующих в сборе, обработке и передачи данных, то есть занимающихся информационными технологиями. Огромная армия менеджеров, аналитиков и других специалистов организуются лишь для того, что бы принять решение. Но, так как интересы у каждого в этой группе свои, часто несовпадающие между собой, то возникают противоречия, выход из которого на первый взгляд, могло бы быть выработка единого языка, типа Esperanto или единого документа для всей системы, но исторический опыт человечества говорит, что это не реально. А вот выработать единые правила, то есть организовать соответствующую информационную технологию для обмена данными между участниками управления транспортным потоком, это вполне приемлемо. Весь вопрос только в инструменте, который бы позволил работать разным специалистам одновременно, с учетом собственных интересов.
Как и любая технология, информационная требует соответствия между способами, методами, методологией ее использования и объектом управления. Начиная с элементарных учетных систем и заканчивая сложными многофакторными системами статистической обработки, проблемы возникали практически только на уровне мощности «железа», то есть мощности процессора, объема памяти и т.д. Сами алгоритмы работы с данными особых изменений не претерпели. И пока количество людей участвующих в управлении информационными технологиями не превышал определенного уровня, своевременность ответной реакции информационных систем удовлетворяла лиц принимающих решение (ЛПР). Но, пришла логистика, которая потребовала от таких систем соответствия изменения и измерения, то есть события, которые происходят, допустим, в транспортном потоке должны быть отслежены, проанализированы, оценены и одобрены ЛПР в приемлемое время. И оказалось, что соответствующих алгоритмов отвечающих этим требованиям, практически нет. То есть, кое-что есть, но стоимость используемых ресурсов необходимых для решения таких задач, не удовлетворял возможности управленцев. Даже появление систем с красивым названием OLAP, к сожалению, положения в управлении информационными потоками существенно не изменил. Ошибка, которую делают проектировщики таких систем, заключается в том, что они пытаются превратить «живую» динамичную систему в жестко фиксированную систему объектов и их отношений, часто не понимая, что один и тот же объект для различных управленцев (отправитель груза, таможенник, экспедитор, заказчик) транспортного потока будет иметь разные свойства и характеристики. А это значит, что информационная система отражающая ситуации в транспортном потоке должна быть прежде всего динамичной и предоставлять данные и их обработку в соответствии виденья управленцев, отсюда, требования к информационным технологиям логистика должны быть следующими:
- анализировать ситуацию и поведение взаимодействующих элементов системы в реальном масштабе времени;
- в динамическом режиме обеспечивать мониторинг и диагностику управленческих процессов;
- моделировать реальные действия и события;
- прогнозировать и предупреждать критические ситуации.
При этом, хочется отметить, что наиболее существенным для ЛПР являются два последних требования. Прогноз – это значит предвидеть будущий результат, а что бы предвидеть, необходимо построить модель.
И так, для решения проблемы управления системами различных потоков необходимо учесть интересы всех участников в их виденье на объекты в потоке с оценкой конечного результата. Исходя из этого, при организации информационной технологии нового типа прежде всего откажемся от идеи, что все можно описать и проклассифицировать. Кроме того, определим, что все участники управления потоком общаются только через документы (устный, электронный, бумажный). Документом в данном случае является формализованным средством общения между логистиками и отношением их к объекту управления. При этом количество документов может быть любое, каждый из участников может изменять уже существующие или добавлять новые документы. «Выживаемость» этих документов будет зависеть от всех участников, если документ будут ими востребован он «выживет», в противном случае – нет. Согласованность между документами будет происходить через индивидуальные или групповые определения, то есть будут формироваться динамически словари для каждого из участника. И самое главное, если проследить за работой логистика, то можно обнаружить некий конечный набор действий, совершаемых ими над данными. Этот набор может выразить в общую процедуру: Ситуация – Анализ – Модель (Сценарий) – Прогноз – Ожидание изменения ситуации. Именно разнообразие этих процедур и определяет квалификации логистика и его опыт. Поэтому новая информационная технология должна иметь возможность накапливать эти процедуры и автоматически, и своевременно предлагать логистику наиболее подходящую для конкретной ситуации, то есть обладать некоторым интеллектом. Ниже представлена приблизительная схема работы такой системы.
Взаимодействие отдельных служб, обеспечивающих управление транспортным потоком, определяется различным набором документов, которые несут в себе различные данные о состоянии этого транспортного потока. Поэтому мы можем представить любые данные, которыми пользуется логистик, в виде потока документов. Все документы принадлежат к набору доступных хранилищ данных (множественные БД как на бумажных так и на электронных носителях). Из этого потока с определенным периодом или по запросу идентифицируются необходимые документы на предмет появления в них изменений, и по шаблонам подготовленными логистиками создаются локальные, групповые и индивидуальные БД и словари, тем самым формируется представление о ситуациях (анализ), которые происходят в системе транспортного потока. Следующий этап работы логистика заключается в построении логистических цепочек из полученных данных и создании модели конкретной ситуации и ее оценка. Тем самым дается прогноз развития конкретной ситуации. Если прогноз удачен, то последовательность событий и действий записывается в базу процедур (БДП). Чем больше сформированных решений как процедуры, тем большим знанием обладает система логистик + технология, а значит вероятность принятия правильного решения у ЛПР возрастает.
Словарь используемых терминов:
Взаимодействие – связь между системами и/или объектами, повлекшая за собой изменения в этих объектах
Данные – набор дифференцирующих признаков и их значений об объекте , или внешней среде
Знания - вербализированные, субъективно выделенные отношения между явлениями, предметами и процессами
Изменение – субъективная оценка приращение или убывания свойств системы
Измерение – количественная оценка изменения
Интеллект – свойство системы предвидеть будущий результат (моделировать последствия)
Информация – свойство системы отражать свои структурные изменения
Модель – отражение одной системы в другой
Объект – выделенный субъектом элемент или система
Отражение - структурное изменение в системе после взаимодействия
Процедура – субъективно выделенная последовательность взаимодействий между предметами, явлениями и процессами
Связь - субъективно выделенные отношения между предметами, явлениями и процессами
Связь внутренняя - субъективно выделенные отношения между элементами системы (или суть формирующая структуру системы)
Система – субъективно выделенные предметы, явления и процессы, которые по мнению субъекта объединены для достижения одной цели
Структура – вся совокупность внутренних связей в системе
Субъект – моделирующая система
Элемент – неделимая часть системы