设计大型dmp系统上mongodb并不是什么灵丹妙药

1、52-设计型DMP系统（上）：MongoDB并不是什么灵丹妙药如果你讲讲跟到现在，那先要恭喜你，上就看到胜利的曙光了。过去的50多讲，我把计算机组成原理中的各个知识点，点点和你拆解了。对于其中的很多知识点，我也给了相应的代码例和实际的应案例。不过呢，相信你和我样，觉得只了解这样个个零散的知识点和案例还不过瘾。那么从今天开始，就进应篇。我会通过两个应系统的案例，串联起计算机组成原理的两块知识点，个是的整个存储器系统，另个然是的CPU和指令系统了。今天就先从搭建个型的DMP系统开始，利组成原理学到的更深地理解计算机组成原理。器知识，来做选型判断，从DMP：数据管理先来看下DMP系统。DMP系统的全

2、称叫作数据管理（Data Management Platform），mendation）这些领域。前泛应在互联的告定向（Ad argeting）、个性化（通常来说，DMP系统会通过处理海量的互联数据以及机器学习算法，给个标注上各种各样的。然后，在作。论是个DMP系统。做个性化和告投放的时候，这些这些，去做实际的告排序、等的搜索告、淘宝千千的商品信息，还是抖的信息流，背后都会有那么，个DMP系统应该怎么搭建呢？对于外部使DMP的系统或者来说，可以简单地把DMP看成是个键 值对（Key Value）数据库。的告系统或者系统，可以通过个客端输的唯标识（ID），然后拿到这个的各种信息。这些信息中，有些

3、是的属性信息（Demographic），如、；有些是常具体的为（Behavior），如最近看过的商品是什么，的机型号是什么；有些是通过算法系统计算出来的（erests），如喜欢健、听乐；还有些则是完全通过机器学习算法得出的算法或者告算法作为数据输。向量，给后的基于此，对于这个KV数据库，的期望也很清楚，那就是：低响应时间（Low Response ime）、可性（High Availability）、并发（High Concurrency）、海量数据（Big Data），同时需要付得起对应的成本（Aordable Cost）。如果数字来衡量这些指标，那么的期望就会具体化成下这样。1. 低响应时

4、间：般的告系统留给整个告投放决策的时间也就是10ms左右，所以对于数据，预期的响应时间都在1ms之内。DMP获取2. 可性：DMP常常在告系统。DMP系统出问题，往往就意味着整个的告收在不可的时间就没了，所以对于可性的追求可谓是没有上限的。2018年的告收是1160亿美元，折合到每分钟的收是22万。即使做到 99.99% 的可性，也意味着每个都会损失100万。3.并发：还是以告系统为例，如果每天就在 100亿 / (86400) = 12K 次左右，所以需要响应100亿次的告请求，那么的DMP需要持并发。每秒的并发请求数4.数据量：如果的产品针市场，那么需要有10亿个Key，对应的假设每个有5

5、00个标签，有对应的分数。和分数都个4字节（Bytes）的整数来表，那么共需要 10亿 x500 x (4 + 4) Bytes = 400 B 的数据了。5.低成本：还是从告系统的度来考虑。告系统的收通常CPM（Cost Per Mille），也就是千次来统计。如果千次的利润是 $0.10，那么每天100亿次的就是100万的利润。这个利过 $0.10。最好润听起来常了。但是反过来算下，你会发现，DMP每1000次的请求的成本只有 $0.01，甚更低，才能尽可能多赚到点告利润。这五个结合，听起来是不是就不那么简单了？不过，更复杂的还在后呢。虽然从外部看起来，DMP特别简单，就是个KV数据库，但

