日志分析：千亿级数量下日志分析系统的技术架构选型

日志分析:千亿级数量下日志分析系统的技术架构选型

随着数据已经逐步成为一个公司宝贵的财富，大数据团队在公司往往会承担更加重要的角色。大数据团队往往要承担数据平台维护、数据产品开发、从数据产品中挖掘业务价值等重要的职责。所以对于很多大数据工程师，如何根据业务需求去选择合适的大数据组件，做合适的大数据架构工作就是日常工作中最常遇到的问题。在这里根据七牛云在日增千亿级的日志分析工作，和大家分享一下大数据技术架构选型的一些经验。

大数据架构师在关注什么

在一个大数据团队中，大数据架构师主要关注的核心问题就是技术架构选型问题。架构选型问题一般会受到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响：

数据量级

这一点在大数据领域尤其是一个重要的因素。不过从根本上讲，数据量级本身也是一种业务场景的衡量。数据量级的不同往往也就昭示着业务场景的不同。

业务需求

经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。

维护成本

这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。

另一方面，大数据架构师要能清楚的了解自己团队成员，能了解其他同学的技术专长和品位，能够保证自己做的技术架构可以得到认可和理解，也能得到最好的维护和发展。

接下来我们会围绕这几个方面去看看，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响？

技术架构选型

业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很有趣的问题，我们在做大数据的过程中，常发现我们对这些需求的疑问很多时候会落在以下几个问题上。

其中数据量级作为一个重要的因素影响着我们对于技术选型的决定，另外在数据量的变化之外各种业务场景的需要也会影响我们对技术组件的选择。

数据量级

如同我们上文中提到的，数据量级这个指标是一个特殊的业务场景的衡量，也是在大数据应用中影响最大的一个因素。往往对应不同的数据量级的业务，我们会有不同的考虑方式。

一般数据量级在 10GB 左右，数据总条数在千万量级的数据，这种数据往往是业务最核心的数据，如用户信息库等。这种数据量由于其核心的业务价值，往往要求强一致性和实时性。在这种量级上，传统关系型数据库如 MySQL 等都能很好的解决各种业务需求。当然如果面对关系型数据库难以解决的问题，比如全文索引等的时候，架构师还是需要根据业务需求选择 Solr 或者 Elasticsearch 等搜索引擎解决此类问题。

如果数据量级增长到 1 亿到 10 亿级别的时候，一般来说这个阶段就会面临一个选择，是采用传统的 RDBMS+ 合理的索引+分库分表等各种策略呢？还是应该选择一些诸如 SQL On Hadoop 或者 HTAP、OLAP 组件呢？这时候灵活性其实还是相对比较大的，一般我们经验是，如果团队内有数据库及中间件方向的专家工程师，希望保持架构简单性，可以选择继续使用传统关系型数据。但是如果为了对未来业务有更高的扩展性，能够在可见的时间内支撑起更广泛的业务需求，还是建议选择使用大数据组件。

当数据量已经增长到 10 亿到百亿级别，特别是 10TB 以上了之后，往往我们传统的关系型数据库基本就已经被我们排除在可选的技术架构之外了。这时候常常要结合各种业务场景去选择具体的场景的技术组件，比如我们要仔细审视，我们的业务场景是否是需要大量的更新操作？是否需要随机读写能力？是否需要全文索引？

以上是一些主流的分析型引擎在各个数据量级下大致的表现结果，这个图表中的数据仅仅是在大部分场景下的一般表现情况（并非精确测试结果，仅供参考）。不过值得注意的是，虽然看起来我们总是希望响应时间越少越好，数据量级越高越好，但要知道大数据领域并没有银弹，能够解决所有的问题。每个技术组件都是牺牲了部分场景，才能在自己的领域中保持优势。

实时性

实时性是一个如此重要的因素，所以我们在一开始就必须要重点的考虑业务需求中对实时性的要求。业务中的实时性往往包含两方面的含义：

