这个周末是圣诞节，不过我没有人约也没有约人，在宿舍宅了一天，于是便有了这篇文章。今天我想谈谈所有工程师都离不开的SQL。最近我们在做一个自助数据分析（OLAP）系统，调研的时候在segmentfault上看到一篇博客，其中一句话我深有同感
面对快速变化的业务需求，很多数据工程师都把自己的青春埋葬在SQL里了。
其实不仅数据工程师，数据分析师同样把大部分精力花费在SQL上。这不是意味着我看轻SQL，相反我认为SQL的发明者真的太厉害了。SQL作为一种30年前诞生的古老的语言，经久不衰，直到今天CRUD基本可以完成60%以上的系统。
大数据时代的SQL
前几年，当大数据概念刚刚兴起的时候，新型数据仓库都宣称自己为“NoSQL”数据库，似乎对schema要求严格的SQL已经不再适合业务发展迅速的互联网。新型数据库更多是Schemaless，不需要预先定义Schema而是通过实际的数据去猜出数据类型。数据在入库的时候并不做类型检查，而是查询的时候会将不符合Schema的数据过滤掉。每个数据库都单独提供一种查询语言（DSL）和操作语言（DML），这带来了很多问题。首先是无论哪种查询语言似乎都只能针对SQL某个操作进行优化，却以牺牲其他操作为代价。KV型的NoSQL数据库，难以支持非主键字段的检索，像HBase的用户不得不使用各种tricks，想方设法把字段放进row key。文档型NoSQL数据库如ElasticSearch和MongoDB，对于聚合型计算又十分吃力。而所以逐渐地很多大数据产品又重新开始提供SQL，”SQL on hadoop “就是典型，从离线处理的Hive、Pig，到现在支持实时处理的SparkSQL、Impala、Druid等等。SQL又回到了大数据的舞台，原来复杂的MapReduce程序或者RDD操作，又重新变为人人都熟悉的SQL。
SQL使用场景的转换
在大数据应用中，数据分析的需求占据主流，SQL的任务更多从OLTP变为OLAP。目前互联网企业使用大数据做数据分析的方式大概分为三种：
- 集市型，专门设置一个提数团队负责ETL，每当有数据需求直接抛给提数人员，后者通过编写执行SQL提取数据给需求部门，数据分析由需求部门负责。这种方式实际上简化了业务部门的提数需求，但很容易出现业务部门随意提需求的问题。对于提数部门来说，仅仅通过面向过程编程也很难有技术积累，最后脚本越写越多，陷入低效和管理混乱的困境。
- 教堂型，设有数据分析部门负责数据的维护。业务部门有提数需求，先整理需求文档，交给数据部门后确定方案，采集数据并处理生成周报月报。这种方式的优点是流程化规范化，容易进行下钻（drill down）等数据分析，不足在于处理流程较长，缺乏灵活性，对于临时需求无能为力。
- 平台型，秉持人人都是数据分析师的理念，数据部门提供数据分析平台，产品运营人员直接在上面进行分析。优点是减少了部门间沟通的成本，减轻了数据工程师的人工SQL工作，更轻量级更灵活；缺点也很明显，产品运营用户只能对数据进行简单的聚合计算，而不具备复杂数据分析和数据挖掘，甚至机器学习的技能。
有一定规模的互联公司大多数都处于集市型的数据分析模式，而（准）一线互联网公司更提供了自己的交互式数据查询分析平台，比如阿里云的quickBI、京东的云海、网易的猛犸等。目前我们处于集市型，但业务流程比较长跟不上需求。这些需求中有不少是临时需求，比如流量异常分析、活动效果分析。这些需求时效性比较高，如果处理成月报意义不大，还会造成资源的浪费，所以我们希望通过开发自助数据分析系统去解决这个问题。
ROLAP和MOLAP
OLAP系统主要可以分两类，ROLAP（关系型OLAP）和MOLAP（多维OLAP）。其中RLOLAP顾名思义是基于关系型数据，数据以最细粒度存放，然后查询的时候聚合得出结果。ROLAP方便上卷和下钻，灵活性大，而且一般的查询引擎（比如SparkSQL、Presto等）就可以支持，门槛比较低但由于计算是实时发起的，查询效率比较低。MOLAP恰好相反，提前将指标数据按照维度聚合，查询效率高，不过数据有一定延时，而且不能下钻到最细粒度的数据。还有一类是两者的融合HOLAP（混合OLAP），通常是底层以关系型数据库存放原始数据，上层计算出高粒度的汇总数据供查询，性能介于两者之间，是比较通用的解决方案，现在很火的Apache Kylin就是属于这类。
我的OLAP项目
我们的项目除了面向产品运营的数据分析需求，还需要支持其他部门的提数需求，所以该项目需要支持交互式查询和原始数据的ETL，在可以查到项目里京东云海的案例最为符合。目前的一个难点是，复用已有查询引擎还是单独搭一套OLAP集群？如果基于已有的SparkSQL引擎实现会比较简单，只需要提供Web页面给用户拼接SQL，但响应速度可能在10s以上，不能满足交互式查询的需求。如果单独为OLAP搭一个集群，无论使用Kylin还是Druid，都会造成较大的数据冗余，并且开源产品通常有边边角角的地方不能切合需求，很有可能需要改动源代码。其实我是更偏向后者，虽然更难，但对于个人成长来说，把Kylin用熟练意义更大。就看老大看了调研报告之后怎么决定啦：）。
本文是原创文章，转载请注明：时间与精神的小屋 - 浅谈数据工程师和SQL