业界分析
从2004年Google发布MapReduce论文，掀起大数据热潮，同时也得益于互联网数据的井喷发展，大数据体系已经高速发展了14年。消息平台、流式处理、分布式计算及海量数据储存已经发展壮大日趋成熟，使得大数据能力逐步达到工业化量产的规模，然而在数据可视这最后一公里上，大数据体系一直没有一个终极一站式解决方案。
Hive、Spark受限于MR框架或者Yarn资源策略问题，其查询性能一直饱受病垢，分钟级体验难以支撑数据可视服务。
而Hbase、ES这类NoSQL数据库主要为点查或扫描而生，聚合统计没有进行针对优化而普遍偏慢。
Kylin查询引擎基于MOLAP进行数据预处理提升大数据查询平台，其数据加载也是一个问题，而且数据模型相对固定。
似乎都不是太好的选择，我们是否需要回到传统数仓？
答案是否定的。
就目前形势看，在绝对意义的分布式数据湖不完善情况下，大数据体系其便利的scale-out能力，能友好解决业务数据井喷情况下，数据平台架构靠扩容机器即可解决，而不需要调整平台架构。
那么如此多的技术选型，又各有优劣，我们应该如何适配应用来进行选择呢？
解决方案
兵无常势，水无常形，首先我们还是要结合业务当前痛点具体分析设计。
我觉得大数据服务主要有三：
数据准确一致：
明细、聚合都需同步刷新，避免出现汇总查询的数据和明细对不齐，造成数据不可用情况。 传统DataMark层数据加速装载为了避免不一致，通常会采用临时表进行置换，或者是物化视图方式优化， 但是到大数据场景，这部分优化强依赖数据开发人员能力，有可能还需长期维护，所以针对这部分较难场景我会推荐使用大数据平台来加速，虽然首次开发有难度但减少后续维护工作。
服务查询高效：
能支持大体量数据湖快速查询，包括明细及汇总场景，以及海量数据随机搜索场景。
支持并发查询：
数据服务会嵌入到APP中，其调用量会随应用情况弹性变化，传统企业比不了互联网企业，但是传统企业也有QPS达到百级规模情况，比如一些业务冲刺场景。
同时不同架构，受并发影响也不同，下面在从架构维度，对上述三个业务要素逐步识别我们推荐的解决方案。
1、RunTime查询引擎
优势战场
在大数据场景下，前面提到hive、spark不适合做交互式分析，所以我们聚焦在当前可用的MPPDB（如LibrA、IQ等）。
RunTime模式最大优势是在于其支持用户自定义的灵活SQL，可以满足自助分析场景， 比如一些数据量较大在Oracle做自助分析性能较差情况，将数据导入MPPDB后进行数据分析对体验提升较大，目前我们在供应链一些领域进行MPPDB平台加速，质量tableau自助分析平台进行数据拖拽显示，基本满足5秒性能。
局限因素
但是RunTime其劣势也如其名，在线查询，势必消耗较大IO、CPU开销来满足性能，在并发不大情况下可以靠资源扩容，提升效率，但是并发增大后应用硬件成本就会较高，同时CPU等负载高时，其相应时间也变长需要预警扩容。
综上所述，选择RT模式，主要为解决应用灵活查询场景，但出现需要考虑应用并发情况，合理扩容。
平台布局
那我们再简单介绍下查询平台，LibrA和IQ都是MPP架构，同样也是内存中计算数据，两者差别主要是前者可以直接查询Hive、Spark、posgreSQL、等数据库数据为主，有较大协同能力和开放性。而IQ为独立数据库，外部储存介质需要先预先导入后才能进行数据查询。
2、NoSQL搜索引擎
优势战场
区别于关系型数据库，NoSQL最大优势是在数据检索上，通过倒排索引、顺序索引、图索引等技术加速数据可视查询，比如我们常用的内部Web办公系统首页搜索，GPS地理位置检索等应用。
局限因素
NoSQL为了提升体验而实现的filter、aggregations函数还不太成熟，大部分还是基于scan方式实现，特别是HBase，不走rowkey查询简直就是要卡死的节奏，当然NoSQL最大劣势还在于其无法进行数据join，只能基于宽表提供数据服务，什么星型、雪花模型，统统都得拉成一个大宽表才可以。所以其数据的时效上，需要先进行宽表整合，比RT模式要慢一个周期（取决于数据量、计算、加载等多个因素），但是在点查场景下，可以支持海量并发，聚合场景应尽量控制，避免IO负载过高，关联场景那就更不要有了，应该在预加载时就提前处理好数据。
平台布局
目前三个NoSQL数据库：
1.MongoDB：主要应用于文档检索，同时依托其地图索引，在GPS计算上性能强劲，亿规模GPS点扫描起来也能到秒级体验；
2.ElasitcSreach：广泛应用在各种基于标签应用的搜索上，数据通过提前打标签后，加载到ES提供数据搜索服务，在filter、agg等函数也进行了不少改进。
3.HBase：适用于特定场景的批量查询，通过RowKey整合数据，基于顺序索引检索数据，因为其region server特性可以将数据buff在多个节点，并直接提供数据服务，可以支持海量数据更新及查询。比如淘宝页面就是很好例子，上面有各种图片、文档、html标签，前端通过key检索数据后快速加载展示。
3、MOLAP（预处理）查询引擎
目前MOLAP技术有kylin项目，华为CarbonData项目，如今华为CarbonData项目已经成为Apache社区的顶级项目。
平台优势
MOLAP通过预处理，实现数据查询开销由O（N）降低到O(1)，将多次scan、processing变成一次点查，所以其能很好解决数据在海量聚合场景下的查询，比如互联网里面常用统计指标pv、uv、月活、存留等。
局限场景
预处理需要提前定义好模型，所以只能处理已确定的应用场景，比如一些web应用服务，偏定制化开发，同时其预计算也需要更长时间，这部分开销需要结合应用情况进行取舍，比如适当降低维度可较大缩短cube刷新时长，但需要权衡是否命中那5%的应用场景。
平台布局
目前我们引入商业版本Kylin（KAP），其一大特性是将明细层和Cube进行整合，数据一次装载后即可实现聚合+明细的查询加速，很好解决数据不一致问题（我们有些基于HBase场景，就需要用snapshot快照表进行数据中转，实现复杂略高），我们在SD、supply领域已有多个应用上线，同时依托FusionInsight HD并行处理能力，千万级数据均可在10分钟完成全量刷新，亿规模的也可以小时级刷新。
TO-BE的技术架构，应该越大越快越实时，这样才能提供ROADS极致体验，业界已经给了一些成熟案例，如presto(impala/kudu) on Kylin，通过两种架构互补方式，进行数据加速及并发扩容。
同时我们也在商业版KAP提出了诉求，目前是spark2.1 on KAP方式，在未加载模型的数据加速上相对presto还是有差距，还需持续迭代。
总结一下，三种模式适合场景各有优劣，需要适配应用而选择，我们不需要太过关心是否平台演进带来的应用改造，因为预测通常不准，所以我觉得应该持续迭代我们的开发模式，加速生产效率，让技术成为提升效率的工具，而不是工作门槛，让应用都能基于新平台实现规模量产。
想，都是问题，做，才出成绩！
声明：本文观点仅代表作者个人，不代表任何公司。
点击了解华为大数据&AI