随着数据逐渐成为企业宝贵的资产，大数据团队在企业中的角色也越来越趋向于承担更重要的角色。 大数据团队往往要承担数据平台维护、数据产品开发、从数据产品中∏挖掘商业价值等重要职责。 因此，对于很多大数据工程师来说，如何根据业务需求选择合适的大数据组件，做好合适的大数据架构工作，是日常工作中最常遇到的问题。 在此，基于七牛云日增千亿级的日志分析Ψ 工作，与大家分享一些大数据技术架构选型的心得。

大数据架构师关注什么

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

这在大数据领域尤为重要。 但从根本上说，数据量级本身也是业务场景的衡量标准。 数据量级的不同，往往代表着业务场景的不同。

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

对此，一方面，大数据架构师必须能够清楚地了解各种大数据技术栈的优缺点。 在满足业☉务需求的要求下，他们可以充分优化架构。 合理的架构可以降低维护成本，提高开发效率。 效率。

另一方面，大数据架构师必须能够清楚地了解自己的团队成员，了解其他同学的技术专长和品味，保证自己的技术架构能够被认可和理解，以及最好的维护和发展。

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

技术架构选择

业务需求是多种多样的，影响我们技术选择的往往不是各〖种需求的细节，而是经过细化后的一些具体场景。 比如业务需求建议我们要搭建一个日志分析系统，或者用户行为分析系统。 在这些具体要∩求的背后，我们应该注意哪些具体点呢？ 这是一个非常有趣的问题。 在做大数据的过程⌒　中，我们经常会发现，我们对这些需求的疑问，往往会落在下面几个问题上。

其中，数据层面是影响我们技术选型决策的重要因素。 另外，各种业务场景的需求，除了数据量的变化，也会影响我们对技术组件的选择。

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

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

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

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

以上是一些主流分析引擎在各个数据层面的一般性能结果。 本图表数据仅为大部分场景下的一般表现（并非准确测试结果，仅供参考）。 不过，值得注意的是，虽然看起来我们总是希望响应时间越短越好，数据︻量越多越好，但要知道大数据领域没有灵丹妙药可以解决所有问题。 每个技术组件都牺牲了一部分场景，以保持在自己领域的优势。

实时性就是这么重要的一个因素，所以我们一开始就要着眼于业务需求的实时性要求。 业务中的实时往往包括两层含义：

一方面，实时性体现在数据摄入的实时性上。 数据摄入的实时性是指当业务数据发生变化时，我们的大数据应用能够接受多少延迟才能看到这些数据？ 理想情况下，当然在业务●上，系统越实时越好，但是从成本和技术两个方面考虑这个问题it技术人员，我们一般分为实时系统（毫秒级延迟），近实时系统-时间系统（秒级延迟）、准实时系统（分钟级延迟）和离线系统（小时级或天级延迟）。 通常，延迟时间、吞吐量和计算能力是成反比的。 吞吐量越强，计算越准确，延迟时间越长。

另一方面，实时性还体现在查询延迟上。 这个延迟被计算为用户在发送查询请求后服务器可以返回计算结果之前需要等待多长时间。 在大多数情况下，这取决于产品的具体形式。 产品如果要展示给终端用户，比如风云榜等统计产品、热搜榜、推荐产品等，就必须有很高的QPS需求。 您将需要亚秒级延迟。 另外一个场景，如果一个产品被数据分析师或者运维人员用来进行数据探索，这时候往往会进行▼大规模的、不可控的计算，可能更适合离线的任务模式。 用户也会更有耐心≡，支持分钟级甚至小时级的数据输出。

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

如果追求更高的分析性能it技术人员，可以选择专业的OLAP（On-Line）组件，比如Kylin或者Druid，属于MOLAP（Multi-OLAP），支持数据立方体的提前创建和指标的预聚合，虽然牺牲了一定的Query灵活性，但是保证了查询的实时性。

它是相对最№灵活的NoSQL查询引擎。 一方面，它支持全文索引，这是其他引擎所不具备的。 此外，还支持明细数据的小量更新、聚合分析、搜索查询，适用于近实时领域的诸多场景。 但是由于ES是基于存储引擎的，相对资╳源成本会更高，分析性能与其他引擎相比也没有优势。

