数据中台-数据查询
数据中台中经过处理后的数据，还需要有高效的查询引擎才能被用户接触使用。厨OLAP的查询技术框架大致分为三类：
1基于HBase做预聚合:如Opentsdb,Ky1in等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求。
2.基于Parquet做列式存储、如Presto, Dri11，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高I0效率，以离线处理为主，很难提高数据写的实时性，超大表的Join支持可能不够好。
3.基于Lucene做外部索引:如ElasticSearch,Solr等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋。
我们以常见的Presto，Druid，Ky1in三个模型来讲讲各自的特点:
Presto:由Facebook开源，是一个分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库。
它背后所使用的执行模式与Hive有根本的不同，并没有使用MapReduce。因其所有的处理都在内存中完成，大部分场景下要比Hive快一个数量级。
Druid:由MetalMarket开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到5分钟。它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能。
Kylin:Cube预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。劣势在于每次增减维度必须对Cube进行历史数据重算追溯，非常消耗时间。据说Kylingence在前几天的新品发布会上已经解决了这个问题，拭目以待 。
很多时候，在计算和查询这块没有明显的边界区分。这里为了方便阐述分成了两个部分。对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用Kyin的预计算能力+Druid的查询引擎，来提高查询的速度等等。
数据可视化及分析
在数据可视化这块，一般会采取三个途径来进行数据展示。最基础的利用开源的图表库，如国外的HighCharts、D3，百度的ECharts，还有阿里Antv的G2、G6、F2等。往上一层是各个知名公司开源的可视化框架，如Airbnb的Superset，Redash，Metabase等等。这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。再往上一层就是商用的可视化软件，如国外的Tableau，Q1ik，国内的FineReport，永洪B等等。这种软件需要付费，但都具备更丰富的可视化功能并提供一些技术支持，对于那些没有精力折腾可视化的公司会是个不错的选择。
理解整个图表开源生态，我们得先了解下SVG和Carvas这两个浏览器提供的原生能力。SVG-全称叫可缩放矢量图，跟HTMIL一样，有自己的命名空间，使用XML标签来绘图。而Canvas是HTMIL5中的新标签，用于客户端的图形绘制，有一个基于Java的绘图API。D3.js全称是Data-DrivenDocuments，支持SVG和Canvas。相对于其他产品，它更偏底层，并没有对图表进行归类。开发者可以通过D3丰富的类库来方便的操作 DOM，绘制任何想绘制的图形，以增加开发复杂度的代价，覆盖更加全面的可视化场景。
