OLAP(On-line Analytical Processing,联机分析处理),基于数仓多维模型基础上实现面向分析的各类操作的集合。老生常谈,一般都会与传统的 OLTP(On-line Transaction Processing,联机事务处理) 进行比较。如下图所示:
总的来说,大部分的互联网企业都需要同时具备 OLTP 和 OLAP 的能力。如果专注功能和事务性操作采用 OLTP,如果需要从海量、低价值密度、多数据源集成分析数据价值可能要采用 OLAP。实际上边界也没有那么清晰,最终的目标还是解决企业的业务痛点,用最小成本解决实际的业务需求,杀鸡尽量不要用宰牛刀。
数据挖掘针对数据仓库的特点包括面向主题、集成、非易失和时变的数据集合,用于支撑管理决策。
对多源异构的数据库系统,按主题进行组织并加以抽象。例如传统事务数据库都是按应用划分的,有 ERP 系统、CRM、OA、HR 和财务系统等,数据都存储在不同的数据库 Oracle、MySQL 等,你咋分析?所以我们需要把各个应用的数据,按主题组织分类,以全局的视角抽象层次上对数据进行完整、一致和准确的描述。
因数据从多源异构系统而来,需要统一数据源,这是最复杂且重要的一步,做数据 ETL(Extract-Transform-Load,抽取-转换-加载)操作,最终生成数仓的全局数据。
不可更新性,数仓的目标为决策分析,也就是查询操作。流经数仓的数据主要为应用产生的具有时间属性的历史事件内容,几乎不会对其进行更新和删除操作。例如订单记录、通话记录及打车记录等。
数据仓库的数据是按照时间属性追加的,通过数仓海量的存储和实时分析能力,留存各个时间粒度的数据(分钟、小时、日、月、年),可通过该信息对未来趋势做出定量分析和预测。
因其具备多维度、多视角和多层次的数据组织特点,OLAP 技术才具备用武之地。基本操作分为下钻(Drill Down)、上卷(Roll UP)、切片(Slicing)、切块(Dicing)和旋转(Pivot)。
业界主流 OLAP 可分为三类:MOLAP、ROLAP 和 HOLAP。
按照查询时间延迟分为两类:简单查询和复杂查询。
理想情况下查询时延在毫秒到秒级,设计满足 80%的用户需求(实际不可能的)。
影响数据库查询性能的稳定性,我们 80%时间都在处理各种慢查询的优化以及做大量的性能测试。
group by dimension order by Metrics desc limit N
复制代码
dimension 枚举量级达到上亿,如何高效的求 TopN 呢?设想在 24 小时范围内,数据规模为 TB 级,执行如上查询,最终的结果基本上会查询超时或内存溢出。这种操作会消耗大量的磁盘 IO 进行 SCAN,通过网络进行汇聚,消耗 CPU 进行计算,对 OLAP 数据引擎来说相当致命。优化建议如下:
如上都具有局限性,需要结合业务场景选择具体的实现方案。在海量原始数据下,计算精确的 TOPN,就是拼资源和算力,也会有重复计算风险。业务允许情况下,取其近似值是一个不错的选择。
如何选择 OLAP 引擎?我们根据业务需求实现功能,也不断的在理想与现实方案做妥协。理想方案是完美的方案,现实不得不在功能与性能之间做 Trade-off。
总的来说,理解业务需求,是辅助做 OLAP 技术选型的关键因素。
目前业界有采用多引擎架构,通过 MOLAP 引擎定制维度统计应用实时渲染场景。采用 ROLAP 引擎作为实时探索分析。采用 ROLAP 单引擎架构,采用物化视图承担 MOLAP 能力。推断未来会有优秀的 HOLAP 引擎推出。
http://webdataanalysis.net/web-data-warehouse/data-cube-and-olap/ https://zhuanlan.zhihu.com/p/266402829 https://galaktika-soft.com/blog/olap-cubes.html
领取专属 10元无门槛券
私享最新 技术干货