日志分析：千亿级数量下日志分析系统的技术架构选型
技术架构师的系统架构设计与技术选型
技术架构师的系统架构设计与技术选型技术架构师在软件开发过程中扮演着至关重要的角色，他们负责系统架构的设计和技术选型，对于项目的成功与否起着决定性的作用。
本文将讨论技术架构师在系统架构设计和技术选型方面的重要考虑因素，并探讨了一些常用的技术选型策略。
首先，系统架构设计是技术架构师必须要做的一项重要工作。
合理的系统架构设计可以提高系统的可伸缩性、可扩展性、可维护性和可靠性。
在进行系统架构设计时，技术架构师应该考虑以下几个方面。
1. 功能划分和模块设计：技术架构师需要将系统的功能进行划分，并设计相应的模块。
每个模块应该具有独立的职责，并且可以进行独立的开发和测试。
模块之间的接口要清晰明确，以便实现模块之间的通信和数据交换。
2. 数据管理和存储：在设计系统架构时，技术架构师需要考虑系统中所涉及的数据，包括数据的结构、存储和管理方式。
数据的安全性和一致性是设计的关键要素，技术架构师需要选择适合的数据库和数据存储解决方案。
3. 系统运行环境和部署方案：技术架构师需要确定系统的运行环境和部署方案，包括硬件和操作系统的选择、网络拓扑结构以及系统的容灾和备份策略。
合理选择运行环境和部署方案可以提高系统的性能和可用性。
4. 性能和扩展性：技术架构师需要考虑系统的性能需求，并选择合适的技术方案来满足这些需求。
系统的扩展性也是一个重要的考虑因素，技术架构师需要设计具有良好扩展性的架构，以便在后续的升级和扩展中能够方便地进行修改和调整。
在进行技术选型时，技术架构师需要根据项目的需求和约束条件选择合适的技术解决方案。
以下是一些常用的技术选型策略。
1. 软件框架选型：技术架构师需要选择合适的软件框架来支持系统的开发和运行。
软件框架可以提供一些常用功能的实现，减少开发工作量，提高开发效率。
在选择软件框架时，技术架构师需要考虑框架的功能完备性、性能、稳定性和社区支持等因素。
2. 数据库选型：技术架构师需要选择合适的数据库来存储系统中的数据。
日志分析报告模板
日志分析报告模板1. 引言在现代技术领域，日志分析在系统管理、故障排除和性能优化等方面起着至关重要的作用。
本报告旨在提供一份日志分析报告模板，以帮助团队成员进行有效的日志分析和问题解决。
2. 背景在进行日志分析之前，首先需要了解日志的背景和相关的环境信息。
这些信息包括但不限于：•系统架构：描述系统的整体架构，包括硬件和软件组件。
•日志生成：说明日志是如何生成的，包括日志级别、格式和输出位置。
•日志量：分析日志数量的规模，并识别可能的日志丢失或截断问题。
3. 日志收集和存储在进行日志分析之前，必须首先收集和存储日志。
以下是一些常用的日志收集和存储工具：•日志收集代理：例如Logstash、Fluentd等，用于从源系统收集日志并将其发送到中央存储库。
•中央存储库：例如Elasticsearch、Splunk等，用于集中存储和索引日志数据。
•可视化工具：例如Kibana、Grafana等，用于在可视化仪表板上呈现日志数据。
4. 日志分析流程在日志分析过程中，可以遵循以下步骤：4.1 收集日志数据使用适当的工具和技术从各个源系统收集日志数据。
确保所有日志都被正确地传输到中央存储库以供进一步分析。
4.2 过滤和清洗在进行进一步分析之前，需要过滤和清洗日志数据。
这包括删除无用的日志、提取关键字段和转换日期/时间格式等。
4.3 提取关键指标根据需求，从日志数据中提取关键指标。
这可以包括系统性能、错误频率、用户行为等方面的指标。
4.4 分析和可视化使用适当的分析工具和技术对日志数据进行分析，并将结果可视化呈现。
这有助于识别潜在问题、趋势和模式。
4.5 故障排除和优化根据分析结果，进行故障排除并进行系统性能优化。
这可能涉及调整配置、修复代码错误或优化系统资源等。
5. 结论日志分析是一个重要的技术活动，可以帮助团队识别和解决系统问题。
通过遵循上述步骤，团队可以更加高效地进行日志分析，并改进系统的可靠性和性能。
请注意，该模板提供了一般性的指导，具体的日志分析过程可能因系统和需求而异。
日志分析系统
日志分析系统日志分析系统的重要性和应用当今数字时代，数据量呈现爆发式增长，企业在日常运营过程中产生了大量的日志数据。
这些日志数据蕴含着宝贵的信息，通过对这些数据进行分析和挖掘，企业可以获得深入洞察和有价值的见解，从而优化运营策略，并做出更明智的决策。
为了实现对日志数据的高效分析和应用，日志分析系统应运而生。
日志分析系统是一种用于收集、存储、分析和展示日志数据的工具。
它能够自动化地对日志数据进行处理和解析，并将其转化为可读性和易理解性较强的格式。
通过对日志数据进行统计、查询和分析，日志分析系统能有效地发现和解决潜在问题，帮助企业提升效率、降低风险以及优化用户体验。
日志分析系统的应用领域非常广泛。
首先，它在电子商务行业中扮演着重要的角色。
电子商务平台每天都会收集大量的用户操作日志，通过对这些日志数据进行分析，企业可以了解用户的行为习惯和购买偏好，进而个性化推荐产品和优化用户界面，提升用户体验和满意度。
另外，日志分析系统在网络安全领域也起到了关键的作用。
网络攻击和入侵事件日益猖獗，为了保护企业的网络安全，日志分析系统可以对网络流量数据进行实时监控和分析，及时发现可疑的活动和异常行为，并采取相应的防御措施，保护企业的信息和资产安全。
此外，在软件开发和运维领域，日志分析系统也发挥着重要的作用。
软件系统的稳定性和性能对于企业的正常运营至关重要，通过对系统日志数据进行监控和分析，可以及时发现和定位潜在的问题，并加以解决，保证系统的稳定性和正常运行。
随着云计算和大数据技术的不断发展，日志分析系统也在不断演进和创新。
传统的日志分析系统主要通过批处理的方式进行数据处理和分析，效率和响应速度相对较低。
而现在，借助云计算和大数据技术的应用，日志分析系统可以实现实时处理和分析，大大提高了系统的性能和响应速度。
总之，日志分析系统在当今数字化时代的企业运营中扮演着重要的角色。
它能够帮助企业挖掘隐藏在海量日志数据中的有价值信息，从而优化运营策略、提升用户体验和保护信息安全。
服务器日志管理及分析工具推荐
服务器日志管理及分析工具推荐随着互联网的快速发展，服务器日志管理和分析变得越来越重要。
服务器日志包含了服务器上发生的各种活动和事件记录，通过对这些日志进行管理和分析，可以帮助管理员监控服务器运行状态、排查问题、优化性能等。
为了更高效地管理和分析服务器日志，推荐以下几款优秀的工具：1. **ELK Stack**ELK Stack 是一个开源的日志管理和分析平台，由三个核心组件组成：Elasticsearch、Logstash 和 Kibana。
Elasticsearch 是一个分布式搜索和分析引擎，可以用于存储和检索大量日志数据；Logstash是一个日志收集工具，可以将各种日志数据收集、过滤和转发到Elasticsearch 中；Kibana 则是一个数据可视化工具，可以帮助用户通过图表、表格等形式直观地展示日志数据。
ELK Stack 能够快速构建起一个强大的日志管理和分析系统，广泛应用于各种规模的企业和组织中。
2. **Splunk**Splunk 是一款功能强大的日志管理和分析工具，可以帮助用户实时监控、搜索、分析和可视化各种类型的日志数据。
Splunk 支持从各种来源收集日志数据，包括服务器日志、应用程序日志、网络设备日志等，用户可以通过 Splunk 的搜索语言快速查询和分析日志数据。
此外，Splunk 还提供了丰富的可视化功能，用户可以通过仪表盘、报表等方式直观地展示日志数据的分析结果。
3. **Graylog**Graylog 是一款开源的日志管理平台，提供了日志收集、存储、搜索和分析等功能。
Graylog 支持从各种来源收集日志数据，包括Syslog、GELF、HTTP 等，用户可以通过 Graylog 的搜索功能快速定位和分析特定的日志事件。
此外，Graylog 还提供了警报功能，用户可以设置警报规则，及时发现和响应异常事件。
4. **Fluentd**Fluentd 是一款开源的日志收集工具，支持从各种来源收集日志数据，并将数据转发到不同的目的地，如 Elasticsearch、Kafka、Hadoop 等。
日志分析平台解决方案
日志分析平台解决方案
《日志分析平台解决方案》
随着互联网和移动应用的普及，各种业务系统产生的日志数量急剧增加，如何高效地分析和利用这些日志成为了企业关注的焦点。
日志分析平台解决方案应运而生，成为企业管理日志的得力工具。
日志分析平台解决方案可以帮助企业实时地收集、处理、分析和存储各种日志数据，从而提供实时的监控、统计和可视化分析功能。
它可以帮助企业对业务系统进行监控和分析，以及发现业务问题、优化系统性能、预测潜在故障，从而提高系统的稳定性和可靠性。
日志分析平台解决方案通常包括以下几个功能模块：
1. 数据采集：支持多种数据源的日志采集，包括服务器日志、网络设备日志、数据库日志、应用程序日志等；
2. 数据处理：对采集到的日志数据进行清洗、解析、转换和聚合等处理，以便进一步分析和利用；
3. 数据存储：支持大规模的日志数据存储和管理，包括文件存储、数据库存储等多种存储方式；
4. 数据分析：提供强大的数据分析和挖掘功能，以及实时的监控和报警功能；
5. 数据展现：支持可视化地展现分析结果，如图表、报表、仪表盘等形式。
日志分析平台解决方案的优势在于其高效、可靠、实时的特点。
它可以帮助企业快速地发现问题和故障根因，并提供实时的反馈和预警，从而大大缩短故障处理的时间，提高系统的稳定性和可靠性。
总而言之，日志分析平台解决方案是企业管理日志的得力助手，它为企业提供了高效、可靠、实时的日志管理和分析功能，帮助企业提高系统的稳定性和可靠性，同时降低故障处理的成本和风险。
随着大数据和人工智能技术的不断发展，日志分析平台解决方案将发挥越来越重要的作用。
日志分析系统
日志分析系统日志分析系统在现代信息技术领域中扮演着重要的角色。
随着信息技术的迅猛发展，大量的数据被生成、收集和存储。
这些数据中蕴含着宝贵的信息，通过对数据进行分析，可以帮助人们了解各种现象、提取隐藏的规律和洞察未来的趋势。
而日志分析系统便是其中的一项重要工具。
日志分析系统主要用于对大规模系统产生的日志数据进行收集、处理和分析。
在一个典型的系统中，各种操作都会留下日志信息，记录下了系统运行的轨迹和各种事件的发生。
这些日志数据具有丰富的信息，通过对其进行分析，可以为系统的运行提供指导，发现潜在的问题，甚至预测未来可能出现的故障或风险。
日志分析系统的主要功能包括日志收集、存储、索引和查询。
日志收集是指将分布在多个节点上的日志数据集中起来，并进行统一的管理。
这需要实时地从各个节点中抽取日志数据，并通过某种协议将其传送到集中存储的服务器上。
存储是指将日志数据以一种高效可靠的方式保存下来，以便后续的查询和分析。
索引是指为存储的日志数据建立索引，以便快速地定位和检索特定的日志记录。
查询是指在存储的日志数据上进行复杂的查询操作，以便对系统的运行情况进行全面的了解。
日志分析系统的核心技术包括数据预处理、特征提取、模式识别和可视化。
数据预处理是指对原始的日志数据进行清洗、转换和归一化处理，以便使其适合日志分析的需求。
特征提取是指从清洗后的日志数据中提取有用的特征，以便进行后续的分析和建模。
模式识别是指通过对大量日志数据进行训练和学习，从中发现潜在的规律和模式。
可视化是指将分析结果以直观清晰的方式展示出来，帮助用户更好地理解和利用日志分析的结果。
日志分析系统的应用非常广泛。
在网络安全领域，日志分析系统可以用于监控网络流量，发现异常行为和入侵行为。
在系统管理领域，日志分析系统可以用于监控系统的运行状态，发现潜在的故障和性能问题。
在商业领域，日志分析系统可以用于分析用户的行为模式和购买偏好，以进行精准的推荐和个性化营销。
日志分析方案
日志分析方案随着大数据时代的到来，日志分析成为了企业管理与运营的重要环节。
通过对日志的深入分析，企业可以了解用户行为、产品性能、系统安全等方面的情况，从而帮助企业做出合理的决策和改进。
为了有效地进行日志分析，本文将介绍一种日志分析方案。
一、搜集日志数据在日志分析之前，首先需要搜集到完整的日志数据。
日志数据的来源有多种多样，比如应用系统的自动生成日志、服务器的事件日志、网络设备的日志等等。
可根据需要选择合适的工具或方法，将这些日志数据搜集到中心化的存储系统中。
二、日志预处理在进行日志分析之前，需要对原始的日志数据进行预处理。
预处理的目的是将日志数据进行清洗、过滤和格式化，以方便后续的分析工作。
可以使用脚本编程语言，通过定义正则表达式等方式，将日志数据中的噪声、无效信息进行过滤，同时对数据进行结构化整理。
三、数据存储与管理日志数据的存储和管理是一个重要的环节。
传统的数据库技术已经不能满足日志数据的高容量和高性能要求。
因此，在日志分析方案中，可以选择使用一些专门用于大数据存储和管理的解决方案，比如Hadoop、Elasticsearch等。
这些解决方案具备良好的横向扩展性和高效的查询性能，能够满足大规模日志数据的存储和检索需求。
四、数据分析与挖掘在日志数据存储和管理的基础上，可以进行进一步的数据分析和挖掘工作。
这一步骤可以使用一些常见的数据分析工具和算法，比如关联规则挖掘、聚类分析、分类分析等。
通过这些技术手段，可以发现日志数据中的隐藏规律和潜在问题，并为后续的决策和改进提供依据。
五、可视化与报告最后一步是将分析结果进行可视化展示和报告。
通过可视化展示，可以直观地呈现数据的分析结果，使得用户和决策者更容易理解和获取有价值的信息。
同时，还可以生成定期报告，用于向管理层和关键利益相关方汇报日志分析的结果和效果。
总结：本文介绍了一种日志分析方案，包括日志数据搜集、预处理、存储与管理、数据分析与挖掘以及可视化报告等环节。
安全日志分析服务器事件日志和数据流量分析
安全日志分析服务器事件日志和数据流量分析随着互联网技术和网络安全威胁的不断发展，越来越多的企业与组织开始关注网络安全问题，其中安全日志分析是网络安全保护的关键环节之一。
本文将讨论安全日志分析的两个方面：服务器事件日志分析和数据流量分析。
一、服务器事件日志分析服务器事件日志是对一个系统内发生的事件进行记录的文件，这些事件包括警告、错误、信息等。
服务器事件日志分析是通过对这些事件进行收集和分析，来检测和诊断系统的问题或异常情况。
服务器事件日志分析的主要目的是监视和管理整个系统内的事件，以及对问题进行定位和处理。
通过对服务器事件日志的分析，我们可以做到以下几点：1. 识别与排除系统故障。
2. 检测安全漏洞，并迅速采取措施。
3. 及时发现系统内的错误、故障、崩溃等问题，并解决它们。
4. 了解和掌握整个系统的运行情况，为后续的管理和优化提供支持。
二、数据流量分析数据流量分析是通过对网络上的数据流进行监测和分析，以发现网络攻击、垃圾邮件等恶意行为，并及时采取应对措施。
数据流量分析是以网络流量为基础，通过对数据流量的内容、流量大小等进行分析，来发现可能存在的恶意攻击行为。
数据流量分析主要包括以下几个方面：1. 数据流量监控：对网络上所有数据流量进行监控，并采用多种技术手段进行分析和处理。
2. 异常检测：对网络上的异常数据流量进行检测，以及异常数据的去除。
3. 可视化展示：将分析结果通过图形化界面展现出来，方便管理员进行查看和管理。
通过数据流量分析，我们可以有效地防范网络攻击、提高整个网络的安全性。
数据流量分析可以帮助我们找出网络上可能存在的安全问题，并采取有效的预防和处置措施。
总结：对于网络安全而言，安全日志分析是一项至关重要的任务，它为网络安全保护提供了重要的技术支持。
通过对日志事件和数据流量进行分析，我们可以有效地防范安全威胁、提高网络安全性。
希望本文能够让大家更好地了解和掌握安全日志分析的相关技术和应用。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
日志分析:千亿级数量下日志分析系统的技术架构选型随着数据已经逐步成为一个公司宝贵的财富，大数据团队在公司往往会承担更加重要的角色。
大数据团队往往要承担数据平台维护、数据产品开发、从数据产品中挖掘业务价值等重要的职责。
所以对于很多大数据工程师，如何根据业务需求去选择合适的大数据组件，做合适的大数据架构工作就是日常工作中最常遇到的问题。
在这里根据七牛云在日增千亿级的日志分析工作，和大家分享一下大数据技术架构选型的一些经验。
大数据架构师在关注什么在一个大数据团队中，大数据架构师主要关注的核心问题就是技术架构选型问题。
架构选型问题一般会受到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响：数据量级这一点在大数据领域尤其是一个重要的因素。
不过从根本上讲，数据量级本身也是一种业务场景的衡量。
数据量级的不同往往也就昭示着业务场景的不同。
业务需求经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。
主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。
维护成本这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。
另一方面，大数据架构师要能清楚的了解自己团队成员，能了解其他同学的技术专长和品位，能够保证自己做的技术架构可以得到认可和理解，也能得到最好的维护和发展。
接下来我们会围绕这几个方面去看看，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响？技术架构选型业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。
就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很有趣的问题，我们在做大数据的过程中，常发现我们对这些需求的疑问很多时候会落在以下几个问题上。
其中数据量级作为一个重要的因素影响着我们对于技术选型的决定，另外在数据量的变化之外各种业务场景的需要也会影响我们对技术组件的选择。
数据量级如同我们上文中提到的，数据量级这个指标是一个特殊的业务场景的衡量，也是在大数据应用中影响最大的一个因素。
往往对应不同的数据量级的业务，我们会有不同的考虑方式。
一般数据量级在 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。
多租户多租户需求也是一个大数据架构师经常需要考虑到的问题，多租户的需求往往是来源于许多不同的使用方，这种需求对于一个公司的基础架构部门非常常见。
多租户要考虑哪些呢？第一是资源的隔离性，从资源节省的角度来看，肯定是不同租户之间资源可以共享的话，资源可以充分的利用起来。
这也是我们一般做基础架构部门最希望做的工作。
不过对于很多租户来说，可能业务级别更高，或者数据量更加的庞大，如果和普通的租户一起共享资源可能会造成资源争抢。
这时候就要考虑物理资源的隔离。
第二，就要考虑用户安全。
一方面是要做认证，需要杜绝恶意或者越权访问数据的事情发生。
另一方面要做好安全审计，每次敏感操作要记录审计日志，能够追溯到每次行为的来源 IP 和操作用户。
第三但也是最重要的一点，就是数据权限。
多租户系统并不仅仅意味着隔离，更加意味着资源能够更加合理有效的得到共享和利用。
现在数据权限往往不能局限于一个文件、一个仓库的读写权限。
更多的时候我们可能要对某个数据子集，某些数据字段进行数据授权，这样每个数据所有者能够将自己的资源更加安全的分发给需要的租户。
将数据能够更加高效的利用起来，这也是一个数据平台/应用重要的使命。
维护成本对于架构师而言大数据平台的维护成本是一个至关重要的指标，经验丰富的架构师能够结合自身团队的特点选择合适的技术方案。
从上图可以看出大数据平台可以根据服务依赖（是依赖云服务还是自建大数据平台）和技术组件的复杂度分为四个象限。
• 使用成本和技术组件复杂度成正比，一般来说组件复杂度越高，组件数量越多，多种组件配合使用成本会越高。
• 维护成本和服务供应商以及组件复杂度都有关系，一般来说，单一的技术组件要比复杂的技术组件维护成本低，云服务提供的技术组件要比自建大数据组件维护成本要更低。
• 团队要求来说，一般来说与使用成本趋同，都是技术组件越复杂，团队要求越高。
不过另一方面团队要求与服务供应商也存在关系，如果云服务厂商能够承担起组件的运维工作，实际上是可以帮助业务团队从运维工作中解放出更多的工程师，参与到大数据应用的工作中。
所以一般来说，架构师对于技术选型的偏好应该是，在满足业务需求和数据量需求的前提下，选择技术架构最简单的，因为往往这种选型是最容易使用和维护的。
在这个基础上，如果有一支非常强大的技术开发和运维团队，可以选择自建大数据平台；如果缺乏足够的运维、开发支撑，那么建议选择云服务平台来支撑业务。
七牛云是如何做架构选型的七牛云的大数据团队叫做 Pandora，这只团队的主要工作就是负责七牛云内的大数据平台需求的支撑工作，另外也负责将大数据平台产品化，提供给外部客户专业的大数据服务。
可以说七牛云就是 Pandora 的第一个客户，我们很多技术选型经验也是在承载公司内部各种需求积累起来的。