浅谈数据工程师和SQL

这个周末是圣诞节,不过我没有人约也没有约人,在宿舍宅了一天,于是便有了这篇文章。今天我想谈谈所有工程师都离不开的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