通过多年的大数据平台建设经验，CTO心中美丽的流沙向大家分享了大数据实时搜索引擎建设过程中获得的经验和挑战，大数据者如何迅速建立了自己的大数据搜索引擎套件，从而实现了自己的数据搜索。

以下是具体内容。

作为数据人的你，遇到了这种情况吗？

数据需求的80%是出数据出报告的需求，但是很多报告只使用一次…暂时的分析很多，无论怎么提前汇总加速开发，业务部门总是很慢…无论反复检查暂时的报告数据口径，最后都会出现数据“写脚本需要3分钟、几个小时”…随着业务的快速变化，数据源不断变化，准确保持统计层的数据非常困难，数据管理建设并不容易。 维护成本更高…大数据工程师每天写各种ETL、数据流脚本，但无法集中精力于大数据技术…究其原因，可知不是数据技术能力差，而是世界变化太快数据驱动本身是一个透明化的过程，业务变化很快，使数据本身“不透明”是一个难题。

业务变化，数据定义变化快，如APP重复，页面变化； 数据经过多次加工，原始信息丢失，仓库表多，多次有血缘关系，全身牵引启动； 数据处理能力不足，时滞： T 1，临时需求T N，OLAP Cube也不能满足需求； 我想临时查询一下，但是数据量太大，TB级数据的普通查询以几十分钟为单位得出结果，跟不上分析师的思路。

怎么办才好呢？ 破局的关键是将即席查询从现有的大数据体系中分离出来。

使用最新的大数据技术ad hoc，让业务人员直接从最详细的数据中统计，秒返回结果，将业务口径返回给业务人员，技术人员只进行最底层的数据整理。

大数据Ad-hoc引擎的优缺点是什么？

好处：

业务负责人不等，直接统计相关数据

业务人员定制口径，数据管理工作量小

技术人员不需要每天计数，而是集中在技术平台上

缺点：

需要额外的硬件/系统资源

数据场景比较单一，需要优秀的数据模型抽象化

新技术的引进、维护和升级工作量问题

企业需要根据自身情况选择是否构建大数据自组织查询引擎。

那么，如何构建企业级的大数据即席查询引擎呢？ 重要的是，选择要解决的业务场景并进行建模，这三个步骤是数据查询的基础引擎和技术生态选择企业自建ad hoc引擎的点和参考体系结构。

选择要解决的业务场景并建模

需要首先选择固定的业务场景。

日常工作场景中数据量巨大，秒回硬件的成本太高，并非所有公司都是谷歌的数据结构复杂，因此难以通过多个业务场景抽象和固定数据模型，最后，查询可以优化以秒为单位的查询需要创建大量适当的索引和算法。

固定场景下的大数据中台——深中台vs广中台不是交换关系，而是补充和加强

其次，需要考虑固定场景需要什么样的粒度。 以能够确定概念数据模型为基准。

总结起来，高度抽象、涵盖该场景多个查询的业务人员可以理解，可以与业务人员进行交流，验证场景的数据关系和逻辑，可以结合概要设计，初步验证整体的数据逻辑和设计逻辑

概念数据模型Conceptual Data Model )，简称概念模型，是面向数据库用户的现实世界的模型，主要用于描述世界的概念结构。 这样，数据库的设计者在设计的初期阶段，就可以摆脱计算机系统和DBMS的具体技术问题，集中精力进行数据和数据之间的联系等分析。

概念模型示例——用户数据分析、物流分析

概念数据模型的验证有助于建立技术和业务的深入沟通渠道。 在大数据中，剧本不是技术IT )项目，而是技术和业务相结合的项目。

主要目的是让技术人员更深入地了解业务场景，修改模型，验证业务计算逻辑，为算法设计铺路，最终让业务人员了解最终的基础逻辑，帮助未来的业务人员自己定义自己的查询逻辑和业务指标

业务验证首先验证详细的业务逻辑和思路，口径细节最终交给业务用户，算法和优化是两回事。

