Традиционные базы данных, известные как реляционные СУБД, – настоящее чудо инженерной мысли и компьютерной науки. Единый пакет программ обеспечивает безопасное хранение данных, поддерживает унифицированный интерфейс SQL для манипулирования ими и даже содержит средства их анализа в определенном контексте.
Некоторые решения до сих пор носят отпечаток прошлого, когда все выполнялось на одной машине, что мешало предприятиям расширять свои возможности анализа. Но после того как интернет-компании Google, Amazon и ряд других научились распределять нагрузку между множеством машин и отвязали базу данных от всего остального, технологии, по сути, переживают второе рождение и приносят своим пользователям более весомые ценности, нежели их оригинальные версии, особенно в части анализа.
.jpg) |
| Тео Вассилакис – основатель и генеральный директор стартапа Metanautix, специализирующегося на анализе Больших Данных. Ранее он занимал в Google должность главного инженера и директора по проектированию — руководил созданием технологии интерактивной обработки запросов к Большим Данным, которая была положена в основу сервиса Google BigQuery. |
Что же изменилось с тех пор, как IBM System R и Oracle изменили правила игры? Во-первых, революция Больших Данных привела к тому, что объемы собираемых полезных данных заметно выросли, а в компаниях увеличилось число людей, изо дня в день работающих с этими данными на постоянной основе. О бизнес-анализе и командах поддержки принятия решений речи здесь больше не идет.
Во-вторых, благодаря развитию сетевых технологий можно легко пересылать терабайты данных в нужное место в тех случаях, когда вычислительные мощности вынесены за пределы корпоративного ЦОД, и осуществлять обмен с широким спектром самого разного оборудования, начиная от настольных и карманных устройств и заканчивая облачными серверами.
В-третьих, последствия игнорирования или некорректного использования данных становятся все более устрашающими как с точки зрения сохранения конкурентоспособности и выполнения требований регулирующих органов, так и с позиций безопасности. Более подробно эту тему я осветил в своем выступлении в Стэнфорде, главную мысль которого можно передать известным афоризмом: There's no data like more data («чем больше данных, тем лучше»).
Традиционные базы данных и бизнес-модель, лежащая в их основе (определение стоимости, к примеру, зависит от объема данных), предполагали, что процедуры хранения должны быть согласованы с вычислительными процедурами. Существуют определенные требования к целостности данных, которая может обеспечиваться с помощью транзакций. Если вы списываете 10 долл. с одного счета и зачисляете их на другой, система гарантирует, что в ходе этой процедуры деньги внезапно не исчезнут и не возникнут из ничего. Реализуется это путем оперативной обработки транзакций (online transaction processing, OLTP). Когда в компании начинают понимать ценность анализа (то есть определения характера движения денежных потоков, а не просто выполнения отдельных операций списания/начисления), технология оперативной аналитической обработки (online analytical processing, OLAP) выходит на передний план, оттесняя OLTP. И если лет десять назад соотношение процессорных циклов, затраченных на операции OLTP и OLAP, составляло примерно 90/10, то теперь оно изменилось на прямо противоположное – 10/90.
Аналитические приложения нового поколения черпают данные из гораздо большего числа источников — как внутренних (электронные таблицы, системные журналы, приложения SaaS Salesforce/Workday), так и внешних (Интернет, социальные медиа, сводки о погоде и т. д.). По мере расширения возможностей хранения и внедрения наряду с традиционными реляционными СУБД технологий NoSQL и высокопроизводительных файловых систем, таких как AWS/S3 (в облаке) или Hadoop/HDFS (в собственном ЦОД), важно уже не где хранятся данные, а что вы с ними делаете. Вам почти неизбежно придется столкнуться с необходимостью переносить данные с одной платформы на другую с целью сократить затраты, повысить производительность, обеспечить соответствие нормативным требованиям и по другим причинам. Ценность данных по отношению к контейнеру, в котором они хранятся, растет, а ценность проявляемой организацией гибкости растет относительно управленческих затрат, вот почему организации инвестируют (иногда даже без каких-либо конкретных целей) в дорогостоящие команды ученых по данным.
SQL — старый язык (хотя и продолжающий развиваться), который находит применение в организациях как современных, так и традиционных. Но зачастую люди сегодня не понимают, что язык этот не обязательно привязывать к контейнеру данных. По большей части его используют для взаимодействия с СУБД, но на самом деле на нем можно «разговаривать» и с данными. В этом и заключается преимущество отделения бизнес-логики и анализа от технической реализации средств хранения. В системах нового поколения разрыв между бизнес-операциями и все более сложными уровнями базовой реализации хранения будет и дальше углубляться. Стратегия встраивания языков общего назначения в системы управления данными развивалась на протяжении многих лет. В их числе была интеграция. Net в Microsoft SQL Server, встраивание Javascript в MongoDB и многое другое.
В 60-х годах Эдсгер Дейкстра написал статью «О вреде оператора goto», которая стала толчком к появлению множества ей подобных — «О вреде …». Уже само ее название бросало вызов ортодоксальным взглядам на эту тему. Вот и я свои мысли стараюсь излагать в том же ключе.
