у вас странный опыт и более напоминает компиляцию предрассудков из эпохи map reduce.
если хотите дельный совет — почитайте книжку Била Инмона Data Lake Architecture: Designing the Data Lake and Avoiding the Garbage Dump
у него там описывается лейк — четкая противоположность вашим представлениям. особливо вокруг applications pond.
по большому счету сплошная ерунда в тексте. реально озера вполне себе конкурируют с DWH и все больше задач отгрызают у классики. у нас вот DWH уже просто зеркало реляционных табличек из озера и живо лишь потому что Impala жрет много памяти при большим кол-вое параллельных пользователей. при этом пресловутый GDPR именно облако делает. при этом писать в parquet вполе получается с avro схемой. а еще в последних версиях parquet (delta lake надстройка поверх parquet от датабриксов) и orc вполне и DELETE говорят что работают.
имхо там все не так. начиная с отсутствия базовых вещей, типа партиций и лога транзакций, заканчивая мутноватый бизнес на горемычных пользователях. с тем самым «нам довольно постоянно присылают БД на починку». по мне это некрасиво не сделать полноценный лог, но устроить бизнес на починках.
кроме этого у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения. без лога транзакций фб вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.
за ценами на лицензии не следил и про express не слышал. вроде не было такой редакции. у них еще можно скачать их сборку (полный дистрибутив) бесплатно, но с февраля они это закроют. скачать дистрибутив смогут лишь обладатели подписки. цены что-то около $6k за ноду в год. странновастая стратегия мягко говоря, учитывая рост облаков и возможность в пару кликов поднимать хадуп кластеры в облаках.
аффтор путает платформу хадупа с канторами-дистроклепателями. место малоизвестного mapr просто займет майкростофт с его mssql2019. в mssql2019 тот самый hadoop+spark пойдет в комплекте.
а клаудера вероятно тоже загнется с такими закидонами. они для проформы выкладывают в опенсорс свои продукты, а на деле позванивают клиентов и вымагают деньги на супорт. заявляют что хрен вы там бесплатно что-то без нас соберете.
у нас на кластере cloudera 5.x, там по дефолту спарк еще из первой ветки. на узлах кластера стоит parcel c 2.x веткой, а на машинках что имеют доступ к узлам кластера похоже не по ставили. т.е. надо или с админами договариваться или самому собирать ванильный, который тоже так просто не собрался.
и локально че-то не работает, зепелин коверкает похоже логи и даже не понять что у него не так
2019-10-17 08:48:30 INFO Client:54 - Setting up container launch context for our AM
2019-10-17 08:48:30 INFO Client:54 - Setting up the launch environment for our AM container
2019-10-17 08:48:30 INFO Client:54 - Preparing resources for our AM container
2019-10-17 08:48:32 WARN Client:66 - Neither spark.yarn.jars nor spark.yarn.archive is set, falling back to uploading libraries under SPARK_HOME.
2019-10-17 08:48:44 INFO Client:54 - Uploading resource file:/tmp/spark-e2b2fd0e-955d-43b7-a203-d86e7680b38a/__spark_libs__8513377897181943277.zip -> hdfs://censoredfs/user/censored/.sparkStaging/application_1570322815840_17054/__spark_libs__8513377897181943277.zip
at org.apache.zeppelin.interpreter.remote.RemoteInterpreterManagedProcess.start(RemoteInterpreterManagedProcess.java:205)
at org.apache.zeppelin.interpreter.ManagedInterpreterGroup.getOrCreateInterpreterProcess(ManagedInterpreterGroup.java:64)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getOrCreateInterpreterProcess(RemoteInterpreter.java:111)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.internal_create(RemoteInterpreter.java:164)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.open(RemoteInterpreter.java:132)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType(RemoteInterpreter.java:299)
at org.apache.zeppelin.notebook.Paragraph.jobRun(Paragraph.java:407)
at org.apache.zeppelin.scheduler.Job.run(Job.java:188)
at org.apache.zeppelin.scheduler.RemoteScheduler$JobRunner.run(RemoteScheduler.java:315)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
INFO [2019-10-17 08:49:25,755] ({pool-2-thread-2} VFSNotebookRepo.java[save]:196) - Saving note:2ERC9JRNE
INFO [2019-10-17 08:49:25,769] ({pool-2-thread-2} SchedulerFactory.java[jobFinished]:120) - Job 20191017-083503_1590331634 finished by scheduler org.apache.zeppelin.interpreter.remote.RemoteInterpreter-spark:shared_process-shared_session
INFO [2019-10-17 08:55:06,098] ({Exec Default Executor} RemoteInterpreterManagedProcess.java[onProcessComplete]:243) - Interpreter process exited 0
удобно наверно было бы запускать из идеи в режиме yarn-cluster, т.е. драйвер программа где-то там на кластере жить будет.
а нам бы пригодилось. по данным с кластера красивые отчетики прямо в родной среде вывести.
зепелин что бы поставить надо админов привлекать, ставить stb, открывать порты. сложно…
1) пока никто не знает
2) может и впереди на десятилетия, а может и позади. вся фишка в том что те кто собрал десятки кубитов экспериментируют на системах менее атома, где требуется по сути абсолютный ноль и полная изоляция квантовой системы от внешнего мира. вполне может быть они уже не смогут собрать стабильную систему более 100 кубитов. а вот «огромные» российские кубиты в 300 микрон позволят выйти на тысячи. а может и не позволят.
3) пока проверенных идей как изолировать квантовую систему от внешнего мира нет. потому все существующие системы работающие на экстремально низких температурах могут запросто быть тупиком.
To guarantee true serializability PostgreSQL uses predicate locking, which means that it keeps locks which allow it to determine when a write would have had an impact on the result of a previous read from a concurrent transaction, had it run first. In PostgreSQL these locks do not cause any blocking and therefore can not play any part in causing a deadlock. They are used to identify and flag dependencies among concurrent Serializable transactions which in certain combinations can lead to serialization anomalies.
ну так и неверно написано. все версионники кинут ошибку сериализации. исключение оракл, который не стал приносить в жертву здравый смысл и реализовал свой serializable, который не совсем честный, но подходит для того что бы считать деньги.
в теоретическом версионнике конечно. но не апдейт конфликт, а ошибка сеариализации. в оракле честного serializable нет, зато у постгреса вроде есть честный serializable, который обязан рубить все, что попробует выдать результат отличный от того что должен был бы получится от сериализованных транзакций.
но это все не столь важно. толку от честного и блокировочного serializable ноль, в реально жизни это просто не взлетает, а реально весь фин сектор сидит на оракле с его не совсем честным но полноценно работающим serializable, где нужно выставлять select for update на подобные чтения. практика показала, что это работает.
чувак прав. учи уровни изолированности. если используешь RC то чего ты вдруг от него требуешь согласованности? на IL serializable будет ошибка сериализации. блокировочник же на RC в принципе ничего не гарантирует, нет даже гарантии того что остаток счета не считается несколько раз.
сделали так, потому как ссср по сути не имел опыта в цифре и задачу выполнить не смог. спутники советского дизайна отработали пару лет не достигнув и близко необходимой точности. пришлось делать глонас-м, там 75-80% импортных комплектующих www.vestifinance.ru/articles/121277
моя предвзятость тут не причем. 75-80% суровый факт, следовательно от советских разработок ничего не оставили. так что не надо сюда притягивать советские достижения. их там попросту нет.
хлам собранный при ссср выбросили и развернули КА практически полностью на импортной комплектующих. ничего советского уже в спутниках первого поколения не было. там до сих пор добрая половина электроники — штаты.
Ну вот, хоть что-то полезное по ссылке вычитали. Вот только никакого отношения эта конвертация (которая и есть та самая эскалация) к описываемому случаю страничной блокировки не имеет.
не имеет и тебе доступно разжевал почему. уровни изоляции и эскалация абсолютно не пересекающиеся понятия. т.е. вот тут ты несешь дважды пургу
С каким-нибудь read committed, например, вы тут получите блокировку на странице данных
а вот тут трижды
Все-таки читать про блокировки. Подсказка для поиска: страничная блокировка при вставке в кучу без блокировки ключей.
в mysql нет страничных блокировок, при вставке ставится next-key lock только если есть ключи. но в моем примере нет ключей.
прежде чем нести пургу, хотя ознакомься хотя бы какие типы блокировок сущетсвуют в mysql.
матчасть я выучил 20 лет назад, 15 лет как сертифицированный ocp. так что дальнейшее разжевывание лишь за деньги. конвертация row level блокировки в page lock приводит блокировке посторонних строк, не имеющих отношения к транзакции. эскалация никакого отношения к уровням изолированности не имеет.
С каким-нибудь read committed, например, вы тут получите блокировку на странице данных
RC требует блокировать лишь необходимые транзакции строки. получить блокировку целой страницы можно исключительно в результате эскалации, которая к уровням изолированности транзакций параллельна.
ты путаешь эскалацию блокировок с уровнями изолированности. эскалация блокировок никакого отношения не имеет ни к уровням изолированности, ни к mysql. mysql утверждает что у него row level блокировки. но врут.
RC с row level блокировками не должен накладывать какие либо блокировки на данные, не имеющие никакого отношения к этой транзакции. то что на странице посторонние данные, не нужные транзакции не повод их блокировать.
чего не ясного? уровни изоляции описывают допустимые коллизии транзакций, обращающиеся к одним и тем же наборам данных. ключевое — одни и те же наборы, я же показываю что у mysql все на столько плохо, что коллизии возникают даже у транзакций, что обрабатывают разный набор данных. уровни изоляции тут не причем.
если хотите дельный совет — почитайте книжку Била Инмона Data Lake Architecture: Designing the Data Lake and Avoiding the Garbage Dump
у него там описывается лейк — четкая противоположность вашим представлениям. особливо вокруг applications pond.
кроме этого у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения. без лога транзакций фб вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.
а клаудера вероятно тоже загнется с такими закидонами. они для проформы выкладывают в опенсорс свои продукты, а на деле позванивают клиентов и вымагают деньги на супорт. заявляют что хрен вы там бесплатно что-то без нас соберете.
и локально че-то не работает, зепелин коверкает похоже логи и даже не понять что у него не так
2019-10-17 08:48:30 INFO Client:54 - Setting up container launch context for our AM
2019-10-17 08:48:30 INFO Client:54 - Setting up the launch environment for our AM container
2019-10-17 08:48:30 INFO Client:54 - Preparing resources for our AM container
2019-10-17 08:48:32 WARN Client:66 - Neither spark.yarn.jars nor spark.yarn.archive is set, falling back to uploading libraries under SPARK_HOME.
2019-10-17 08:48:44 INFO Client:54 - Uploading resource file:/tmp/spark-e2b2fd0e-955d-43b7-a203-d86e7680b38a/__spark_libs__8513377897181943277.zip -> hdfs://censoredfs/user/censored/.sparkStaging/application_1570322815840_17054/__spark_libs__8513377897181943277.zip
at org.apache.zeppelin.interpreter.remote.RemoteInterpreterManagedProcess.start(RemoteInterpreterManagedProcess.java:205)
at org.apache.zeppelin.interpreter.ManagedInterpreterGroup.getOrCreateInterpreterProcess(ManagedInterpreterGroup.java:64)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getOrCreateInterpreterProcess(RemoteInterpreter.java:111)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.internal_create(RemoteInterpreter.java:164)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.open(RemoteInterpreter.java:132)
at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType(RemoteInterpreter.java:299)
at org.apache.zeppelin.notebook.Paragraph.jobRun(Paragraph.java:407)
at org.apache.zeppelin.scheduler.Job.run(Job.java:188)
at org.apache.zeppelin.scheduler.RemoteScheduler$JobRunner.run(RemoteScheduler.java:315)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
INFO [2019-10-17 08:49:25,755] ({pool-2-thread-2} VFSNotebookRepo.java[save]:196) - Saving note:2ERC9JRNE
INFO [2019-10-17 08:49:25,769] ({pool-2-thread-2} SchedulerFactory.java[jobFinished]:120) - Job 20191017-083503_1590331634 finished by scheduler org.apache.zeppelin.interpreter.remote.RemoteInterpreter-spark:shared_process-shared_session
INFO [2019-10-17 08:55:06,098] ({Exec Default Executor} RemoteInterpreterManagedProcess.java[onProcessComplete]:243) - Interpreter process exited 0
удобно наверно было бы запускать из идеи в режиме yarn-cluster, т.е. драйвер программа где-то там на кластере жить будет.
зепелин что бы поставить надо админов привлекать, ставить stb, открывать порты. сложно…
2) может и впереди на десятилетия, а может и позади. вся фишка в том что те кто собрал десятки кубитов экспериментируют на системах менее атома, где требуется по сути абсолютный ноль и полная изоляция квантовой системы от внешнего мира. вполне может быть они уже не смогут собрать стабильную систему более 100 кубитов. а вот «огромные» российские кубиты в 300 микрон позволят выйти на тысячи. а может и не позволят.
3) пока проверенных идей как изолировать квантовую систему от внешнего мира нет. потому все существующие системы работающие на экстремально низких температурах могут запросто быть тупиком.
но это все не столь важно. толку от честного и блокировочного serializable ноль, в реально жизни это просто не взлетает, а реально весь фин сектор сидит на оракле с его не совсем честным но полноценно работающим serializable, где нужно выставлять select for update на подобные чтения. практика показала, что это работает.
www.vestifinance.ru/articles/121277
моя предвзятость тут не причем. 75-80% суровый факт, следовательно от советских разработок ничего не оставили. так что не надо сюда притягивать советские достижения. их там попросту нет.
не имеет и тебе доступно разжевал почему. уровни изоляции и эскалация абсолютно не пересекающиеся понятия. т.е. вот тут ты несешь дважды пургу
а вот тут трижды
в mysql нет страничных блокировок, при вставке ставится next-key lock только если есть ключи. но в моем примере нет ключей.
прежде чем нести пургу, хотя ознакомься хотя бы какие типы блокировок сущетсвуют в mysql.
RC требует блокировать лишь необходимые транзакции строки. получить блокировку целой страницы можно исключительно в результате эскалации, которая к уровням изолированности транзакций параллельна.
вы придется заслужить «пониманием базовой матчасти» (тм)
RC с row level блокировками не должен накладывать какие либо блокировки на данные, не имеющие никакого отношения к этой транзакции. то что на странице посторонние данные, не нужные транзакции не повод их блокировать.