需要注意的是，概念模型可以使用宽表，但涵盖的场景相对较少，不汇总数据也需要注意详细数据，这与大数据平台、数据仓库的BDS层业务聚合层)有关

实际情况vs理想的状况

lass=”pgc-h-arrow-right”>选择数据查询底层引擎与技术生态

Ad-hoc 底层引擎选型标准有4条，即支持SQL，支持JDBC；内存计算而不是磁盘计算；支持即席从明细当中进行统计，而不是事先生成Cube（查询场景不同）；开源（推荐Apache社区或者全部Apache协议）。

这里需要给大家介绍以下，为什么会推荐开源选择Apache生态？

Apache开源确保Licence、未来各种使用不会出现任何商业问题，而且社区互动也可以快速提高团队能力。同时，Apache开源版本对人员素质要求较高，启动时代价相对较高。

Apache HDFS

常见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张事实表，17sqdxxm表平均每张表含有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:

https://github.com/analysys

易观开源进入Apache社区的可视化多活 Apache Dolphin Scheduler：

https://github.com/apache/incubator-dolphinscheduler

3、数据如何展现——数据采集与数据导入

数据展现，初步使用可以尝试AirBnB开源的Superset，基本展现需求都满足，有能力的建议使用百度开源的E-Chart二次开发Dashobard会更加有力。

AirBnB开源的Superset：

https://github.com/apache/incubator-superset

百度开源的可视化套件Apache Echart：

https://github.com/apache/incubator-echarts

高阶：

1、数据查询实时性的索引

进阶情况下，数据量巨大（千亿——千万日活，一天3亿，一年数据）需要Ad-hoc秒级返回，只靠底层引擎无法完成，那么就需要增加底层索引，并在查询时做查询中间层。

以用户分析为例，易观方舟转化漏斗界面

2、数据权限要从概念模型做起

进阶情况下，数据权限需要根据概念模型，每个模型设定相关权限，来应对用户“各种各样“的权限要求。以用户分析 主-谓-宾模型为例，用户、行为、商品都要设置权限与脱敏，在数据中间层实现。支持全局&分用户的字段脱敏及权限逻辑分别设置：

平台管理员通过不同层级权限控制，确保数据安全；支持个体用户设置以及全局设置，方便管理；高权限管理员可以对单个账号进行设置。

帮助企业内针对不同部门，可以设计不同的脱敏逻辑。

3、数据查询队列是必不可失的Ad-hoc功能

大数据Ad-hoc查询，往往遇到很大的挑战是大量用户在同一时间查询复杂，机器资源不够，大量报错或者用户没有预期的等待导致大量投诉：

可显示的智能分队离线查询进度

基于SQL语法解析，预判查询耗时与查询进度，有正确预期；并动态决定是否提交到离线队列，避免大查询独占资源影响小查询性能进而影响体验。

用户可随时查询离线进度情况，并回顾历史查询

不着急的查询用户可以离线等待用户粒度查询记录可以随时回顾历史查询报表

管理员根据整体优先级，可调整优先级，确保业务顺利执行

平台管理员权限与分行用户权限隔离平台管理员可针对重要任务提高优先级，灵活统筹系统资源

易观内部用户数据分析Ad-hoc查询实例

免费的用户Ad-hoc查询分析工具——易观 Argo

一个企业会有多种场景的Ad-hoc查询工具，互联网用户数据就是其中一种场景。易观Argo是一个针对互联网用户数据免费的Ad-hoc查询、分析工具免费版本上限20万DAU 单机32线64G），年度一亿新增事件量。

总结：构建企业级大数据Ad-hoc查询引擎三部曲

1、选择要解决的业务场景并建模

确定业务场景抽象概念模型业务部门共同验证

2、选择数据查询底层引擎与技术生态

底层引擎标准（Apache开源）常见底层引擎与性能对比选择开源生态积极贡献

3、企业自建Ad-hoc引擎要点与参考架构

应对底层引擎更迭数据采集数据展现增加查询实时性索引增加数据权限增加数据查询队列

————————————