Ieri am văzut un domn de 80 de ani care nu purta niciun diagnostic, nu lua nicio pastilă. Îl priveam și, cumva, încercam să-mi dau seama care-i era secretul. Am mai mulți pacienți așa, care vin la controale de rutină, sunt 80+, arată ca niște floricele, mintea le e limpede, e o plăcere să-i am în fața mea.
Ce am văzut până acum:
- niciunul nu fumează;
- au făcut exerciții fizice și încă mai fac, fie că vorbim numai despre mersul pe jos, evident subestimat de mulți dintre noi;
- sunt foarte dinamici;
- au hobbiuri, domnul de ieri avea grijă de o grădină și o făcea cu pasiune;
- socializează;
- nu se consumă la toate nimicurile, domnul de ieri nu se gândea mai deloc la pseudofurtuna anunțată;
- mănâncă rațional, toți sunt normoponderali sau puțin peste limită, nimic exagerat, nici vorbă de obezitate;
- nu le au cu alcoolul, câțiva mai beau niște vin sau bere din când în când;
- i-am văzut pe mulți cu cărți la ei;
- starea nu le depinde neapărat de bani, domnul de ieri avea o situație modestă, dar era împăcat cumva cu ideea;
- se bucură de ce au;
- nu se proiectează în furtuni închipuite, trăind în calmul prezent;
- își mențin o relație frumoasă cu medicul și respectă recomandările acestuia;
- au o recunoștință aparte pentru toate lucrurile frumoase care li se întâmplă și cred că așa continuă să le atragă.
Mi-ar plăcea să-i studiez mai mult, să aflu mai multe din poveștile lor. Sunt convins că e și genetica la mijloc, dar la fel de convins sunt că ce am văzut în conduita lor contează enorm.

Vasi Radulescu


avro parquet

I think the main difference I can describe relates to record oriented vs. column oriented formats. Record oriented formats are what we're all used to -- text files, delimited formats like CSV, TSV. AVRO is slightly cooler than those because it can change schema over time, e.g. adding or removing columns from a record. Other tricks of various formats (especially including compression) involve whether a format can be split -- that is, can you read a block of records from anywhere in the dataset and still know it's schema? But here's more detail on columnar formats like Parquet.
Parquet, and other columnar formats handle a common Hadoop situation very efficiently. It is common to have tables (datasets) having many more columns than you would expect in a well-designed relational database -- a hundred or two hundred columns is not unusual. This is so because we often use Hadoop as a place to denormalize data from relational formats -- yes, you get lots of repeated values and many tables all flattened into a single one. But it becomes much easier to query since all the joins are worked out. There are other advantages such as retaining state-in-time data. So anyway it's common to have a boatload of columns in a table.
Let's say there are 132 columns, and some of them are really long text fields, each different column one following the other and use up maybe 10K per record.
While querying these tables is easy with SQL standpoint, it's common that you'll want to get some range of records based on only a few of those hundred-plus columns. For example, you might want all of the records in February and March for customers with sales > $500.
To do this in a row format the query would need to scan every record of the dataset. Read the first row, parse the record into fields (columns) and get the date and sales columns, include it in your result if it satisfies the condition. Repeat. If you have 10 years (120 months) of history, you're reading every single record just to find 2 of those months. Of course this is a great opportunity to use a partition on year and month, but even so, you're reading and parsing 10K of each record/row for those two months just to find whether the customer's sales are > $500.
In a columnar format, each column (field) of a record is stored with others of its kind, spread all over many different blocks on the disk -- columns for year together, columns for month together, columns for customer employee handbook (or other long text), and all the others that make those records so huge all in their own separate place on the disk, and of course columns for sales together. Well heck, date and months are numbers, and so are sales -- they are just a few bytes. Wouldn't it be great if we only had to read a few bytes for each record to determine which records matched our query? Columnar storage to the rescue!
Even without partitions, scanning the small fields needed to satisfy our query is super-fast -- they are all in order by record, and all the same size, so the disk seeks over much less data checking for included records. No need to read through that employee handbook and other long text fields -- just ignore them. So, by grouping columns with each other, instead of rows, you can almost always scan less data. Win!
But wait, it gets better. If your query only needed to know those values and a few more (let's say 10 of the 132 columns) and didn't care about that employee handbook column, once it had picked the right records to return, it would now only have to go back to the 10 columns it needed to render the results, ignoring the other 122 of the 132 in our dataset. Again, we skip a lot of reading.
(Note: for this reason, columnar formats are a lousy choice when doing straight transformations, for example, if you're joining all of two tables into one big(ger) result set that you're saving as a new table, the sources are going to get scanned completely anyway, so there's not a lot of benefit in read performance, and because columnar formats need to remember more about the where stuff is, they use more memory than a similar row format).
One more benefit of columnar: data is spread around. To get a single record, you can have 132 workers each read (and write) data from/to 132 different places on 132 blocks of data. Yay for parallelization!
And now for the clincher: compression algorithms work much better when it can find repeating patterns. You could compress AABBBBBBCCCCCCCCCCCCCCCC as 2A6B16C but ABCABCBCBCBCCCCCCCCCCCCCC wouldn't get as small (well, actually, in this case it would, but trust me :-) ). So once again, less reading. And writing too.
So we read a lot less data to answer common queries, it's potentially faster to read and write in parallel, and compression tends to work much better.
Columnar is great when your input side is large, and your output is a filtered subset: from big to little is great. Not as beneficial when the input and outputs are about the same.
But in our case, Impala took our old Hive queries that ran in 5, 10, 20 or 30 minutes, and finished most in a few seconds or a minute.
Hope this helps answer at least part of your question!





"Doi oameni de ştiinţă — Sherry Pagoto de la University of Massachusetts Medical School şi Bradley Appelhans de la Rush University Medical Center din Chicago — lansează un apel pentru încetarea aşa-numitelor „războaie ale dietelor”, pentru că toate sunt la fel de bune (sau rele) în a-i ajuta pe oameni în lupta contra kilogramelor în plus.
În cele din urmă, pacienţii devin confuzi şi ajung să creadă că o dietă este superioară celeilalte, când de fapt schimbările în stilul de viaţă, şi nu dietele, reprezintă singura metodă prin care putem preveni creşterea în greutate şi pericolele asociate, cum ar fi diabetul şi afecţiunile circulatorii."


Could not verify signing in resource

Doc ID 2289672.1

When attempting to launch JavaClient the following error occurs.

Could not verify signing in resource: http://xxxxxxxxx/JavaClient/lib/jagile/saaj.jar


Installed Java 8 Update 141


Possible incompatibility with the Java Client code with the security update made in JRE to 1.8.0_141.

WorkAround: Downgrade JRE to version 1.8.0_131 or lower version or Install 1.8.0_144