-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
2067 lines (1962 loc) · 99.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<title>Trino</title>
<link rel="stylesheet" href="dist/reset.css">
<link rel="stylesheet" href="dist/reveal.css">
<link rel="stylesheet" href="dist/theme/black.css">
<link rel="stylesheet" href="dist/theme/custom.css" />
<!-- Theme used for syntax highlighted code -->
<link rel="stylesheet" href="plugin/highlight/monokai.css">
<style>
img.carita-r1-c1 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: 0px 0;
}
img.carita-r1-c2 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: -200px 0;
}
img.carita-r1-c3 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
border-style: hidden;
background-position: -400px 0;
}
img.carita-r2-c1 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: 0px -188px;
}
img.carita-r2-c2 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: -200px -188px;
}
img.carita-r2-c3 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: -400px -188px;
}
img.carita-r3-c1 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: 0px -376px;
}
img.carita-r3-c2 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: -200px -376px;
}
img.carita-r3-c3 {
background-image: url('/img/emojis.png');
background-repeat: no-repeat;
height: 130px;
width: 130px;
display: inline-block;
background-position: -400px -376px;
}
.fragment.current-visible.visible:not(.current-fragment) {
display: none;
height:0px;
line-height: 0px;
font-size: 0px;
}
</style>
</head>
<body>
<div class="reveal">
<div class="slides">
<section>
<h1><code>Trino</code></h1>
<img class="top framed" src="img/Trino_homepage.png" />
<div class="r-stack">
<p class="fragment fade-out" data-fragment-index="0">
<span class="red">Un breve vistazo a Trino</span>
</p>
<p class="fragment current-visible" data-fragment-index="0">
<span class="red">Un (no tan) breve vistazo a Trino</span>
</p>
</div>
<a class="fragment" style="font-size: 0.75em;" href="https://edatos.github.io/trino-istac/">https://edatos.github.io/trino-istac/.</a>
<aside class="notes">
<ol style="font-size: 0.75em;">
<li>Bienvenidos a todos. Gracias por asistir a esta charla sobre Trino, enmarcada dentro de la línea de sesiones técnicas que organiza habitualmente el ISTAC.</li>
<li>Para el registro, mi nombre es Miguel Núñez de la empresa Ecosistemas Virtuales y Modulares (EVM), soy informático y actualmente estoy desarrollando labores de soporte informático para el ISTAC.</li>
<li>La presentación está disponible en la url que les paso por el chat (https://m-nunez.github.io/trino-istac/)</li>
<li>Quiero aclarar que no soy un experto en Trino. Esta es mi primera toma de contacto, y la intención es compartir con ustedes mis descubrimientos.</li>
<li>Intentaré no aburrir demasiado. Si lo desean, me pueden interrumpir en cualquier momento.</li>
</ol>
</aside>
</section>
<!-- INTRODUCCION -->
<section>
<h3>Índice</h3>
<ol>
<li class="fragment highlight-red">Introducción y conceptos básicos</li>
<li>Funcionalidades</li>
<li>Instalación y configuración</li>
<li>Pruebas realizadas</li>
<li>Conclusiones</li>
</ol>
<aside class="notes">
<div style="font-size: 0.75em;">
<p>Empezaremos por dar una breve introducción para saber de qué vamos a hablar.</p>
<p>Veremos unos conceptos teóricos básicos sobre la materia.</p>
<p>Luego pasaremos a detallar las principales funcionalidades de Trino.</p>
<p>También explicaremos cómo se instala Trino y unas notas sobre su configuración.</p>
<p>Mostraremos algunas pruebas que se han realizado.</p>
<p>Y acabaremos con las conclusiones que he extraído.</p>
</div>
</aside>
</section>
<section>
<h2>Introducción y conceptos básicos</h2>
</section>
<section>
<h4>¿Qué es Trino?</h4>
<ul>
<li class="fragment" _data-fragment-index="1">Es un motor SQL distribuido ideado para trabajar con grandes volúmenes de datos de una gran variedad de sistemas de datos.</li>
<li class="fragment" _data-fragment-index="2">Desarrollado en Java (soporta Openjava). Tecnología madura y fiable.</li>
<li class="fragment" _data-fragment-index="2">Diseñado para un rendimiento óptimo y escalable.</li>
<li class="fragment" _data-fragment-index="3" style="color:red">No es una base de datos: no almacena datos.</li>
</ul>
<aside class="notes">
<div style="font-size: 0.75em;">
<p>Características:</p>
<ol>
<li>Por diseño, se evita la copia innecesaria de datos y se maximiza el paralelismo.</li>
<li>Preparado para Big Data, Machine Learning y AI.</li>
<li>Diseñado para gestionar eficientemente consultar grandes cantidades de datos mediante queries distribuidas y para análisis de datos (OLAP, OnLine Analytical Processing).</li>
</ol>
</div>
</aside>
</section>
<section>
<h4>¿Por qué usar Trino?</h4>
<div class="r-stack">
<div class="blk-full">
<ul>
<li class="fragment">Velocidad</li>
<li class="fragment">Escalado</li>
<li class="fragment">Simplicidad</li>
<li class="fragment">Versatilidad</li>
<li class="fragment">Análisis in-situ</li>
<li class="fragment">Query federation</li>
<li class="fragment">Funciona en cualquier lugar</li>
<li class="fragment">Confiable</li>
<li class="fragment">Abierto</li>
</ul>
</div>
<img class="top framed fragment" src="img/memes/suatmm.gif" />
</div>
<aside class="notes">
<ol style="font-size: 0.75em;">
<li><b>Velocidad</b>: El procesador SQL tiene un alto nivel de paralelismo y ejecución distribuida.</li>
<li><b>Escalado</b>: Trabaja con los mayores bancos de datos</li>
<li><b>Simplicidad</b>: SQL ANSI que funciona con las herramientas BI más famosas (R, Tableau, Power BI, Superset, etc.).</li>
<li><b>Versatilidad</b>: Queries analíticas interactivas, queries batch masivas y apps que hacen consultas sobre grandes conjuntos de datos.</li>
<li><b>Análisis in-situ</b>: No es necesario copiar los datos a bases de datos secundarias para realizar estas consultas.</li>
<li><b>Query federation</b>: Accede a datos de múltiples fuentes en una única query.</li>
<li><b>Funciona en cualquier lugar</b>: Disponible on-premise y en entornos cloud (Amazon, Azure, Google Cloud, etc).</li>
<li><b>Confiable</b>: Usado en operaciones críticas a lo largo de todo el mundo.</li>
<li><b>Abierto</b>: Es un projecto open-source de la fundación Trino Software Foundation.</li>
</ol>
</aside>
</section>
<section>
<h4>Historia</h4>
<ul>
<li><span>Proyecto Presto en Facebook en 2012.</span></li>
<li><span>En 2013 se liberó con licencia Apache.</span></li>
<li><span>La versión más reciente es la v380 (6/5/22).</span></li>
</ul>
<aside class="notes">
<ol style="font-size: 0.75em;">
<li>Comenzó siendo el proyecto Presto en Facebook en 2012 por cuatro desarrolladores (Martin Traverso, Dain Sundstrom, David Phillips y Eric Hwang) como alternativa al lento Hive (curiosamente Trino cuenta con un conector Hive que sólo reemplaza el componente SQL HiveQL) usado sobre Hadoop (HDFS) para permitir a los analistas de datos lanzar consultas interactivas sobre los ingentes datos de Facebook (300 PB).</li>
<li>En 2013 se liberó con licencia Apache, en 2019 se creó la fundación Presto Software Foundation y a finales de 2020 se renombró como Trino.</li>
<li>Actualmente es un proyecto Opensource muy activo, respaldado por la compañía Starburst.</li>
</ol>
</aside>
</section>
<section>
<h4>¿Quién usa Trino?</h4>
<img class="w70" src="img/Trino-usuarios.png" />
<aside class="notes">
<ol style="font-size: 0.75em;">
<li>En su desarrollo hay involucrada gente de muchas compañías: Amazon, Bloomberg, Eventbrite, Gett, Google, Line, LinkedIn, Lyft, Netflix, Pinterest, Qubole, Red Hat, Salesforce, Shopify, Starburst, Treasure Data, Varada, Zuora, etc.</li>
<li>Algunas empresas que usan Trino: AWS, LinkedIn, NTT Communications, DiDi… (muchas del tercer mundo).</li>
</ol>
</aside>
</section>
<section>
<h4>Conceptos básicos - I</h4>
<p>Arquitectura del sistema</p>
<ul>
<li class="fragment">
<p>Trino es un sistema en cluster.</p>
<div class="fragment">
<p>Tipos de nodos:</p>
<ol>
<li>Coordinator<span class="fragment">: El cerebro...</span></li>
<li>Worker<span class="fragment">: El currito...</span></li>
</ol>
</div>
</li>
</ul>
<aside class="notes">
<ul style="font-size: 0.75em;">
<li>Aunque puede ejecutarse en un único servidor, Trino está pensado para funcionar en modo cluster.</li>
<li> Existen con los siguientes tipos de nodos:
<ol>
<li><strong>Coordinator</strong>: Es el cerebro del sistema, parsea las queries, las planifica y se encarga del control de los nodos workers. Este nodo recoge los resultados desde los nodos workers y devolver al cliente la respuesta final. Debe existir al menos uno aunque puede haber varios.</li>
<li><strong>Worker</strong>: Es responsable de llevar a cabo las tareas asignadas por el nodo coordinador, recogiendo los datos desde los connectors e intercambiadolos con otros nodos workers. Puede haber uno o más nodos workers que se registrarán durante su arranque en el nodo coordinador.</li>
</ol>
</li>
<li>Los nodos se comunican entre sí mediante REST API.</li>
</ul>
</aside>
</section>
<section>
<h4>Conceptos básicos - I</h4>
<img class="top framed" src="img/Trino_architecture.png" />
</section>
<section>
<section>
<h4>Conceptos básicos - II</h4>
<p>En relación a los datos</p>
<ol start="1">
<li class="fragment"><strong>Connector</strong>: Interfaz a sistemas de datos.</li>
<li class="fragment"><strong>Catalog</strong>: Metadatos de las fuentes de datos.</li>
<li class="fragment"><strong>Schema</strong>: Organización de las tablas de datos.</li>
<li class="fragment"><strong>Table</strong>: Grupo de registros.</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.75em;">
<li><strong>Connector</strong>: Hace las veces de interfaz entre un determinado sistema de datos y Trino permitiendo un manejo estandarizado. Se implementan siguiendo un modelo extensible Java SPI (Service Provider Interface). Trino viene con muchos conectores preinstalados: JMX, System, Hive, TPCH, etc.</li>
<li><strong>Catalog</strong>: Está asociado a una determinada fuente de datos y contiene la información sobre los esquemas. En el fichero de configuración de cada catalog, se indica el connector a usar mediante la propiedad connector.name. El nombre del catalog se usa como raíz de los nombres completos de los elementos como tablas, índices, etc.</li>
<li><strong>Schema</strong>: Junto con los catalogs, es una forma de organizar las tablas de datos. En las BBDD relacionales, se corresponden con los esquemas de éstas pero en otro tipo de BBDD pueden seguir otras estrategias.</li>
<li><strong>Table</strong>: Es un grupo de registros desordenados, estructurados en columnas con sus respectivos tipos. En las BBDD relacionales, se corresponden con las tablas de éstas pero en otro tipo de BBDD pueden seguir otras estrategias.</li>
</ol>
</aside>
</section>
<section>
<p style="font-size: 0.65em;">Comparativa entre distintos sistemas</p>
<img class="top framed" src="img/Trino-containment-hierarchy.png" />
<aside class="notes">
<ol style="font-size: 0.75em;">
<li><strong>Mongo</strong>: Ejemplo de base de datos NoSQL orientada a objetos donde cada objeto se almacena como un documento separado.</li>
<li><strong>Apache Pinot</strong>: Es un ejemplo de base de datos columnar con almacenamiento distribuido.</li>
<li><strong>MySQL</strong>: Ejemplo de base de datos relacional (RDBMS) propiedad de Oracle.</li>
<li><strong>Elasticsearch</strong>: Es una base de datos NoSQL orienta a objetos de tipo pares clave-valor.</li>
</ol>
</aside>
</section>
</section>
<section>
<section>
<h4>Conceptos básicos - III</h4>
<p>En relación al modelo de ejecución</p>
<ol start="1">
<li class="fragment"><strong>Statement</strong>: El comando SQL</li>
<li class="fragment"><strong>Query</strong>: Colección de objetos</li>
<li class="fragment"><strong>Stage</strong>: Pasos</li>
<li class="fragment"><strong>Task</strong>: Tarea</li>
<li class="fragment"><strong>Driver</strong>: Subtareas</li>
<li class="fragment"><strong>Operator</strong>: Operadores</li>
<li class="fragment"><strong>Otros</strong>: Exchange, Split</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.65em;">
<li><strong>Statement</strong>: son las instrucciones SQL-ANSI que admite el Trino, tal y como se reciben del cliente.</li>
<li><strong>Query</strong>: Es una colección de stages, tasks, splits, connectors y otros elementos trabajando sobre un conjunto de fuentes de datos para producir un resultado. Se crea al parsear un statement, generandose un plan de ejecución distribuida que se llevará a cabo mediante una serie de stages interconectados.</li>
<li><strong>Stage</strong>: Son los diferentes pasos organizados jerárquicamente (árbol) en que se descompone una query, formando el plan de ejecución distribuida. Cada stage recoge los resultados de sus descendientes directos y los pasa a su ancestro. Los stage se ejecutan en paralelo en el nodo coordinador y generan una serie de tasks que se distribuyen en la red de nodos workers.</li>
<li><strong>Task</strong>: Son procesos que toman entradas y generan salidas. Igual que las stages, pueden ser ejecutados en paralelo.</li>
<li><strong>Driver</strong>: Las tasks se descomponen en múltiples drivers que procesan en paralelo datos en memoria usando operators. Son los componentes que más abajo están en el planning de la query.</li>
<li><strong>Operator</strong>: Consume y transforma datos. Algunos operators recuperan datos de un conector, otros filtran datos según un predicado, etc.</li>
<li><strong>Otros</strong>:
<ul>
<li><strong>Exchange</strong>: Se encargan de mover los datos de un buffer a otro de las distintas tasks.</li>
<li><strong>Split</strong>: Son las secciones, de un conjunto de datos más extenso, que son recuperados desde un connector (nivel más bajo del planning de la query) o desde stages.</li>
</ul>
</li>
</ol>
</aside>
</section>
<section>
<img class="top framed" src="img/pantallazos/p007.png" />
</section>
</section>
<!-- FUNCIONALIDADES -->
<section>
<h3>Índice</h3>
<ol>
<li>Introducción y conceptos básicos</li>
<li style="color: red">Funcionalidades</li>
<li>Instalación y configuración</li>
<li>Pruebas realizadas</li>
<li>Conclusiones</li>
</ol>
</section>
<section>
<section>
<h4>Funcionalidades - I</h4>
<ol start="1">
<li class="fragment">Web UI</li>
</ol>
</br>
<ul class="fragment" style="font-size: 0.65em;">
<li class="fragment">Es la interfaz de usuario que permite monitorizar el cluster de nodos y manejar las queries.</li>
<li class="fragment">Puede hacerse un seguimiento de su ejecución y detalles de las queries.</li>
<li class="fragment">No permite lanzar queries</li>
<li class="fragment">No muestra los datos resultantes</li>
</ul>
<aside class="notes">
<div style="font-size: 0.75em;">
<ul>
<li>No se puede:
<ul>
<li>Bloquear el Web UI para un usuario determinado.</li>
</ul>
</i>
<li>Se puede:
<ul>
<li>Desactivar completamente el Web UI.</li>
<li>Fijar el usuario del Web UI de forma que no se necesite introducir credenciales.<br/>
Se puede controlar los accesos de este usuario mediante la configuración.</li>
<li>Por defecto, todos los usuarios ven las queries de todos. Se puede modificar este comportamiento en la configuración.</li>
</ul>
</i>
</ul>
<p>No permite bloquear el acceso a un usuario concreto al interfaz web.</p>
</div>
</aside>
</section>
<section>
<!-- Imagen #1 -->
<img class="top framed" src="img/pantallazos/p003.png" />
</section>
<section>
<!-- Imagen #2 -->
<img class="top framed" src="img/pantallazos/p001.png" />
</section>
<section>
<!-- Imagen #3 -->
<img class="top framed" src="img/pantallazos/p004.png" />
</section>
<section>
<!-- Imagen #4 -->
<img class="top framed" src="img/pantallazos/p005.png" />
</section>
<section>
<!-- Imagen #5 -->
<img class="top framed" src="img/pantallazos/p006.png" />
</section>
<section>
<img class="top framed" src="img/pantallazos/p011.png" />
</section>
<section>
<img class="top framed" src="img/pantallazos/p009.png" />
</section>
</section>
<section>
<h4>Funcionalidades - II</h4>
<ol start="2">
<li class="fragment"><b>Autenticación de usuarios</b></li>
<li class="fragment"><b>Autorización de usuarios</b></li>
<li class="fragment"><b>Clientes: Trino CLI, Trino Web UI y librerías para intergrar en aplicaciones.</b></li>
<li class="fragment"><b>Comunicaciones seguras</b></li>
<li class="fragment"><b>Extensible</b></li>
</ol>
<aside class="notes">
<ol style="font-size: 0.75em;">
<li><b>Autenticación</b>: Password file, LDAP, Salesforce, OAuth 2.0, Certificate, JSON Web Token (JWT) y Kerberos.</li>
<li><b>Tip</b>: Permite la autenticación LDAP sobre múltiples ramas del DA. Permite autorización de acceso en función de membresías a grupos del DA (y posiblemente otras expresiones LDAP).</li>
<li>El interface con el usuario es mínimo por lo que no requiere más sistemas de autenticación.</li>
<li><b>Autorización</b>: Se puede controlar el acceso de los usuarios a los recursos de forma muy selectiva. Permite agrupar a los usuarios para facilitar la gestión de los permisos.</li>
<li><b>Clientes</b>: Trino JDBC driver for Java/JVM, Starburst ODBC driver for Windows, trino-go-client for Go, presto-client-node for Node.js, lento for Node.js, dbt adapter, trino-python-client for Python, PyHive for Python, RPresto for R, trino-client-ruby for Ruby.</li>
<li><b>Seguridad</b>: Es posible securizar con TLS las conexiones entre los nodos y con los clientes. El nodo coordinador dispone de un interfaz web HTTP que permite lanzar queries y muchas otras operaciones. El cliente JDBC usa internamente este interfaz.</li>
<li><b>Extensible</b>: Altamente adaptable. Dispone de SPI (Service Provider Interface, tecnología java) para modificar controladores, extender o agregar distintos componentes software. También se puede señalizar eventos a herramientas externas mediante llamadas HTTP/S POST con información en JSON.</li>
</ol>
</aside>
</section>
<section>
<section>
<h4>Funcionalidades - III</h4>
<ol start="7">
<li class="fragment"><b>Quotas sobre los recursos</b></li>
<li class="fragment"><b>Lenguaje SQL potente</b></li>
<li class="fragment"><b>Connectors preinstalados</b>
<ul class="fragment fade-in-then-out" style="font-size: 0.65em;">
<li>TPCDS</li>
<li>TPCH</li>
<li>JMX</li>
<li>SYSTEM</li>
<li>MEMORY</li>
<li>BLACK HOLE</li>
<li><b>...</b></li>
</ul>
</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.55em;">
<li><b>Quotas</b>: Se pueden poner quotas al uso de recursos. Se encolan queries en función de la disponibilidad de recursos.</li>
<li><b>SQL</b>: Dispone de una cantidad importante (723) de funciones SQL incluídas propias de todo tipo (manejo de arrays, geospaciales, de soporte de dialectos SQL específicos como Teradata SQL, de información del sistema, machine learning, etc.).</li>
<li><b>Connectors</b>:
<ul>
<li><b>TPCDS</b>: (TPC Benmark DS) conector de sólo lectura para realizar pruebas de rendimiento estandarizadas.</li>
<li><b>TPCH</b>: (TPC Benmark H) conector de sólo lectura para realizar pruebas de rendimiento estandarizadas.</li>
<li><b>JMX</b>: conector de sólo lectura para una fácil monitorización avanzada del sistema completo mediante métricas JMX (Java Management) usando utilidades (jconsole, VisualVM, etc.) así como con queries SQL.</br>
Expone datos históricos, agregados y actuales y puede desactivarse y/o controlarse el acceso usando reglas sobre el catálogo jmx.</br>
Con SQL, se puede consultar las métricas actuales usando el schema <i>current</i> (por ejemplo, el número de ficheros abiertos en cada nodo SELECT openfiledescriptorcount FROM jmx.current."java.lang:type=operatingsystem";) ó consultar historiales almacenados en memoria usando el schema <i>history</i> de aquellas métricas que se hayan configurado en las propiedades del catálogo (fichero <i>jmx.properties</i>).</li>
<li><b>SYSTEM</b>: conector de sólo lectura para obtener distinta información y métricas del sistema mediante queries SQL.</li>
<li><b>MEMORY</b>: conector de escritura limitada (básicamente sólo se permite la insersión y el borrado completo de tablas).</br>Es un conector especial que reside en la memoria RAM de los nodos workers y que sirve para acelerar queries, almacenando temporalmente datos traídos desde fuentes externas.</br>El contenido de este conector se pierde al reiniciar Trino.</li>
<li><b>BLACK HOLE</b>: Similar al dispositivo /dev/null de Linux, todo lo que se manda allí desaparece.</br>Útil para hacer pruebas de rendimiento.</li>
<li><b>Otros</b>: Y muchísimos más...</li>
</ul>
</li>
</ol>
</aside>
</section>
<section>
<h4>Ejemplo - Consulta de métrica</h4>
<p style="font-size: 0.65em;">Número de ficheros abiertos en cada nodo</p>
<pre><code data-trim data-noescape style="font-size: 0.6em;">
trino> SELECT openfiledescriptorcount FROM jmx.current."java.lang:type=operatingsystem";
ERROR: failed to open pager: Cannot run program "less": CreateProcess error=2, El sistema no puede encontrar el archivo especificado
openfiledescriptorcount
-------------------------
2929
2928
2989
2933
(4 rows)
Query 20220519_002644_00001_7jb7m, FINISHED, 4 nodes
Splits: 6 total, 6 done (100,00%)
4,50 [4 rows, 32B] [0 rows/s, 7B/s]
</code></pre>
</section>
</section>
<section>
<section>
<h4>Funcionalidades - IV</h4>
<ol start="10" style="font-size: 0.75em;">
<li class="fragment"><strong>SQL-on-Anything</strong>: SQL para todo.
<ul style="font-size: 0.65em;">
<li>TPCDS</li>
<li>TPCH</li>
<li>JMX</li>
<li>SYSTEM</li>
<li>MEMORY</li>
<li>BLACK HOLE</li>
<li><b>...</b></li>
</ul>
</li>
<li class="fragment"><strong>Federated Query</strong>: Queries sobre varias fuentes de datos.</li>
<li class="fragment"><strong>Virtual Data Warehouse</strong>: Almacenamiento homogéneo.</li>
<li class="fragment"><strong>Procesamiento/Almacenamiento</strong>: Aisla los recursos usados por las queries de los usados por el almacenamiento.</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.65em;">
<li><strong>SQL-on-Anything</strong>: Provee acceso usando un SQL estandarizado a muchos tipos de sistemas de datos: Distributed Object Storage, RDBMS, NoSQL, etc. Evitando las ETLs para cargar en sistemas intermedios.</li>
<li><strong>Federated Query</strong>: Soporta queries que referencien distintas fuentes de datos en un sólo comando.</li>
<li><strong>Virtual Data Warehouse</strong>: Muestra un almacenamiento de datos uniforme, ocultando las particularidades de cada uno de los sistemas que contienen los datos reales. Soporta el uso de sistemas de datos masivos en la nube (raw Data Lakes como HDFS y AWS S3). Amazon ha usado Presto en su Amazon Athena para que los usuarios puedan hacer consultas SQL interactivas sobre su sistema de datos Amazon S3.</li>
<li><strong>Procesamiento/Almacenamiento</strong>: Separa los recursos de almacenamiento de datos de los de procesado de queries, permitiendo un escalado más fácil. Se puede escalar el almacenamiento cuando sea necesario sin necesidad de cambiar los recursos usados en el procesado de las queries. Igualmente, se puede incrementar los recursos de procesado cuando las queries se vayan complicando sin necesidad de cambiar el almacenamiento de datos.</li>
</ol>
</aside>
</section>
<section>
<p style="font-size: 0.65em;">Tipos de Bases de Datos</p>
<ul style="font-size: 0.65em;">
<li>RDBMS (Microsoft SQL Server, Oracle Database, MySQL, PostgreSQL, ...)</li>
<li>NoSQL (Apache Cassandra, MongoDB, CouchDB, ...)</li>
<li>Cloud databases (Microsoft Azure SQL Database, Amazon Relational Database Service, Oracle Autonomous Database, ...)</li>
<li>Columnar databases (Google BigQuery, Cassandra, HBase, MariaDB, Azure SQL Data Warehouse, ...)</li>
<li>Wide column databases (BigTable, Apache Cassandra and Scylla, ...)</li>
<li>Object-oriented databases (Wakanda, ObjectStore, ...)</li>
<li>Key-value databases (Amazon DynamoDB, Redis, ...)</li>
<li>Hierarchical databases (IBM Information Management System (IMS), Windows Registry, ...)</li>
<li>Document databases (MongoDB, Amazon DocumentDB, Apache CouchDB, ...)</li>
<li>Graph databases (Datastax Enterprise Graph, Neo4J, ...)</li>
<li>Time series databases (Druid, eXtremeDB, InfluxDB, ...)</li>
<li></li>
<li></li>
</ul>
<aside class="notes">
<ol style="font-size: 0.65em;">
<li><strong></strong>: .</li>
<li><strong></strong>: .</li>
<li><strong></strong>: .</li>
<li><strong></strong>: .</li>
<li><strong></strong>: .</li>
</ol>
</aside>
</section>
<section>
<p style="font-size: 0.65em;">Tipos de Bases de Datos NoSQL</p>
<img class="top framed" src="img/types-of-databases3.png" />
<aside class="notes">
<ol style="font-size: 0.65em;">
<li><strong>Key-value storage</strong>: Es la más simple de las bases de datos NoSQL. Cada elemento tiene un atributo nombre (key) y conserva un valor.</li>
<li><strong>Document-oriented Database</strong>: Almacena datos como documentos JSON. Tiene la ventaja de usar el mismo formato que los usados en las aplicaciones.</li>
<li><strong>Graph Databases</strong>: Usadas para almacenar grandes volúmenes de datos en una estructura de grafo. Muy usada en las web de las redes sociales.</li>
<li><strong>Wide-column stores</strong>: Parecida a las bases de datos relacionales pero los datos correspondientes a cada columna se almacenan juntos en vez de por filas.</li>
</ol>
</aside>
</section>
</section>
<section>
<section>
<h4>Funcionalidades - V</h4>
<ol start="14">
<li class="fragment"><strong>Query optimizer</strong>: Uso de datos estadísticos.
<ul>
<li class="fragment">Tablas
<ul>
<li>Row count</li>
</ul>
</li>
<li class="fragment">Columnas
<ul>
<li>Data size</li>
<li>Nulls fraction</li>
<li>Distinct value count</li>
<li>Low value</li>
<li>High value</li>
</ul>
</li>
</ul>
</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.65em;">
<li>Trino utiliza información estadística de las tablas para optimizar las queries. Esta información la proporcionan los connectors y el nivel de disponibilidad varía de uno a otro.</li>
<li>Los datos estadísticos usados son los siguientes:
<ul>
<li><b>Tabla</b>: Row count == Número de filas de la tabla</li>
<li><b>Columna</b>: Data size == tamaño del dato que debe ser leído</li>
<li><b>Columna</b>: Nulls Fractino == porcentaje de valores nulos</li>
<li><b>Columna</b>: Distinct value count == número de valores diferentes</li>
<li><b>Columna</b>: Low value == el valor mínimo</li>
<li><b>Columna</b>: High value == el valor máximo</li>
</ul>
</li>
<li>Esta información puede consultarse usando el comando SQL <i>SHOW STATS</i>.</li>
</li>Por otro lado, es posible obtener el detalle de la planificación de una query (realizada en base a la información estadística anterior) mediante el comando SQL <i>EXPLAIN</i>.</li>
<li>Las optimizaciones que realiza Trino, basadas en estos costes calculados a partir de las estadísticas de tablas, son: Join enumeration y Join distribution selection.</li>
</ol>
</aside>
</section>
<section>
<h4>Ejemplo - Comando SHOW STATS</h4>
<pre><code data-trim data-noescape style="font-size: 0.6em;">
trino> show stats for ppa.public.tb_encuesta;
ERROR: failed to open pager: Cannot run program "less": CreateProcess error=2, El sistema no puede encontrar el archivo especificado
column_name | data_size | distinct_values_count | nulls_fraction | row_count | low_value | high_value
------------------------+---------------------+-----------------------+---------------------+-----------+-----------+------------
id_establecimiento | 5.0 | 1.0 | 0.0 | NULL | NULL | NULL
id_producto | 3.0 | 0.20454545319080353 | 0.0 | NULL | NULL | NULL
id_grupo_producto | 3.0 | 0.15909090638160706 | 0.0 | NULL | NULL | NULL
latitud | 4.0 | 1.0 | 0.0 | NULL | NULL | NULL
longitud | 5.0 | 1.0 | 0.0 | NULL | NULL | NULL
id_marca | 1.8181819915771484 | 0.11363636702299118 | 0.7727272510528564 | NULL | NULL | NULL
marca_aux | 1.624999761581421 | 0.13636364042758942 | 0.8522727489471436 | NULL | NULL | NULL
variedad | 0.0 | 0.0 | 1.0 | NULL | NULL | NULL
formato_aux | 0.0 | 0.0 | 1.0 | NULL | NULL | NULL
cantidad | NULL | 0.28409090638160706 | 0.13636364042758942 | NULL | NULL | NULL
precio | NULL | 0.6818181872367859 | 0.0 | NULL | NULL | NULL
ano | 5.0 | 1.0 | 0.0 | NULL | NULL | NULL
mes | 3.0 | 1.0 | 0.0 | NULL | NULL | NULL
fecha_hora_recogida | NULL | 1.0 | 0.0 | NULL | NULL | NULL
id_articulo | 0.28409063816070557 | 0.011363625526428223 | 0.9886363744735718 | NULL | NULL | NULL
descripcion_incidencia | 0.0 | 0.0 | 1.0 | NULL | NULL | NULL
created_at | NULL | 0.46590909361839294 | 0.0 | NULL | NULL | NULL
updated_at | NULL | 0.46590909361839294 | 0.0 | NULL | NULL | NULL
id_estado | 5.0 | 1.0 | 0.0 | NULL | NULL | NULL
id_formato | 8.335227448940277 | 0.9261363670229912 | 0.07386363297700882 | NULL | NULL | NULL
id_unidad_medida | 1.863636391727548 | 0.9318181797862053 | 0.06818182021379471 | NULL | NULL | NULL
NULL | NULL | NULL | NULL | 1.0 | NULL | NULL
(22 rows)
Query 20220518_150518_00007_b78u8, FINISHED, 1 node
Splits: 1 total, 1 done (100,00%)
0,39 [0 rows, 0B] [0 rows/s, 0B/s]
</code></pre>
</section>
<section>
<h4>Ejemplo - Comando EXPLAIN</h4>
<pre><code data-trim data-noescape style="font-size: 0.6em;">
trino> EXPLAIN select count(*) from fermio.e59021a_rd.urd_llamcan20201231_v01;
ERROR: failed to open pager: Cannot run program "less": CreateProcess error=2, El sistema no puede encontrar el archivo especificado
Query Plan
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Fragment 0 [SINGLE]
Output layout: [_pfgnrtd]
Output partitioning: SINGLE []
Stage Execution Strategy: UNGROUPED_EXECUTION
Output[_col0]
Ôöé Layout: [_pfgnrtd:bigint]
Ôöé Estimates: {rows: 1 (9B), cpu: 9, memory: 0B, network: 9B}
Ôöé _col0 := _pfgnrtd
ÔööÔöÇ RemoteSource[1]
Layout: [_pfgnrtd:bigint]
Fragment 1 [SOURCE]
Output layout: [_pfgnrtd]
Output partitioning: SINGLE []
Stage Execution Strategy: UNGROUPED_EXECUTION
TableScan[fermio:Query[SELECT count(*) AS "_pfgnrtd_0" FROM "e59021a_rd"."urd_llamcan20201231_v01"] columns=[_pfgnrtd_0:bigint:bigint], grouped = false]
Layout: [_pfgnrtd:bigint]
Estimates: {rows: 1 (9B), cpu: 9, memory: 0B, network: 0B}
_pfgnrtd := _pfgnrtd_0:bigint:bigint
(1 row)
Query 20220518_151129_00008_b78u8, FINISHED, 1 node
Splits: 1 total, 1 done (100,00%)
1,30 [0 rows, 0B] [0 rows/s, 0B/s]
</code></pre>
</section>
</section>
<section>
<section>
<h4>Funcionalidades - VI</h4>
<ol start="14">
<li class="fragment"><strong>Query optimizer</strong>: Pushdown.
<ul>
<li>Predicate (WHERE)</li>
<li>Projection (SELECT)</li>
<li>Dereference</li>
<li>Aggregation (GROUP BY)</li>
<li>Join (JOIN)</li>
<li>Limit (LIMIT)</li>
<li>Top-N</li>
</ul>
</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.75em;">
<li><strong>Pushdown</strong>: Como parte de la estrategia de optimización, Trino puede enviar parte de las queries hacia la fuente de datos para su procesamiento. Esto incrementa el rendimiento de la query, reduce el tráfico de datos y la carga en la fuente de datos remota. Este mecanismo se llama pushdown y las partes enviadas son: Predicate (cláusula WHERE) para ayudar a filtrar filas, Projection (cláusula SELECT y otras) para filtrar qué columnas recuperar, Dereference para filtrar aún más las columnas devueltas, Aggregation (cláusula GROUP BY y otras), Join (cláusulas JOIN), Limit (cláusulas LIMIT y otras) para reducir el número de filas devueltas y Top-N similar a la anterior.</li>
<li>La aplicación de estas optimizaciones pushdown puede observarse en la salida del comando SQL EXPLAIN ya que los operadores correspondientes (Join, Aggregate, etc.) no aparecen en la planificación de la query ya que han sido delegados en las BBDD de origen.</li>
</ol>
</aside>
</section>
<section>
<img class="top framed" src="img/sql-queries.jpeg" width="400" height="400" />
</section>
<section>
<p>¿Qué son las windows functions?</p>
<div style="font-size: 0.65em;">
<blockquote>Realizan cálculos sobre un conjunto de registros relacionados con el actual, de forma similar a las funciones de agregación, pero sin agrupar filas.</blockquote>
<pre style="width: 60%"><code data-trim data-noescape>
SELECT
duration,
SUM(duration) <u>OVER</u> (ORDER BY start_time) AS running_total
FROM
tasks;
</code></pre>
</div>
<aside class="notes">
<p style="font-size: 0.75em;"><b>Ejemplo</b>: cálculo de la duración relativa de cada tarea frente al total.</p>
</aside>
</section>
</section>
<section>
<h4>Funcionalidades - VII</h4>
<ol start="15">
<li class="fragment" data-fragment-index="0">Spill to disk</li>
<li class="fragment" data-fragment-index="1">Dynamic filtering</li>
<img class="fragment top framed" data-fragment-index="1" src="img/585px-Joins_del_SQL.svg.png" style="background-color: #6DB3F2;" />
</ol>
<aside class="notes">
<ol style="font-size: 0.6em;">
<li><strong>Spill to disk</strong>
<p>Por defecto, las queries que exceden los límites de memoria de sesión son abortadas para asegurar que el sistema no cae. Esto puede causar que las queries con grandes requisitos de memoria no lleguen a ejecutarse nunca.</p>
<p>Para evitarlo, puede activarse el mecanismo de Spill to disk (rebose a disco), similar al sistema de paginación de memoria del sistema operativo, que vuelca a disco parte de la memoria (revocable) usada para ser procesada más tarde, liberando memoria para continuar.</p>
<p>Las queries pueden solicitar memoria revocable que no se contabiliza a efectos de alcanzar los límites de memoria de sesión.</p>
<p>El Spill to disk está disponible sólo para algunas operaciones concretas (join, agregaciones, order by y window functions).</p>
<p>El volcado a disco puede separarse por configuración en distintas unidades físicas, que son tratadas como JBOD (Just a Branch Of Drives) por lo que no es necesario ponerlas bajo control RAID.</p>
<p>También es posible habilitar compresión y/o encriptado.</p>
</li>
<li><strong>Dynamic filtering</strong>
<p>En las queries de tipo join, la tabla izquierda (tras la cláusula FROM) y la tabla derecha (tras el JOIN) son filtradas según el predicado (cláusula WHERE) y recuperadas en memoria para hacer el matching según la condición del join (cláusula ON). Cuando las tablas son grandes y el predicado no filtra suficientemente la tabla fact, esto es muy ineficiente.</p>
<p>Cuando se activa el Dynamic Filtering, se filtra la tabla derecha (fase #1) según el predicado y se obtienen posibles valores candidatos de las columnas usadas para el join. Estos valores se agregan como nuevas condiciones al predicado creando un nuevo filtro (filtro dinámico generado) usado para filtrar la tabla izquierda (fase #2). Esto ocurre en cada nodo worker (broadcast joins).</p>
<p>Adicionalmente, estas nuevas condiciones pueden ser enviadas al nodo coordinador que las agrega y redistribuye a todos los nodos workers para el filtrado de la tabla izquierda.</p>
<p>Ambas funcionalidades (dynamic filtering y dynamic filtering distribution) están activadas por defecto aunque pueden desactivarse usando las propiedades enable-dynamic-filtering y enable-coordinator-dynamic-filters-distribution de la configuración o sus respectivas de la sesión (enable_dynamic_filtering y enable_coordinator_dynamic_filters_distribution).</p>
<p>El Dynamic filtering está disponible sólo en algunos connectors (Hive[dynamic partition pruning], Memory, etc.).</p>
<h5>Las ventajas que se consiguen son:</h5>
<ul>
<li>Mejorar el rendimiento de las queries</li>
<li>Reducir el tráfico entre el Trino y las BBDD</li>
<li>Reducir la carga en las BBDD</li>
</ul>
</li>
</ol>
</aside>
</section>
<section>
<h4>Funcionalidades - VIII</h4>
<ol start="17">
<li class="fragment">Resource groups</li>
<li class="fragment">Session properties</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.6em;">
<li><strong>Resource groups</strong>
<p>Permite asignar límites en el uso de recursos a las queries. Se puede limitar el número de queries, la cantidad de memoria y el uso de CPU. Esto se hace definiendo distintos resources groups y cada query es asignada a uno de estos. Un resource group define límites en los recursos (propiedades) y puede contener, a su vez, otros resource groups. Sólo aquellos que no contienen elementos anidados, pueden aceptar queries.</p>
<p>Los resource groups son gestionados por un manager, implementado como plugin, que puede ser de dos tipos: file (configurado en fichero JSON en el nodo coordinador) ó db (configurado en BD separado MySQL, Postgresql ó Oracle que pueden ser compartidas por varios clusters Trino).</p>
<p>Cada query es asignada a un resource group usando un conjunto de reglas (selectors) en función del usuario, grupo del usuario, fuente (texto externo), tipo de query ó tags. Una vez asignado a un grupo, si la query incumple los límites de uso de los recursos fijados en el grupo no falla sino que es encolada para su posterior ejecución (la estrategia usada para poner en ejecución nuevamente las queries encoladas es configurable por cada resource group).</p>
<p>Un ejemplo típico del uso de estos resource groups es la de crear dos grupos para priorizar las queries con ejecución programadas sobre las queries interactivas.</p>
</li>
<li><strong>Session properties</strong>
<p>Las propiedades de sesión pueden controlar el comportamiento de Trino como: el uso de recursos, activar funcionalidades y características de queries.</p>
<p>Algunas propiedades son aplicables a todo el sistema, mientras que otras lo pueden ser a cada catálogo por separado.</p>
<p>Pueden ser modificables por aquellos usuarios autorizados (ver autorización).</p>
<p>Las propiedades son gestionadas por managers pluggables.</p>
<p>El manager por defecto usa un fichero de configuración JSON con reglas en función de: usuario, grupo del usuario, fuente (texto externo), tipo de query ó tags.</p>
</li>
</ol>
</aside>
</section>
<section>
<section>
<h4>Funcionalidades - IX</h4>
<ol start="19">
<li class="fragment">Distributed sort</li>
<li class="fragment">Graceful shutdown</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.70em;">
<li><strong>Distributed sort</strong>
<p>Esta funcionalidad permite al operador sort ordenar un conjunto de datos en paralelo repartiendo los datos entre múltiples nodos workers para luego realizar una última ordenación en un único worker.</p>
<p>Esto posibilita ordenar datos que superarían el límite de memoria de un único nodo (propiedad query.max-memory-per-node) ganando además en rendimiento.</p>
<p>Normalmente activado, puede activarse por configuración (distributed-sort) ó sesión (distributed_sort).</p>
</li>
<li><strong>Graceful shutdown</strong>
<p>Al igual que el autoregistro de los nodos workers en el nodo coordinador, via el servicio discovery, permite agregarlos dinámicamente al cluster Trino, esta funcionalidad permite apagar nodos workers sin afectar a las queries que estén en curso, dando un tiempo de gracia antes del apagado (propiedad shutdown.grace-period, 2 minutos por defecto).</p>
<p>Para apagar un nodo, se realiza una petición HTTP-PUT.</p>
<p>El apagado puede ser protegido por los mecanismos de control de acceso disponibles.</p>
</li>
</ol>
</aside>
</section>
<section>
<p>Ejemplo de apagado de nodo worker</p>
<pre><code data-trim data-noescape style="font-size: 0.6em;">curl -X PUT -d '"SHUTTING_DOWN"' -H "Content-type: application/json" http://worker:8081/v1/info/state</code></pre>
</section>
</section>
<section>
<h4>Funcionalidades - X</h4>
<ol start="21">
<li class="fragment">Fault-tolerant
<ul>
<li>Query retry</li>
<li>Task retry</li>
</ul>
</li>
<li class="fragment">JMX</li>
</ol>
<aside class="notes">
<ol style="font-size: 0.6em;">
<li><strong>Fault-tolerant</strong>
<p>En el caso de que una query falle debido a causas internas (por ejemplo, falta de recursos), por defecto, debe ser relanzada manualmente.</p>
<p>Activando el mecanismo <i>Fault-tolerante execution</i>, Trino puede reintentar aquellas tasks fallidas ó la query entera según se configure. Las queries fallidas por errores de sintaxis o por haber sido detenidas por el usuario, no se reintentan.</p>
<p>La configuración de <u>reintento de queries</u> es apropiada cuando la mayoría de las queries son cortas o cuando no se disponga de un exchange manager.</p>
<p>Por otro lado, cuando las queries sean largas o se lancen en grandes lotes (batch), es perferible el <u>reintento por tasks</u> y se requiere el uso de un exchange manager que conserve los datos usados por los workers basado en un sistema de fichero local o en un sistema compatible S3.</p>
<p>En el reintento de queries, por defecto aquellas que devuelven más de 32MB de datos no se reintentan aunque este límite puede modificarse en la configuración (propiedad exchange.deduplication-buffer-size) aunque eso conlleva más consumo de memoria en el nodo coordinador. Para grandes volúmenes se recomienda usar un exchange manager basado en S3.</p>
<p>Es posible configurar el número de reintentos, el tiempo entre reintentos, etc. usando multitud de propiedades de configuración.</p>
</li>
<li><strong>JMX (Java Management Extensions)</strong>
<p>Es posible monitorizar el sistema mediante métricas accesibles via Java Management Extensions (JMX), que pueden consultarse mediante un servidor interno (propiedades de configuración jmx.rmiregistry.port y jmx.rmiserver.port) usando cualquier cliente JMX.</p>
<p>Existen muchas aplicaciones de monitorización que usan este sistema (jconsole, visualVM, etc.).</p>
<p>También es posible ver estas métricas accediendo a un catálogo que use el connector JMX.</p>
<p>Hay métricas de todo tipo: de la máquina java (JVM), del cluster Trino, de las queries, de las tasks, etc.</p>
</li>
</ol>
</aside>
</section>
<!-- INSTALACIÓN Y CONFIGURACIÓN -->
<section>
<h3>Índice</h3>
<ol>
<li>Introducción y conceptos básicos</li>
<li>Funcionalidades</li>
<li class="fragment highlight-red">Instalación y configuración</li>
<li>Pruebas realizadas</li>
<li>Conclusiones</li>
</ol>
</section>
<section>
<section>
<h4>Instalación docker</h4>
<ol start="1" style="font-size: 0.65em;">
<li>Configuración docker-compose</li>
<span style="font-size: 0.5em;">fichero <i>docker-composer.yml</i></span>
<pre style="font-size: 0.6em; width: 100%"><code data-trim data-noescape style="font-size: 0.6em;">
version: "3.9"
services:
mi-proxy:
build:
context: mi-proxy
args:
SERVER_HOSTNAME: $SERVER_HOSTNAME
TRINO_URL_PATH: $TRINO_URL_PATH
TRINO_API_URL_PATH: $TRINO_API_URL_PATH
TRINO_API_PORT: $TRINO_API_PORT
image: mi-proxy
container_name: mi-proxy
# user: $TRINO_USER
ports:
- 443:443
volumes:
- ./mi-proxy/logs:/var/log/nginx
# Compartimos el socker de Docker Engine para poder usar el Docker Engine API dentro del contenedor
- /var/run/docker.sock:/var/run/docker.sock
# networks:
# - mi-proxy
# - mi-trino
restart: always
depends_on:
- mi-trino-coordinator
mi-trino-coordinator:
build:
context: mi-trino-coordinator
args:
SERVER_HOSTNAME: $SERVER_HOSTNAME
# Otros parámetros opcionales pueden ir aquí
# Como los usados en https://github.com/trinodb/trino/blob/master/core/docker/README.md
# docker exec -it trino trino --catalog tpch --schema sf1
image: mi-trino-coordinator
container_name: mi-trino-coordinator
env_file:
- .env
- trino-catalogs/.env
# user: $DOCKER_USER
restart: always
ports:
# Mapeamos el puerto 80 externo al 8080 interno que es el puerto por defecto para HTTP usado en la imagen oficial del Trino.
# Mapeamos el puerto 443 externo al 8443 interno que es el puerto para HTTPS por el servidor Trino.
- "8080:8080"
- "9000:9000"
# - "443:8443"
volumes:
- ./trino-catalogs:/etc/trino/catalog:ro
- ./mi-trino-coordinator/logs:/data/trino/var/log
- ./mi-trino-coordinator/nodejs/files:/home/node/app/files
- ./mi-trino-coordinator/nodejs/apps:/home/node/app/apps
- ./mi-trino-coordinator/nodejs/logs:/var/log/trino-api
# - ./mi-trino/files:/home/node/app/files
# - ./mi-trino/apps:/home/node/app/apps
# Compartimos el socker de Docker Engine para poder usar el Docker Engine API dentro del contenedor
# - /var/run/docker.sock:/var/run/docker.sock
# - /tmp/docker-fake.sock:/tmp/docker-fake.sock
mi-trino-worker:
build:
context: mi-trino-worker
args:
SERVER_HOSTNAME: $SERVER_HOSTNAME
# Otros parámetros opcionales pueden ir aquí
# Como los usados en https://github.com/trinodb/trino/blob/master/core/docker/README.md
# docker exec -it trino trino --catalog tpch --schema sf1
image: mi-trino-worker
# container_name: mi-trino-worker0
env_file:
- .env
- trino-catalogs/.env
ports:
- "8081-8091:8080"
volumes:
- ./trino-catalogs:/etc/trino/catalog:ro
- ./mi-trino-worker/logs:/data/trino/var/log
</code></pre>
</ol>
<aside class="notes">
<p style="font-size: 0.5em;"></p>
</aside>
</section>
<section>
<h4>Instalación docker</h4>
<span style="font-size: 0.325em;">fichero <i>.env</i></span>
<pre style="font-size: 0.39em; width: 100%"><code data-trim data-noescape style="font-size: 0.6em;">
SERVER_HOSTNAME=cinco-ap01p.gobiernodecanarias.net
TRINO_URL_PATH=aplicaciones/trino
TRINO_SERVER_USER=admin
TRINO_SERVER_PASS=****
TRINO_INTERNAL_COMM_SHARED_SECRET=KCZZItOB+oAMHi5jH59pt4pBE
TRINO_API_URL_PATH=aplicaciones/trino/api
TRINO_API_PORT=9000
</code></pre>
<aside class="notes">
<p style="font-size: 0.5em;"></p>
</aside>
</section>
<section>
<h4>Instalación docker</h4>
<span style="font-size: 0.325em;">fichero <i>Dockerfile</i> (nodo coordinador)</span>
<pre style="font-size: 0.39em; width: 100%"><code data-trim data-noescape style="font-size: 0.6em;">
FROM trinodb/trino
ARG SERVER_HOSTNAME
ENV SERVER_HOSTNAME=${SERVER_HOSTNAME:-localhost}
ARG TRINO_API_PORT
ENV TRINO_API_PORT=${TRINO_API_PORT:-9000}
LABEL org.opencontainers.image.authors="[email protected]"
LABEL Mi-TRINO='Trino Server v370'
# Instalamos el editor nano (para pruebas)
#RUN apt-get update && \
# apt-get -y install nano
COPY --chown=trino:trino ./config/* /etc/trino/
#COPY --chown=trino:trino ./../trino-catalogs/* /etc/trino/catalog/
RUN rm -rf /etc/trino/catalog/*
##################
##### NODEJS #####
##################
# https://www.ibm.com/docs/en/z-chatops/1.1.0?topic=software-installing-nodejs
# Ficheros descargados offline usando el comando `curl -sL -o node-v18.1.0-linux-x64.tar.gz 'https://nodejs.org/dist/latest/node-v18.1.0-linux-x64.tar.gz'`
# NOTA: La versión docker del Centos no soporta el formato tar.xz.
COPY ./downloads/* /downloads/
USER root
# Instalamos el comando ps usado por el módulo node-ps para listar los procesos.
RUN dnf --disablerepo="*" --nodocs install -y /downloads/procps-ng-3.3.15-6.el8.x86_64.rpm && \
rm -f /downloads/procps-ng-3.3.15-6.el8.x86_64.rpm
# Descomprimimos e instalamos los binarios del Node v18.1.0
RUN tar zxf /downloads/node-v18.1.0-linux-x64.tar.gz -C /opt && \
rm -f /downloads/node-v18.1.0-linux-x64.tar.gz
ENV PATH="/opt/node-v18.1.0-linux-x64/bin:${PATH}"
RUN dnf clean all && rm -rf /var/cache/* /var/log/dnf* /downloads