diff --git a/app_vx.py b/app_vx.py index 9429a92a..190a3045 100644 --- a/app_vx.py +++ b/app_vx.py @@ -55,6 +55,9 @@ from datetime import datetime, timedelta, time as dt_time from werkzeug.security import generate_password_hash, check_password_hash import json from clickhouse_driver import Client as Cclient +from queue import Queue, Empty, Full +from threading import Lock, RLock +from contextlib import contextmanager import jwt from docx import Document from tencentcloud.common import credential @@ -69,6 +72,289 @@ engine_med = create_engine("mysql+pymysql://root:Zzl5588161!@222.128.1.157:33060 engine_2 = create_engine("mysql+pymysql://root:Zzl5588161!@222.128.1.157:33060/valuefrontier", echo=False) logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(name)s - %(levelname)s - %(message)s') logger = logging.getLogger(__name__) + + +# ===================== ClickHouse 连接池实现 ===================== +class ClickHouseConnectionPool: + """ + ClickHouse 连接池 + - 支持连接复用，避免频繁创建/销毁连接 + - 支持连接超时和健康检查 + - 支持自动重连 + - 线程安全 + """ + + def __init__(self, host, port, user, password, database, + pool_size=10, max_overflow=10, + connection_timeout=10, query_timeout=30, + health_check_interval=60): + """ + 初始化连接池 + + Args: + host: ClickHouse 主机地址 + port: ClickHouse 端口 + user: 用户名 + password: 密码 + database: 数据库名 + pool_size: 连接池核心大小（预创建连接数） + max_overflow: 最大溢出连接数（总连接数 = pool_size + max_overflow） + connection_timeout: 获取连接超时时间（秒） + query_timeout: 查询超时时间（秒） + health_check_interval: 健康检查间隔（秒） + """ + self.host = host + self.port = port + self.user = user + self.password = password + self.database = database + self.pool_size = pool_size + self.max_overflow = max_overflow + self.connection_timeout = connection_timeout + self.query_timeout = query_timeout + self.health_check_interval = health_check_interval + + # 连接池队列 + self._pool = Queue(maxsize=pool_size + max_overflow) + # 当前活跃连接数 + self._active_connections = 0 + # 锁 + self._lock = RLock() + # 连接最后使用时间记录 + self._last_used = {} + # 连接创建时间记录 + self._created_at = {} + + # 初始化核心连接 + self._init_pool() + logger.info(f"ClickHouse 连接池初始化完成: pool_size={pool_size}, max_overflow={max_overflow}") + + def _init_pool(self): + """初始化连接池，预创建部分核心连接（非阻塞）""" + # 只预创建 2 个连接，其余按需创建 + init_count = min(2, self.pool_size) + for i in range(init_count): + try: + conn = self._create_connection() + if conn: + self._pool.put(conn) + logger.info(f"预创建 ClickHouse 连接 {i+1}/{init_count} 成功") + except Exception as e: + logger.warning(f"预创建 ClickHouse 连接失败 ({i+1}/{init_count}): {e}") + # 预创建失败不阻塞启动，后续按需创建 + break + + def _create_connection(self): + """创建新的 ClickHouse 连接""" + try: + client = Cclient( + host=self.host, + port=self.port, + user=self.user, + password=self.password, + database=self.database, + connect_timeout=self.connection_timeout, + send_receive_timeout=self.query_timeout, + sync_request_timeout=self.query_timeout, + settings={ + 'max_execution_time': self.query_timeout, + 'connect_timeout': self.connection_timeout, + } + ) + conn_id = id(client) + self._created_at[conn_id] = time.time() + self._last_used[conn_id] = time.time() + with self._lock: + self._active_connections += 1 + logger.debug(f"创建新的 ClickHouse 连接: {conn_id}") + return client + except Exception as e: + logger.error(f"创建 ClickHouse 连接失败: {e}") + raise + + def _check_connection_health(self, conn): + """检查连接健康状态""" + try: + conn_id = id(conn) + last_used = self._last_used.get(conn_id, 0) + + # 如果连接长时间未使用，进行健康检查 + if time.time() - last_used > self.health_check_interval: + # 执行简单查询检查连接 + conn.execute("SELECT 1") + logger.debug(f"连接 {conn_id} 健康检查通过") + + return True + except Exception as e: + logger.warning(f"连接健康检查失败: {e}") + return False + + def _close_connection(self, conn): + """关闭连接""" + try: + conn_id = id(conn) + conn.disconnect() + self._last_used.pop(conn_id, None) + self._created_at.pop(conn_id, None) + with self._lock: + self._active_connections = max(0, self._active_connections - 1) + logger.debug(f"关闭 ClickHouse 连接: {conn_id}") + except Exception as e: + logger.warning(f"关闭连接时出错: {e}") + + def get_connection(self, timeout=None): + """ + 从连接池获取连接 + + Args: + timeout: 获取连接的超时时间，默认使用 connection_timeout + + Returns: + ClickHouse 客户端连接 + + Raises: + TimeoutError: 获取连接超时 + Exception: 创建连接失败 + """ + timeout = timeout or self.connection_timeout + + # 首先尝试从池中获取连接 + try: + conn = self._pool.get(block=True, timeout=timeout) + + # 检查连接健康状态 + if self._check_connection_health(conn): + self._last_used[id(conn)] = time.time() + return conn + else: + # 连接不健康，关闭并创建新连接 + self._close_connection(conn) + return self._create_connection() + + except Empty: + # 池中没有可用连接，检查是否可以创建新连接 + with self._lock: + if self._active_connections < self.pool_size + self.max_overflow: + try: + return self._create_connection() + except Exception as e: + logger.error(f"创建溢出连接失败: {e}") + raise + + # 已达到最大连接数，等待连接释放 + logger.warning(f"连接池已满，等待连接释放... (当前连接数: {self._active_connections})") + raise TimeoutError(f"获取 ClickHouse 连接超时 (timeout={timeout}s)") + + def release_connection(self, conn): + """ + 释放连接回连接池 + + Args: + conn: 要释放的连接 + """ + if conn is None: + return + + conn_id = id(conn) + self._last_used[conn_id] = time.time() + + try: + self._pool.put(conn, block=False) + logger.debug(f"连接 {conn_id} 已释放回连接池") + except Full: + # 池已满，关闭多余连接 + logger.debug(f"连接池已满，关闭多余连接: {conn_id}") + self._close_connection(conn) + + @contextmanager + def connection(self, timeout=None): + """ + 上下文管理器方式获取连接 + + Usage: + with pool.connection() as conn: + result = conn.execute("SELECT * FROM table") + """ + conn = None + try: + conn = self.get_connection(timeout) + yield conn + except Exception as e: + # 发生异常时，检查连接是否需要重建 + if conn: + try: + # 尝试简单查询检测连接状态 + conn.execute("SELECT 1") + except: + # 连接已损坏，关闭它 + self._close_connection(conn) + conn = None + raise + finally: + if conn: + self.release_connection(conn) + + def execute(self, query, params=None, timeout=None): + """ + 执行查询（自动管理连接） + + Args: + query: SQL 查询语句 + params: 查询参数 + timeout: 查询超时时间 + + Returns: + 查询结果 + """ + with self.connection(timeout) as conn: + return conn.execute(query, params) + + def get_pool_status(self): + """获取连接池状态""" + return { + 'pool_size': self.pool_size, + 'max_overflow': self.max_overflow, + 'active_connections': self._active_connections, + 'available_connections': self._pool.qsize(), + 'max_connections': self.pool_size + self.max_overflow + } + + def close_all(self): + """关闭所有连接""" + while not self._pool.empty(): + try: + conn = self._pool.get_nowait() + self._close_connection(conn) + except Empty: + break + logger.info("ClickHouse 连接池已关闭所有连接") + + +# 初始化全局 ClickHouse 连接池（懒加载模式） +clickhouse_pool = None +_pool_lock = Lock() + + +def _init_clickhouse_pool(): + """懒加载初始化 ClickHouse 连接池""" + global clickhouse_pool + if clickhouse_pool is None: + with _pool_lock: + if clickhouse_pool is None: + clickhouse_pool = ClickHouseConnectionPool( + host='222.128.1.157', + port=18000, + user='default', + password='Zzl33818!', + database='stock', + pool_size=5, # 减少预创建连接数 + max_overflow=20, # 增加溢出连接数，总共支持 25 并发 + connection_timeout=10, # 连接超时 10 秒 + query_timeout=30, # 查询超时 30 秒 + health_check_interval=60 # 60 秒未使用的连接进行健康检查 + ) + return clickhouse_pool +# ===================== ClickHouse 连接池实现结束 ===================== app = Flask(__name__) Compress(app) UPLOAD_FOLDER = 'static/uploads/avatars' @@ -1150,13 +1436,40 @@ def update_investment_preferences(): def get_clickhouse_client(): - return Cclient( - host='222.128.1.157', - port=18000, - user='default', - password='Zzl33818!', - database='stock' - ) + """ + 获取 ClickHouse 客户端（使用连接池，懒加载） + + 返回连接池对象，支持两种使用方式： + + 方式1（推荐）- 直接调用 execute： + client = get_clickhouse_client() + result = client.execute("SELECT * FROM table", {'param': value}) + + 方式2 - 使用上下文管理器： + client = get_clickhouse_client() + with client.connection() as conn: + result = conn.execute("SELECT * FROM table") + """ + return _init_clickhouse_pool() + + +@app.route('/api/system/clickhouse-pool-status', methods=['GET']) +def api_clickhouse_pool_status(): + """获取 ClickHouse 连接池状态（仅供监控使用）""" + try: + pool = _init_clickhouse_pool() + status = pool.get_pool_status() + return jsonify({ + 'code': 200, + 'message': 'success', + 'data': status + }) + except Exception as e: + return jsonify({ + 'code': 500, + 'message': str(e), + 'data': None + }), 500 @app.route('/api/stock//kline') @@ -1292,6 +1605,7 @@ def get_daily_kline(stock_code, event_datetime, stock_name): 'name': stock_name, 'data': kline_data, 'trade_date': event_datetime.date().strftime('%Y-%m-%d'), + 'event_time': event_datetime.isoformat(), 'type': 'daily', 'is_history': True, 'data_count': len(kline_data) @@ -4120,7 +4434,9 @@ def api_stock_detail(event_id, stock_code): 'event_info': { 'event_id': event.id, 'event_title': event.title, - 'event_description': event.description + 'event_description': event.description, + 'event_start_time': event.start_time.isoformat() if event.start_time else None, + 'event_created_at': event.created_at.strftime("%Y-%m-%d %H:%M:%S") if event.created_at else None }, 'basic_info': { 'stock_code': basic_info.SECCODE, diff --git a/public/htmls/阿里AI千问、灵光.html b/public/htmls/阿里AI千问、灵光.html index f736e6fb..9457e375 100644 --- a/public/htmls/阿里AI千问、灵光.html +++ b/public/htmls/阿里AI千问、灵光.html @@ -1,259 +1,170 @@ - - + - 阿里AI千问、灵光概念深度分析 + 阿里AI千问、灵光 - 概念深度分析 + - - - + - + -
-
-
-
-
- 热点概念 -
-

- 阿里AI千问、灵光 -

-

- 从B端技术领先到C端超级入口的战略跃迁 -

-
-
-
1000万+
-
首周下载量
+
+
+
+

阿里AI千问、灵光

+

从B端技术输出到C端生态入口的历史性拐点

+
+
+
下载量
+
1000万+
+
千问APP公测一周
-
-
TOP 3
-
App Store排名
+
+
App Store排名
+
Top 3
+
2天冲榜
-
-
3800亿
-
AI基础设施投资
-
-
-
- - -
-
-
-
- - -
-
-

- 核心观点摘要 -

-
-
-
-
- -
-

战略跃迁

-

从B端技术领先到C端超级入口的关键转折点

-
-
-
-
-
- -
-

开源护城河

-

全球第一开源模型家族，3亿下载量，10万+衍生模型

-
-
-
-
-
- -
-

生态协同

-

全场景生活服务闭环，淘宝、高德、支付宝深度融合

-
-
-
-
-
- -
-

投资主线

-

算力基础设施与生态合作伙伴最具确定性

+
+
开源模型
+
200+
+
全球下载量超3亿次
- -
-
-

- 概念事件时间轴 + +
+
+

+ 核心观点摘要 +

+
+ + + +
+

核心观点

+
阿里AI战略正经历从B端技术输出到C端生态入口的历史性拐点，千问APP的爆发式增长验证了其"开源技术+场景垄断+免费策略"的独特路径有效性。然而，当前市场高度聚焦于用户数据和下载量，却可能忽视两个关键预期差：一是AI收入占比仍处个位数，商业化路径尚未跑通；二是技术层面虽在开源生态占据第一，但推理能力与DeepSeek等竞品仍存在差距。
+
+
+
+
+ + +
+
+

+ 关键时间轴

-
+
- -
-
-
-
-
2025年11月17日
-

千问APP公测版上线

-

定位"会聊天能办事的个人AI助手"，全面对标ChatGPT

-
-
-
-
-
-
-
-
-
-
2025年11月19日
-

冲入App Store前三

-

首周下载量突破1000万次，成为史上增长最快的AI应用

-
+ +
+
2024年4月
+
+
+

技术基建期

+
    +
  • 阿里云发布通义千问2.5，性能追平GPT-4 Turbo
    • +
  • Qwen2.5系列开源，奠定全球第一开源模型族地位
    • +
  • 衍生模型超10万，下载量突破700万次
    • +
+
-
-
-
-
2025年9月
-

Qwen3-Next发布

-

训练成本降低90%，实现性能与效率的最优平衡

-
-
-
-
-
-
-
-
-
-
2025年4月
-

新加坡国家AI合作

-

新加坡放弃Meta模型，转向阿里千问开源架构

-
+ +
+
2025年4月
+
+
+

Qwen3重磅发布

+
    +
  • Qwen3-235B-A22B在编程、数学基准测试中超越DeepSeek-R1、GPT-4.1
    • +
  • 登顶Hugging Face趋势榜
    • +
  • Qwen3 Coder编程能力达全球SOTA，API调用量突破千亿级Tokens
    • +
+
-
-
-
-
2025年2月
-

苹果战略合作

-

为国内2.5亿iOS用户提供AI服务，带来确定性算力需求

-
-
-
-
-
-
-
-
-
-
2024年9月
-

三年3800亿投资计划

-

彰显AI战略决心，重点布局算力基础设施

+ +
+
2025年11月 - C端产品爆发期
+
+
+

里程碑时刻

+
+
+
11月14日
+
通义App升级为千问App
+
+
+
11月17日
+
千问App公测版上线
+
2天冲榜Top 3
+
+
+
11月18日
+
灵光App发布
+
4天下载破100万
+
@@ -262,252 +173,113 @@
- -
-
-

- 四维共振逻辑 + +
+
+

+ 核心驱动力分析

-
-
+ +
+ +
-
-
- -
-

技术壁垒驱动

+
+ + 技术开源战略 +
★★★★☆
+
+
+

开源200+模型，全球下载量超3亿次

+

衍生模型数量超10万，稳居Hugging Face第一

+

区域性语言处理优势（印尼语、泰语）

+

短板：推理能力与DeepSeek存在差距

-
    -
  • Qwen3系列在11项基准测试全面超越DeepSeek V3
    • -
  • 开源生态：200+模型，3亿下载量，10万+衍生模型
    • -
  • Qwen3-Next训练成本降低超90%
    • -
  • QwQ-32B以320亿参数实现6710亿参数性能
    • -
-
+ +
-
-
- -
-

战略决心驱动

+
+ + C端生态整合 +
★★★★★
+
+
+

淘宝、高德、支付宝、飞猪全场景覆盖

+

从聊天到办事的能力闭环

+

石基信息打通酒店预订系统

+

护城河：竞品无法复制的场景垄断

-
    -
  • 管理层视千问为"AI时代的未来之战"
    • -
  • 集团CEO吴泳铭亲自管理，组织架构大调整
    • -
  • 3800亿投资，年资本开支超1200亿
    • -
  • 千问APP从启动到上线仅4天，执行力验证
    • -
-
+ +
-
-
- -
-

生态协同驱动

+
+ + 战略资源投入 +
★★★★★
-
    -
  • 淘宝、高德、飞猪、支付宝全场景融合
    • -
  • 自然语言交互+任务自动执行闭环
    • -
  • 与NBA合作开发专属AI模型
    • -
  • 独特的生活服务体验，竞争对手难以复制
    • -
-
-
- -
-
-
-
- -
-

市场需求驱动

+
+

3800亿AI基础设施投入（三年）

+

吴泳铭定义"AI时代的未来之战"

+

资本开支2025年预计增长超50%

+

风险：ROI压力巨大

-
    -
  • 千问APP完全免费，CAC趋近于零
    • -
  • 首周1000万下载，网络效应已启动
    • -
  • 苹果合作带来2.5亿iOS用户确定性增量
    • -
  • 2026年C端AI应用重要突破年
    • -
- -
-
-

- 产业链核心公司 + +
+
+

+ 市场热度与预期差

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
公司关联度核心逻辑竞争优势潜在风险投资评级
石基信息极高千问生态落地最大受益方 -
-
• 股权绑定：淘宝为第二大股东
-
• 业务独占：预订功能强制使用
-
• 场景刚需：酒旅预订核心场景
-
- 		-
-
• 阿里战略调整
-
• 酒店业景气度下行
-
- 		Alpha来源最纯
数据港高阿里算力基础设施提供商 -
-
• 深度绑定：阿里最大IDC供应商
-
• 需求刚性：C端爆发带来增量
-
• 地域优势：满足低延时要求
-
- 		-
-
• 行业竞争加剧
-
• 阿里议价能力强
-
- 		Beta属性明显
值得买中阿里电商数据服务商 -
-
• 数据资产完善
-
• 场景融合需要
-
• 深度合作历史
-
- 		-
-
• 变现模式不清晰
-
• 阿里可能自建
-
- 		逻辑较弱，观望
浪潮信息高阿里服务器供应商 -
-
• 国产替代机遇
-
• 规模效应
-
- 		-
-
• 价格战激烈
-
• 技术迭代风险
-
- 		偏硬件，弹性有限
-
-
-
- - -
-
-

- 关键跟踪指标 -

-
-
+ +
+
-

- 用户粘性指标 +

+ 市场热度

-
+
- 30日留存率 - 目标 >40% + 研报覆盖密度 +
峰值
- 人均日使用时长 - 目标 >15分钟 + 概念板块涨幅 +
- 功能渗透率 - 目标 >20% + 乐观情绪占比 +
-
+
-

- 商业化指标 +

+ 关键预期差

-
-
- ARPU值 - 2026目标 >50元/年 +
+
+ +
C端爆发 ≠ 商业化兑现
+
AI收入占比仍处个位数
-
- MaaS平台利润率 - 目标 >25% -
-
- 苹果合作收入 - 2026Q4 >20亿 -
-
-
-
- -
-
-

- 技术指标 -

-
-
- 开源模型下载增速 - 目标 >10%/月 -
-
- Agent任务成功率 - 目标 >80% -
-
- QwQ-Max发布 - 2026Q2前 +
+ +
开源第一 ≠ 性能无敌
+
Agent能力低于DeepSeek
@@ -516,145 +288,355 @@
- -
-
-

- 综合结论与投资启示 + +
+
+

+ 产业链图谱

-
-
-

阶段判断

-

- 当前阿里AI千问概念处于 "预期验证"的第二阶段： -

-
-

▸ 第一阶段（2024年及以前）：纯主题炒作，市场不信任阿里C端能力

-

▸ 第二阶段（2025年11月至今）：产品数据验证，估值开始反应

-

▸ 第三阶段（2026年H2-2027年）：若留存和商业化数据验证，估值体系重构

+ +
+ +
+
+

上游：算力基础设施

+
+

价值占比: 40%

+
    +
  • IDC/智算中心: 数据港、杭钢股份、科华数据
    • +
  • AI芯片: 寒武纪、海光信息、平头哥
    • +
  • 服务器: 浪潮信息、中科曙光、工业富联
    • +
  • 光模块: 中际旭创、新易盛
    • +
+
-
-

核心矛盾

-

- - 短期股价反映"用户增长故事"，但长期价值取决于"商业化能力" -

+ +
+
+

中游：模型与平台

+
+

价值占比: 30%（阿里主导）

+
    +
  • 大模型: 通义千问（已开源200+模型）
    • +
  • MaaS平台: 百炼（29万企业用户）
    • +
  • 工具链: 通义灵码（已开始收费）
    • +
+
+
+ +
+
+

下游：应用与场景

+
+

价值占比: 30%

+
    +
  • 电商/消费: 光云科技、丽人丽妆
    • +
  • 旅游/酒店: 石基信息（核心标的）
    • +
  • 交通/物流: 千方科技
    • +
  • 数据服务: 值得买
    • +
+
+
+
+
+
+
+ + +
+
+

+ 核心关联股票 +

+ + +
+

阿里系参股企业

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
股票名称分类行业相关性持股比例
石基信息参股消费信息技术酒店直连核心13.02%
朗新集团参股TMT信息技术能源数字化16.63%
千方科技参股TMT信息技术交通领域唯一伙伴14.11%
分众传媒参股TMT传媒营销合作6.13%
三江购物参股消费零售新零售布局30%
+
+
+ + +
+

业务合作企业

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
股票名称项目/业务原因相关性
恒银科技灵光接入千问大模型及灵光直接合作
华策影视内容制作已接入千问大模型应用合作
润建股份智算云业务与阿里云共同投资智算中心基础设施
数据港ZH13数据中心阿里核心数据中心供应商核心标的
杭钢股份B栋数据中心已上电机柜1069个算力需求
+
+
+ + +
+

技术供应商

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
股票名称产品/服务合作内容类别
浪潮信息服务器阿里服务器采购份额最高硬件
中际旭创光模块阿里云主要供应商硬件
紫光股份交换机400G交换机大份额硬件
寒武纪GPU云端产品线合作芯片
英维克液冷温控阿里数据中心制冷配套
+
+
+
+
+ + +
+
+

+ 风险提示 +

+ +
+
+
+ +

技术风险

+

推理能力瓶颈

+

多模态整合瑕疵

+

自研芯片性能差距

+
+
+ +
+
+ +

商业化风险

+

变现模式不清晰

+

ROI压力巨大

+

用户留存不确定

+
+
+ +
+
+ +

政策风险

+

数据安全监管

+

跨境数据限制

+

反垄断压力

+
+
+ +
+
+ +

竞争风险

+

字节豆包竞争

+

价格战内卷

+

同质化严重

+
+
+
+
+
+ + +
+
+

+ 投资启示 +

+ +
+ + +
-

投资建议

-
-
-

首选

-

算力基础设施

-

数据港、万国数据

-

确定性算力需求，上架率70%→90%加速

-
-
-

次选

-

场景绑定应用

-

石基信息

-

若留存率>40%，酒旅场景产生真实GMV

-
-
-

谨慎

-

纯模型概念

-

阿里巴巴自身

-

股价已隐含较高预期，适合观察仓

-
-
-
- -
-

- - 当前阶段："重算力、轻应用、缓判巨头" - -

+

投资策略建议

+
    +
  • 首选标的：石基信息（002153.SZ）- 阿里二股东+酒店场景独占，50-70%上行空间
    • +
  • 次选标的：数据港（603881.SH）- 算力需求直接受益，PS 4倍存重估空间
    • +
  • 防御配置：值得买（300785.SZ）- 稳定数据服务，10-15%仓位
    • +
  • 关键跟踪指标：千问DAU、AI收入占比、Agent任务完成率
    • +
  • 仓位建议：总体控制在10-15%，设置15%止损线
    • +
-
-
- - -
-
-

- 相关股票数据 -

-
-
- -

股票数据更新

-

阿里AI千问、灵光(251124)更新

-
- - 数据文件: FB9D0D78-6EA9-4429-8461-A233333158F3.png - -
-
+ +
+

⚠️ 风险提示：本概念当前市梦率成分较重，请谨慎投资

+

核心观测期：2025年4月（Q1财报+Qwen4发布）

-