闲聊面试

最近有不少同学咨询面试应该怎么准备？一般面试官会问哪些问题？对于这些比较困惑或者是感觉需要准备的东西太多了无从下手，所以这篇文章主要聊聊自己的看法，希望能够帮助建立系统性上的思考，应该怎么去准备。面试其实是自我检验的一个过程，不仅仅是技术上的考察，更是自我总结的能力的考察，因此，我会从技术细节、技术架构、项目目标三个维度上谈一谈自己的理解。

技术细节

技术细节主要考察对某一项技术的掌握情况、技术深度如何、是否有自己的理解。但是我们经常性的会止步于如何使用、原理是什么这个阶段(特别是业务开发同学)，并没有进一步的去思考，更重要的是要将其能从一个点扩展到一条线甚至是一个面上， 需要经得住面试官的进一步考察。对于某一个技术点(以Flink DataStrem 层API join)可以使用如下的方式一步步的思考：

如何使用？

stream.join(otherStream)
    .where(<KeySelector>)
    .equalTo(<KeySelector>)
    .window(<WindowAssigner>)
    .apply(<JoinFunction>)

解决什么问题？

join 最直观解决信息补全的问题，在数仓中有大量这样的操作，一方面是因为数仓集成了来自不同源的数据，再者关系型数仓都是范式设计规范，另一方面是因为数仓为了追求性能，使用反规范化的方式提前处理。

原理&实现?

在DataStream join中，其本身的实现原理很简单，可以分为四步：1. 合并，也就是union操作；2. 打标，对不同流的数据打上一个识别标签；3. 分发，根据join 的key 将相同的数据发送到相同的节点；4. 处理，window的处理方式。可以看到整个的实现方式与mr的join 实现极为相似。

有什么限制?

这种方式的join 有窗口范围的限定，对于偏移窗口之外的数据是无法关联起来的。

抽象&通用

抽象&通用其实是一个总结的过程，从DataStream join 到KeyedStream join、regular-join、lateral-join、temporary-join, 再到离线里面的map-join、hash-join、sort-merge-join， 或者是再到mpp 里面比较常见的colocation join方式，将所有的join 方式进行一个总结，在不同的场景中如何选择最优的方式。

技术架构

技术架构是对一个面的考察，考查候选人对全局技术的掌握情况。常见离线架构、实时架构、流批一体架构、OLAP架构等，对于不同架构的选择一定是在特定的场景下演变而成，也包括具体的技术框架选择，为什么选用Flink 而不是Storm。主要从功能、性能、稳定性、成本几个方面说明。

功能

功能上要求主要从业务场景出发，业务场景是需要一个支持分析的数据库，因此肯定不会选择HBase、Redis这样的KV存储。

性能

在几亿或者是几十亿的数据量情况，需要能够快速分析数据得到结果，首要选择分布式的列存存储Doris、Clickhouse等，而不会去选择MySQL。

稳定性

业务需要更加稳定的系统环境，从稳定性上思考如何构建架构，比喻说计算双链路、存储高可用、指标监控等，都是提升稳定性的因素。

成本

成本一般是最后才开始考虑的点，但是为了追求低成本，肯定会对性能、稳定性上造成一定的损失，比喻说高可用的常见处理方式就是冗余，冗余就会带来成本上的增加。

上面几点是架构中比较常见的考量维度，在实际中可能还有会其他的考虑方式，尽量做到对整个架构中每一个点都想的比较清楚。

项目目标

了解项目目标，主要是清楚我们整个项目的意义与方向。我们工作中所做的事情目标大概可以分为两类：业务目标、技术目标。

业务目标

业务层面往往可能会是大家比较容易忽略的一个点，技术与业务是相辅相成的，并且技术最终一定是需要为业务服务的，因此一定要站在业务角度去思考技术能力的构建能带来什么样的业务价值，经常看到一些简历在描述项目的时候，采用平铺直述的方式去描述做的一件事情，并没有突出给业务带来的增量。

业务价值的确认应该在需求阶段需要明确下来，比喻说当前广告业务只有离线指标，但是现在需要实时指标，对于业务上的价值就是实时辅助商家做投放策略上调整，特别是在一些大促的场景下，减少无效的广告投放与资金消耗。如果要具体的衡量可以通过设定某一项指标去体现，比喻说消耗的提升比或者是转化率的提升比。

技术目标

技术目标比较常见的提效、降本。这两个效果在数仓中最容易体现，通用公共层的建设、计算任务优化、存储缩减等。