一方面，实时性体现在数据摄入的实时性上，数据摄入的实时性指的是当业务数据发生变化时候，我们的大数据应用能接受多少的延迟能看到这个数据？从理想情况上来说，当然业务上无论如何都是希望系统越实时越好，但是从成本和技术上两方面去考量这个问题，我们一般分为实时系统（毫秒延迟）、近实时系统（秒级延迟）、准实时系统（分钟级延迟）和离线系统（小时级或者天延迟）。一般延迟时间和吞吐能力，和计算能力都是反比的，吞吐越强，计算越精确，延迟时间会更长。

另一方面，实时性也体现在查询的延迟上面，这个延迟计算的是，用户发出查询请求之后，要等待多长时间，服务端能够返回计算结果。这个大部分情况下决定于产品的具体形态，如果这个产品是要给终端用户进行展示，比如风云榜、热搜榜、推荐商品等统计类产品，是要有很高的 QPS 需求的产品，必然会需要将延迟控制在亚秒级。在另一种场景下，如果一个产品是给数据分析师，或者运营人员进行数据探索使用，往往这时候会经过大规模且不可控制的计算，这时候可能更适合于一种离线任务的模式，用户的忍耐程度也会更高，支持分钟级甚至小时级别的数据输出。

可以从这个图中看出，一般在实时领域会选择 HBase，Cassandra 这种能支持事务同时支持高更新吞吐量的技术组件，或者也可以选择 TiDB、Spanner、Kudu 等这种 HTAP 组件，同时支持事务和分析的分布式数据库。

如果追求更高的分析性能，可以选择专业的 OLAP（On-Line Analytical Processing）组件，如 Kylin 或者 Druid，他们属于 MOLAP （Multi-dimensional OLAP），支持提前创建数据立方，对指标进行预聚合，虽然牺牲一定的查询灵活程度，但是保证了查询实时性。

而 Elastic Search 是相对最为灵活的一个 NoSQL 查询引擎，一方面它支持全文索引，这个是其他引擎所不具备的。另外它也支持少量的更新，支持聚合分析，也支持明细数据的搜索查询，在近实时领域适用场景非常的多。不过由于 ES 是基于 Lucene 的存储引擎，相对需要资源成本会更高，而且分析性能对比其他引擎不具备优势。

另外，如果我们的数据是离线或者追加的方式进行归档，同时产品形态需要依赖大批量数据的运算。这种产品往往可以忍受较高的查询延迟，那么 Hadoop 生态的一系列产品会非常适合这个领域，比如新一代的 MapReduce 计算引擎 Spark，另外一系列 SQL On Hadoop 的组件，Drill，Impala，Presto 等各有各自的优点，我们可以结合其他业务需求来选型。

计算维度/灵活度

计算维度和计算灵活度，这两个因素是对计算选型很重要的因素。试想一下，如果我们的产品只产出固定的若干指标项，我们完全可以使用 Spark 离线计算将数据结果导入到MySQL 等业务数据库中，作为结果集提供展示服务。

但当如果我们的查询是一个交互式的，如果用户能够自己选择维度进行数据聚合，我们无法将所有维度的排列组合都预计算出来，那这时候我们可能就需要的是一个 OLAP 组件，需要能够根据指定维度做指标预聚合，这种选型能增强结果展示的灵活度，也能大大降低查询的延迟。

更深一步，用户如果不仅仅能够对数据指标进行计算，同时要能够查询到原始的明细数据，这时候可能 OLAP 组件不再适用，那么可能就需要到 ES 或者 SQL On Hadoop 这样更加灵活的组件。这时候如果有全文搜索需求，那么就选择 ES，如果没有就选择 SQL On Hadoop。

多租户

多租户需求也是一个大数据架构师经常需要考虑到的问题，多租户的需求往往是来源于许多不同的使用方，这种需求对于一个公司的基础架构部门非常常见。

多租户要考虑哪些呢？