本文介绍如何保存原始数据。 原始数据的数据量太大，很难保存。 此数据不能直接咨询或分析业务系统。 有两个理由。 一是数据量太大，二是没有足够的数据结构和查询能力支持业务系统查询。
因此，通常使用流计算或批处理计算对原始数据进行一次或多次过滤、聚合和计算，并将计算结果传递给另一个存储系统，并从该存储系统向业务系统提供查询支持。 这里的“流计算”是指Flink和Storm这样的实时计算，批处理计算是Map-Reduce和Spark这样的非实时计算。
点击流、监控、日志等原始数据是“海量数据中的海量数据”，这些原始数据经过过滤聚合、计算后，往往从TB级的数据量减少到千兆级。
也有计算出的数据非常少的业务。 例如，以天为单位的粒度汇总数据和排名类数据可以满足任何存储的要求。 它有一些业务，不能通过预算解决所有问题。 原始数据的计算结果是，与原始数据相比，数据量略有减少，但仍然是大量数据。 另外，我们需要对这个庞大的数据提供性能可以接受的查询服务。
本文就来聊一聊，面对这样的海量数据，如何才能让查询更快一些。
一、常用的分析系统应该如何选择存储器？ 查询海量数据的系统大多是离线分析类系统。 可以很容易地理解为像制作报告的系统。 也就是说，主要功能是统计分析数据的系统。 这样的系统很大程度上依赖于存储。 选择什么存储系统以及使用什么数据结构存储数据直接决定了数据查询、聚合和分析的性能。
分析系统对存储的需求一般包括：
1、常用于分析的数据量比在线业务大几个数量级，这要求存储系统能够存储大量数据；
2、可以快速聚合、分析、查询大量数据。 请注意，这里的“高速”假设您需要处理GB、TB甚至PB级别的海量数据。 分析如此庞大的数据量，几十秒到几分钟就会快很多。 与在线业务要求的毫秒级别的速度不同。
3、数据大部分是异步写入，因此对写入性能和响应延迟一般要求不高
4、分析系统不直接支撑前端业务，也不要求高并发性。
接下来，让我们看看可以选择的存储产品。 如果您的系统的数据量小于或等于GB订单，则MySQL仍然可以考虑在内。 为什么这么说，是因为它的查询能力可以满足大多数分析系统的业务需求。 另外，可以在线业务系统和一个数据库并用，不需要提取数据(ETL )，省时省力，实时性好。 同样，请注意在分析系统中放置单独的MySQL实例，以避免影响在线业务。
如果数据量超过了MySQL限制，则可以选择列数据库，如HBase、Cassandra和ClickHouse。 这些产品对大量数据具有非常好的查询性能，在正确使用的前提下，10GB级别的数据查询基本上可以秒返回。 高性能的代价是功能上的缩减，这些数据库在组织数据的方式上存在一些限制，查询方式也没有MySQL那么灵活。 很多时候，必须熟悉这些产品的脾气，并按预定的姿势使用，才能达到预期的性能。
另一个需要考虑的选择是电子搜索(es )。 es原本是为了搜索而诞生的存储产品，但也支持结构化数据的存储和查询。 所有这些数据都存储在内存中，并支持分布式并行查询(如Map-Reduce方法)，因此对大量结构化数据的查询性能也非常好。
最重要的是，ES对数据的组织和查询方法有限制，而且不如其他列数据库灵活。 也就是说，ES的查询能力和灵活性优于上述列数据库。 在这个班的几个选手中，我个人强烈建议优先考虑ES。 但是，ES需要配备大内存的服务器，存在硬件成本有点高的缺点。
对于超过TB级的数据量，如果对如此大量的数据进行统计分析，则无论使用什么存储系统，都将无处可去。 此时的性能瓶颈是磁盘I/o和网络带宽。 在这种情况下，绝对不能进行实时查询和分析。 解决方案是定期聚合和计算数据，保存结果，并在必要时重新查询结果。 这样大量的数据一般存储在HDFS中，并与Map-Reduce、Spark、Hive等大数据生态圈产品联合进行数据的聚合和计算。
二、改变你的想法：根据查询选择存储系统面对大量数据，仅仅根据数据量的级别选择存储系统是不够的。
朋友经常说：“我的系统每天产生数GB的数据量，现在已经慢得几乎无法找到了。 你认为改变什么样的数据库才能解决问题？ ”我问你。 那是我的回答。 对不起，换数据库不能解决你的问题。 为什么会这样呢？
因为在过去的几十年中，存储技术和分布式技术在基础理论方面没有得到本质突破。 技术的发展往往体现在应用层面，如集群管理简单，查询更加自动化。 例如，类似于Map-Reduce。 不同的存储系统之间没有本质的区别。 区别仅在于存储引擎的数据结构、如何构建存储群集以及提供的查询功能。 由于这些差异，每个存储都可以在您擅长的领域和场景中提供卓越的性能。
例如，最近很受欢迎的RocksDB、Lev
elDB，它们的存储结构 LSM-Tree，其实就是日志和跳表的组合，单从数据结构的时间复杂度上来说，和“老家伙”MySQL 采用的 B+ 树，有本质的提升吗？没有吧，时间复杂度都是 O(log n)。但是，LSM-Tree 在某些情况下，它利用日志有更好的写性能表现。没有哪种存储能在所有情况下，都具有明显的性能优势，所以说，存储系统没有银弹，不要指望简单地更换一种数据库，就可以解决数据量大，查询慢的问题。但是，在特定的场景下，通过一些优化方法，把查询性能提升几十倍甚至几百倍，这个都是有可能的。这里面有个很重要的思想就是，根据查询来选择存储系统和数据结构。ES 采用的倒排索引的数据结构，并没有比 MySQL 的 B+ 树更快或者说是更先进，但是面对“全文搜索”这个查询需求，选择使用 ES 的倒排索引，就比使用其他的存储系统和数据结构，性能上要高出几十倍。
再举个例子，大家都知道，京东的物流速度是非常快的。经常是，一件挺贵的衣服，下单之后，还没来得及后悔，已经送到了。京东的物流之所以能做到这么快，有一个很重要的原因是，它有一套智能的补货系统，根据历史的物流数据，对未来的趋势做出预测，来给全国每个仓库补货。这样京东就可以做到，你下单买的商品，很大概率在离你家几公里那个京东仓库里就有货，这样自然很快就送到了。这个系统的背后，它需要分析每天几亿条物流数据，每条物流数据又细分为几段到几十段，那每天的物流数据就是几十亿的量级。
这份物流数据，它的用途也非常多，比如说，智能补货系统要用；调度运力的系统也要用；评价每个站点儿、每个快递小哥的时效达成情况，还要用这个数据；物流规划人员同样要用这个数据进行分析，对物流网络做持续优化。
那用什么样的存储系统保存这些物流数据，才能满足这些查询需求呢？显然，任何一种存储系统，都满足不了这么多种查询需求。我们需要根据每一种需求，去专门选择合适的存储系统，定义适合的数据结构，各自解决各自的问题。而不是用一种数据结构，一个数据库去解决所有的问题。
对于智能补货和运力调度这两个系统，它的区域性很强，那我们可以把数据按照区域(省或者地市)做分片，再汇总一份全国的跨区物流数据，这样绝大部分查询都可以落在一个分片上，查询性能就会很好。
对于站点儿和人的时效达成情况，这种业务的查询方式以点查询为主，那可以考虑事先在计算的时候，按照站点儿和人把数据汇总好，存放到一些分布式 KV 存储中，基本上可以做到毫秒级查询性能。而对于物流规划的查询需求，查询方式是多变的，可以把数据放到 Hive表中，按照时间进行分片。
我们之前也讲到过，按照时间分片是对查询最友好的分片方式。物流规划人员可以在上面执行一些分析类的查询任务，一个查询任务即使是花上几个小时，用来验证一个新的规划算法，也是可以接受的。
三、总结海量数据的主要用途就是支撑离线分析类业务的查询，根据数据量规模不同，由小到大可以选择：关系型数据库，列式数据库和一些大数据存储系统。对于 TB 量级以下的数据，如果可以接受相对比较贵的硬件成本，ES 是一个不错的选择。
对于海量数据来说，选择存储系统没有银弹，重要的是转变思想，根据业务对数据的查询方式，反推数据应该使用什么存储系统、如何分片，以及如何组织。即使是同样一份数据，也要根据不同的查询需求，组织成不同的数据结构，存放在适合的存储系统中，才能在每一种业务中都达到理想的查询性能。
前段时间因个人原因停更了，非常抱歉，从今天起每天分享干货，敬请期待 ....
觉得还不错的话，点个红心吧
→公众号：慕容千语