Сообщение Re[71]: В России опять напишут новый объектно-ориентированны от 17.05.2018 17:52
Изменено 17.05.2018 18:16 Lexey
Re[71]: В России опять напишут новый объектно-ориентированны
Здравствуйте, alex_public, Вы писали:
_>Да, только вот аналитикам этот самый YQL в таком случае будет уже не интересен
Будет он им интересен. Просто потому, что он позволяет делать выборки и трансформацию данных из пачки источников без написания зубодробильного кода.
А вот результаты этого уже можно грузить куда угодно.
_>Хы, ты похоже вообще не в курсе темы.
_>У Яндекса не может быть отказов от SQL в сторону Питона или наоборот, потому как в основе у них лежит вообще другой инструмент. Их базис — это собственноручно написанное nosql решение по схеме MapReduce, работающее с C++ (в смысле не только само на нём написанное, но и выполняющее произвольный код в запросах).
Т.е. это что-то вроде своего аналога Hadoop, только не с Java, а с C++. В какой-то момент им видимо надоело писать однотипный императивный код для шаблонных случаев и они захотели написать свой высокоуровневный язык запросов. Только не такой убогий, как SQL, а значительно лучше: там есть и исполнение произвольного императивного кода (причём аж на C++! Ну и на Питоне ещё, но это там реализовано как просто C++ функция с интерпретатором Питона) и MapReduce и декомпозиция запросов и ещё много чего интересного.
О, ты, похоже, слышал про YT. А слышал ли ты, что кроме него есть еще минимум 2 другие MR-системы. Это не считая реляционных баз и всяких key-value хранилищ.
Любая приличная реализация SQL умеет UDF, которые, внезапно, можно писать на плюсах (Яве, Шарпе, etc). В YQL оно работает ровно так же. Хочешь исполнять код на плюсах или питоне — пиши UDF с довольно жестким интерфейсом.
_>Но это всё касалось грубо говоря доступа к данным (по сути API к БД), а реальной обработкой данных современные аналитики предпочитают заниматься в Питоне и с помощью Jupyter Notebook.
Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.
_>Только раньше им надо было в начале загрузить данные (с помощью низкоуровневой mapreduce команды, написанной на C++) из хранилища Яндекса в csv файлик, а потом импортировать его в Питон. А теперь они могут просто в одну строчку загрузить данные их хранилища данных Яндекса (точно так же как они привыкли это делать для любых SQL баз, Hadoop'a и т.п.).
А ничего, что CSV-файлик на десяток терабайт может получиться, например? Долго его питону будешь скармливать?
_>Да, только вот аналитикам этот самый YQL в таком случае будет уже не интересен
Будет он им интересен. Просто потому, что он позволяет делать выборки и трансформацию данных из пачки источников без написания зубодробильного кода.
А вот результаты этого уже можно грузить куда угодно.
_>Хы, ты похоже вообще не в курсе темы.
_>У Яндекса не может быть отказов от SQL в сторону Питона или наоборот, потому как в основе у них лежит вообще другой инструмент. Их базис — это собственноручно написанное nosql решение по схеме MapReduce, работающее с C++ (в смысле не только само на нём написанное, но и выполняющее произвольный код в запросах).
Т.е. это что-то вроде своего аналога Hadoop, только не с Java, а с C++. В какой-то момент им видимо надоело писать однотипный императивный код для шаблонных случаев и они захотели написать свой высокоуровневный язык запросов. Только не такой убогий, как SQL, а значительно лучше: там есть и исполнение произвольного императивного кода (причём аж на C++! Ну и на Питоне ещё, но это там реализовано как просто C++ функция с интерпретатором Питона) и MapReduce и декомпозиция запросов и ещё много чего интересного.
О, ты, похоже, слышал про YT. А слышал ли ты, что кроме него есть еще минимум 2 другие MR-системы. Это не считая реляционных баз и всяких key-value хранилищ.
Любая приличная реализация SQL умеет UDF, которые, внезапно, можно писать на плюсах (Яве, Шарпе, etc). В YQL оно работает ровно так же. Хочешь исполнять код на плюсах или питоне — пиши UDF с довольно жестким интерфейсом.
_>Но это всё касалось грубо говоря доступа к данным (по сути API к БД), а реальной обработкой данных современные аналитики предпочитают заниматься в Питоне и с помощью Jupyter Notebook.
Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.
_>Только раньше им надо было в начале загрузить данные (с помощью низкоуровневой mapreduce команды, написанной на C++) из хранилища Яндекса в csv файлик, а потом импортировать его в Питон. А теперь они могут просто в одну строчку загрузить данные их хранилища данных Яндекса (точно так же как они привыкли это делать для любых SQL баз, Hadoop'a и т.п.).
А ничего, что CSV-файлик на десяток терабайт может получиться, например? Долго его питону будешь скармливать?
Re[71]: В России опять напишут новый объектно-ориентированны
Здравствуйте, alex_public, Вы писали:
_>Да, только вот аналитикам этот самый YQL в таком случае будет уже не интересен
Будет он им интересен. Просто потому, что он позволяет делать выборки и трансформацию данных из пачки источников без написания зубодробильного кода.
А вот результаты этого уже можно грузить куда угодно.
_>Хы, ты похоже вообще не в курсе темы.
_>У Яндекса не может быть отказов от SQL в сторону Питона или наоборот, потому как в основе у них лежит вообще другой инструмент. Их базис — это собственноручно написанное nosql решение по схеме MapReduce, работающее с C++ (в смысле не только само на нём написанное, но и выполняющее произвольный код в запросах). Т.е. это что-то вроде своего аналога Hadoop, только не с Java, а с C++. В какой-то момент им видимо надоело писать однотипный императивный код для шаблонных случаев и они захотели написать свой высокоуровневный язык запросов. Только не такой убогий, как SQL, а значительно лучше: там есть и исполнение произвольного императивного кода (причём аж на C++! Ну и на Питоне ещё, но это там реализовано как просто C++ функция с интерпретатором Питона) и MapReduce и декомпозиция запросов и ещё много чего интересного.
О, ты, похоже, слышал про YT. А слышал ли ты, что кроме него есть еще минимум 2 другие MR-системы. Это не считая реляционных баз и всяких key-value хранилищ.
Любая приличная реализация SQL умеет UDF, которые, внезапно, можно писать на плюсах (Яве, Шарпе, etc). В YQL оно работает ровно так же. Хочешь исполнять код на плюсах или питоне — пиши UDF с довольно жестким интерфейсом.
_>Но это всё касалось грубо говоря доступа к данным (по сути API к БД), а реальной обработкой данных современные аналитики предпочитают заниматься в Питоне и с помощью Jupyter Notebook.
Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.
_>Только раньше им надо было в начале загрузить данные (с помощью низкоуровневой mapreduce команды, написанной на C++) из хранилища Яндекса в csv файлик, а потом импортировать его в Питон. А теперь они могут просто в одну строчку загрузить данные их хранилища данных Яндекса (точно так же как они привыкли это делать для любых SQL баз, Hadoop'a и т.п.).
А ничего, что CSV-файлик на десяток терабайт может получиться, например? Долго его питону будешь скармливать?
_>Да, только вот аналитикам этот самый YQL в таком случае будет уже не интересен
Будет он им интересен. Просто потому, что он позволяет делать выборки и трансформацию данных из пачки источников без написания зубодробильного кода.
А вот результаты этого уже можно грузить куда угодно.
_>Хы, ты похоже вообще не в курсе темы.
_>У Яндекса не может быть отказов от SQL в сторону Питона или наоборот, потому как в основе у них лежит вообще другой инструмент. Их базис — это собственноручно написанное nosql решение по схеме MapReduce, работающее с C++ (в смысле не только само на нём написанное, но и выполняющее произвольный код в запросах). Т.е. это что-то вроде своего аналога Hadoop, только не с Java, а с C++. В какой-то момент им видимо надоело писать однотипный императивный код для шаблонных случаев и они захотели написать свой высокоуровневный язык запросов. Только не такой убогий, как SQL, а значительно лучше: там есть и исполнение произвольного императивного кода (причём аж на C++! Ну и на Питоне ещё, но это там реализовано как просто C++ функция с интерпретатором Питона) и MapReduce и декомпозиция запросов и ещё много чего интересного.
О, ты, похоже, слышал про YT. А слышал ли ты, что кроме него есть еще минимум 2 другие MR-системы. Это не считая реляционных баз и всяких key-value хранилищ.
Любая приличная реализация SQL умеет UDF, которые, внезапно, можно писать на плюсах (Яве, Шарпе, etc). В YQL оно работает ровно так же. Хочешь исполнять код на плюсах или питоне — пиши UDF с довольно жестким интерфейсом.
_>Но это всё касалось грубо говоря доступа к данным (по сути API к БД), а реальной обработкой данных современные аналитики предпочитают заниматься в Питоне и с помощью Jupyter Notebook.
Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.
_>Только раньше им надо было в начале загрузить данные (с помощью низкоуровневой mapreduce команды, написанной на C++) из хранилища Яндекса в csv файлик, а потом импортировать его в Питон. А теперь они могут просто в одну строчку загрузить данные их хранилища данных Яндекса (точно так же как они привыкли это делать для любых SQL баз, Hadoop'a и т.п.).
А ничего, что CSV-файлик на десяток терабайт может получиться, например? Долго его питону будешь скармливать?