Re[70]: В России опять напишут новый объектно-ориентированны
От: alex_public  
Дата: 17.05.18 12:44
Оценка:
Здравствуйте, Lexey, Вы писали:

_>>А то там на первой же картинке под названием "Архитектура YQL" красуются и Python и Jupyter...

L>Угу, первый в качестве одного из языков расширения и одного из публичных API, второй — в качестве одного из возможных UI. Если их выкинуть, работоспособность YQL практически никак не пострадает.

Да, только вот аналитикам этот самый YQL в таком случае будет уже не интересен, т.к. они в большинстве своём предпочитают именно Python (с соответствующими библиотеками и GUI) в роли центрального инструмента для своей работы. В который в одну команду импортируются данные и из YQL и из SQL и из cvs/excel и из SAP и из Hadoop и много чего ещё.

_>>В общем фееричное возражение у тебя получилось...

L>Ты его просто не понял. Статья вполне явно показывает, что в Яндексе тренд идет вовсе не в сторону отказа от SQLя в пользу питона, а, наоборот, в сторону создания "продвинутого SQLя", который позволяет решать многие задачи обработки данных вообще без питона, плюс позволяет интегрироваться с питоном, если возможностей одного YQLя недостаточно.

Хы, ты похоже вообще не в курсе темы.

У Яндекса не может быть отказов от SQL в сторону Питона или наоборот, потому как в основе у них лежит вообще другой инструмент. Их базис — это собственноручно написанное nosql решение по схеме MapReduce, работающее с C++ (в смысле не только само на нём написанное, но и выполняющее произвольный код в запросах). Т.е. это что-то вроде своего аналога Hadoop, только не с Java, а с C++. В какой-то момент им видимо надоело писать однотипный императивный код для шаблонных случаев и они захотели написать свой высокоуровневный язык запросов. Только не такой убогий, как SQL, а значительно лучше: там есть и исполнение произвольного императивного кода (причём аж на C++! Ну и на Питоне ещё, но это там реализовано как просто C++ функция с интерпретатором Питона) и MapReduce и декомпозиция запросов и ещё много чего интересного.

Но это всё касалось грубо говоря доступа к данным (по сути API к БД), а реальной обработкой данных современные аналитики предпочитают заниматься в Питоне и с помощью Jupyter Notebook. Только раньше им надо было в начале загрузить данные (с помощью низкоуровневой mapreduce команды, написанной на C++) из хранилища Яндекса в csv файлик, а потом импортировать его в Питон. А теперь они могут просто в одну строчку загрузить данные их хранилища данных Яндекса (точно так же как они привыкли это делать для любых SQL баз, Hadoop'a и т.п.).
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.