企業的數據開發體系，往往伴隨着業務規模增長逐步演進。數據的產生源頭複雜、數據量不斷擴大、業務部門對數據的依賴程度提高，導致數據開發能力是否合理選型，將直接影響數據平台的穩定性、擴展性以及成本投入。

一、需求分析是技術選型的起點

在很多實際項目中，技術選型失敗主要不是因為技術不好，而是對實際訴求理解不清。技術選型之前應明確以下問題：

  1. 數據規模

    • 日新增數據是否為 GB、TB 或 PB 級
    • 數據是否需要歸檔、冷熱分層

  2. 時效性需求

    • 是批處理（分鐘/小時級）
    • 還是實時處理（秒級/亞秒級）

  3. 查詢及使用方式

    • 大屏展示
    • 分析報表
    • 推薦/畫像
    • 機器學習訓練

  4. 成本約束

    • 是否具備擴容預算
    • 是否有云資源支持

  5. 團隊能力現狀

    • 是否已有成熟框架
    • 是否具備運維資源

只有回答以上問題，後續決策才有依據。

二、採集層的技術選型原則

採集層技術選型要圍繞來源系統和數據實時性來確定：

場景 推薦技術
日誌採集 Filebeat / Fluentd
數據庫增量數據 Canal / Debezium
高實時消息流 Kafka / Pulsar
API 拉取 Python + Airflow 任務

典型方案組合：

  • OLTP → Kafka → Flink → 數倉
  • 日誌 → Filebeat → Kafka → ClickHouse

採集層的關鍵指標是穩定性與可追溯性，因此日誌、死信隊列、失敗重試必須提前設計。

三、存儲層選型策略：冷熱分層是核心

存儲方案要回答兩個問題：

  1. 數據作為資產是否需要長期保存
  2. 查詢場景是否高頻

冷熱策略示例

層級 技術 説明
熱數據 ClickHouse、Hologres、TiDB 支撐實時查詢
近線數據 Hive、Iceberg、Hudi 存儲成本低、ETL 算子豐富
歸檔數據 OSS、S3、HDFS 成本最低

企業常見組合：

  • 近實時 + 分析查詢：ClickHouse + Iceberg
  • 低成本大規模倉儲：Hive + S3/OSS

注意：冷熱分層不是增加複雜度，而是降低成本。

四、計算引擎的取捨

計算層是數據開發體系的核心。選型維度：

批處理框架

框架 特點
Spark 生態完善、資源彈性好
Hive 成熟穩健，但性能偏弱
Flink Batch 統一計算模式

實時計算

框架 場景
Flink 實時指標、風控、推薦
Kafka Streams 輕量、有狀態計算

決策邏輯：

  • 指標分鐘級實時性 —— Flink
  • 離線定時報表 —— Spark
  • 多表 Join 且數據量大 —— SparkSQL + Iceberg

很多項目失敗是因為：

明明離線即可滿足，但硬要做實時架構。

實時並不是價值本身，需求穩定、高級別 SLA 才值得實時化。

五、調度選型與自動化治理能力

調度能力決定研發效率。

比較體系：

方案 優點 缺點
Airflow 編排靈活、插件豐富 部署運維複雜
DolphinScheduler UI 友好、企業場景適配好 擴展度略弱
Oozie 穩定性好 生態淘汰