Просто крупные игроки не хотят зависеть от какой-то третьей стороны, поэтому делают свой «улучшенный язык», который и продвигают везде.
Да нет, не думаю — для Android, например, Google не стал изобретать новый язык программирования, а просто сделал свою реализацию рантайма.
К тому же, потребность в своём собственном языке никак не влияет на дизайн этого языка. Задачи Google не так сильно отличаются от задач тысяч других компаний — (микро)сервисы с максимальной утилизацией CPU и памяти. Это объясняет горутины, например. Стремление к простоте изучения и близости к C тоже понятна, учитывая тысячи работающих у них студентов, хотя для многих других компаний это свойство языка может быть совершенно ненужным или неуместным. А вот замена дженериков на кодогенерацию или использование зависимостей без чёткого версионирования лично для меня ну совсем непонятны.
появление открытых баз данных химических соединений и реакций
А не подскажете пару-тройку источников таких данных? А то медицинские и биохемические базы зачастую либо очень маленькие, либо распространяются исключительно между университетами и крупными компаниями.
Пожалуйста, не пишите на темы, связанные с искусственным интеллектом или машинным обучением — вы напрочь не понимаете, о чём идёт речь. DeepMind не разрабатывает ИИ для StarCraft, он создаёт среду для других разработчиков, в которой те смогут отрабатывать свои алгоритмы ИИ. По сути, просто API, предоставляющий удобный программный доступ к игре.
Для тех, кто всё-таки в теме, читайте оригинальную статью — там всё вполне логично.
Судя по всему, автор статьи как раз и попал в ту терминологическую путаницу, про которую я говорю. Смотрите:
The second advantage of symbolic computing is the automatic differentiation
Здесь есть 2 понятия: символьные вычисления и автоматическое дифференцирование.
Символные вычисления — это очень общее направление в информатике, описывающее вычисления над некоторыми символами. Как вы правильно обратили внимание, выражения, состоящие из переменных и операций могут быть предствлены в виде графа символов. Над этими выражениями можно проводить ряд символьных преобразований (например, упрощать выражения или находить символьные производные), трансформировать в код или план выполнения (как в случае с SQL) или делать логический вывод (как в случае эспертных систем). Графы в Theano и TensorFlow только частично являются символьными, ибо кроме имени символа хранят информацию о типе данных (это важно, см. ниже про символьное дифференцирование).
Автоматическое дифференцирование (AD) в основном встречается в двух вариантах: forward-mode AD и reverse-mode AD. Forward-mode AD позволяет эффективно вычислять производные функций вида R -> R^n, что в рамках машинного обучения не очень интересно. А вот reverse-mode AD как раз хорошо работает с функциями R^n -> R, т.е. как раз к большинству функций потерь, для которых и требуется вычислить градиент.
Фишка в том, что reverse-mode AD, вообще говоря, не требует никакого символьного представления. Например, стандартный алгоритм обратного распространения ошибки (backpropagation) — это как раз частный случай reverse-mode AD, но никакого симпольного графа в нём и рядом нет.
Есть и другое направление — символьное дифференцирование. Чистое символьное дифференцирование, например, используется в Mathematica или SymPy. Пример из последнего:
>>> diff(cos(x), x)
-sin(x)
Обратите внимание, что мы нигде не указали тип переменной x. По сути, большинство движков символьного дифференцирования умеет работать только с числами, но не с тензорами более высокого порядка. Более того, символьное дифференцирование не умеет обрабатывать условные переходы и циклы. С точки зрения математики, любое ветвление теоретически создаёт точку разрыва, а производная функции с точками разрыва может вообще не существовать или иметь очень сложну форму, вычислить которую компьютерными средствами ппц как нетривиально.
Автоматическое дифференцирование не имеет таких проблем: в нём мы не пытаемся найти единое символьное представление для производной, а только находим её значение в одной конкретной точке, заданной на входе. Это и плюс и минус: с одной стороны, мы можем анализировать голый программный код, с условмиями, циклами, структурами данных и т.д., а с другой, на выходе мы получаем не красивое символьное выражение, а вычислительный граф, работать с которым всё-таки посложней (как минимум, человек не сможет его "прочитать" и вручную закодировать). Кроме того, в reverse-mode AD мы вынуждены сохранять значения промежуточных переменных, а это могут быть тензоры довольно больших размеров.
Как Theano, так и TensorFlow (про MXNet не знаю) используют reverse-mode AD. Имена переменных (т.е. собственно "символы") при построении графа в них являются опциональными и могут польностью игнорироваться пользователем (сравните это с тем же SymPy или с логическими движками типа Prolog, где пользователя как раз и интересует конкретный символьных результат). Соответсвенно, слово "символьный" в названии, насколько я понимаю, не несёт никакой смысловой нагрузки и "символьное глубокое обучение" ничем не отличается от обычного :)
(а началось всё с того, что я понадеялся увидеть совмещение современных глубоких сетей и старого доброго символьного AI :))
В том то и дело, что там есть графы, но не символы :) В TensorFlow, например, граф состоит из переменных и операций, в MXNet — из переменых и слоёв, а термин "символ" встречается для обозначения тех же переменных только в Theano :)
Непонятно только, почему автор решил назвать эти фреймворки символьными: термин "symbolic AI" имеет совершенно другой смысл и относится скорее к логическому выводу в экспертных системах. Есть подозрение, что вся статья навеяна термином "symbol" в Theano, где он оправдан только наполовину (например, дифференцирование в нём всё-таки автоматическое, а не символьное).
Поставте s3 api на любое абстрактное хранилище, хоть полку c дисками — эффект будет тот же.
Это всё понятно, вопрос был в том, нужен ли HDFS, если все данные — структурированые. Я привёл пример того, где абсолютно структирированные данные пишутся на HDFS, а не в RDBMS, потому что RDBMS не даёт нужного уровня абстракции и контроля.
В конечном счете, если мы говорим о realtime — все, что не висит в памяти, напрямую из application или косвенно как object store — не есть realtime, ибо (относительно памяти) медленно.
Real-time — понятие относительное. Например, Википедия говорит нам, что
"real-time" means a range from milliseconds to a few seconds (5s) after the business event has occurred
На практике же всё определяется ожиданиями клиента: если клиент загружает 3Гб данных и видит по ним аналитику через 15 минут, 13 из которых заливался файл, то для него это всё ещё "real-time".
Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.
WAT?? Поясните, пожалуйста, о какой фрагментации и рандомном чтении идёт речь?
Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.
Расскажите, как, например, Vertica, справляется с real-time аналитикой? Я отвечу за вас: плохо. А вот, например, Druid, хранящий абсолютно структурированные данные на HDFS, делает это вполне эффективно. А всё потому, что HDFS и Hadoop вообще предоставляют более низкоуровневые инструменты и гораздо более широкие возможности, чем любая отдельно взятая SQL СУБД.
В Teradata Aster можно вроде как реализовывать задачи запускаемые непосредственно в самой базе либо на Java, либо на C/С++, про R как раз-таки не уверен.
Про R у них прямо на сайте написано, так что я так понял, что это основной аналитический инструмент у них.
В остальном да, согласен — термин перегретый, часто рождает мифы и слухи. Но и статьи вроде этой не помогают: автор явно пристрастен к SQL базам данных, поэтому я и пытаюсь показать примеры, где SQL сильно проигрывает.
О, значит, наконец, допилили. А вы случайно не пользовали? Как оно вообще, стабильно? Быстро? Для нас сейчас не суперактуально, но на будущее хотелось бы знать.
Другое дело насколько эта поддержка удовлетворяет вашим потребностям.
Вот именно поэтому я и попросил привести решение озвученный задач на любой из названных СУБД. Если вы считаете, что большинство или хотя бы какая-то одна БД позволяет сделать озвученные задачи, пожалуйста, приведите пример.
А я потом приведу пример, как это делается в Spark, хоть со встроенным MLlib, хоть с использованием сторонних библиотек и их алгоритмов. И вот тогда уже можно будет предметно обсудить, стоит ли Hadoop своей славы или нет.
Продукт интересный, согласен, но я всё-таки задачи для примера привёл, чтобы показать, что SQL базы обычно не умеют. Для Teradata можно найти кучу других примеров (например, меня сразу смутило, что из general purpose языков, судя по всему, поддерживается только R и только через межпроцессорное взаимодействие, весь продукт недоступен шикорому кругу open source разработчиков, что замедляет развитие и т.д.). И точно так же можно назвать кучу недостатков для любого продукта из инфраструктуры Hadoop. Но нельзя говорить, что весь кипеш вокруг Hadoop и big data — это исключительно работа маркетологов: для формирования текущего рынка были вполне обоснованные исторически предпосылки со вполне конкретной выгодой.
Открою для вас горькую правду — ничего бесплатного в нашем мире нет. Используя CDH или Hortonworks, вы должны купить подписку на поддержку, которая, кстати, не бесплатная.
Нет, не должны. За деньги вы можете получить версию с парой дополнительных фич и да, поддержку, но и абсолютно бесплатной community edition обычно хватает за глаза.
Все это есть в любой аналитической МРР системе, в том же Greenplum — библиотека MadLib, умеет делать очень много и на SQL-подобном языке.
Так покажите мне, как конкретно решить эту задачу на Greenplum. Я не спорю, что вы сможете через трёхэтажный неэффективный запрос вы сможете сделать наивный Байсовский классификатор, может быть даже реализуете безумную логистическую регрессию, SVM — уже маловероятно. А на Spark я это (и много гораздо более сложных вещей) сделаю в пару строк кода. Смысл в том, что в отличие от SQL баз данных, Hadoop позволяет использовать любой кастомный код, строить любые статистические модели, вызывать любые сторонние API, сохранять состояние, отсылать метрики процесса и многое многое другое. Вы же увидели только SQL составляющу Hadoop и пытаетесь доказать, что все компании страдают ерундой, разворачивая себе Hadoop кластер вместо SQL СУБД.
Согласен, не все так категорично, но перед тем как эти две таблички связать, необходимо провести много работы и не обязательно для этого использовать инструменты из зоопарка Hadoop.
Естественно, и никто чисто на Hadoop не завязывается. Просто в инфраструктуре Hadoop много новых полезных инструментов таких как Spark, Storm, Kafka, GraphX, HBase и т.д., которые могут крутиться на одном и том же кластере и хорошо интегрированы друг с другом. Это удобно, но я пока не видел ни одной компании, которая бы замыкалась только на Hadoop и не использовала другие инструменты (в т.ч. классические SQL базы данных).
Ключевой момент в том, что это работает только для Google, с их инфраструктурой и подходами, а язык используется тысячами других компаний.
Получается, что отсутствие версионирования зависимостей работает только для Google с их большим монолитным репозиторием, так?
Да нет, не думаю — для Android, например, Google не стал изобретать новый язык программирования, а просто сделал свою реализацию рантайма.
К тому же, потребность в своём собственном языке никак не влияет на дизайн этого языка. Задачи Google не так сильно отличаются от задач тысяч других компаний — (микро)сервисы с максимальной утилизацией CPU и памяти. Это объясняет горутины, например. Стремление к простоте изучения и близости к C тоже понятна, учитывая тысячи работающих у них студентов, хотя для многих других компаний это свойство языка может быть совершенно ненужным или неуместным. А вот замена дженериков на кодогенерацию или использование зависимостей без чёткого версионирования лично для меня ну совсем непонятны.
Спасибо!
А не подскажете пару-тройку источников таких данных? А то медицинские и биохемические базы зачастую либо очень маленькие, либо распространяются исключительно между университетами и крупными компаниями.
+1 и буду ждать статью про VAE + GAN. Единственное, что не понял, это:
А как эти понятия вообще связаны в данном случае?
Пожалуйста!
Для тех, кто всё-таки в теме, читайте оригинальную статью — там всё вполне логично.
Судя по всему, автор статьи как раз и попал в ту терминологическую путаницу, про которую я говорю. Смотрите:
Здесь есть 2 понятия: символьные вычисления и автоматическое дифференцирование.
Символные вычисления — это очень общее направление в информатике, описывающее вычисления над некоторыми символами. Как вы правильно обратили внимание, выражения, состоящие из переменных и операций могут быть предствлены в виде графа символов. Над этими выражениями можно проводить ряд символьных преобразований (например, упрощать выражения или находить символьные производные), трансформировать в код или план выполнения (как в случае с SQL) или делать логический вывод (как в случае эспертных систем). Графы в Theano и TensorFlow только частично являются символьными, ибо кроме имени символа хранят информацию о типе данных (это важно, см. ниже про символьное дифференцирование).
Автоматическое дифференцирование (AD) в основном встречается в двух вариантах: forward-mode AD и reverse-mode AD. Forward-mode AD позволяет эффективно вычислять производные функций вида
R -> R^n, что в рамках машинного обучения не очень интересно. А вот reverse-mode AD как раз хорошо работает с функциямиR^n -> R, т.е. как раз к большинству функций потерь, для которых и требуется вычислить градиент.Фишка в том, что reverse-mode AD, вообще говоря, не требует никакого символьного представления. Например, стандартный алгоритм обратного распространения ошибки (backpropagation) — это как раз частный случай reverse-mode AD, но никакого симпольного графа в нём и рядом нет.
Есть и другое направление — символьное дифференцирование. Чистое символьное дифференцирование, например, используется в Mathematica или SymPy. Пример из последнего:
Обратите внимание, что мы нигде не указали тип переменной
x. По сути, большинство движков символьного дифференцирования умеет работать только с числами, но не с тензорами более высокого порядка. Более того, символьное дифференцирование не умеет обрабатывать условные переходы и циклы. С точки зрения математики, любое ветвление теоретически создаёт точку разрыва, а производная функции с точками разрыва может вообще не существовать или иметь очень сложну форму, вычислить которую компьютерными средствами ппц как нетривиально.Автоматическое дифференцирование не имеет таких проблем: в нём мы не пытаемся найти единое символьное представление для производной, а только находим её значение в одной конкретной точке, заданной на входе. Это и плюс и минус: с одной стороны, мы можем анализировать голый программный код, с условмиями, циклами, структурами данных и т.д., а с другой, на выходе мы получаем не красивое символьное выражение, а вычислительный граф, работать с которым всё-таки посложней (как минимум, человек не сможет его "прочитать" и вручную закодировать). Кроме того, в reverse-mode AD мы вынуждены сохранять значения промежуточных переменных, а это могут быть тензоры довольно больших размеров.
Как Theano, так и TensorFlow (про MXNet не знаю) используют reverse-mode AD. Имена переменных (т.е. собственно "символы") при построении графа в них являются опциональными и могут польностью игнорироваться пользователем (сравните это с тем же SymPy или с логическими движками типа Prolog, где пользователя как раз и интересует конкретный символьных результат). Соответсвенно, слово "символьный" в названии, насколько я понимаю, не несёт никакой смысловой нагрузки и "символьное глубокое обучение" ничем не отличается от обычного :)
(а началось всё с того, что я понадеялся увидеть совмещение современных глубоких сетей и старого доброго символьного AI :))
В том то и дело, что там есть графы, но не символы :) В TensorFlow, например, граф состоит из переменных и операций, в MXNet — из переменых и слоёв, а термин "символ" встречается для обозначения тех же переменных только в Theano :)
Непонятно только, почему автор решил назвать эти фреймворки символьными: термин "symbolic AI" имеет совершенно другой смысл и относится скорее к логическому выводу в экспертных системах. Есть подозрение, что вся статья навеяна термином "symbol" в Theano, где он оправдан только наполовину (например, дифференцирование в нём всё-таки автоматическое, а не символьное).
Это всё понятно, вопрос был в том, нужен ли HDFS, если все данные — структурированые. Я привёл пример того, где абсолютно структирированные данные пишутся на HDFS, а не в RDBMS, потому что RDBMS не даёт нужного уровня абстракции и контроля.
Real-time — понятие относительное. Например, Википедия говорит нам, что
На практике же всё определяется ожиданиями клиента: если клиент загружает 3Гб данных и видит по ним аналитику через 15 минут, 13 из которых заливался файл, то для него это всё ещё "real-time".
Т.е. на распределённую файловую систему, которая в данном случае является необходимостью, а не "лишними издержками" :)
Расскажите use case, мы тоже считаем в т.ч. и клики, но 0.3 для вертики, честно говоря, звучит фантастически.
WAT?? Поясните, пожалуйста, о какой фрагментации и рандомном чтении идёт речь?
Расскажите, как, например, Vertica, справляется с real-time аналитикой? Я отвечу за вас: плохо. А вот, например, Druid, хранящий абсолютно структурированные данные на HDFS, делает это вполне эффективно. А всё потому, что HDFS и Hadoop вообще предоставляют более низкоуровневые инструменты и гораздо более широкие возможности, чем любая отдельно взятая SQL СУБД.
Про R у них прямо на сайте написано, так что я так понял, что это основной аналитический инструмент у них.
В остальном да, согласен — термин перегретый, часто рождает мифы и слухи. Но и статьи вроде этой не помогают: автор явно пристрастен к SQL базам данных, поэтому я и пытаюсь показать примеры, где SQL сильно проигрывает.
О, значит, наконец, допилили. А вы случайно не пользовали? Как оно вообще, стабильно? Быстро? Для нас сейчас не суперактуально, но на будущее хотелось бы знать.
Вот именно поэтому я и попросил привести решение озвученный задач на любой из названных СУБД. Если вы считаете, что большинство или хотя бы какая-то одна БД позволяет сделать озвученные задачи, пожалуйста, приведите пример.
А я потом приведу пример, как это делается в Spark, хоть со встроенным MLlib, хоть с использованием сторонних библиотек и их алгоритмов. И вот тогда уже можно будет предметно обсудить, стоит ли Hadoop своей славы или нет.
Продукт интересный, согласен, но я всё-таки задачи для примера привёл, чтобы показать, что SQL базы обычно не умеют. Для Teradata можно найти кучу других примеров (например, меня сразу смутило, что из general purpose языков, судя по всему, поддерживается только R и только через межпроцессорное взаимодействие, весь продукт недоступен шикорому кругу open source разработчиков, что замедляет развитие и т.д.). И точно так же можно назвать кучу недостатков для любого продукта из инфраструктуры Hadoop. Но нельзя говорить, что весь кипеш вокруг Hadoop и big data — это исключительно работа маркетологов: для формирования текущего рынка были вполне обоснованные исторически предпосылки со вполне конкретной выгодой.
Нет, не должны. За деньги вы можете получить версию с парой дополнительных фич и да, поддержку, но и абсолютно бесплатной community edition обычно хватает за глаза.
Так покажите мне, как конкретно решить эту задачу на Greenplum. Я не спорю, что вы сможете через трёхэтажный неэффективный запрос вы сможете сделать наивный Байсовский классификатор, может быть даже реализуете безумную логистическую регрессию, SVM — уже маловероятно. А на Spark я это (и много гораздо более сложных вещей) сделаю в пару строк кода. Смысл в том, что в отличие от SQL баз данных, Hadoop позволяет использовать любой кастомный код, строить любые статистические модели, вызывать любые сторонние API, сохранять состояние, отсылать метрики процесса и многое многое другое. Вы же увидели только SQL составляющу Hadoop и пытаетесь доказать, что все компании страдают ерундой, разворачивая себе Hadoop кластер вместо SQL СУБД.
Естественно, и никто чисто на Hadoop не завязывается. Просто в инфраструктуре Hadoop много новых полезных инструментов таких как Spark, Storm, Kafka, GraphX, HBase и т.д., которые могут крутиться на одном и том же кластере и хорошо интегрированы друг с другом. Это удобно, но я пока не видел ни одной компании, которая бы замыкалась только на Hadoop и не использовала другие инструменты (в т.ч. классические SQL базы данных).