作者：付力力，神策数据联合创始人&技术 VP
毕业于北京理工大学软件工程专业，2008 年至 2013 年期间历任百度新产品研发部、网页搜索部、基础架构部工程师。2013 年 9 月年至 2014 年 8 月担任豌豆荚数据部门资深研发工程师。2014 年 9 月至 2015 年 4 月担任黄金钱包技术合伙人。2018 年 8 月，荣登“2018 福布斯中国 30 岁以下精英榜”。
2015 年 9 月正式发布了神策分析 1.0 版本，在随后的 3 年里，我们的产品研发团队一直在不断地进行版本迭代，到目前为止一共发布了 12 个大版本。
相比于最初的 1.0 版本，现在的神策分析无论是在产品体验还是在底层架构上都已经发生了很大的变化：
从最初只能使用 3 个单薄的基础分析功能，到现在支持 10 个分析模型联合构建的场景化分析能力；从最初只能支持每天数万日活的小 App，到现在可以轻松应对一天产生数百亿的数据量巨型 App。
而另一方面，3 年内，神策分析里也有很多地方没有改变：
例如，从第一版的设计里就确定了模型的 Event-User，该模型现在依然是整个神策分析里最基础和重要的概念。
在这篇文章里，我给大家介绍神策分析最近在底层架构上一些比较大的设计改进，同时也会分享我们在这些架构设计中关于"变"与"不变"的思考。
从 SQL 查询引擎到用户行为分析引擎
我们之前在很多场合都对神策分析的底层架构做过详细的介绍，这个架构的主要特点之一是：
神策所有的分析结果都是从明细数据实时查询得出，而不是基于大多数分析系统所使用的预计算技术，之所以这么设计，因为我们希望系统数据分析能力的上限在于数据本身。
换句话说，我们期望只要是从已经采集的数据里可以分析得到的结论，神策都希望可以帮助我们的客户很容易的实现。
从结果看来，这种架构设计的好处是非常显著的：
它大大简化了整个系统的数据流，我们不需要为不同的分析模型来维护复杂的聚合表，并在数据回溯的时候保持这些数据之间的一致性（大多数类似的数据系统里要么抛弃数据回溯的能力，要么放弃数据一致性）。
受益于这种架构，我们在很短的时间内推出众多灵活的分析模型，并且这些分析模型之间可以通过分群等方式来进行自由的组合查询。
同时，配合我们开发的查询缓存机制，这套架构也可以在报表等相对固定的数据分析需求上得到比较好的使用体验。
当然，这种设计的另外一个结果是，神策分析很明确地抛弃了对高 QPS 查询需求的直接支持（例如不应该尝试在商品详情页里直接从神策分析获取这个商品本周的销量）。
不过，整体上我们认为，牺牲一个非必要的特性来换取数倍的分析灵活性以及一个简单可维护的架构，是一个非常划算的选择。
在这套架构里，ImpalaS 作为我们使用的数据查询引擎，可以说是一个非常核心的模块。
在最初的设计选型上我们选择 Impala，一方面是因为 Impala 已经是一个相对比较成熟的 MPP 架构的查询引擎，而且对 SQL 有着比较良好的支持。另外一方面则是因为我们的研发团队在 Impala 的使用和二次开发上有着比较多的经验。
其中，是否支持 SQL 是一个很重要的选型依据。虽然 SQL 是一种有着几十年历史、至今也没有太多变化的古老工具，但是到目前为止它依然是对表格数据进行操作的最佳选择，在易用性
今天的文章 技术内参 | 神策分析架构演进：“变”与“不变” 中的思索与创新分享到此就结束了，感谢您的阅读。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/bian-cheng-ji-chu/84336.html