Gt_>>указывает.
IB>Каким образом?
возьми любую книжку по F# и почитай вводную, там везде будет разжевано почему C# imperative language
Gt_>>то что декларативным sql такие вещи не решить, но есть костыль на императивном C#, который убьет оптимизатор и все равно ничего не даст.
IB>Чего это не даст? В вашем любимом хадупе, точно такой же код, точно так же не известный оптимизатору и движку.
в мап-редюсе в принципе нет оптимизатора, там по сути голый жава код с парой вызовов из наследумых от хадупа классов.
у spark оптимизатор есть, но там и управлять потоком данных можно совершенно на ином уровне и код совершенно иначе выглядит. что в вашем мсскл ? тут декларативный sql, тут с# между ними пропасть и тучи сугубо технического геморроя подружить энжины из разных миров, нихера толком не интегрированных. зачастую это вообще три мира — процедурный t-sql бежит в цикле по курсору из декларативного мира, дергая C# процедуру из мира .net. и в каждом из миров свой синтаксис, свои типы, свои процессы и память.
у спарка же все это жава или скала код, где декларативный и императивный мир гораздо изящней интегрированы вместе в единой jvm.
Dataset<Row> shit = vars.mapGroups(
(MapGroupsFunction<Integer, String, String>) (key, values) -> {
MyMegaClass mc = new MyMegaClass(key);
while (values.hasNext()) {
mc.process(values.next());
}
return mc.toString();
}, Encoders.STRING()) ;
datasetCache.cache("shit", shit);
той пропасти в синтаксисе нет, все в одном енжине, где вмешаться можно хоть в кеширование. и работает хоть локально в тесте, хоть на кластере распределившись на сотни узлов.
Gt_>>нет. хранимка это то, что заранее задефайнено в субд, а тут либы используемые твоим кодом. соответственно можно выполнять код с разными версиями либ одновременно.
IB>можно, но нужно ли? К тому же хранимки тоже можно на лету делать.
с дуру можно и ... сломать. но первое код ревью за "хранимки на лету" с волчьим билетом
Gt_