另外，如果我们的数据是离线或者附加归档的，产品形态需要依赖大批量数据的操作。 这类产品往往可以容忍高查询延迟，所以一系列的生态产品会非常适合这个领域，比如新一代的计算引擎Spark，还有另外一系列的SQL On组件，Drill等，各有各的各有优势，可以结合其他业务需求选择机♂型。

计算维度和计算灵活性，这两个因素是计算模型选择非常重要的因素。 试想一下，如果我们的产品只产生固定数量的指标，我们可以使用Spark离线计算，将数据结果导入到MySQL等业务数据库★中，以结果集的形式提供展示服务。

但是如果我们的查询是交互式的，如果用户可以选择维度进行数据聚合，我们无法预先计算所有维度的排列组合，那么这时候我们可能需要一个OLAP组件，它需要能够◣预索引索引- 基于指定维度的聚合，可以增强结果展示的灵活性，大大降低查〓询延迟。

更进一步，如果用户不仅可以计算数据指标，还可以查询原始的明细数据，此时OLAP组件可能不再适用，可能需要ES或SQL On等更灵活的组件。 这时候如果有∑全文检索的需求，就选择ES，如果不需要，就选择SQL On。

多租户需求也是大数据架构师经常需要考虑的问题。 多租户需求通常来自许多不同的用户。 这种需求对于公司的基础设施部门来△说是很常见的。

多租户应该考虑什么？

首先是资源隔离。 从资←源节约的角度来说，一定是不同租户之间共享资源，才能充分利用资源。 这也是我们普遍希望基建部门做的最多的事情。 但是对于很多租户来说，可能业务层次●更高，或者数据量更大。 如果他们与普通租户共享资源，可能会造成资源竞争。 这时候就需要考虑物理资源的隔离了。

其次，要考虑用户安全。 一方面，需要进行身份验证以防止＠恶意或未经授权访问数据。 另一方面，要做好安全审计，对每一个敏感操作都要记录审计日志，可以追溯到每一个动作的源IP和操作用户。

第三点也是最重要的一点是数据权限。 多租户系统不仅仅意味着隔离，还意味着可以更合理有效地共享和利用资源。 现在的数据权限ξ　往往不能局限于一个文件或者一个仓库的读写权限。 更多时候，我们可能需要对数据的子集和某些数据字段进行数据授权，以便每个数据所有者可以更安全地将他们的资源分配给所需的租户。 更高效地利用数据也是数据平台/应用的◥重要使命。

对于架构师来说，大数据平台的维护成本是一个至关重要的指标。 有经验的架构师可以根据自己团队的特点选择合适的技术方案。

从上图可以看出，大数据平台可以根据服务依赖（是↘依赖云服务还是自建大数据平台）和技术组件的复杂程度分为四个象限。

? 使用成本与技术组件的复杂性成正比。 一般来说，组件的复杂度越高，组件的数量就越多，使用多个组件的成本也越高。

? 维护成本与服务提供商》和组件的复杂性有关。 一般来说，单一技术组件的维护成本低于复杂技术组件，云服务提供的技术组件维护成本低于自建大数据组件。 低的。

? 在团队需求方面，一般来说，与使用成本趋于一致。 技术组件越复杂，对团队的要求就越高。 但是，另一方面，团队需要与服务提供商建立关系。 如果云服务商能够承担▃组件的运维，其实可以帮助业务团队把更多的工程师从运维工作中解放出来，参与到大数据中来。 工作中的应用。

因此，一般来说，架构师对技术选型的偏好应该是在满足业务需求和数据量要求的前提下，选择最简单的技术架构，因为这种选型往往是最容易使用和维护的。 在此基础上，如果你有非常强大的技术开发和运维团队，你可以选择搭建自己的大数据平台； 如果你缺乏足够的运维和开发支持，那么建议选择云服务平台来支持你的业务。

整理/夏立成 上海蓝梦创始人兼CEO，湖北IT公司副总裁，致力于以IT外包网络维护服务赋能企业客户发展，帮助企业客户创新、迭代、进化。