6、是成这个数据库需要做的事情起来看看。下在这个系统中，关的是蓝的数据管道、绿的数据仓库和KV数据库为了能够成这个KV数据库，需要有个在客端或者Web端的模块，不断的为，向后端的服务器发送数据。服务器端接收到数据，就要把这份数据放到个数据管道（DataPipeline）。数据管道的下游，需要实际将数据到数据仓库（Data Warehouse），把所有的这些数据结构化地起来。后续，就可以通过程序去分析这部分志，成报表或者或者利数据运各种机器学习算法。除了这个数据仓库之外，还会有个实时数据处理模块（Realtime Data Prosing），也放在数据管道的下游。它同样会数据库去。数据管道的数据，去

7、进各种实时计算，然后把需要的结果写到DMP的KVMongoDB真的万能吗？对这的KV数据库、数据管道以及数据仓库，这三个不同的数据呢？你可以先思考下，我这先卖个关。的需求，最合理的技术案是什么我共事过的不少不错的Web程序员，对这个问题的时候，常常会说：“这难的，MongoDB就好了呀！”如果你也选择了MongoDB，那最终的结果定是场。我为什么这么说呢？MongoDB的设计听起来特别厉害，不需要预先数据Schema，速度很快，还能够限平扩展。作为KV数据库，可以把MongoDB当作DMP的KV数据库；除此之外，MongoDB还能平扩展、跑MQL，可以把它当作数据仓库来。于数据管道，只要能够不

8、断往MongoDB，插新的数据就好了。从运维的度来说，个选择真是相当完美！只需要种数据库，技术栈也变得简单了。看起来，MongoDB这但是，作为个程序员，第次听到MongoDB这样“万能”的解决案，第反应是，“天哪有这样的好事”。所有的系统，都有它的适场景，想通过种解决案适三个差异常的应场景，显然既不合理，不现实。接下来，就来仔细看下，这个“不合理”“不现实”在什么地。就来看下数据管道和数据仓上已经讲过DMP的KV数据库期望的应场景和性能要求了，这库的性能取舍。对于数据管道来说，需要的是吞吐量，它的并发量虽然和KV数据库差不多，但是在响应时间上，要求就没有那么严格了，1 2秒甚再多秒的延时都是

9、可以接受的。且，和KV数据库不太的数据读写都是顺序读写，没有量的随机读写的需求。样，数据管道数据仓库就更不样了，数据仓库的数据的量要管道得多。管道的数据就是当时写的数的数据，再据，天有10 B志数据，管道只会写10 B。下游的数据仓库存放数据和实时数据模块加上个2倍的10 B，也就是20 B也就够了。但是，数据仓库的数据分析任务要的数据量就多了。，可能要分析周、个乃个季度的数据。这次分析要的数据可不是10B，是100 B乃1PB。量是巨的。另，天在数据仓库上跑的分析在数据仓库的数任务也不是1个，是成千上万个，所以数据的据，也不像数据管道样，存放个时、最多天的数据，是往往要存上3个甚是1年的数据

10、。所以，需要的是1PB乃5PB这样的空间。我把KV数据库、数据管道和数据仓库的应场景，总结成了想想为什么MongoDB在这三个应场景都不合适。个表格，放在这。你可以对照着看下，在KV数据库的场景下，需要持并发。那么MongoDB需要把成本就会特别了。的数据放在内存，但是这样的在数据管道的场景下，需要的是量的顺序读写，MongoDB则是个档数据库系统，并没有为顺序写和吞吐量做过优化，看起来也不太适。在数据仓库的场景下，主要的数据时顺序，并且需要海量的。MongoDB这样的档式数据库也没有为海量的顺序读做过优化，仍然不是个最佳的解决案。且档数据库总是会有很多冗余的字段的元数据，还会浪费的空间。那该

