Druid在OneAPM的大数据分析实践

    我今天的主题是Druid的大数据分析实践。我自己原来在IBM中国研究院做大数据，我记得大概两年前也是在这个会场，我在分享Hadoop在软硬件件协同优化方面的一些经验。现在我在OneAPM，这是一个创业公司，我们刚融完了C轮融资，现在大概有400个人，其中有200个人是研发。

    Druid中文叫德鲁伊，我先做个简单的调查，在座有多少同学听过Druid这个开源项目，能举手示意一下吗？听说过的，OK，说实话其实还是比较少的，实际上我觉得Druid是一个非常有潜力的一个开源项目，可能区别于现在这个开源的Hadoop或者Spark这一系列的开源大数据项目，最大的一个区别就是它还没有进Apache社区。实际上，如果现在大家在自己的一些OLAP多维度组合分析的一些场景下面去尝试用的话，Druid是一个非常好的一个选择，我后面会把Druid的跟其他一些类似功能的开源项目，包括Apache Kylin就是麒麟，包括ElasticSearch，包括LinkedIn最近开源的Pinot做一个对比。另外，我们组建了一个叫Druid中国用户组的微信群，现在大概有两百多人，但我其实觉得这远远不够，因为要推进一个技术的发展的话，肯定要做很多开源社区的技术推广活动，所以我们Druid中国用户组会陆陆续续的做一些线下的Meetup这种技术分享的形式。下面我就从业务层面和技术层面上跟大家分享一些Druid的一些特点。先讲一下用Druid的一些特点，我们这个公司本身就是创业型公司，最早的时候，我们后台部的数据实际上就是MySQL，很简单，后来数据量大了以后我们换了一个版本，用了HBase，并在HBase上面加了一层SQL层，就是Apache Phoenix那个项目，那个项目是Salesforce开源的。我们当时想把MySQL迁移到Phoenix加HBase上的方案，是因为想平滑的迁移我们的SQL查询，因为我们SQL查询是一些复杂的TOP-N的组合查询，带Group by ,Order by。在我们这个生产系统上线了之后，它的效果非常不好，经常会出现查询10秒都返回不了结果，甚至说查不出来结果。简单来讲的话，HBase加Phoenix不适合干这件事情，你没有把HBase的列式存储这种特点优化好，因为你是生生的套了一个SQL的接口上去。Phoenix本身是很好，它本身对SQL的支持程度，完备程度的支持也是相当不错的，但是等我们把HBase加Phoenix换成了Druid之后，我们发现，这才是真正适合我们业务场景的。那么我们的业务场景到底是什么样子的呢，首先第一点它是一个时间序列的数据流，我们要求对实时进来的数据能够最快速度的被用户查询到，然后我们希望90%以上的查询都能在1s中之内返回结果，而我们这些查询很多都是多维度的组合查询，比如说IP地址，应用ID，当前的metric ID等各种维度非常多，大概六七个维度。同时我们还有很多的指标，就是Metric数值型的指标，代表不同的意义，比如说CPU利用率啊，内存利用率啊，错误率啊，响应时间啊，吞吐量啊，调用次数等等，因为我们是做应用性能管理的，所以很多这种Metric指标数据跟Dimension（维度）的数据组合，要做它们的组合查询。同时我们还有两条这条软件的业务线，一条是我们SaaS，就是我们用户直接在公有云上面去享受这样一个应用性能监控的产品，同时我们还需要支持私有化部署，嵌入到用户的生产系统里面去，所以两种部署模式都需要支持，这是我们对本身数据引擎上一个特点。所以呢我们综合了这种需求之后，做了很多的选型工作，和一些开源项目做一些对比，比如说典型的SQL-on-Hadoop方案，比如SparkSQL，这个在业界已经有很多朋友在用，那包括Impala也算其中一个。我们觉得Druid强处在于它本身是一个Lamda架构，它强处是说实时的injection进来的数据，还能马上被查询到，因为它有列式存储，索引，然后有bitmap，所以它可以快速的做组合的OLAP查询，查询效率还是很高的。所以最后我们觉得在SQL-on-Hadoop这一系列里面，不管是(Impala/Drill/SparkSQL/Presto)都没有Druid适合我们这个场景。而Key/Value Stores(HBase/Cassandra/OpenTSDB)查询速度很快,但要想达到较快的多维聚合功能，往往需要对数据进⾏行预计算(否则会很慢)，不仅难以穷尽所有的查询组合条件，也会带来较⾼高的数据冗余。而Druid在Scan与多维聚合两⽅方⾯面有很⾼高的效率。Spark偏重并强于内存迭代计算，与Druid的领域不同。相反Spark与Druid可以做⽐比较好的集成——Druid扩展Spark的OLAP能⼒，它们是互补型的，而ElasticSearch较之Druid，无法提供复杂的聚合查询功能，而且资源消耗相对较大。Pinot跟Druid架构类似，但是功能不如Druid完善，坑很多。对于这方面，阿里巴巴的同学做过测试，最后他们在Druid和Pinot之间选择了前者。还有就是Kylin，京东等电商公司用的比较多，Kylin主要是空间换时间的方式，灵活性相对来说丧失比较多，和Druid走了不同的两条路，不适合灵活的探索型组合查询。这就是我们和一些热门开源项目对比的结果。当新技术出现时，大家可能会问有没有在大规模场景下做一些验证，那我摘取了Druid官方公布的生产系统指标数据，其中一个应用就是广告公司，有好几百台机器在运行Druid。还有一个就是雅虎，也有500多台的机器在跑数据分析，所以Druid可以每秒写入几百万条的实时性数据，存储500万条的数据，内存总量在100TB以上，查询时90%的数据可以在1s内返回，95%的数据可以在2s内返回，99%的数据可以在10s内返回，这就符合交互式查询的应用场景。当然这肯定是写的多，读的少，一般适用于广告性的，或者同时几百个几千个用户在做查询。如果是亿万个用户同时在查询，那它就不适合了。

    简单介绍一下Druid一些核心的概念，Segment：Druid的数据存储格式，首先来说它是按按时间段分Partition存储，读写不会引起资源竞争，一旦写完后不可更改。Columnar Storage：按需读取、压缩、基于BitMap的索引。DataSource：定义Segment的Schema，类似于RDBMS中的表，包含所有相关的Segment。比如说下面这个案例里面，以GOOGLE为例，包括一些时间戳啊，然后到底是哪个用户名啊，然后是什么语言，什么城市，哪个国家，然后最后两列是维基百科的数据是说这个用户添加了多少个字，然后又删除了多少个字，这样的一个记录。然后这是一个监控界面，把这些Segment的信息，然后数据量多大，里面的metric量有多少，在监控台可以看到用户添加或者删除了哪些信息。

    简单讲一下Druid 架构：我们先说一下黄色的部分，黄色的部分主要是Druid 本身的一些模块，左上角是实时节点real-time node,实时节点一般是通过Kafka进行数据的消费，你可以理解成它本身是一个Kafka 消费者，把数据实时的导入，然后实时节点边导入数据边生成新的Segment，然后他会把Segment的数据落到磁盘，然后到了默认大小，他会做merge,就是类似Hadoop中的merge操作，然后会把它放到左下角deep storage里面去，然后放到HDFS里面去，它一般就是不会再变的了，那然后右下角的historical node就是历史节点，他会把这个已知的Segment先导入到磁盘，然后再加载到内存里面去，然后最右边不是有个broker node，所有的查询的client都是去跟broker node进行交互，然后broker node会同时从实时节点和历史节点拿数据，组合的最后查询的结果之后返回给查询的客户端，这就是大概的一个数据流向。那它当然会做一些交互或者是调度的工作，比如说是coordinator节点，中间的那个黄色的节点，然后HDFS去做数据的交换，整体的就是一个Lamda的一个架构：即有实时的数据流，又有BATCH的数据流。那么这里面又牵扯到一些概念，比如说，因为你要做实时的数据的导入，那你会遇到数据延迟的问题。所谓数据延迟的问题是说，你会设置一个时间窗口，我希望把过去十分钟的数据聚合到一起，然后把它存起来，在后面帮我做查询，因为各种网络延迟的原因，有一个数据它本来是属于前十分钟的，然后他因为延迟在第十五分钟才到了，那它已经错过那个时间窗户了，怎么办，那这就是为什么他会有一个叫做batch data,就是左下方batch data那个数据流，这就是说他会通过batch 这种批处理的任务来补齐这样晚到的数据，这就是帮你去做典型的补齐或者是校验，是这样的一个场景。所以这是他既有实时又有批处理这样的一个设计。好，那简单介绍一下我们自己在OneAPM目前基于 Druid 的应用场景，我们主要有OneAPM利用 Druid 存储查询SaaS数据：AI(Application Insight)，它是监控API，监控一些中间件，不管它是什么语言开发的，都能监控。 BI(Browser Insight)用来监控网页，比如说监控网页的刷新时间啊，还有白屏时间啊,其实也是和用户体验相关的一些性能指标。还有个就是MI(Mobile Insight)，可以监控APP的闪退率啊，http错误率啊等用户体验相关的一些性能指标，那里面会有很多的维度。包括你的IP地址，或者说你来自哪个省份，哪个国家，你到底用的是哪个URL，这些都是维度，还有就是一些性能上的指标，比如说响应时间，吞吐量，这些都是数值型的指标，所以都非常适合像Druid这样的查询场景。我们从数据流角度来讲的时候，就是在各个被监控的对象里面监控的数据实时传送给后台，不管是公有的还是用户的私有部署的那种后台，我们都要求能实时的把数据传回来，能够被用户查询到，说刚刚在过去五分钟之内，或者说过去十分钟之内，三十分钟之内，任意一个时间段内，你每一个应用做组合分析说细节里面的性能指标怎么样，这就是我们典型的一个应用场景。这实际上和我们Druid的场景是非常符合的。这是我们在生产集群里面的一些情况，每天我们进来的实时的数据大概是七十亿条，这是SaaS的，也就是说公有云那块的，每天的数据量大概是超过了三个TB，通过组合查询看出每个性能的指标是怎样的。OneAPM Druid 集群概况，这是SaaS上的，集群分类：生产集群、测试与监控集群，每天实时处理event数：> 7 billion，总Data Source数量：> 10个，每天实时处理数据量: > 3 TB，查询数量：峰值> 8000 QPH，查询平均响应时间：< 150 ms，我们也专门对查询进行了响应时间分布的统计：0 – 100 ms : 70.63%，100 – 200 ms : 16.87%，200 – 300 ms : 5.43%，300 – 800 ms : 6.77%，> 800 ms : 0.3 %。OneAPM Druid 集群拓扑情况：一般每个Druid集群包含:2 Coordinator Nodes，2 Broker Nodes，>= 2 Historical Nodes，1 MySQL database，>= 2 Memcached Nodes。我们还做了一个在datasourse上的，我们还做了OneAPM金字塔结构的Druid DataSources，简单理解的话就是说，我们在业务场景里面，用户是需要查询时三十天的数据的，那么我们就在想如果三十分钟都按最小粒度，也就是按一分钟这样的数据粒度去存的话，那么我们的存储成本真的是非常高。所以呢我们做了一个设计，用金字塔的方案，保证整体的存储率存储成本降低，查询速度还能够提高比较快的方案。我们做了1分钟是一个data source，10分钟是一个data source，1小时各是一个data source的粒度，我们按照分层的方式进行设计，所以它们每层的粒度是不同的。你可以理解成有一个Data Source它最小粒度是一分钟，然后还有一个datasourse是十分钟，有一个datasourse的最小粒度是一个小时，这样的话，如果是最近六个小时的数据，我能保证你可以查到最细粒度，然后如果你要查过去一天或者过去十天的数据，那么之能查到中等细粒度的，如果你想查过去十五天或者过去三十天的那个时间，我们可能保证能查到小时那个精度的，这样进行不同粒度的分层，根据要查询的时间来保证粒度的精度，这就是在金字塔方案中我们对存储和查询的一个折中。

    但凡是一个分布式的系统的话，你都会做一个比较好的监控，那开源项目都会有一个比较突出的特点，就是说，开源项目都会给你暴露一些监控接口，但是这样的监控方案你要自己去做，开源的项目都会开放一个接口，OneAPM Druid 集群监控方案都是自己在做。Druid 通过 metrics 记录集群运行时产生的各个主要指标；Druid可以发送metrics 到log，或者通过http往外发送。

    OneAPM Druid 集群监控方案一：通过http将broker等service产生的metrics发送到一个http proxy(druid-metrics-to-kafka)，然后该proxy再将metrics push到对应的Kafka topic。最后，在用作监控的Druid集群里创建一个独立的DataSource，让其消费该Kafka topic上的数据，并保存到Druid集群中。此时，便可以通过查询该DataSource的内容得到具体的metrics信息——查每一条详细信息、聚合结果、平均值等。OneAPM Druid 集群监控方案二：从Kafka topic上将Metrics数据拉到OneAPM的数据管理平台Cloud Insight(CI)上。CI 兼顾 IT 基础设施和平台服务监控，能够很好地对Druid Metrics进行分析与展示，也可以进一步接上报警系统实现报警功能。这是公司自己做的一个监控。在国内，用Druid的公司也越来越多，比如像阿里，小米，网易有道，优酷，滴滴打车。我们整个社区在不断壮大，而且Druid有加入Apache社区的可能。生态系统方面，Druid的周边项目越来越多，为Druid项目提供了有力的补充。商业推动方面：主要作者创建了基于Druid服务的公司——Imply.io，他们提供数据的监控运维以及可视化方案，正在大力推动Druid的发展。Imply.io下个版本主要新功能：Plywood：提供Javascript接口以查询Druid数据，为Pivot与PlyQL提供基础支持。Pivot：一个Web UI，提供对Druid数据模型做可视化操作与展示。可以通过拖拽的方式进行数据组合的分析。PlyQL：SQL over Druid的解决方案。这就是我今天的主题演讲，谢谢大家。本文相关PPT与音视频请点击【查看】。

演讲嘉宾：陈冠诚  

速记整理：刘颖