Сообщение Re[74]: В России опять напишут новый объектно-ориентированны от 16.05.2018 8:38
Изменено 16.05.2018 8:54 Gt_
Re[74]: В России опять напишут новый объектно-ориентированны
Gt_>>не, смешно было когда ты блокировки на чтение оракла нашел.
IB>Так они все еще там есть, смешно что вам до сих пор их не видно. ))
и вот это еще рассуждает о выученных билетах
IB>Ну конечно, яндекс неправильный, вы-то точно знаете как лучше делать ))
не? яндекс конечно же безусловный авторитет, после того как почту запилил на oracle EE edition с rac, партишинингом, датагвардом и прочими лицензиями. ну реально, кто бы из профессионалов мог бы заранее предвидеть, что могучий оракл не совсем тот инструмент и выйдет дорого. а ставка на С++, тоже чувствуется глубокое понимание ...
Gt_>>sql в бигдате лишь еще один интерфейс.
IB>Конечно еще один. Не было, потом появился, очевидный же тренд?
тренд уход от hive sql к всяким spark dataframe, который дает больше низкоуровневых возможностей, не отнимая sql. по моим наблюдениям джависты sql вообще не пользуют в спарке.
IB>Я нарошно ушел от термина "декларативный" к уровню абстракции, чтобы понятнее было, но теперь видно кто злится и бухает ))
ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.
IB>Прекрасно, то есть данные у нас в хадупе, на самом деле, к которому, как мы уже выяснили, прикручивают SQL. Какой там у нас тренд, напомните? То есть, не выиграл, а проиграл и не в шахматы, а в преферанс ))
IB>Но даже не важно. Допустим получили мы наши csv-шки или json... И с какого боку к ним sql прислонять?
IB>Когда источник данных понимал sql — использовали sql, когда он стал в csv или json, то вкрячивать между ними и питоном sql, очевидно странная затея. Как и предполагалось, пример вообще про другое, и не имеет никакого отношения к обсуждаемому вопросу.
тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
create table и sql это здорово, но дальше то о чем alex_public говорит, люди захотели большего. больше гибкости, джоинить не реляционные данные, подключать библиотеки ML, тут-же генерить графики. декларативный язык заточенный лишь на работу с реляционными данными все это может через обходные маневры, но тенденция явно просматривается в туче задач. люди хотят большего.
Gt_
IB>Так они все еще там есть, смешно что вам до сих пор их не видно. ))
и вот это еще рассуждает о выученных билетах
IB>Ну конечно, яндекс неправильный, вы-то точно знаете как лучше делать ))
не? яндекс конечно же безусловный авторитет, после того как почту запилил на oracle EE edition с rac, партишинингом, датагвардом и прочими лицензиями. ну реально, кто бы из профессионалов мог бы заранее предвидеть, что могучий оракл не совсем тот инструмент и выйдет дорого. а ставка на С++, тоже чувствуется глубокое понимание ...
Gt_>>sql в бигдате лишь еще один интерфейс.
IB>Конечно еще один. Не было, потом появился, очевидный же тренд?
тренд уход от hive sql к всяким spark dataframe, который дает больше низкоуровневых возможностей, не отнимая sql. по моим наблюдениям джависты sql вообще не пользуют в спарке.
IB>Я нарошно ушел от термина "декларативный" к уровню абстракции, чтобы понятнее было, но теперь видно кто злится и бухает ))
ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.
IB>Прекрасно, то есть данные у нас в хадупе, на самом деле, к которому, как мы уже выяснили, прикручивают SQL. Какой там у нас тренд, напомните? То есть, не выиграл, а проиграл и не в шахматы, а в преферанс ))
IB>Но даже не важно. Допустим получили мы наши csv-шки или json... И с какого боку к ним sql прислонять?
IB>Когда источник данных понимал sql — использовали sql, когда он стал в csv или json, то вкрячивать между ними и питоном sql, очевидно странная затея. Как и предполагалось, пример вообще про другое, и не имеет никакого отношения к обсуждаемому вопросу.
тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
create table и sql это здорово, но дальше то о чем alex_public говорит, люди захотели большего. больше гибкости, джоинить не реляционные данные, подключать библиотеки ML, тут-же генерить графики. декларативный язык заточенный лишь на работу с реляционными данными все это может через обходные маневры, но тенденция явно просматривается в туче задач. люди хотят большего.
Gt_
Re[74]: В России опять напишут новый объектно-ориентированны
Gt_>>не, смешно было когда ты блокировки на чтение оракла нашел.
IB>Так они все еще там есть, смешно что вам до сих пор их не видно. ))
и вот это еще рассуждает о выученных билетах
IB>Ну конечно, яндекс неправильный, вы-то точно знаете как лучше делать ))
не, яндекс конечно же безусловный авторитет, после того как почту запилил на oracle EE edition с rac, партишинингом, датагвардом и прочими лицензиями. ну реально, кто бы из профессионалов мог бы заранее предвидеть, что могучий оракл не совсем тот инструмент и выйдет дорого. а ставка на С++, тоже чувствуется глубокое понимание ...
Gt_>>sql в бигдате лишь еще один интерфейс.
IB>Конечно еще один. Не было, потом появился, очевидный же тренд?
тренд уход от hive sql к всяким spark dataframe, который дает больше низкоуровневых возможностей, не отнимая sql. по моим наблюдениям джависты sql вообще не пользуют в спарке.
IB>Я нарошно ушел от термина "декларативный" к уровню абстракции, чтобы понятнее было, но теперь видно кто злится и бухает ))
ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.
IB>Прекрасно, то есть данные у нас в хадупе, на самом деле, к которому, как мы уже выяснили, прикручивают SQL. Какой там у нас тренд, напомните? То есть, не выиграл, а проиграл и не в шахматы, а в преферанс ))
IB>Но даже не важно. Допустим получили мы наши csv-шки или json... И с какого боку к ним sql прислонять?
IB>Когда источник данных понимал sql — использовали sql, когда он стал в csv или json, то вкрячивать между ними и питоном sql, очевидно странная затея. Как и предполагалось, пример вообще про другое, и не имеет никакого отношения к обсуждаемому вопросу.
тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
create table и sql это здорово, но дальше то о чем alex_public говорит, люди захотели большего. больше гибкости, джоинить не реляционные данные, подключать библиотеки ML, тут-же генерить графики. декларативный язык заточенный лишь на работу с реляционными данными все это может через обходные маневры, но тенденция явно просматривается в туче задач. люди хотят большего.
Gt_
IB>Так они все еще там есть, смешно что вам до сих пор их не видно. ))
и вот это еще рассуждает о выученных билетах
IB>Ну конечно, яндекс неправильный, вы-то точно знаете как лучше делать ))
не, яндекс конечно же безусловный авторитет, после того как почту запилил на oracle EE edition с rac, партишинингом, датагвардом и прочими лицензиями. ну реально, кто бы из профессионалов мог бы заранее предвидеть, что могучий оракл не совсем тот инструмент и выйдет дорого. а ставка на С++, тоже чувствуется глубокое понимание ...
Gt_>>sql в бигдате лишь еще один интерфейс.
IB>Конечно еще один. Не было, потом появился, очевидный же тренд?
тренд уход от hive sql к всяким spark dataframe, который дает больше низкоуровневых возможностей, не отнимая sql. по моим наблюдениям джависты sql вообще не пользуют в спарке.
IB>Я нарошно ушел от термина "декларативный" к уровню абстракции, чтобы понятнее было, но теперь видно кто злится и бухает ))
ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.
IB>Прекрасно, то есть данные у нас в хадупе, на самом деле, к которому, как мы уже выяснили, прикручивают SQL. Какой там у нас тренд, напомните? То есть, не выиграл, а проиграл и не в шахматы, а в преферанс ))
IB>Но даже не важно. Допустим получили мы наши csv-шки или json... И с какого боку к ним sql прислонять?
IB>Когда источник данных понимал sql — использовали sql, когда он стал в csv или json, то вкрячивать между ними и питоном sql, очевидно странная затея. Как и предполагалось, пример вообще про другое, и не имеет никакого отношения к обсуждаемому вопросу.
тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
create table и sql это здорово, но дальше то о чем alex_public говорит, люди захотели большего. больше гибкости, джоинить не реляционные данные, подключать библиотеки ML, тут-же генерить графики. декларативный язык заточенный лишь на работу с реляционными данными все это может через обходные маневры, но тенденция явно просматривается в туче задач. люди хотят большего.
Gt_