电商平台每天产生几千万条用户行为日志，大数一条日志里藏着时间戳、据分用户ID、析技商品类目、大数点击位置、据分设备型号。析技把这些字段扔进Hadoop集群，大数跑一遍MapReduce，据分就能算出哪个时段转化率最高。析技这是大数大数据分析最朴素的起点——把散落的记录变成可读的规律。

数据仓库是据分绕不开的底座。传统企业用Oracle、析技DB2，大数互联网公司更认Hive、据分ClickHouse。析技Hive把SQL翻译成MapReduce任务，写起来像数据库，跑起来是分布式计算。ClickHouse则走另一条路，列式存储加向量化执行，单表百亿行做聚合查询，响应时间能压到秒级。我见过一个广告团队用ClickHouse实时统计各渠道的曝光点击，运营人员每五分钟刷新一次看板，调整出价策略。

批处理之外，流式计算解决“来不及”的问题。Flink和Spark Streaming是主流选择。Flink的窗口机制很灵活，滑动窗口、滚动窗口、会话窗口，按事件时间还是处理时间，都能配。有个物流公司的案例：货车上的GPS每10秒发一次位置，Flink消费Kafka里的轨迹数据，检测到某辆车在非停车区域停留超过15分钟，立刻触发告警。这套逻辑用批处理做不了，因为等一天再算，货可能已经丢了。

数据量大了，查询性能靠索引和预聚合。Elasticsearch倒排索引擅长全文检索，但做数值聚合容易爆内存。Druid和Kylin走预聚合路线，提前把维度组合的指标算好，查询时直接查结果。Kylin依赖Hadoop生态，Cube构建动辄几小时，适合T+1报表。Druid的摄入实时性更好，但节点一多，元数据管理就头疼。选哪个，看业务对延迟的容忍度。

机器学习把分析从“看历史”推到“猜未来”。Spark MLlib提供分类、回归、聚类的基础实现，但特征工程才是脏活累活。用户年龄缺失，用中位数填还是模型预测？类别特征高基数，One-Hot之后维度爆炸，改用Target Encoding又怕泄露标签。XGBoost和LightGBM在结构化数据上依然能打，调参比深度学习省事。一个风控团队用LightGBM做交易欺诈识别，特征里加了“过去一小时同设备登录次数”“收货地址与IP归属地距离”，AUC从0.78拉到0.91。

图计算处理关系型问题有奇效。Neo4j存好友关系、资金流向，PageRank找影响力节点，Louvain做社区发现。反洗钱场景里，资金网络动辄上亿边，Neo4j单机扛不住，换成Spark GraphX或阿里GraphScope。有个细节：图算法对数据倾斜特别敏感，某个超级节点连了几千万条边，任务卡在最后一个reduce，得先做度数过滤或者切分。

时序数据库专治监控指标。InfluxDB、TimescaleDB、Prometheus，写入吞吐高，降采样和保留策略是标配。运维团队采集服务器CPU、内存、磁盘IO，每15秒一个点，保留30天原始数据，一年聚合数据。Grafana接上去画图，异常检测用3-sigma或者Prophet。别小看这些，一次磁盘写满导致的线上故障，往往就是某个指标曲线突然翘头没被注意到。

最后提一嘴数据湖。Delta Lake、Iceberg、Hudi在HDFS或S3上加了一层事务和Schema管理，解决“读时写时不一致”的老毛病。以前Hive表分区写一半失败，查询看到脏数据，现在ACID保证要么全可见要么全不可见。Iceberg的隐藏分区和分区演进很实用，业务改字段不用重写全量数据。

工具选型没有银弹。日增10GB和日增10TB，架构完全不同。小团队用DuckDB加Parquet文件就能跑分析，大厂才需要Flink加Iceberg加Trino的豪华套餐。关键是搞清楚数据量、延迟要求、团队维护成本，别为了技术而技术。