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

千亿级数量下日志分析系统的技术架构选型 在一个大数据团队中，大数据架构师次要关注的核心问题就是技术架构选型问题。架构选型问题一般会遭到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响： 数据量级 这一点在大数据领域尤其是一个重要的因素。不过从根本上讲，数据量级本身也是一种业务场景的衡量。数据量级的不同往往也就昭示着业务场景的不同。 业务需求 阅历丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，依据笼统的技术点选择合适的技术架构。次要的业务需求可能包括：应用实时性要求、查询的维度和机警程度、多租户、平安审计需求等等。 维护成本 这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。 另一方面， 大数据架构师要能清楚的了解本人团队成员，能了解其他同学的技术特长和档次，能够保证本人做的技术架构可以得到认可和理解，也能得到最好的维护和进展。 接下来我们会围绕这几个方面去看看，做一个最适合本人团队业务的架构选型会如何遭到这些因素的影响？ 技术架构选型 业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很好玩的问题，我们在做大数据的过程中，常发觉我们对这些需求的疑问很多时候会落在以下几个问题上。 其中数据量级作为一个重要的因素影响着我们对于技术选型的打算，另外在数据量的变化之外各种业务场景的需要也会影响我们对技术组件的选择。 数据量级 犹如我们上文中提到的，数据量级这个目标是一个特殊的业务场景的衡量，也是在大数据应用中影响最大的一个因素。往往对应不同的数据量级的业务，我们会有不同的考虑方式。 一般数据量级在 10GB 左右，数据总条数在千万量级的数据，这种数据往往是业务最核心的数据，如用户信息库等。这种数据量由于其核心的业务价值，往往要求强全都性和实时性。在这种量级上，传统关系型数据库如 MySQL 等都能很好的处理各种业务需求。当然假如面对关系型数据库难以处理的问题，比如全文索引等的时候，架构师还是需要依据业务需求选择 Solr 或者 Elasticsearch 等搜索引擎处理此类问题。 假如数据量级增长到 1 亿到 10 亿级别的时候，一般来说这个阶段就会面临一个选择，是接受传统的 RDBMS+ 合理的索引 + 分库分表等各种策略呢？还是应当选择一些诸如 SQL On Hadoop 或者 HTAP、OLAP 组件呢？这时候机警性其实还是相对比较大的，一般我们阅历是，假如团队内有数据库及两头件方向的专家工程师，期望保持架构简约性，可以选择连续使用传统关系型数据。但是假如为了对将来业务有更高的扩展性，能够在可见的时间内支撑起更广泛的业务需求，还是建议选择使用大数据组件。 当数据量已经增长到 10 亿到百亿级别，特殊是 10TB 以上了之后，往往我们传统的关系型数据库基本就已经被我们排解在可选的技术架构之外了。这时候经常要结合各种业务场景去选择具体的场景的技术组件，比如我们要认真端详，我们的业务场景能否是需要大量的更新操作？能否需要随机读写力量？能否需要全文索引？ 以上是一些主流的分析型引擎在各个数据量级下大致的表现结果，这个图表中的数据仅仅是在大部分场景下的一般表现情况（并非精确测试结果，仅供参考）。不过值得留意的是，虽然看起来我们总是期望响应时间越少越好，数据量级越高越好，但要晓得大数据领域并没有银弹，能够处理全部的问题。每个技术组件都是牺牲了部分场景，才能在本人的领域中保持优势。 实时性 实时性是一个如此重要的因素，所以我们在一开头就必需要重点的考虑业务需求中对实时性的要求。业务中的实时性往往包含两方面的含义： 一方面，实时性体现在数据摄入的实时性上，数据摄入的实时性指的是当业务数据发生变化时候，我们的大数据应用能接受多少的延迟能看到这个数据？从抱负情况上来说，当然业务上无论如何都是期望系统越实时越好，但是从成本和技术上两方面去考量这个问题，我们一般分为实时系统（毫秒延迟）、近实时系统（秒级延迟）、准实时系统（分钟级延迟）和离线系统（小时级或者天延迟）。一般延迟时间和吞吐力量，和计算力量都是反比的，吞吐越强，计算越精确，延迟时间会更长。 另一方面，实时性也体现在查询的延迟上面，这个延迟计算的是，用户发出查询恳求之后，要等待多长时间，服务端能够前往计算结果。这个大部分情况下打算于产品的具体外形，假如这个产品是要给终端用户进行呈现，比如风云榜、热搜榜、推举商品等统计类产品，是要有很高的 QPS 需求的产品，必定会需要将延迟把握在亚