11、选择什么样的解决案呢？拿着的应场景去找案，其实并不难找。对于KV数据库，最佳的选择案然是使SSD硬盘，选择Aeroe这样的KV数据库。并发的随机并不适合HDD的机械硬盘，400 B的数据，如果内存的话，成本会显得太。对于数据管道，最佳选择然是Kafka。因为追求的是吞吐率，采了Zero Copy和DMA机制的Kafka最化了作为数据管道的吞吐率。且，数据管道的读写都是顺序读写，所以持，上HDD硬盘就好了。也不需要对随机读写提供到了数据仓库，存放的数据量更了。在硬件层使HDD硬盘成了个必选项。否则，的成本就元数会差上10倍。这么量的数据，在上需要定义清楚Schema，使得每个字段都不需要额外据，

12、能够通过Avro/ hrift/ProtoBuer这样的进制序列化的下来，或者脆直接使Hive这样明确了字段定义的数据仓库产品。很明显，MongoDB那样不限制Schema的数据结构，在这个情况下并不好。2012年前后做告系统的时候，也曾经尝试使MongoDB，尽管只是作DMP中的数据报表部分。事实证明，即使是已经做了数据层的汇总的报表，MongoDB都法很好地撑需要的复杂需求。最终，也不得不选择在整个DMP技术栈彻底废弃MongoDB，只在Web应MongoDB。事实证明，我最初的是正确的，并没万能的解决案。总结延伸好了，相信到这，你应该对怎么从最基本的原理出发，来选择技术栈有些感觉了。你应

13、该地从底层的系统的特性和原理去考虑问题。旦能够从这个度去考虑问题，那么你对各类新的技术项和产品的稿，然会有定的免疫了，不会轻易根据商业公司的宣传来做技术选型了。因为低延时、并发、写少读多的DMP的KV数据库，最适合SSD硬盘，并且采专的KV数据库是最合适的。可以选择之前章提过的Aeroe，也可以开源的Cassandra来提供服务。对于数据管道，因为主要是顺序读和顺序写，所以不定要选SSD硬盘，可以HDD硬盘。不过，对于最化吞吐量的需求，使zero copy和DMA是必不可少的，所以现在的数据管道的标准解决案就是Kafka了。对于数据仓库，于是，通常是次写、多次。并且，由于的数据量很，还要考虑成

14、本问题。会HDD硬盘不是SSD硬盘；另，往往会预先给数据规定好Schema，使得单条数据的序列化，不需要像存JSON或者MongoDB的BSON那样，冗余的字段名称这样的元数据。所以，最常的解决案是，Hadoop这样的集群，采Hive这样的数据仓库系统，或者采Avro/ hrift/ProtoBuer这样的进制序列化案。在型的DMP系统设计当中，需要根据各个应场景临的实际情况，选择不同的硬件和的组合，来作为整个系统中的不同组件。阅读如果通过这讲的内容，能让你对型数据系统的设计有了，那就再好不过了。我你去读读数据密集型应系统设计这本书，深了解下，设计数据系统需要关注的各个核要点。课后思考这讲，讲

15、到了数据管道通常所使的开源系统Kafka，并且选择了使机械硬盘。在Kafka的使上，有没有必要使SSD硬盘呢？如果了SSD硬盘，会带来哪些好处和坏处呢？请你仔细思考下，也可以和周围的朋友给其他的同学。如果你觉得有所收获，也请你的想法写在留区，精选留：胖头C 2019-09-02 09:15:21SSD硬盘好处是读写更快，但是使不，在Kafka经常擦除情况下，机械盘更耐，经济，且是顺序读写，机械盘也是很快的，综合还是机械盘更好 3赞webmin 2019-09-02 09:27:35Kafka使SSD硬盘：好处：Kafka是顺序追加写，较适合SSD硬盘的特性；坏处：Kafka的落盘数据类似于志，顺序追加写SSD机械硬盘没有太多的优势，再者擦写太频繁SSD硬盘有擦写，使SSD的性价不如机械硬盘。 1赞2019-09-02 14:16:25我觉得没有必要使SSD，Kafka主要利PageCache来提系统写的性能，且Kafka对磁盘多是顺序读写，在磁盘上提IOPS，并不能显著的Kafka的性能。2019-09-02 10:49:51ssd顺