Уменьшение шума — это следствие того, что мы не можем правильно проанализировать данные, т.е. наши гипотезы расходятся с полученными результатами, следственно, мы допускам, что часть исходных данных неверна. Вполне возможно, что так оно и есть, но в то же время мы можем проанализировать полный набор данных и вычислить, что больший процент данных из этого набора дает одни результаты, а остальная часть — другой результат. И оба они имеют право на существование.
Если на конкретных примерах: стоит ли выкидывать поисковые запросы с орфографическими ошибками при попытке анализа тех или иных поисковых запросов(например, на Google)? Или, стоит ли при опросе об ОС Windows принимать мнение домохозяек, или опрашивать только мнение ИТ-специалистов, или даже только системных администраторов Windows?
Не увидел противоречия — почему полный набор данных вместо ограниченный выборки должен препятствовать работе алгоритмов машинного обучения? Для тех же задач классификации и кластеризации довольно сложно подобрать репрезентативную ограниченную выборку данных…
Не думаю, что цель государства — это закошмарить использование новых технологий. :) Скорее выступить в роли арбитра, устанавливающего общие правила для покупателей и производителей в этой сфере. Хотя, риски есть, это несомненно.
Чиновники сами говорят о необходимости перехода на облако. Понятно, что на облако пойдет только десятая часть из выделенных средств, всё остальное осядет в известных местах. Однако, какое-то облако все-таки будет и оно будет использоваться для централизации и размещения всех государственных информационных систем на нем. Можно надеяться, что в процессе постройки такого облако они наступят на все грабли, осознают все спорные моменты и как-то обозначат свою позицию по этим моментам.
Кроме самой зарплаты троим айтишникам, надо еще учитывать дополнительные расходы, связанные с ними — ЕСН(+30%), страховка, рабочее место. Так что выйдут они не в 5000 евро на троих.
Я не спорю, что сейчас облака в некоторых случаях выходят значительно дороже, но я не вижу причин, почему бы им не подешеветь в будущем — вычислительные мощности растут, память дешевеет. А когда облачные сервисы достигнут достаточной централизации и массовости, то они смогут значительно снизить цену, как это когда-то случилось с электричеством. И опять же, я говорю про долгосрочную перспективу — уже понятно в какую сторону поворачивает тенденция, и я не вижу никаких оснований, почему она должна повернуть в другую сторону.
Мне ежемесячно приходит счет за Google Music — очень удобно, я оценил все преимущества этого сервиса. А с другой стороны — зачем мне это нужно? Можно же найти всю эту музыку в Интернете, скачать на флэшку и слушать в свое удовольствие. Но Google Music оказался хорошей альтернативой, которая существенно сокращает длительность поиска и нет необходимости что-то скачивать.
Также и с облачными сервисами — тот же salesforce, ну зачем он нужен? Не проще ли и надежнее купить Oracle Siebel или Microsoft Dynamics, всю программную обвязку к ним в виде СУБД и серверов приложений, железо под все этой(не забудем про сеть) и помещение под железо, нанять аналитиков, админов и разработчиков, который этот CRM допилят, заплатить за поддержку вендору и спокойно наслаждаться? Ведь владельцам малого и среднего бизнеса этот путь кажется кратчайшим и логически верным…
Я понимаю, о какой коммерческой тайне идет речь — решением этого вопроса будет шифрование. В этом случае, жесткий диск забрать могут, но вот данные с него прочитать — нет. Сейчас все современные СУБД могут шифровать данные, файловые системы тоже. Я не вижу никаких технических сложностей, а если под это подвести законодательную базу(что, кстати, и делается во многих странах мира сейчас), то вообще никаких преград не остается.
Спасибо. Очень интересная статья. Если ЦРУ спешит на рынок Больших Данных, то это говорит о том, что они видят в нем громадные перспективы. Удивило, что они говорят о Больших Данных в контексте предоставления услуг — неужели ЦРУ поставили на хозрасчет и самоокупаемость? Вообще последние фразы о том, что правительство и политики не успевают за быстро меняющимся миром расставили всё по своим местам — это попытка использовать ЦРУ для переосмысления ситуации, которая сейчас происходит в мире. В любом случае, вмешательство ЦРУ в Big Data даст огромный толчок всей этой области, что, конечно же, не может не радовать.
Не совсем понял Ваш комментарий. Я думаю, что объяснения должны быть простыми и понятными, в доступной форме, чтобы это могли понять даже люди, совсем не разбирающиеся в предмете. Можно накидать графиков, диаграмм, умных английских слов, таблиц и всего такого, но все это будет интересно только гикам или людям, глубоко погруженным в этой области. В описании тех или иных механизмов и технологий примером для меня служит творчество Стивена Хокинга.
Хмм… У меня была как раз цель рассказать как можно проще про основные аспекты технологии CDC, не прибегая к маркетингу. Хотелось, конечно, чтобы больше людей узнало об этом, но не с помощью откровенного маркетинга. А что вам показалось в этой статье маркетинговым мусором?
Само незнание, что такое CDC, причем незнание среди специалистов в этой области, меня удивляет. В принципе, я попытался в популярной форме объяснить базовые принципы.
CDC — это технология, позволяющая отслеживать изменения данных в БД. Конкретная реализация этой технологии зависит от решения, в котором она применяется. Это чисто софтовое решение, железных решений здесь нет и навряд ли появится в ближайшем будущем — нет необходимости в том, чтобы реализовать этот функционал в железе.
Из этой статьи понять почему же Big Data так модно просто невозможно. Мешанина терминов, подходов и суждений — ни одна тема не раскрыта полностью. Я бы сконцентрировался бы на чем-то одном и уже потом говорил, как это относится к Big Data и применяется к этой сфере.
Вообще непонятно, как связано то, что написано в статье и модность Big Data. По моему мнению, причина популярности Big Data в том, что компании надеются получить с помощью нее больше денег — продавцы решений Big Data — продавая эти решения, те, кто покупает эти решения — используя данные для того, чтобы повысить продажи или решить насущные проблемы.
«А чем объективно плоха бизнес-логика на стороне БД?»
Попробую ответить, чем, по моему мнению, плоха бизнес-логика, реализованная на стороне БД. Во-первых, увеличивается нагрузка на сервер БД. СУБД занимается теперь не только своими непосредственными обязанностями, но вообще чем угодно. Непонятно, кто сколько ресурсов потребляет, как он это делает, какая часть чем занимается. Как это паралеллить? Как это масштабировать в дальнейшем? Вертикально? Горизонтально?
Во вторых, строго говоря, в функции СУБД не входит выполнение каких-либо команд, не относящихся к извлечению данных. А тут все наоборот — в одной СУБД наворочено черте что — AQ, MGW, Streams, работа с файлами, работа с почтой, Scheduler, пакеты со сложной логикой. Через некоторое время, все это становится настолько запутанным и сложным, что вопрос — как это поддерживать дальше становится критическим. Где вы получаете данные, а где просто отправляете почту? Необходимо больше квалифицированных специалистов, для поддержки всего этого нужна большая команда — нужны PL/SQL разработчики(желательно сертифицированные), архитекторы, куча DBA, тестеры на ту часть, на эту часть. Все это начинает работать плохо, понятие thread незнакомо oracle. Пользуетесь DBMS_JOB? В 11g это теперь включено в DBMS_SCHEDULER — надо переделывать. При взгляде на счета за поддержку такой системы владельцы бизнеса хватаются за сердце — Ларри Эллисон покупает еще остров. Хотите переехать на другую СУБД — даже не мечтайте.
Хотелось бы классифицировать тему про бизнес-логику в СУБД по ЯП(скорей даже по фреймворкам):
1) PL/SQL. Oracle не только реализовал свой полноценный язык программирования(хотя официально это считается процедурным расширением SQL — странный подход, по моему мнению), но и построил вокруг него свой блэкджек с аттракционами. Oracle Forms, Oracle Reports, Oracle Applications — если вы используете все это, то реализация логики на стороне БД вас неизбежно настигнет — тут никуда не денешься. Если проект достаточно масштабный, то через некоторое время понимать, что там происходит, будут только старожилы.
2) .NET, Java. Тут несколько сложнее, вспоминаем про очистку мусора — использовать большие массивы памяти для хранения данных довольно накладно в плане операционных расходов на очистку мусора. Если использовать их достаточно интенсивно и в больших объемах, то сталкиваемся с STW. Поэтому малодушные переносят часть логики в СУБД, думая, что избавились от головной боли, а заодно и повысили быстродействие — Java-то летает. Через некоторое время возникают проблемы — как масштабировать непонятно, слово «рефакторинг» вызывает истерический смех, PL/SQL вызывает лютую ненависть. Другие нанимают высококвалифицированного DBA, который бьет по рукам всех, кто вызывает неэффективные запросы к БД, используется несколько серверов или экземпляров приложений, изучают ORM(потому как изобретать велосипед незачем) — тут будущее выглядит более радужно — с масштабированием понятно, растем вширь, не забывая про балансировку. Отважные кидаются на распределенные кэши, coherence, off heap и т.п. — что тоже выход.
3) Python, Perl, PHP — это ж скриптовые языки!!! Причем тут бизнес-логика?
По остальным ЯП комментарии приветствуются.
vendor lock-in — в принципе, не так и страшно, если вендор хороший.
Реализация бизнес-логики на уровне СУБД страшный моветон сегодня именно потому, что к сегодняшнему моменту мы имеем кучу систем, которые непонятно, как дальше поддерживать и как дальше масштабировать. Да, они выполняют свои функции в каких-то пределах, а что делать дальше? Не проще ли проектировать такие системы, которые можно поддерживать за разумные деньги и время? Или важнее выйти на рынок раньше всех, а потом думать, как же допилировать её дальше?
На самом деле, у меня самые теплые чувства к FoxPro. На первой серьезной работе использовалась связка VFP + SQL Server. Я тогда буквально влюбился в VFP. До последнего надеялся, что Microsoft одумается и продолжит развитие FoxPro. Но, к сожалению, они закончили поддержку на VFP 9. Жаль…
Exadata хороша для DWH, скажем так, относительно небольших размеров. У нее есть определенные сложности с масштабированием, хотя они попытались решить это превентивно с помощью InfiniBand.
Есть неплохой документ от Teradata, описывающий основные недостатки Exadata. Ссылка
По мне, основной недостаток — это не MPP система, соответственно, масштабируется плохо. А так, она вполне подходит для среднего класса DWH, если не обращать внимания на её эффективность за такие деньги.
Teradata никогда не претендовала на этот рынок и разрабатывала свои решения в строгой концепции с DWH. OLTP для них неизведанный мир, нет ни одной Teradata в промышленной эксплуатации(насколько я знаю), использующаяся, как OLTP. Я также не знаю ERP, CRM и подобный решений, использующих Teradata.
Странно, что только сейчас начали полевые испытания. На самом деле, на рынке давно уже есть устройства, в которых реализован алгоритм Forward Error Correction — это WAN оптимизаторы от Silver Peak. Они есть в виде железок и виртуальных машин и оптимизируют трафик на транспортном уровне(TCP и UDP).
Они действительно считают, что основная проблема для TCP — это постоянно уменьшающееся cwnd в сетях(постоянные ACKи повышают latency), где существует перегрузка(TCP считает перегрузкой все) и декларируют, что могут растягивать окно до 1Гб именно за счет FEC, ну и также SACK.
И я даже видел практически такие же графики где-то у них.
Хмм… в таком случае, Teradata Data Mart edition не подходит для проведения PoC. Это версия, которая используется для ознакомительной демонстрации, чтобы понять что из себя представляет решение от Teradata в целом и для прототипирования (но тоже не для любого, а для ограниченного количества случаев). Тут становится непонятно, почему Teradata берет за это от 26К$ за ядро — однако если учитывать политику Teradata в отношении распространения своих продуктов, то можно списать это на затраты на специалистов, которым необходимо приехать к заказчику, развернуть систему и устроить общую демонстрацию и демонстрацию применительно к конкретной бизнес задаче заказчика.
Я думаю, не стоит вводить общественность в заблуждение и менять табличку/добавлять текст, так как Teradata Data Mart edition не подходит для решения задач, встающих перед аналитическими хранилищами данных. Кстати, у IBM Netezza тоже есть софтверная версия для таких же целей, что и Teradata Data Mart edition. Есть и у Greenplum — Community Edition, про Oracle можно сказать, что у них есть Express Edition, про Microsoft — SQL Server Express. Но все эти версии существуют для того, чтобы только посмотреть на продукты «вживую» и никак не подходят для решения серьезных бизнес-задач.
Если на конкретных примерах: стоит ли выкидывать поисковые запросы с орфографическими ошибками при попытке анализа тех или иных поисковых запросов(например, на Google)? Или, стоит ли при опросе об ОС Windows принимать мнение домохозяек, или опрашивать только мнение ИТ-специалистов, или даже только системных администраторов Windows?
>>любая автоматизация — зло.
Патриарх с вами несогласен — newsland.com/news/detail/id/730969/
РПЦ тоже — www.mpda.ru/cit/
Автоматизация и религия очень далеки друг от друга, также как религиозные подвижники от луддитов.
Чиновники сами говорят о необходимости перехода на облако. Понятно, что на облако пойдет только десятая часть из выделенных средств, всё остальное осядет в известных местах. Однако, какое-то облако все-таки будет и оно будет использоваться для централизации и размещения всех государственных информационных систем на нем. Можно надеяться, что в процессе постройки такого облако они наступят на все грабли, осознают все спорные моменты и как-то обозначат свою позицию по этим моментам.
Я не спорю, что сейчас облака в некоторых случаях выходят значительно дороже, но я не вижу причин, почему бы им не подешеветь в будущем — вычислительные мощности растут, память дешевеет. А когда облачные сервисы достигнут достаточной централизации и массовости, то они смогут значительно снизить цену, как это когда-то случилось с электричеством. И опять же, я говорю про долгосрочную перспективу — уже понятно в какую сторону поворачивает тенденция, и я не вижу никаких оснований, почему она должна повернуть в другую сторону.
Также и с облачными сервисами — тот же salesforce, ну зачем он нужен? Не проще ли и надежнее купить Oracle Siebel или Microsoft Dynamics, всю программную обвязку к ним в виде СУБД и серверов приложений, железо под все этой(не забудем про сеть) и помещение под железо, нанять аналитиков, админов и разработчиков, который этот CRM допилят, заплатить за поддержку вендору и спокойно наслаждаться? Ведь владельцам малого и среднего бизнеса этот путь кажется кратчайшим и логически верным…
Само незнание, что такое CDC, причем незнание среди специалистов в этой области, меня удивляет. В принципе, я попытался в популярной форме объяснить базовые принципы.
Вообще непонятно, как связано то, что написано в статье и модность Big Data. По моему мнению, причина популярности Big Data в том, что компании надеются получить с помощью нее больше денег — продавцы решений Big Data — продавая эти решения, те, кто покупает эти решения — используя данные для того, чтобы повысить продажи или решить насущные проблемы.
Попробую ответить, чем, по моему мнению, плоха бизнес-логика, реализованная на стороне БД. Во-первых, увеличивается нагрузка на сервер БД. СУБД занимается теперь не только своими непосредственными обязанностями, но вообще чем угодно. Непонятно, кто сколько ресурсов потребляет, как он это делает, какая часть чем занимается. Как это паралеллить? Как это масштабировать в дальнейшем? Вертикально? Горизонтально?
Во вторых, строго говоря, в функции СУБД не входит выполнение каких-либо команд, не относящихся к извлечению данных. А тут все наоборот — в одной СУБД наворочено черте что — AQ, MGW, Streams, работа с файлами, работа с почтой, Scheduler, пакеты со сложной логикой. Через некоторое время, все это становится настолько запутанным и сложным, что вопрос — как это поддерживать дальше становится критическим. Где вы получаете данные, а где просто отправляете почту? Необходимо больше квалифицированных специалистов, для поддержки всего этого нужна большая команда — нужны PL/SQL разработчики(желательно сертифицированные), архитекторы, куча DBA, тестеры на ту часть, на эту часть. Все это начинает работать плохо, понятие thread незнакомо oracle. Пользуетесь DBMS_JOB? В 11g это теперь включено в DBMS_SCHEDULER — надо переделывать. При взгляде на счета за поддержку такой системы владельцы бизнеса хватаются за сердце — Ларри Эллисон покупает еще остров. Хотите переехать на другую СУБД — даже не мечтайте.
Хотелось бы классифицировать тему про бизнес-логику в СУБД по ЯП(скорей даже по фреймворкам):
1) PL/SQL. Oracle не только реализовал свой полноценный язык программирования(хотя официально это считается процедурным расширением SQL — странный подход, по моему мнению), но и построил вокруг него свой блэкджек с аттракционами. Oracle Forms, Oracle Reports, Oracle Applications — если вы используете все это, то реализация логики на стороне БД вас неизбежно настигнет — тут никуда не денешься. Если проект достаточно масштабный, то через некоторое время понимать, что там происходит, будут только старожилы.
2) .NET, Java. Тут несколько сложнее, вспоминаем про очистку мусора — использовать большие массивы памяти для хранения данных довольно накладно в плане операционных расходов на очистку мусора. Если использовать их достаточно интенсивно и в больших объемах, то сталкиваемся с STW. Поэтому малодушные переносят часть логики в СУБД, думая, что избавились от головной боли, а заодно и повысили быстродействие — Java-то летает. Через некоторое время возникают проблемы — как масштабировать непонятно, слово «рефакторинг» вызывает истерический смех, PL/SQL вызывает лютую ненависть. Другие нанимают высококвалифицированного DBA, который бьет по рукам всех, кто вызывает неэффективные запросы к БД, используется несколько серверов или экземпляров приложений, изучают ORM(потому как изобретать велосипед незачем) — тут будущее выглядит более радужно — с масштабированием понятно, растем вширь, не забывая про балансировку. Отважные кидаются на распределенные кэши, coherence, off heap и т.п. — что тоже выход.
3) Python, Perl, PHP — это ж скриптовые языки!!! Причем тут бизнес-логика?
По остальным ЯП комментарии приветствуются.
vendor lock-in — в принципе, не так и страшно, если вендор хороший.
Реализация бизнес-логики на уровне СУБД страшный моветон сегодня именно потому, что к сегодняшнему моменту мы имеем кучу систем, которые непонятно, как дальше поддерживать и как дальше масштабировать. Да, они выполняют свои функции в каких-то пределах, а что делать дальше? Не проще ли проектировать такие системы, которые можно поддерживать за разумные деньги и время? Или важнее выйти на рынок раньше всех, а потом думать, как же допилировать её дальше?
Есть неплохой документ от Teradata, описывающий основные недостатки Exadata. Ссылка
По мне, основной недостаток — это не MPP система, соответственно, масштабируется плохо. А так, она вполне подходит для среднего класса DWH, если не обращать внимания на её эффективность за такие деньги.
Они действительно считают, что основная проблема для TCP — это постоянно уменьшающееся cwnd в сетях(постоянные ACKи повышают latency), где существует перегрузка(TCP считает перегрузкой все) и декларируют, что могут растягивать окно до 1Гб именно за счет FEC, ну и также SACK.
И я даже видел практически такие же графики где-то у них.
Я думаю, не стоит вводить общественность в заблуждение и менять табличку/добавлять текст, так как Teradata Data Mart edition не подходит для решения задач, встающих перед аналитическими хранилищами данных. Кстати, у IBM Netezza тоже есть софтверная версия для таких же целей, что и Teradata Data Mart edition. Есть и у Greenplum — Community Edition, про Oracle можно сказать, что у них есть Express Edition, про Microsoft — SQL Server Express. Но все эти версии существуют для того, чтобы только посмотреть на продукты «вживую» и никак не подходят для решения серьезных бизнес-задач.