тогда уже «мастер серверА», к тому же это плюс одна сущность
я не отрицаю, что можно сделать, но пока у нас проблема была с get/put на хазелкасте, мы ее и решаем, когда от него останется только сборка кластера, тогда и будем думать как лучше выпиливать окончательно
так потиху все к тому и идет… но нужны тесты, как себя поведет система когда мы в нее еще и сессии в hbase начнем впихивать.
с конфигурацией чуть сложнее, так как помимо всего мы используем discovery из hazelcast для прослушки, когда удаленный сервер добавляется или удаляется, с hbase такое сложно будет сделать, тут уже надо использовать zookeeper.
в общем процесс идет, пускай и не сильно быстро, но движется =)
«устраняем косяки по мере их появления», так как большую систему сложно вот так взять и переписать
когда я пришел на проект, то это уже было сделано, сейчас приводим к более вменяемому виду.
одна nosql уже имеется (hbase), поэтому затягивать еще и couch как-то не хочется.
отдельно стоит отметить, что для couch еще нужно отдельно запускать процессы, что дополнительно усложняет инфраструктуру.
в общем как уже говорилось, сейчас осталось:
1) конфигурация кластера (где какие сервисы доступны)
2) хранение сесии, так как запрос может в процессе жизни пройтись по многим серверам, то имеем apache shiro и кеширование в hazelcast
пока справляется после написания N-го количества сериализаторов (до этого на некоторых структурах скатывался до java сериализатора, а так как кеширование класлоадера в hazelcast не было, то получали contention на класлоадере). hazelcast.org/docs/latest/manual/html/customserialization.html
с текущей нагрузкой справляется, дальше пока думаем куда двигаться.
в данный момент вынесли все что некритично в свой код, hazelcast остался для кластерного кеша сессий и хранения конфигурации. альтернативы сильно не рассматривали, так как зависимость от хазелкаста постоянно уменьшаем.
в embedded режиме внутри нескольких серверов.
первоначально там средний объем данных лежал, была попытка использовать их очереди
но с ростом нагрузки перестала устраивать их производительность, в итоге он остался как кластерный кеш сессий и хранилище конфигурации.
вы еще думаете? =)
вообще хазелкаст по разработке похож на wine: в каждой новой версии пофисили старые баги, добавили новые.
а если без шуток: в 3.1 висит баг на утечку ресурсов который пофиксили в 3.2, но в 3.2 добавили новую утечку которую пофиксили только в 3.3 (в 3.2 портировать не собираются фикс). вот сидим думаем добавили ли что в 3.3 =)
постоянная сериализация-десериализация тоже немного напрягает:
1) выбираем формат хранения object
2) делаем put — объект сериализуется в формат data, передается в хранилище, там десериализуется в object
3) делаем get — запрос уходит в хранилище, там он сериализуется в data, на выходе десериализуем обратно в object
вопрос: в чем профит относительно хранения в Data? а хез его знает, так как на практике даже медленней выходит, может для query и подойдет в некоторых случаях.
другой пример: выбор по префиксу, заявляют как хорошую query (формат репозитория binary), на практике все скатывается к
1) запрос ушел на партишены
2) десериализовали ключи и значения, apply на ключи и если проходит, то emit ключ-значение
3) которые для возврата обратно сериализуем в data, а на выходе еще раз десериализуем
для меня непонятно, зачем гонять значение через сериализаторы по 100 раз?
в общем, чем плотнее сталкиваешься с его работой, а соответственно заглядываешь в код, тем меньше хочется его использовать.
1) правильно, помучались немного и решили, что овчинка не стоит выделки.
2) вот это в данный момент и обсуждается, причем нужно сделать так, чтобы не поломать совместимость со всем существующим кодом (это вам не c# где можно все взять и поломать, пользователи спокойно проглотят, для stream api в 8ке даже придумали default methods).
хочется быстрее? так никто не мешает принять участие в дискуссии КАК это должно быть сделано или помочь РЕАЛИЗОВАТЬ.
p.s. может я и ошибаюсь, но считаю что любой кто следит за разработкой именно платформы, видит куда все движется и что движение последнее время активизировалось. indy из 7й jvm более ограничен чем он же в 8й, так как в 7й его активно уже начал использовать ruby и дал хороший feedback, что нужно чтобы работало быстро. Похожий подход пытается применяться везде, так как после того как уйдет в люди, что-то менять будет уже очень сложно, а местами и невозможно.
The key limitation for the moment is that Scala programs cannot use libraries in .Net that are compiled using CLR generics, such as the .Net collections. However, for this particular example that's a minor limitation as the much better Scala collections library would be the natural developer choice anyway. Just to be clear: it's only CLR generics that are not implemented in the Scala.Net compiler, all the Scala features (including Scala generics) are available to the programmer. The .Net generics will be supported in the fall.
The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system… Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala. On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime. (David Pollak, ему то хоть немного можно верить)
в пределах jvm за счет erasure нет разницы в каком из jvm языков использовать скала коллекции, так же верна и обратная вещь.
erasure дает как плюсы, так и минусы, но без него работа с типами требует больше накладных расходов, особенно когда вы не замыкаетесь только на своем языке.
да, чуть не забыл, еще не анонсированны какие-либо наработки из graal, из наиболее интересных это работа с gpu (генерация как opencl кода, так и ptx, ну и единый jit для пачки архитектур, причем написанный на java) и Truffle
отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.
поддержка примитивных типов в дженериках — в контексте Value Types возможно частично будет сделано, так как обсуждение идет, отдельно еще тестируют в www.infoq.com/news/2014/07/Project-Valhalla
Continuations/легковесные потоки — для первого придется заниматься перебрасыванием стека (что сразу усложняет ещё и jit), для второго тянуть еще и свой шедулер в jvm
Почему по первым JEP которые войдут в 9ку делается вывод о том, что там будет, а чего не будет?
Никто же не пытается по первым строкам кода говорить «какой говняный релиз вы делаете, ни нормальной админки, ни ui, а уж производительность вообще печальна»
знаю его, пользовался, вот только иногда он тааааакой пакет сгенерит, что проще самому спек файл написать
да и более надежно это, так как между версиями в большинстве случаев достаточно будет поменять пару строк
>> Вы пробовали сделать DWH, хотя бы для хранения на базе хадупа?
пробовал, делал, крутится в проде и каши не просит, вот только постоянно приходится объяснять что он может, а что не стоит пытаться делать, результат получишь, но завтра.
>> У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске.
ну что же, когда я его усиленно ковырал умел только в памяти держать, но не одновременно и память-диск.
>> Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
Вы бы знали насколько я с вами согласен, особенно по поводу итеративных алгоритмов. Жаль что большинству это приходится объяснять на пальцах и примерах спускаясь в дебри реализаций.
>> MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP.
то есть мы скатываемся к тому, что судим MPP или не-MPP по умению работы с диском.
в том контексте в которых используют импалу и хадуп (обычные реляционки не справляются, вкладывать миллионы в терадату и тд желания нету) эти ограничения учитываются и не мешают сильно жить.
>> Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Неймнода всегда имеет полную картину где и что лежит. Это не хранится в метаданных в файле, там только структура каталогов и id элементов, но хранится в памяти после поднятия всего кластера (когда датаноды отрапортуют об поднятии). Если бы неймнода не имела этой картины, то не было бы возможности считать произвольный файл в произвольный момент времени. Граничный случаи: нода вывалилась и мы клиенту отдаем токен на чтение с этой ноды, клиент обвалился.
Кеширование метаданных демоном импалы ставит совсем другие задачи:
1) разгрузка namenode от лишних запросов
2) (более критичная) имея полную картину распределения блоков можно построить более оптимальный physical plan запроса. можно конечно каждый раз вытягивать данные на каждом запросе, но тогда встает пункт 1, что отписал.
>> еще одна уникальная возможность выстрелить себе в ногу
не понял посыла, файлы неизменяемы (хотя append местами портит эту картину), поэтому кеширование не проблема, только ускорит чтение с медленных дисков. точно так же импала кеширует не только метаданные, но и hdfs блоки целиком.
>> сервера с 126-256 ГБ памяти стоят не дешево
www.itcreations.com/show-server.asp?s=3613
Product Details: DELL POWEREDGE R910 SERVER 4 X INTEL 8C X7560 2.26GHZ 256GB RAM 4 X 146GB SAS HARD DRIVE
8319.00$, не скажу что сильно бюджетно, но и назвать сильно дорогой ее тоже нельзя.
десяток таких серверов + свичи + обвязка обойдется менее чем в 100к
на выходе будем иметь 2,5ТБ памяти.
память нынче достаточно дешевая, чтобы суммарно на кластер иметь не один терабайт.
>> Пока что не понимаю идею сравнивать in-memory DB и MMP систему Импала (по словам её авторов)
MemSQL’s distributed in-memory data management platform utilizes in-memory data storage and a distributed, shared-nothing massively parallel (MPP) processing architecture to drive performance.
>> Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
мысль была в том, что чем меньше мы делаем сбросов на диск данных и последующих чтений, тем быстрее оказывается результат. именно поэтому сейчас у многих в моде spark (как замена mr, тут все понятно) / shark (запуск hive на spark, за счет того что все в памяти показывают хороший результат).
стоимость самых дешевых узлов терадаты можно узнать? импала как и хадуп решает задачу на доступном железе, на котором диски являются самым узким местом системы. А за стоимость Терадата/Экзадата можно поднять кластер не с одним десятком терабайт памяти, поэтому для разных задач и финансовых возможностей разные инструменты.
>> Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки.
на старте (чтобы собрать карту, где и что сейчас валяется, мало ли некоторые машинки не поднялись) и периодически дельту (мало ли диск вылетел, блоки покараптились или еще чего), чтобы гарантировать отсутствие рассинхронизации. любое выделение блока проходит через неймноду — запрашиваем у нее разрешение на запись, она возвращает id и токет с указанием datanode куда мы будем писать. Чтение в обратном порядке: запросили у нее по файлу id и токены с адресами откуда читать. fsck потому и проходит быстро, что он работает только с метаданными, проверяется уровень консистентности и все ли блоки присутсвуют в данный момент, конечно если у вас в этот момент вылетела нода, но мы исключим ее информацию с задержкой, т.е. когда посчитаем что ее уже нету или она не вернется и не пришлет новые данные. Поэтому к namenode и были такие требования по условиям хранения информации в памяти: все дерево каталогов и карта блоков хранится в памяти, и если у вас много больших файлов, то стоит увеличить у тех файлов blocksize для снижения потребления памяти.
>> костыль, проще говоря.
да, костыль решающий текущие задачи в текущих условиях, в следующих версиях по мере расширения api для namenode костыль скорее всего уберется.
чем джойн через диск отличается от join в памяти?
скоростью работы и ограничением на объем.
И я считаю это хорошо, что она не пытается лезть на диск, так как работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе. А распределенный join она и так умеет, следовательно размером памати одной ноды мы не ограниченны.
(offtop: www.memsql.com/ заявляют что такие супер-отличные in-mem база данных, но на практике это шардинг, для join данные сливаются на ОДИН узел и если в память не влазят, то валится весь запрос, распределенного join нету, но ведь никто не говорит что они не база данных)
REFRESH, как по мне, является временным решением, так как при большом желании не проблема сделать доп слушателя к namenode и чекать любые изменения в положении блоков, но раз до сих пор это не сделали, то следовательно не сильно то и мешает.
если рассматривать базу данных с надеждой иметь update, то согласен что импала на нее не тянет.
если рассматривать как систему для выполнения sql и получения результатов, то очень даже вменяемая база данных.
p.s. с таким подходом любая база данных это нашлепка над блочным устройством
пишите, нет проблем,
но перечитайте мой комментарий: я просто хотел указать, что первоначальная фраза о том, что НАДО использовать для udf именно jython некорректна, правильно было бы указать о любом jvm языке.
надо было и указать, что Python хотели использовать, а то фраза «Для UDF используется Jython» вводит людей в заблуждение, что только на нем можно писать. Более корректно было бы «Для UDF используется любой JVM совместимый язык. Если нужны сторонние библиотеки, то необходимо написание дополнительных оберток или реализация нужного языка под JVM, например Jython для запуска Python скриптов, но это накладывает ограничения на разнообразие доступных библиотек»
я не отрицаю, что можно сделать, но пока у нас проблема была с get/put на хазелкасте, мы ее и решаем, когда от него останется только сборка кластера, тогда и будем думать как лучше выпиливать окончательно
с конфигурацией чуть сложнее, так как помимо всего мы используем discovery из hazelcast для прослушки, когда удаленный сервер добавляется или удаляется, с hbase такое сложно будет сделать, тут уже надо использовать zookeeper.
в общем процесс идет, пускай и не сильно быстро, но движется =)
«устраняем косяки по мере их появления», так как большую систему сложно вот так взять и переписать
одна nosql уже имеется (hbase), поэтому затягивать еще и couch как-то не хочется.
отдельно стоит отметить, что для couch еще нужно отдельно запускать процессы, что дополнительно усложняет инфраструктуру.
в общем как уже говорилось, сейчас осталось:
1) конфигурация кластера (где какие сервисы доступны)
2) хранение сесии, так как запрос может в процессе жизни пройтись по многим серверам, то имеем apache shiro и кеширование в hazelcast
пока справляется после написания N-го количества сериализаторов (до этого на некоторых структурах скатывался до java сериализатора, а так как кеширование класлоадера в hazelcast не было, то получали contention на класлоадере).
hazelcast.org/docs/latest/manual/html/customserialization.html
с текущей нагрузкой справляется, дальше пока думаем куда двигаться.
первоначально там средний объем данных лежал, была попытка использовать их очереди
но с ростом нагрузки перестала устраивать их производительность, в итоге он остался как кластерный кеш сессий и хранилище конфигурации.
Все остальное переделалось под p2p взаимодействие
вообще хазелкаст по разработке похож на wine: в каждой новой версии пофисили старые баги, добавили новые.
а если без шуток: в 3.1 висит баг на утечку ресурсов который пофиксили в 3.2, но в 3.2 добавили новую утечку которую пофиксили только в 3.3 (в 3.2 портировать не собираются фикс). вот сидим думаем добавили ли что в 3.3 =)
постоянная сериализация-десериализация тоже немного напрягает:
1) выбираем формат хранения object
2) делаем put — объект сериализуется в формат data, передается в хранилище, там десериализуется в object
3) делаем get — запрос уходит в хранилище, там он сериализуется в data, на выходе десериализуем обратно в object
вопрос: в чем профит относительно хранения в Data? а хез его знает, так как на практике даже медленней выходит, может для query и подойдет в некоторых случаях.
другой пример: выбор по префиксу, заявляют как хорошую query (формат репозитория binary), на практике все скатывается к
1) запрос ушел на партишены
2) десериализовали ключи и значения, apply на ключи и если проходит, то emit ключ-значение
3) которые для возврата обратно сериализуем в data, а на выходе еще раз десериализуем
для меня непонятно, зачем гонять значение через сериализаторы по 100 раз?
в общем, чем плотнее сталкиваешься с его работой, а соответственно заглядываешь в код, тем меньше хочется его использовать.
2) вот это в данный момент и обсуждается, причем нужно сделать так, чтобы не поломать совместимость со всем существующим кодом (это вам не c# где можно все взять и поломать, пользователи спокойно проглотят, для stream api в 8ке даже придумали default methods).
Из последнего:
cr.openjdk.java.net/~jrose/pres/201407-JVMEvolution.pdf
там половина ответов на ваши вопросы.
хочется быстрее? так никто не мешает принять участие в дискуссии КАК это должно быть сделано или помочь РЕАЛИЗОВАТЬ.
p.s. может я и ошибаюсь, но считаю что любой кто следит за разработкой именно платформы, видит куда все движется и что движение последнее время активизировалось. indy из 7й jvm более ограничен чем он же в 8й, так как в 7й его активно уже начал использовать ruby и дал хороший feedback, что нужно чтобы работало быстро. Похожий подход пытается применяться везде, так как после того как уйдет в люди, что-то менять будет уже очень сложно, а местами и невозможно.
The key limitation for the moment is that Scala programs cannot use libraries in .Net that are compiled using CLR generics, such as the .Net collections. However, for this particular example that's a minor limitation as the much better Scala collections library would be the natural developer choice anyway. Just to be clear: it's only CLR generics that are not implemented in the Scala.Net compiler, all the Scala features (including Scala generics) are available to the programmer. The .Net generics will be supported in the fall.
stackoverflow.com/questions/11607170/reified-generics-in-scala-on-net-clr
The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system… Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala. On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime. (David Pollak, ему то хоть немного можно верить)
в пределах jvm за счет erasure нет разницы в каком из jvm языков использовать скала коллекции, так же верна и обратная вещь.
erasure дает как плюсы, так и минусы, но без него работа с типами требует больше накладных расходов, особенно когда вы не замыкаетесь только на своем языке.
По поводу Manifest я знаю.
wiki.openjdk.java.net/display/Graal/Main
www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf
aosd.net/2014/sites/default/files/2014-04-24Graal_Modularity.pdf
openjdk.java.net/jeps/169
отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.
поддержка примитивных типов в дженериках — в контексте Value Types возможно частично будет сделано, так как обсуждение идет, отдельно еще тестируют в www.infoq.com/news/2014/07/Project-Valhalla
Continuations/легковесные потоки — для первого придется заниматься перебрасыванием стека (что сразу усложняет ещё и jit), для второго тянуть еще и свой шедулер в jvm
Почему по первым JEP которые войдут в 9ку делается вывод о том, что там будет, а чего не будет?
Никто же не пытается по первым строкам кода говорить «какой говняный релиз вы делаете, ни нормальной админки, ни ui, а уж производительность вообще печальна»
как коснется, то там оказывается исключений не меньше, а то и больше чем в русском =)
да и более надежно это, так как между версиями в большинстве случаев достаточно будет поменять пару строк
2) собрать пакет
3) через штатные средства поставить пакет
в итоге всегда видно где какие зависимости будут ломаться или файлы перетираться, да и откатить изменения тогда в разы проще
пробовал, делал, крутится в проде и каши не просит, вот только постоянно приходится объяснять что он может, а что не стоит пытаться делать, результат получишь, но завтра.
>> У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске.
ну что же, когда я его усиленно ковырал умел только в памяти держать, но не одновременно и память-диск.
>> Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
Вы бы знали насколько я с вами согласен, особенно по поводу итеративных алгоритмов. Жаль что большинству это приходится объяснять на пальцах и примерах спускаясь в дебри реализаций.
>> MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP.
то есть мы скатываемся к тому, что судим MPP или не-MPP по умению работы с диском.
в том контексте в которых используют импалу и хадуп (обычные реляционки не справляются, вкладывать миллионы в терадату и тд желания нету) эти ограничения учитываются и не мешают сильно жить.
>> Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Неймнода всегда имеет полную картину где и что лежит. Это не хранится в метаданных в файле, там только структура каталогов и id элементов, но хранится в памяти после поднятия всего кластера (когда датаноды отрапортуют об поднятии). Если бы неймнода не имела этой картины, то не было бы возможности считать произвольный файл в произвольный момент времени. Граничный случаи: нода вывалилась и мы клиенту отдаем токен на чтение с этой ноды, клиент обвалился.
Кеширование метаданных демоном импалы ставит совсем другие задачи:
1) разгрузка namenode от лишних запросов
2) (более критичная) имея полную картину распределения блоков можно построить более оптимальный physical plan запроса. можно конечно каждый раз вытягивать данные на каждом запросе, но тогда встает пункт 1, что отписал.
>> еще одна уникальная возможность выстрелить себе в ногу
не понял посыла, файлы неизменяемы (хотя append местами портит эту картину), поэтому кеширование не проблема, только ускорит чтение с медленных дисков. точно так же импала кеширует не только метаданные, но и hdfs блоки целиком.
>> сервера с 126-256 ГБ памяти стоят не дешево
www.itcreations.com/show-server.asp?s=3613
Product Details: DELL POWEREDGE R910 SERVER 4 X INTEL 8C X7560 2.26GHZ 256GB RAM 4 X 146GB SAS HARD DRIVE
8319.00$, не скажу что сильно бюджетно, но и назвать сильно дорогой ее тоже нельзя.
десяток таких серверов + свичи + обвязка обойдется менее чем в 100к
на выходе будем иметь 2,5ТБ памяти.
>> Пока что не понимаю идею сравнивать in-memory DB и MMP систему Импала (по словам её авторов)
MemSQL’s distributed in-memory data management platform utilizes in-memory data storage and a distributed, shared-nothing massively parallel (MPP) processing architecture to drive performance.
>> Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
мысль была в том, что чем меньше мы делаем сбросов на диск данных и последующих чтений, тем быстрее оказывается результат. именно поэтому сейчас у многих в моде spark (как замена mr, тут все понятно) / shark (запуск hive на spark, за счет того что все в памяти показывают хороший результат).
стоимость самых дешевых узлов терадаты можно узнать? импала как и хадуп решает задачу на доступном железе, на котором диски являются самым узким местом системы. А за стоимость Терадата/Экзадата можно поднять кластер не с одним десятком терабайт памяти, поэтому для разных задач и финансовых возможностей разные инструменты.
>> Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки.
на старте (чтобы собрать карту, где и что сейчас валяется, мало ли некоторые машинки не поднялись) и периодически дельту (мало ли диск вылетел, блоки покараптились или еще чего), чтобы гарантировать отсутствие рассинхронизации. любое выделение блока проходит через неймноду — запрашиваем у нее разрешение на запись, она возвращает id и токет с указанием datanode куда мы будем писать. Чтение в обратном порядке: запросили у нее по файлу id и токены с адресами откуда читать. fsck потому и проходит быстро, что он работает только с метаданными, проверяется уровень консистентности и все ли блоки присутсвуют в данный момент, конечно если у вас в этот момент вылетела нода, но мы исключим ее информацию с задержкой, т.е. когда посчитаем что ее уже нету или она не вернется и не пришлет новые данные. Поэтому к namenode и были такие требования по условиям хранения информации в памяти: все дерево каталогов и карта блоков хранится в памяти, и если у вас много больших файлов, то стоит увеличить у тех файлов blocksize для снижения потребления памяти.
>> костыль, проще говоря.
да, костыль решающий текущие задачи в текущих условиях, в следующих версиях по мере расширения api для namenode костыль скорее всего уберется.
скоростью работы и ограничением на объем.
И я считаю это хорошо, что она не пытается лезть на диск, так как работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе. А распределенный join она и так умеет, следовательно размером памати одной ноды мы не ограниченны.
(offtop: www.memsql.com/ заявляют что такие супер-отличные in-mem база данных, но на практике это шардинг, для join данные сливаются на ОДИН узел и если в память не влазят, то валится весь запрос, распределенного join нету, но ведь никто не говорит что они не база данных)
REFRESH, как по мне, является временным решением, так как при большом желании не проблема сделать доп слушателя к namenode и чекать любые изменения в положении блоков, но раз до сих пор это не сделали, то следовательно не сильно то и мешает.
если рассматривать как систему для выполнения sql и получения результатов, то очень даже вменяемая база данных.
p.s. с таким подходом любая база данных это нашлепка над блочным устройством
но перечитайте мой комментарий: я просто хотел указать, что первоначальная фраза о том, что НАДО использовать для udf именно jython некорректна, правильно было бы указать о любом jvm языке.
«учить hive и писать свои udf» нужно читать как «учить PIG и писать свои udf», так как с sql на hql перейти заметно проще