2019-12-30面试反思

标签：使用   ado   spark   combine   磁盘   准备   合并   排序   cache   

• 面试公司: 一家中小型电商

• 面试中的问题:

  • 思路不要太跳跃性, 不然容易尬。

  • 引导的时候脑子需要快速运转该说什么。

  • 自己熟的那块一定要准备充分答出百分之80以上。

  • 排序算法, 选一个说: 建议快排, 归并, 面试前手写一下找找感觉。

    • 挖坑桶排: 需要对难点做准备: 按照什么条件分桶? 空间利用率的优化等。

    • 我下次打算挖坑下计排看看。

  • Spark Core -> RDD -> 分类 -> 资源调度 -> Spark On Yarn

  • 小文件处理:

    • hdfs
      • Hadoop Archive(HAR)
      • Sequence file
      • CombineFileInputFormat
    • HBase
      • 答的基本上可以了, minor compact, major compact(会删除数据, crontab脚本半夜手动合并), rowKey设计

  • SparkStreaming

    • 建议使用Direct模式, kafka0.11的坐标与更高版本目前为止都是兼容的。
      • 没有使用 Zookeeper 管理消费者 offset, 使用的是 Spark 自己管理, 默认存在内存中, 可以设置 checkpoint, 也会保存到 checkpoint 中一份。
      • 读取 kafka 使用 Simple Consumer API, 可以手动维护消费者 offsset
      • 并行度 与 读取的 topic 的 partition 一一对应
      • 可以使用设置 checkpoint 的方式管理消费者 offset, 使用StreamingContext.getOrCreate(ckDir, CreateStreamingContext) 恢复。
      • 如果代码逻辑改变, 就不能使用 checkpoint 模式管理 offset, 可以手动维护消费者 offset, 可以将 offset 存储到外部系统。
    • 与kafka0.11以上版本的整合
    • kafka特性:
      • ISR
      • ACK
      • PageCache
      • ZeroCopy(netty)
      • 磁盘顺序写
      • 消息默认保留7天
      • 底层结合RocksDB可以直接当成数据库使用
      • 容错机制(checkpoint)
      • 是否有状态
      • 反压机制
        • 根据流数据的处理效率动态调整摄入速率，以达到限流的目的。
        • 当批处理时间(Batch Processing Time)大于批次间隔(Batch Interval，即 BatchDuration)时,说明处理数据的速度小于数据摄入的速度，持续时间过长或源头数据暴增，容易造成数据在内存中堆积，最终导致Executor OOM或任务奔溃。
    • 消息的幂等性
      • at least once
      • Exactly once

  • SparkSQL

    • Spark on Hive / Hive on Spark
    • Dataset 与 DataFrame
      • Dataset -> DataFrame
    • 底层架构想的起来就说, 想不起来没事。
    • 谓词下推(这个是应该要说出来的)

  • 机器学习:

    • 问了简单的线性回归梯度下降
    • 如果一定要用线性回归处理簇状数据该咋么处理?
      • 可以通过添加多项式特征进行升维(如sklearn中可以使用PolynomialFeatures)
      • 结论: 对于低维数据集，线性模型常常出现欠拟合的问题，而将数据集进行多项式特征扩展后，可以在一定程度上解决线性模型欠拟合的问题。
      • 线性回归一般升几个维度之后就不存在性能优势了。
      • 多维度数据还是适合用支持向量机SVM(Support vector machine)

2019-12-30面试反思

标签：使用   ado   spark   combine   磁盘   准备   合并   排序   cache   

原文地址：https://www.cnblogs.com/ronnieyuan/p/12127159.html