易观 CTO 郭炜：如何构建企业级大数据 Ad-hoc 查询引擎
凭借多年大数据平台建设经验，易观 CTO郭炜为大家分享了易观在大数据实时查询引擎建设过程所获经验与挑战，以及大数据人员如何快速建立自己的大数据查询引擎套件，让自己的数据人员不再是“表哥表妹”的方法。
以下是具体内容：
作为数据人的你，是不是遇到这样的情况？
数据需求80%都是提数、出报表的需求，而很多报表往往只用一次…
临时分析众多，不管怎么提前做汇总加速开发，业务部门总觉得慢…
临时报表数据口径反复和业务部门核对，最后出的数据还是对不上，“写脚本3分钟，对数3小时”…
业务快速变化导致数据源的变化层出不穷，汇总层数据保持准确非常难，数据治理建设不易，维护成本更是高昂…
大数据工程师每日工作在写各种ETL、数据流脚本，而无法专注在大数据技术上…
究其原因会发现，不是数据技术能力不行，而是世界变化太快。数据驱动本身，是一个透明化的进程，挑战是业务变化很快，让数据本身“不透明”。
业务变化，数据定义变化快，例如，APP迭代，页面变化；数据经过层层加工，原始信息丢失，仓库表繁多，层层血缘关系，牵一发动全身；数据处理能力不足，时间滞后：T+1，临时需求 T+N，OLAP Cube也无法满足需求；想用Ad-hoc查询，但数据量过大，Tb 级别数据普通查询以数十分钟为单位出结果，跟不上分析师思路。
怎么办呢？破局的关键在于，将Ad-hoc查询从现有大数据体系中分离出来。
使用最新的大数据技术Ad-hoc，直接让业务人员从最明细的数据中统计，秒级返回结果，把业务口径还给业务人员，技术人员只做最底层的数据整理。
大数据Ad-hoc引擎的优缺点有哪些呢？
优点：
业务人员无需等待，直接统计相关数据
业务人员自定义口径，数据治理工作量小
技术人员无需天天提数，专注在技术平台
缺点：
需要额外的硬件/系统资源
数据场景相对单一，需要优秀的数据模型抽象
新的技术引入，维护、升级工作量问题
企业需根据自己的情况选择是否建立大数据Ad-hoc查询引擎。
那么，如何去构建企业级大数据Ad-hoc查询引擎呢？关键是做好这三步：选择要解决的业务场景并建模；选择数据查询底层引擎与技术生态；企业自建Ad-hoc引擎要点与参考架构。
选择要解决的业务场景并建模
日常业务场景中数据量巨大，秒级返回硬件成本过高，不是每家公司都是Google；由于数据结构复杂，所以多个业务场景导致数据模型很难抽象和固定下来；最后就是查询无法优化，秒回的查询是需要建立大量合适的索引和算法。
固定场景下的大数据中台——深中台 vs 广中台 ，不是替换关系，而是补充和加强
接着需要思考固定场景需要什么粒度？以可以确定概念数据模型为准。
总结来说就是，高度抽象，涵盖这个场景多个查询；业务人员可懂，可以和业务人员沟通，并验证场景；数据关系与逻辑可验证，结合概要设计，可以初步验证整体数据逻辑与设计逻辑。
概念数据模型（Conceptual Data Model）：简称概念模型，是面向数据库用户的现实世界的模型，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等。
主要目的是为了让技术人员更深入理解业务场景，修正模型，同时验证业务计算逻辑，为算法设计铺路，最终让业务人员理解最终底层逻辑，有利于未来业务人员自己定义自己的查询逻辑和业务指标。
业务验证先验证明细业务逻辑与思路，口径细节最终交给业务用户，算法和优化是另外的事情。
需要注意的是，概念模型虽然可以使用大宽表，但覆盖的场景相对更少，也需要注意明细数据而不是汇总数据，这与大数据平台、数据仓库的BDS层（业务汇总层）有区别。
实际情况vs理想情况
选择数据查询底层引擎与技术生态
Ad-hoc 底层引擎选型标准有4条，即支持SQL，支持JDBC；内存计算而不是磁盘计算；支持即席从明细当中进行统计，而不是事先生成Cube（查询场景不同）；开源（推荐Apache社区或者全部Apache协议）。
这里需要给大家介绍以下，为什么会推荐开源选择Apache生态？
Apache开源确保Licence、未来各种使用不会出现任何商业问题，而且社区互动也可以快速提高团队能力。同时，Apache开源版本对人员素质要求较高，启动时代价相对较高。（点击理解更多易观大数据平台Apache的详情）
常见Ad-hoc底层引擎介绍
Spark SQL ：Spark 处理结构化数据的程序模块。它将 SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。
Presto：一个分布式SQL查询引擎， 它被设计为用来专门进行高速、实时的数据分析。Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。
Impala ：Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互SQL大数据查询工具，它拥有和Hadoop一样的可扩展性、它提供了类SQL（类Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。
HAWQ：一个 Hadoop 上的 SQL 引擎，是以 Greenplum Database 为代码基础逐渐发展起来的。HAWQ 采用 MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。除了能高效处理本身的内部数据，还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。
ClickHouse：由俄罗斯Yandex公司开发。专为在线数据分析而设计。采用列式存储；数据压缩；基于磁盘的存储，大部分列式存储数据库为了追求速度，会将数据直接写入内存，按时内存的空间往往很小；CPU 利用率高。
Greenplum：一个开源的大规模并行数据分析引擎。借助MPP架构，在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。
对比参照物
Hive：建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL）。
几款常见引擎性能对比
TPC-DS测试
TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张维度表平均每张表含有18列。其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。因此TPC-DS成为客观衡量多个不同Hadoop版本以及SQL on Hadoop技术的最佳测试集。
本次测试采用TPC-DS提供的dsdgen命令工具生成指定量级的测试数据，我们指定数据量级为100G。
多表SQL测试
更多测评结果请前往知乎搜索「开源OLAP引擎哪个快？」
做好以上准备后，就需要选择适合自己企业的开源技术生态，并积极贡献。
使用一个开源技术生态的代码，不仅使用还要参与其中，这样不仅贡献了社区，也打磨了团队。如根据水平选择团队可以参与社区（Java? C?）；积极贡献从社区中获得最好的支持；积极贡献让团队成员技术也获得最大的收益。
Presto深度参与，开源最新的大小Pool Feature帮助我们解决用户问题
企业自建Ad-hoc引擎要点与参考架构
企业初期可以直接使用上面的底层引擎来解决相关问题，但往往还不能满足需求，企业会基于上述底层引擎自己二次开发企业自己需要的功能。
中阶使用者
如何应对数据底层引擎的更迭
数据输入（导入、采集）
数据如何展现
高阶使用者
数据查询实时性的索引
数据权限
数据查询队列
中阶：
1、如何应对底层引擎的更迭
大数据行业一直在发展，没有一个引擎是永远最快的，如何确保底层引擎更替？分离计算与存储，分而治之的方法——大数据Iota架构；没有银弹，带来的挑战——Connector的效率问题。
易观开源的 Connector https://github.com/analysys
2、数据怎么来——数据采集与数据导入
涉及到数据实时性，数据来源，建议直接从源系统直接引入，也就是嵌入代码（SDK）的方式，退而求其次，采用数据导入的方式，这里分享两个开源工具：
易观开源的用户数据采集SDK Toolset:
易观开源进入Apache社区的可视化多活 Apache Dolphin Scheduler：
3、数据如何展现——数据采集与数据导入
AirBnB开源的Superset：
https://github.com/apache/incubator-superset
百度开源的可视化套件Apache Echart：
高阶：
1、数据查询实时性的索引
进阶情况下，数据量巨大（千亿——千万日活，一天3亿，一年数据）需要Ad-hoc秒级返回，只靠底层引擎无法完成，那么就需要增加底层索引，并在查询时做查询中间层。
2、数据权限要从概念模型做起
进阶情况下，数据权限需要根据概念模型，每个模型设定相关权限，来应对用户“各种各样“的权限要求。以用户分析 主-谓-宾模型为例，用户、行为、商品都要设置权限与脱敏，在数据中间层实现。支持全局&分用户的字段脱敏及权限逻辑分别设置：
平台管理员通过不同层级权限控制，确保数据安全；
支持个体用户设置以及全局设置，方便管理；
高权限管理员可以对单个账号进行设置。
帮助企业内针对不同部门，可以设计不同的脱敏逻辑。
3、数据查询队列是必不可失的Ad-hoc功能
大数据Ad-hoc查询，往往遇到很大的挑战是大量用户在同一时间查询复杂，机器资源不够，大量报错或者用户没有预期的等待导致大量投诉：
可显示的智能分队离线查询进度
基于SQL语法解析，预判查询耗时与查询进度，有正确预期；
并动态决定是否提交到离线队列，避免大查询独占资源影响小查询性能进而影响体验。
用户可随时查询离线进度情况，并回顾历史查询
不着急的查询用户可以离线等待
用户粒度查询记录
可以随时回顾历史查询报表
管理员根据整体优先级，可调整优先级，确保业务顺利执行
平台管理员权限与分行用户权限隔离
平台管理员可针对重要任务提高优先级，灵活统筹系统资源
免费的用户Ad-hoc查询分析工具——易观 Argo
一个企业会有多种场景的Ad-hoc查询工具，互联网用户数据就是其中一种场景。易观Argo是一个针对互联网用户数据免费的Ad-hoc查询、分析工具免费版本上限20万DAU (单机32线64G），年度一亿新增事件量。
总结：构建企业级大数据Ad-hoc查询引擎三部曲
1、选择要解决的业务场景并建模
确定业务场景
抽象概念模型
业务部门共同验证
2、选择数据查询底层引擎与技术生态
底层引擎标准（Apache开源）
常见底层引擎与性能对比
选择开源生态积极贡献
3、企业自建Ad-hoc引擎要点与参考架构
应对底层引擎更迭
数据采集
数据展现
增加查询实时性索引
增加数据权限
增加数据查询队列
还未添加个人签名 2020.07.02 加入
数据智能产品和平台提供商；智能用户运营，就用易观方舟
评论