06｜数据计算：响应速度、灵活性与使用难度如何适配？
曹犟
你好，我是曹犟。
在上一节课中，我们讨论了大数据系统的存储方案应该如何设计。而数据在存储好了之后，就要对数据进行分析和处理，从中挖掘价值。而这就是数据计算层的核心价值。
今天这节课，我们就来深入聊聊计算层的设计与选型。
设计目标中的三个维度
我想先跟大家分享一个我自己亲身经历的案例。
在过去十年中，神策数据的用户行为分析产品神策分析，不仅存储系统的设计经历了三次重构（可以回顾上节课内容），计算引擎也是如此。
十年前创业之初，我们选择了某个商业化的 OLAP 数据库，作为整体的存储和计算系统。而在一年多以后，为了支撑更大的数据量和更复杂的分析需求，将存储系统重构到 HDFS + Kudu 架构外，批量查询引擎也调整为 Impala。同时，也引入了 Flink 作为实时计算引擎来完成实时流上的数据处理和加工工作。
而此时此刻，为了得到更极致的分析性能，我们正在考虑重构计算引擎，比如基于 Doris 这类现代化的 MPP 分析型数据库来进行重新设计。
其实，每一次计算引擎的重构，对于应用层来说，都是一个不小的变动。那么，为什么要进行重构呢？是否存在一种完美的计算引擎，能够一直满足我们的需求呢？
答案当然是否定的。每一种计算引擎，在设计上，都是有所折衷的，这种折衷体现在响应速度、灵活性和使用难度这三个方面：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 数据计算层的核心价值在于对数据进行分析和处理，从中挖掘价值。 2. 计算引擎的重构对应用层来说是一个不小的变动，需要权衡响应速度、灵活性和使用难度。 3. 响应速度维度包括实时计算、交互式分析和批量处理，不同业务场景对响应速度的需求不同。 4. 灵活性维度体现在计算能力的丰富程度上，包括支持的计算范式、数据源和数据格式以及扩展能力。 5. 使用难度维度影响团队的开发效率和维护成本，包括学习成本、开发效率和运维门槛。 6. 技术决策需要考虑应用场景、团队能力和演进路径，不应追求技术的“先进性”，而是追求“适用性”。 7. 在技术决策中，团队能力建设要先于技术架构升级，渐进式演进比一步到位风险更小。 8. 在组织中，需要评估和取舍响应速度、灵活性和使用难度，以及承担更高的使用难度来换取强大的计算能力的情况。 9. 对于数据开发工程师，需要深入理解业务需求，不盲目追求先进技术，而是根据实际场景选择合适的工具。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《大数据应用实战》，新⼈⾸单¥59
《大数据应用实战》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
大寒我们算是一个小团队，所以从上面三点来看是使用难度，因为团队规模小，需要用那些学习曲线较平缓的引擎，否则不好上手。而且业务大部分诉求还是报表需求，所以对于时效性要求不高。同时由于资源并不充裕，对于内存消耗高的引擎也不便倾斜。但是呢，我个人也会在力所能及帮业务争取时效性高的方式处理数据，因为我感觉离线处理内容挑战性是不太足的，而且在某些场景对于业务理解也不友好（比如小时数仓算出来的数据为什么不含当前小时，需要专门开个沟通会交流），所以也会带头逼着自己和团队其他成员往这方面考量（在成本可控范围内）。从我自身经历来说，面对一些刚起步的业务线且数据量有限时，尝试一些高难度处理方式积累经验会好些；而面对大数据量业务会因为成本问题不采取冒险措施，满足需求即可。 同时也回忆起了当初为了解决各式各样场景，加入了非常多的OLAP数据引擎（impala，presto，kylin，clickhouse）都有接触，经常是一个引擎解决不了特定问题再来个新的。但是，这样做的坏处就是学的杂而不精，到最后自己都乱了，所以团队后来一致同意后逐渐统一到了doris上（社区支持好，同时大部分场景满足）。所以，给我个人启示便是不能只以解决一个个业务场景为导向，同时也要兼顾未来拓展性。不知道老师是否认可这个想法？2025-11-05归属地：北京
收起评论